craneca0

co-pilots tend to be really effective at this kind of migration work. especially once you've got the before and after schemas as types in your code.

That's interesting with the Zillow anecdote. I wonder if the nuance in the title is actually correlated with a difference in behavior/culture/best practices/approach?

agreed on the presence and stickiness of no-code tooling. but in a future where we want to enable LLMs and agents to do as much of that work as possible, a code-first approach seems far more likely to make that effective. not just because agents are better are writing code than clicking through interfaces (maybe that will change as agents evolve?), but because the SDLC is valuable for agents for the same reasons it's valuable for human developers - collaboration, testing, auditing, versioning, etc.

yeah, i've seen large fortune 100 data and analytics orgs where the majority of folks with data engineering titles are uncomfortable with even the basics of git.

“You want to know how to paint a perfect painting? It's easy. Make yourself perfect and then just paint naturally.”

Image caption: "The comet debris consists of a cluster of building-size chunks near the center of the image. They form a 3,000-mile-long trail, larger than the width of the continental U.S."

What am I not getting here? If the cluster in that image is 3K+ miles wide, then those are city sized dots, not building sized. I'm guessing the long tail is not actually in the image?

link: https://www.identrust.com/

Another introductory resource: https://sysdig.com/fascinating-world-linux-system-calls/

Very interesting. I'm not convinced this captures the core value of containers though. Or at least not the only core value. Calling containers an evolution of configuration management tools seems like an oversimplification just to make a point. This may be one aspect of building a micro-service driven architecture that containers make easier, but there are other very important ones. Portability comes to mind. It's not just that you can build your stack once and save it, but that you can then run that stack anywhere, and it becomes much easier to share/borrow bits and pieces of other people's stacks.

The conclusion of that article actually doesn't seem to be that the Hyperloop is technically infeasible - only that the original spec does have issues, and it glossed over those issues.

"I’m not saying that the problems with Hyperloop can’t be solved. Money, time, and talent can solve any problem that doesn’t involve breaking physical laws, but I wouldn’t put my money, time, or talent in the hands of someone who takes me for a fool."

"To be clear though, the point of the OCP is not to standardize Docker, but rather to standardize the baseline for containers. Polvi explained that with an open standard, there can be multiple implementations of the standard. So for CoreOS, it means the company will continue to work on its Rocket container technology, while Docker will continue to work on the Docker container technology."

http://www.eweek.com/enterprise-apps/docker-rivals-join-toge...

What does this mean for rkt?

The new csysdig curses CLI [1] unifies and replaces a bunch of the system debugging tools listed here.

[1] https://github.com/draios/sysdig/wiki/Csysdig%20Overview

Interesting branding. "Rocket" is basically only one letter different from "Docker". That can't be coincidental. Also has opposite implications - taking off vs settling in.

"Three days into joining YC, we decided to pivot. We’d been working on the dating site for six months at that point, and we knew it wasn’t working... Also, I’d read a study that said happy employees are twice as productive as unhappy employees. That was the beginning of AnyPerk."

After all the flak the word 'pivot' has gotten I'm surprised to see it used this way here. This does not seem like a pivot, but rather you just deciding to work on a completely new business. Were the two ideas related in any way? Did anything in the original dating business inform this new idea?