I think the discussion above is about using cameras to monitor the driver as a means to replace the torque test needed on the wheel, not technologies for outside the car.
What would you like to do with PHP/Laravel that isn't unit testable? Laravel is, from my experience, written in a way that specifically makes testing of most things very easy.
Sounds like this will specifically allow for older devices to continue to work with newer versions of apps. Obviously not everything will work, but it would still be nice to be able to use some old i-device even if it can't run the latest iOS.
I'm glad that they posted a "miss" - but this reads over and over like a sales pitch:
- I created a card in <X> Basecamp
- Someone posted a message in Campfire
- We have our own encryption
- Another message posted in a different Campfire
- Oh, this one uses custom categories!
- Todo's in Basecamp project
I get it, 37signals dogfoods their system. What we don't normally see from other posts is that person/company X posted in slack and made a ticket in jira and then created a todo on their trello board.
I appreciate the explanation, but I don't know what junior-dev would understand most of this. I may be just a web developer, but I couldn't understand most of this. I'd still have to read for 30m to grok it all.
I don't know why it's still hard, but I can tell you, from the perspective of trying to prototype something, I would love to not have to use it just to find out if this functionality I want to build is worthwhile. I don't want to have to create a client, get some keys, worry about refresh tokens, etc. I want to hit an endpoint with an easily accessible token and get some data.
Make it so that the token is only valid for 30 days or something and then it requires moving to OAuth. But for prototyping stuff with curl and bash scripts, it's a giant pain.
How does this compare to Ripcord[0]? Granted there haven't been any new releases of Ripcord in a couple of years, it's super lightweight and mostly perfect for my uses.
The documentation looks better than when I was trying to write some Rust with GTK (2020), when it was basically an output of the C functions that could be called...
This also ignores the overhead of business processes. The dev effort may be very low to switch the (flawed) example of text to database, but the product/project team is going to have to create and maintain stories for it, the qa team is going to have to test it, the documentation team is going to have to update their information (where necessary, of course), the support team is almost guaranteed to get calls about it so they need to be informed, and I don't know about you, but my production data rarely looks like my dev/qa data, so there's the non-zero potential for bugs to creep up in the data migration.
All of that sounds a lot more than "the same" to me.
A lot of what I saw in the demo video looks like workflowy.com with a slightly different UI on it. It feels a little faster than workflowy, so that's definitely a bonus.
Those of us that remember "This page works best in Internet Explorer 5" are shivering at your statement. I love Firefox and use it as my primary browser on my desktop. But suggesting to users that they should use that instead of fixing issues in your site feels bad.
I think "productive" depends on who's paying the bill and whether the uses of it were how the system was actually designed. I don't think that the roots ever had the idea of serving random requests billions of times because that's the entire point of having the downstream servers and DNS caching. I remember a time when directly pinging the root servers was considered very bad practice because you should always be using the downstream... Google's method essentially makes those downstream servers useless.
Near the beginning of the pandemic (May/June '20) I interviewed with AWS, specifically in the Lambda space. Before even speaking with the hiring manager, I made it clear that I wasn't interested in relocation, but they pushed for it anyway. After I reiterated my statement, I was told that WFH wasn't an option, and they moved on to other candidates.
My understanding is that you don't even want to store them as UTC and always store them in the timezone of the user/system that generated the data since you lose some information in the translation from local timezone to UTC - given that the timezone database changes, you may actually want to know that the record created in Fiji before 2022-10-28[1] was stored in DST so that it can be properly converted to the new Fiji time.
The goal of the "meat replacements" that are Beyond and Impossible was never being better for you (from what I recall). It was about offsetting the footprint of raising cattle.
It's unlikely to happen. 10-20 years of use for many of those community generated functions is a lot to break. It may happen eventually, but I wouldn't count on it.
I think that people believe they'll switch out components more than they really end up doing, but in Laravel, you can override things within Service Providers, and then use the built-in dependency injection to get the thing you want.
MySQL historically isn't very good about blocking bad data. Sometimes it would silently truncate strings to fit the column type, for example. It's getting better as time goes on, though.
I love k9s, it's completely changed the game for me. I really wish the keyboard shortcuts and available commands were better documented, though. Figuring out that you have to be in the deployment view (and how to get there) to scale something took some doing.