Oh. This is a pretty stereotypical character among data scientists. This character thinks software development is all about generating text, and because they know how to generate text, they're automatically considered an expert. But they know nothing about the software lifecycle. Working with them is a real pain, especially when they shift responsibility for their "software" to your engineers.
It's an awkward article. To answer why a query is slow you need a bit more details than just the query. Also, I reread about timeouts and didn't get it, what was the database, whether it was a database issue, how it was related to migration.
The only information I could extract was that the company made bad architectural decisions, believes in ORM (looking at the queries, there are many doubts that the data layouts in DB are adequate) and cannot clearly explain situations. But this is only interesting to their candidates or investors.
It's a terrible post. What it suggests is to turn your head off and follow overly generalised principle. I guess when somebody invent yet another acronym it is a red flag.
Data has its own life cycles in every area it passes through. And it's part of requirements gathering to find those cycles: the dependent systems, the teams, and the questions you need to answer. Mindlessly adding fields won't save you in every situation.
Bonus point: when you start collecting questions while designing your service, you'll discover how mature your colleagues' thinking is.
> Spring Boot gives you a set of dependencies that all work together.
But spring boot deps is infamous meme.
> Then you don't have to spend time messing around with things like OAuth and authentication
Yeah. The funny thing is reality is quite complicated and spring supports a lot of (almost) documented cases. But 99% javaspring developers do not care. I met quite a lot of experienced devs and only 2 of them know how to optimize application start or which errors Kafka wrapper would not retry and so on. Half of the non-default situations are solved via reinventing the wheel because of a lack of understanding of nuances. I can't say people are dumb, many of those devs are smart. I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources.
> I tend to say that ultra-framework kills people's expertise and in the long term hardly saves resources.
You can use as much of Spring or as little as you want. Don't want Hibernate? Use JDBC template.
I have noticed that people who don't use a framework, just end up inventing their own bespoke framework, which unlike Spring, is not documented and has no help available online.
Otherwise intelligent devs assume they can do a better job without all the "complication" and "bloat", but then just end up with homegrown unmaintainable crap that does half of what the frameworks offer for significantly more effort.
> all the "complication" and "bloat", but then just end up with homegrown unmaintainable crap that does half of what the frameworks offer for significantly more effort.
I don't see how you deduct the conclusion of reinventing wheels is the only solution of overcomplex and far from ideal frameworks. But you can categorise this deduction also.
Agree. I have seen same thing where many people maintain a home grown crap called kitchen and think they can do better job than getting ready meal from restaurant.
There is a huge difference between no value and default value. I had plenty cases where I needed to distinguish them because absent value is a violation of a contract. Defaults are not a solution.
And more. Defaults bring their own problem. Chosen values are neutral only for some operations. The most simplest case - int default value is 0, but it kinda "works" only for sums. With nulls you'll get an error in production. With defaults discovery of the error is postponed even more. It's literally the same as making up values ignoring clients will (and this decision even not ours but designers of the lang).
Defaults are implicit. It's simplifies mistakes due to human factor.
As far as I understand the backslash is a mark of a variable. The problem that it looks like the escape symbol and this is really confusing. What about another symbol? #,%,|,<...
Of course, $ is ideal because it's already everywhere and familiar.
I guess a typographer of a font designer would be helpful to find a good solution.
> As far as I understand the backslash is a mark of a variable. The problem that it looks like the escape symbol and this is really confusing.
No, it is the escape symbol and works just like the escape symbol because it is the escape symbol.
The escape symbol \ means that whatever follows should not be treated literally but interpreted in some special way. So "\n" means "not the letter n but rather a newline", and "\u1234" means "not the letter u followed by the digits 1, 2, 3, 4, but rather the unicode character U+1234". And in exactly the same way, "\{...}" means "not the opening curly brace followed by some stuff and then a closing curly brace, but rather special semantics for the expression (not variable) within the curly braces".
> Of course, $ is ideal because it's already everywhere and familiar.
It is already everywhere, including in existing Java strings in existing Java code, and the semantics of that existing code must not change. The very fact that it is already everywhere means that it is not ideal in the context of retrofitting this feature onto Java.
