51–60 of 121 posts
the react module bloat example is not a fair one, the recommended way to start a react project isn't to use create-react-app. other methods are more streamlined. but then again, the deprecation of create-react-app perhaps proves the point that updates create problems.
It's not anymore the recommended way and last I checked it's not really being maintained as much as other ways, but for quite a while, it was the recommended way.
Earlier quoted context omitted.
Apache is stable for wrapping mixed services, but needs a few firewall rules to keep it functional (slow loris + mod_qos etc.) =) Ubuntu LTS kernels are actually pretty stable, but containers are still recommended. ;)
That's fair! Honestly, it's kind of cool to see how many different kinds of packages are available for Apache. A bit off topic, but I rather enjoyed the idea behind mod_auth_openidc, which ships an OpenID Connect Relying Party implementation, so some of the auth can be offloaded to Apache in combination with something like Keycloak and things in the protected services can be kept a bit simpler (e.g. just reading the…
Gets rid of 99.999% of problem traffic on APIs.
It is the most boring thing I ever integrated, and RabbitMQ has required about 3 hours of my time in 5 years. I like that kind of boring... ;)
Because of this, in the JDK we've adopted a model we call "tip & tail". The idea is that there are multiple release trains, but they're done in such a way that 1/ different release trains target different audiences and 2/ the model is cheap to maintain -- cheaper, in fact, than many others, especially that of a single release train. The idea is to realise that there are two different classes of consumers who want dif…
Because of this, in the JDK we've adopted a model we call "tip & tail". The idea is that there are multiple release trains, but they're done in such a way that 1/ different release trains target different audiences and 2/ the model is cheap to maintain -- cheaper, in fact, than many others, especially that of a single release train. The idea is to realise that there are two different classes of consumers who want dif…
A feature I've wanted for ages, for every OS package manager (Windows, apt, yum, apk, etc.), every language's package manager (npm, pypi, etc.), and so on is to update but filter out anything less than one day, one week, or one month old. And it applies here, too. Now, some software, they effectively do this risk mitigation for you. Windows, macOS, browsers all do this very effectively. Maybe only the most cautious e…
We're being paid to migrate our hardware boxes programmatically to Windows 10 IoT LTSC so that new boxes ship with 10+ years of security. We're still supporting some XP devices (not connected to the internet.) So to anyone depending on us: You're welcome. But let me tell you something: Long-Term Support software mostly doesn't pay well, and it's not fun either. Meanwhile some Google clown is being paid 200k to fuck u…
The fucking up of Fitbit and the rewriting of Wallet are not the engineers' fault. These kind of projects are mostly decided and planned by PMs: clueless and incompetent PMs. For payments in particular it was not even just an incompetent PM, but an incompetent director that saw the success of the NBU Paisa payment in India and thought the U.S. would be the same. The engineers are at most just complicit. Those who are…
No one is paying such salaries for mundane clerical job.
Because of this, in the JDK we've adopted a model we call "tip & tail". The idea is that there are multiple release trains, but they're done in such a way that 1/ different release trains target different audiences and 2/ the model is cheap to maintain -- cheaper, in fact, than many others, especially that of a single release train. The idea is to realise that there are two different classes of consumers who want dif…
Is this any different than the LTS approach Canonical and others take?
Even some JDK vendors can't resist offering those who want the comforting illusion of stability (while actually taking on more real risk) "tail patches" that include enhancements.
"In my eyes it could be pretty nice to have a framework version that's supported for 10-20 years and is so stable that it can be used with little to no changes for the entire expected lifetime of a system." This is what applications used to be like, before the web and internet hit and regular or even push updating became easy. It was simply so difficult and expensive to provide updates once the software was in the cu…
Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too.
Because of this, in the JDK we've adopted a model we call "tip & tail". The idea is that there are multiple release trains, but they're done in such a way that 1/ different release trains target different audiences and 2/ the model is cheap to maintain -- cheaper, in fact, than many others, especially that of a single release train. The idea is to realise that there are two different classes of consumers who want dif…
Earlier quoted context omitted.
> Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too. The internet has normalized poor QA. The bosses don't give a shit about QA anymore because it's so cheap to just push out a patch. I mean just look at old video game magazines that talked about the software development process: the developers would test the hell out of a game, then…
I never worked on games, but I did do a streaming video app for PS3 in 2010, during the time period when it was arguably the best media center box available. Working with Sony (SCEE) on this was eye opening how their QA process was set up. Essentially you formally submitted the compiled app (C++ and Flash!) to them, and then tickets would come back and you'd have to address them. QA was a separate org so you never re…
Luxury! With Nintendo you'd often get only one ticket. Any further bugs would cost you further submissions, and months of slippage.