Great suggestion! We haven't yet integrated ESC into Pulumi AI, but it's something we'll be looking into. Great opportunity to really make it easy to get started with ESC.
Congratulations on the release! I have a question about the YAML DSL for ESC. Yaml is pretty convenient and easy to read when there isn't a lot of nesting but it can become unwieldy quickly and hard to make sense of, especially when you are referencing other fields. How good is the linting/intellisense to figure out if you are making a mistake in your references without having to compile?
Agreed that YAML (and JSON) can be difficult to manage at large scale. This is actually a big part of why Pulumi ESC exists, to be able to decompose large YAML/JSON configuration files into smaller logical and composable units.
As you note, intellisense and error squiggles can also help a lot here - both for ensuring references to other environments are correct, and to get checking for your dynamic secrets providers. We’ve added the Monaco editor (from VS Code) into the Pulumi Cloud console to make it easier to offer these features in the very near future.
We also offer a preview pane to make it easy to play interactively validate your environments documents while working on them directly in the console.
Lots more coming for providing an even richer experience working with environments in Pulumi ESC.
I really like Apache Drill. I used it about 4 years ago as an MPP SQL on Anything Engine. Presto took a lot of that momentum away and MapR failed to adapt to the new age kind of meant EOL for the project. I hope someone else picks it up.
1. I'm usually down on dark-mode but this looks clean as hell
2. The JupyterHub integration looks nice! It was mentioned in the article it was the "tip of the iceberg" I'm wondering how hard it would be to integrate with a tool like Observable.
Mike Bostock's notebook here is a great starting point, showing how to import and use mapd-connector [1] in an Observable notebook and then feed its data into a vega-lite chart:
This is a good point. There are lots of interesting possibilities with Observable, especially using the OmniSciDB open-source project for analyses that people intentionally do want to share
It's certainly possible, I guess the bigger question is whether people would be comfortable having a database do an automatic data transfer into a public tool. In the case of this Jupyter integration, it's a Docker image that's running next to the OmniSci database, so it's all within the same network
We have a subscription (For about 3 months) and it's been a great value for us. We order things like bread, some staples for our 2-year-old and some other packaged goods for about $40 a week. Walmart uses DoorDash for delivery in our area and we can usually place an order and have it delivered 2-3 hours later.
One negative aspect of using the service is Walmart seems to have a hard time knowing what will be in stock even a few hours from order. Every order we've done (around 12) has had a missing item due to it being out of stock.
I tried Prime Now, Peapod, and Freshdirect so far. FD is the most reliably good, but there's no same-day delivery, and it's the most expensive. Peapod also has no same-day, often misses items, and isn't That much cheaper.
Prime Now has the same-day, but so far, on three occasions, they've delivered subpar produce I'd never have picked myself, super stale bread, and damaged-during-delivery produce, for only slightly less than the cost of freshdirect. I like same-day delivery of goods, but not same-day delivery of bads.
I worked at 3 walmarts in 2 states over about 7 years. They all had issues with inventory.
Corporate has been trying to fix the issue for years with different technology. They bought into RFID tech pretty heavily but it didn't really work as advertised. It seems the plan was to interrogate tags as they come off the truck since they had readers on both sides of the loading dock. Even with my limited experience with RFIDs I can see that not working. Passive RFIDs are only reliable when you have line of sight. Active and semi-passive tags work far better but they're way more expensive. When unloading the truck you need to deal with box orientation, un-loader's watery bodies, and equipment. Now the readers look abandoned and in disrepair.
Later they re-purposed the Layaway system to assign cases/items to locations in the back room. It was an amazing idea but it's fundamentally flawed in a few ways.
1. Adding and removing items is too slow and unreliable. The portable terminals lose connection or take seconds to process scans. Those seconds add up when scanning hundreds of boxes.
2. Each item/case requires a label that takes time to print
3. Large quantities of unsold special items can fill precious backroom space. This requires hunting for holes to add new, normal items.
4. Lack of time results in corners being cut. Items are not scanned or they fall behind stacks of other boxes and are lost.
Add in theft and items being left in the wrong place by customers and it's not hard to have a seriously messed up inventory.
What I would like to see is a store where all merchandise is kept in the stockroom. Customers scan bar-codes on the shelf or on displays. A team in the back picks the items from inventory and meets the customer at the door after payment is made. Of course that would require a major change to story layouts, staffing, and customer expectations so I doubt it will ever happen.
Walmart was an early adopter of handheld on RF networks clear back to the early 1990s. I worked on integrating support for our database/4GL apps with Telxon and Symbol RF network devices (including portables and wearables) then.
Sears had a line of stores back in the early 90's like that. Everything in the store was a display and you took around a little clipboard. Name escapes me, maybe just a so-cal thing.
The idea dates back even further than that, to the failed but fascinating Keedoozle, the second venture attempted by Clarence Saunders, founder of Piggly Wiggly, after his financial ruin attempting to corner the market in his own stock.
You'd go around the store, your selections would be punched into a card, and at the front your food would be automatically delivered via conveyor belt.
We had the same issue with Walmart pickup, and switched to Target pickup instead. Substitution/stock issues disappeared, and we found Target pickup to be more frictionless.
I really want Walmart to succeed in online delivery because I don't want Amazon to gobble everything.
Recently, I was shopping for a media entertainment cabinet. Its for our upstairs media room, so I wasn't super concerned about it being "nice furniture". I went and checked at our local Walmart and found a piece that would work. Instead of trying to load the 180lb piece into my car by myself, I thought "I'll just order online and have it delivered to my door and take it upstairs in pieces"
When it was delivered I was out and when I returned I discovered they sent me the wrong item (desk instead of media center). Went online to start the return process and the only option given was "return to your local store".
Luckily the desk was only 90lbs, but still it was a chore to load this in a car, drive to walmart, then at walmart there's no flat handtrucks or dollys, so had to wrestle into regular cart to bring to service desk.
They processed the return quickly and had the right media center in stock, but now I was back to square one: How to load a 190lb piece in my car using a standard shopping cart?
By Amazon being a 100% online store, they were forced to develop sane and customer friendly approaches to handling these types of issues. Because Walmart has never had to deal with these things, they are very lacking in handling these edge cases.
I still plan to use Walmart online, but will be very cognizant of what I'm ordering given their return process.
I must say this is the first time I've been really impressed by a client-side, real-time implementation. The API is simple and I can imagine building something real-time without thinking about the translation from one protocol to another like I would with web-sockets for example. I've never written a line of Elixir, but this is interesting enough for me to try it.
I mean, I already 'bought in' to the ecosystem for many other reasons, but these are / could be huge extra reason because 1) they solve problems I'm facing, and 2) the potential popularity might alleviate the mild nervousness I have about investing so much into what is still a very young and small ecosystem. As it is, I still hesitate to use Elixir/Phoenix with many of my clients.
