Android started doing the same thing to app icons many years ago, and I hate it. Luckily there's custom icon packs that help solve this but it's annoying to figure out how to set up on each new phone.
Increasingly UI teams seem to be stopping developing interfaces for humans. Same has e.g. happened to icons in IntelljiJ IDEA, now only usable with icon pack plugins. All these UI teams need to put on mandatory HCI courses or fired.
Readit Newsnpstr commented on How to Bring Back Oddly Shaped App Icons in macOS 26 Tahoe simonbs.dev/posts/how-to-... · Posted by u/Bogdanp
npstr commented on A Pregnancy Souvenir: Cells That Are Not Your Own (2015) nytimes.com/2015/09/15/sc... · Posted by u/Tomte
npstr commented on The Tyranny of Structurelessness (1970) jofreeman.com/joreen/tyra... · Posted by u/rzk
I recommend this essay often to people, especially in a start up. When someone describes their organization as being "flat", it's often a red flag because it means that there are unwritten power structure that newer employees will likely be excluded from.
In Germany it just means it's a bad place to have a career in. Thankfully most HRs will happily advertise it in the job description making it easy to dodge.
Your first example is a case of lawmakers not willing to finish the job moreso than of regulation being bad.
That is like saying "when we write software there are bugs, so rather than fix them, we should never write software again".
Your second example is ascribing to regulation something that goes way beyond regulation.
No, what he says is "when we write software there are bugs, so we should write less software".
I'm sure there is plenty of movement visible on all kinds of bridges. We also know that all bridges will fail eventually, so the real value is having a more or less exact prediction _when_ they will fail, not a "we totally saw that coming" after the fact.
Yeah, "My" is actually pronounced wrong by 99% of all MySQL users.
The SQL part as well, it should be pronounced "squeal".
that team is probably telling a story how someone convinced management to ditch their best in class product which would conquer market share, with a lame cookie cutter version that didn't even validate jwt tokens or something at launch and now they're one of the bottom also-run in the market.
Hehe, the original pitch for this project contained lots of mentions of AI =)
> You'll get it when you make it to true Senior level :)
This and the following lines have so many opinions presented as truisms, it’s difficult to take the poster seriously.
2-4 “senior” devs were spending time on tech-only features without delivering actual end-user / business features. Ookay. Seems like a failure of engineering management, but let’s press forward.
2-4 engineers replaced with 1 “true Senior” engineer, who rewrote the microservices nightmare into a monolith powered by Spring. And he had C Suite backing for this. All’s well now.
I mean, that’s a great result. But it feels like there’s also some great people/motivation backstory we’re not getting. Also, maybe lessons from a one-person monolith don’t apply everywhere, even if that monolith serves millions of users?
You don't have to take me serious to derive value from the post. It's obvious anecdotal, just shares a story. I skipped some of the details to focus on the topic of Spring. But I think I can add some as you have rightly spotted they are missing:
The major problem was imho indeed engineering management of that specific team, which was also swapped out at the same time I was put on the team (which was before we got the buy in to rewrite it). There were actually at least two dev generations of the team building the software before ours. The first one caused the most damage by the demented infrastructure decisions, while the second iteration was not able to successfully challenge that, even though they had the right ideas already. New engineering management was awesome in that they supported devs with most of our radical ideas, but also pulled in resources from other departments to help deal with the largest pain points such as adding Spring Boot quite early in the mending journey, with the heavy lifting being done by an expert from another team temporarily joining us.
Forgive my judgy wordings in the direction of seniority...our org has (had?) an issue where complexity is rewarded over simplicity. Some senior people here all they could do is build something so clusterfucked noone can understand it. Funnily enough, this project was originally launched to replace a legacy system noone was able to (or unwilling to) maintain.
Nobody here was saying you should always write your own framework, which is what your engineers were trying to do. Vert.x is a a low-level framework when compared to Spring, so it doesn't provide much organization for your code. This is betrayed by the fact that there are higher-level frameworks written on top of Vert.x, like Quarkus.
What you are describing above is a skill issue. If the developers are bad, they'll be bad with any framework. As a proof, I can give you dozens of bloated, slow, buggy and hard to maintain Spring projects I've seen during my career. I can also list a bunch of successful projects we've built with Vert.x and a custom framework. At the same time, we also have a bunch of successful Spring projects. This has more to do with the skills of the team involved rather than the framework selection.
But when it comes to selecting your framework, there are good reasons we avoid Spring. Spring shines when it comes to having a bunch of built-in modules for everything: authentication, configuration, dependency injection, monitoring, various template engines and databases - whatever you want. The advantage is that you don't need to spend time investigating and arguing dependencies - they're all right there. It's also easy to structure your projects and to hire developers who claim to know Spring (whether they actually do understand how Spring works is another story).
But Spring has a lot of issues too:
- Performance: This is the main reason we avoid it for most projects. Spring is slow. This appears to be the main reason OP has created a Rust version of the Spring framework. Of course, Rust has less overhead than Java, but there are many Java frameworks that are faster than Spring. Spring is just proudly underoptimized. Almost anything else I could say about Spring or you could say about other frameworks may be subjective or anecdotal — but speed is easy to quantify. If you look at the TechEmpower benchmarks, there is an order of magnitude of difference between Spring and lightweight frameworks like Vert.x and Jooby and even some optimized heavyweight frameworks like Quarkus[1]. If you care about performance you just cannot use Spring.
- Inscrutable Magic: Spring has a lot of annotation-based magic. A lot of Spring enthusiasts like it, since it gets stuff done and reduces boilerplate. But it also makes your framework behavior hard to understand and scrutinize. If you want to know what an annotation does, you can't just click "go to definition" in your editor and look at its source code. You need to find out where all the possible annotation processors are and then read all the relevant code until you find how that particular annotation is processed into generated code or wrapper classes or whatever.
- Security: I beg to differ here. Spring Security can save you from the bugs that you would have if you wrote your own authentication code, but the code that Spring itself brings to the table does not have a very good track record. The sheer amount of CVEs found in Spring[2] is staggering. A lot of is due to popularity and exposure, but this is also due to Spring's desire to include everything under the sun and do as much as possible behind the scenes, with automagic. A great example of this approach is how Spring Actuator used to expose a lot of sensitive endpoints (including a full heapdump endpoint) by default, on a standard path. This needed you to add the actuator module, but a lot of servers included it because this is the standard way to enable health checks in Spring, and almost every cloud infrastructure nowadays requires health checks. The end result is that if you wanted your Spring Boot 1.5 web server to be secure, you'd had to explicitly disable these endpoints[3]. Even with modern Spring versions, the sensitive "/actuator/info" endpoint is still exposed by default.
[1] https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
The performance argument I cannot subscribe to. We did extensive load testing in the past on different products, and the bottleneck in the end was always the DB (or more recently, getting screwed by OpenSSL v3). Sure Spring might not be the fastest in its class, but it's a cheap problem to solve, just fire up more or bigger VMs (as long as you've kept it stateless).
The security concerns about actuator I cannot subscribe to either. Why are your endpoints exposed to the outside by default? Why is the management port reachable from the outside? Why are devs not reading the docs and only enabling the endpoints they need?
The magic annotations part can definitely be a problem. Would recommend to stay away as much as possible and keep that simple. Only use it as a last resort, but boy can it be powerful. Need your own request scope that is bound to transactional commit/rollback? You can have that to for example only send out side effects when the transaction succeeds, or to build transparent caching solutions on request scope.
Considering the difficulty and cost of repairing underground anything, most of which will be there for many many decades, it's never going to be perfect, but there's a lot of resources that do go into improving this.