Not exactly the same but Zipline has been transporting medical supplies in Africa for almost a decade (in the US I think they're mostly focused on food delivery which is more profitable)
https://time.com/5295821/ziplines-drones-are-saving-lives/
To be precise, innovation doesn't mean invention. I never claimed that Ukraine was the first to invent organ delivery, but it definitely keeps innovating in this field.
Anyway, the point is that there is a lot of interesting/innovative going on with regards to drones in Ukraine.
It's neat but pretends to be more innovative than it actually is. BI has already been decoupled from everything else. People use AI to generate Excel and Power BI reports. YAML/XML/JSON - that doesn't matter. AI can generate whatever you instruct it to do.
So yes, a nice and logical development of dbt, but hardly as innovative as the blog post wants to sound. Nevertheless, I think it's a good idea that will be popular in certain circles. Hiring a professional data designer is a good idea - data visualization is very easy to get wrong.
I think I agree, but I'm not sure where Dave is claiming this is a paradigm shift in data visualization?
One of the key claims is actually that it's based on _old_ established visualization patterns from before BI tools were popular, and therefore results in consistently nice charts. The other key claim is just that it's simple and maintainable.
Sometimes tools & products can be useful as just well executed points in the known design space. You can already do all this with AI, but it's perhaps a little bit less nice and less maintainable.
AI can definitely generate whatever you tell it to do, but what to do with that artifact afterwards? If you want it to be reusable it needs to be a well-defined structured protocol/language. What good is a YAML describing a chart if all I can do is to give it back to the agent and say "read this and create a chart from it", the result will be vastly different from the chart you got the first time.
> the result will be vastly different from the chart you got the first time.
AI can generate reusable artifacts including definitions of the data sources, why not? Most BI dashboards are just XML or JSON (or YAML) files and include definitions of data sources (directly or via semantic models). I struggle to see how dbtCharts is different. Yes, your YAML schema is clean and nice, but that's because you're in the early stages :) Once you go through feature bloat, your YAML format will become much more complex.
AI can generate an XML/JSON/YAML definition of a BI report according to a spec and link the data source in whatever form it should be referenced in the file. For instance, here is a skills file for defining data sources (semantic models) in AI-generated Power BI dashboards: https://github.com/microsoft/skills-for-fabric/blob/main/plu...
A smart but wrong path to solve the problem. We need competitive markets that would force corporations be responsible instead of an extra layer of complexity in the already complex consumer world.
I applaud to the author for creativity and I'd be tempted to try (elements of) it in practice next time, but I don't see anything good coming out of it at scale.
I left AWS recently, but I don't think the entire place is a mess. It really depends on the team.
On my team we were expected to work 90+ hours a week, and were told we were slackers if we were unwilling to work Sunday afternoons. But I've heard from others that some teams are a lot better.
Many Amazon teams have had high expectations for work. The stories I’ve heard have largely been around how AI is used, slipping CR standards, and what is funded.
> Startups succeed or fail based on how much customers like the product.
This is in theory. In practice, a worse product with more money and louder marketing easily wins against a better product nobody knows about. I'm sure Paul perfectly understands it.
There are other idealizations I won't comment on, but the whole piece reads like an attempt to nurture an application pipeline for YC rather than the genuine writing I liked in earlier Paul's essays.
Here is an alternative point of view: get your degree and work for a few years. Then go back to university to learn business basics (finance, marketing, management). Start a company in your late 30s, when you know your subject area well and you have an idea how to steer finance/marketing (marketing is much harder that it might seem). Bootstrap or take as little investment as possible until you get PMF. Then scale up without giving away (much) equity.
It worked well for me. It can surely work well for others.
This is a common approach (very close to the norm for the most successful startups and companies I have worked with in my career), but I strongly disagree with this: "go back to university to learn business basics (finance, marketing, management)".
You will learn all of that on the job by the time you make it to Principal Engineer, Senior Sales Engineer, Staff Product Manager, or Enterprise AE in the American/Israeli/Indian and Chinese startup and BigTech scenes and especially in Enterprise SaaS, Cybersecurity, Hardware, AI/MLOps, Infra, and other high domain expertise but high revenue and exit potential heavy segments.
Also, a plurality of VCs in the segments I mentioned above tend to have learnt on the job and later switched to VC after successful exits and/or head-hunting.
If you do consider going back to school - only do a graduate research driven CS, EE, CE, or ECE degree program like Stanford, UIUC, CMU, GT (their online program is as good as on-campus with the right courses), UT Austin (their online program is as good as on-campus), and a handful of others.
https://ukrspecsystems.com/blog/pd-2-uav-tested-for-organ-de...
reply