

The inverse is true as well for Kotlin being supported on iOS.


The inverse is true as well for Kotlin being supported on iOS.


I think we’re meaning the same thing.


Don’t provide bailouts for neither your manager nor your colleague. Highlight as far up the chain as you can the damage their behavior is having on the business.


Case in point: AI models could be written to be more efficient in token use
They are being written to be more efficient in inference, but the gains are being offset by trying to wring more capabilities out of the models by ballooning token use.
Which is indeed a form of Jevon’s paradox


It’s hardly viable as a temporary step when the time to bring a new one online is 20 years. The economics are already bad today and have been trending to be worse every year, while renewables and batteries are trending in the complete opposite direction.
The time for transitionary measures has passed. Renewables and batteries are here today. All we need to do is build it.
Under semantic versioning, you should really be ashamed of bumping the major number, since this means you went and broke backwards compatibility in some way.


Clearly in reference to
@Service
public class MyPublicService {}


The same as taking over any legacy project applies, really.
Start out with some expectation management - the current state of the solution prevents progress from going fast, and your stakeholders need to understand that.
Then get some tests going, such that you can try to defend whatever value the system has, if any.
Finally, start refactoring as much as you can get the space to do. Repeat until the system reaches your desired state.


Handed to review, handed to maintain, handed to extend?


Portugal is still eastern europe, despite their best efforts


I think we all know it actually stands for One Rich Asshole Called Larry Ellison
In all honesty, the protocols and structs-thing they talk about in Swift-land is the way to go. Interfaces and data classes in JVM-land
Why even use DI if you’re not planning on faking dependencies for unit testing purposes
I managed to organically create a StrategyFactory at work once.
It was a good design, but it felt extremely wrong
For anyone who opened this link in the GitHub mobile app and got confused, make sure to read from the very beginning of the comment thread - the mobile app only shows the very last comments, which cuts out the actual interesting part.
Communal laundry rooms are better for spreading the capital costs among the residents - energy still costs more or less the same on a per-load basis, and it gets charged to the residents in one way or the other at the end of the day.
They’re also successively being replaced by in-home laundry machines. Lots of places offer a communal laundry room, but the residents also have a machine in their homes for the sake of convenience. Some new builds have started omitting a communal laundry room in favour of in-home machines.
A bit of a pity, to be honest. Spreading capital costs is societally good. I say this while having had a laundry machine in-home for the past 10 years (came included with the purchase of the apartments), which I do use and enjoy the convenience of.