optician_owl

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.

That's funny.

- Let's create a new Kafka in rust. Yeah!

- Let's create a Kafka client that's ready to use. Blah.

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 may sound rude, so I apologise.

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.

> 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.

> 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 would. Not because it's something pleasant.

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.

The worst thing - default values as a solution for absent values. What can go wrong with implicit value assignments?!

Capture One.

One off the main problem is a parallax. Especially if there are moving objects in the background and foreground. For example, tree branches or leaves.

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.

I would argue that jdbc API is far more dangerous than string interpolation :)

But I wholeheartedly support the idea of JEP. Scala got several good UX benefits based on the string interpolation (sql and logging).

Does not allow to use a struct field. That's strange.