It feels like this is missing the mid sized company that isn't looking to grow and IPO. There are plenty of companies that just have a product and sell it to make payroll. They're just overlooked in the hustle.
Yup, for the most part you define your own controls! Even type 2 is pretty hard to "fail" if you're serious about security. You're more likely to just get minor exceptions in the report for being sloppy about something.
In my experience this is actually a great thing. Let AI hack away at the agile metrics that it can. Maybe those are the right metrics for AI, and engineers should be focused on building reliable infrastructure and abstractions for that AI.
The description of MUMPS always misses what working with it directly is actually like (at least for me). It feels more like a custom OS than a programming language. Code being stored alongside data so changes apply live in the system, writing schemas and indexes by hand, and the difficulties combining it with other standard programming tools make it a fairly unique experience in 2025.
Given that Apple has really smart people, I assume this design was the right answer to whatever actual problem they were set. My guess - someone noticed a small cohort of potential new users that want this; and the company prioritized the marginal user over the core user base. Maybe there's a cohort of VR users not on iOS yet?
As one of the developers on this project, I'm most excited about the declarative LLM interface it offers as an alternative to chat. Chat is powerful, but (with today's models) I find it to be too open ended for most non-developers to write high quality code.
While I generally agree that it sounds dubious, this argument depends on whether the entropy of the liquid in the pore is lower than the entropy of the vapor in the air in the pore. I could see a highly hydrophilic capillary restricting a vapor enough to where it has better entropy in a liquid state.
If that's true we just need to balance energy, which the cooler does.
I think there's some selection bias. In my experience many folks that work on open source projects tend to lean more altruistic and good natured - so understanding the license doesn't mean expecting exploitation.
In the past I've worked at startups that hired way too many bright junior developers and at companies that insisted on only hiring senior developers. The arguments for/against AI coding assistants feel very reminiscent of the arguments that occur around what seniority balance we want on an engineering team. In my experience it's a matter of balancing between doing complex work yourself and handing off simple work.
When I looked SFO, DEN, LAS, and EWR were all delayed due to weather. Do busier airports end up on this list more for some reason, or is it just really bad luck today?
This is great! I did a similar project a while back to do image processing in a SQL database with pixels being individual records. It's amazing what SQL can do with the right table structures.
I would say Judy is far too pragmatic to fall into the bucket of late 90's silicon valley startups. For example, people talk a lot about MUMPS being so quirky for the Epic operational database, but few people mention that Epic is a heavy Microsoft shop and ALSO provides a reporting SQL data warehouse built on SQLServer.
I've long since moved into startups, but Epic was a great place to learn process and the less technical aspects of enterprise software development. The tech has modernized a lot in recent years, but still isn't transferable quite as easily as other tech companies - but that legacy means it's an amazing place to learn the why behind best practices.
There is a theory that specific shades of colors are difficult to recognize or differentiate unless you name them. I wonder how unique these 100% saturated colors would look without context compared to other colors.
Is this the logical conclusion of the marginal user effect? If your business model depends on growth, you need to keep changing the product to attract new users even at the cost of quality to old ones that are unlikely to leave.
I used this to bootstrap a small community page with a handful of admin users that entered content. The users were technical enough to be comfortable with the interface, but wouldn't have been able to use SQL directly. It saved building out the CRUD interfaces with the ~4 hours a week of dev time we had at the time. It took us a few months to get around to the CRUD interfaces, so it felt well worth it.
I personally try to nudge even my junior team members towards this. I would never admonish them for taking this type of initiative working with me. I WOULD however have some difficult conversations if they thought this meant they could cut corners on communicating with stakeholders or execute on something without appropriate planning or review. There's a big difference between showing initiative and ignoring process that exists for good reason.
Looking at the GitHub project, this looks to be a passion project more than a community driven one. It's great to see a project like that getting some eyes and potentially attracting contributors. If anything, the main website is a little misleading in this regard.
Little technical nitpick - I would have prioritized moving off of a shared-volume sqlite database before introducing a backend message queue.
Cat food dispensers are an interesting product where this trend hasn't quite landed - it's still easy to get a new model without WiFi for roughly the same price. I wonder if the possibility of your pet not getting fed is a line consumers won't cross for convenience features.