Well, it’s obviously not going to be the iPad that wins in that case

Depends on what kind of generation of MacBook that is. Intel-series? I’m leaning ThinkPad. M-series? It’s gonna have to be the MacBook.

Somewhat impressive, but still not quite a threat to my professional career, as it cannot produce reliable software for business use.

It does seem to open up for novices to create ‘bespoke software’ where they previously would not have been able to, or otherwise unable to justify the time commitment, which is fun. This means more software gets created which otherwise would not have existed, and I like that.

Moving to Kotlin taught me to appreciate the underlying fundamentals in the JVM and the patterns present in Java.

I’d rather not use Java today, though. Kotlin is basically Java but with the best practices enabled by default and the bad parts made impossible at a language level.

The caveat there is that you’re personally responsible to maintain backups of your image catalog when self-hosting.

Not really, it’s not feasible for open source developers to get the kind of access required from payment providers to make it work.

Fwiw, I think Android is starting to get to a good place now with Kotlin, Compose and the MVVM-architecture.

The old days were completely wild though

If you’re just rubber-stamping in code reviews, why even have them in the first place in that case? They aren’t exactly providing you with any mileage at that point.

Elon starting to comment on technical matters was the moment I learned he was actually completely beyond incompetent, since I have some actual expertise on the subject. Right around the time he bought Twitter and commented publicly on its architecture.

This is further evidence to that point

The correct response to any PR that is too large to digest is to reject it and ask the author to split it up.

Android Studio or VSCode usually.

But really, there’s no single best option here - use whatever works the best with you and the tech you’re targeting. The same advice applies for programming languages, libraries and just about everything in tech

Interesting constraint - what’s the motivation, if you don’t mind me asking?

Testing in production rules actually. Use feature flags and monitoring and you’re all good

This is what feature flags are for. You can test in production to your hearts content if you use them!

The hot dog-operator

I was mostly thinking about hand-written tests and manual test procedures, but yeah, fuzzing can help you catch issues as well and you don’t necessarily consciously know about the test cases you put into the system in that case.

Then again, you have to design the fuzzing input consciously so I guess that’s kind of a “what you can think about”-limitation.

Good point regardless, thanks

I use this as well. In fact, I have an instance of VSCode running only for access to the extension library - I do most of my editing in Android Studio, but manage Git interactions and things like Rest Client in VSCode.

A limitation of testing is that you can only write tests for cases that you can think of, and cases you can think of ways to write tests for.

It’s still valuable despite this limitation, of course.

It’s not necessary for Rust, no.

This is only a problem for Python because of a design flaw, one which Rust did not copy.

Ruby has enough syntactic sugar to give you type 2 diabetes honestly.