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

One of the best application I've seen is structured and contextual logging [1]. Combined with implicits, this allows you to require a right renderer or/and automatically get a current state of an execution context.

1. https://docs.tofu.tf/docs/tofu.logging.key-features/

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

The most obvious Nikon problem is the absence of cine lenses (I skip ergonomic because it is a common 'photo camera for video' problem). Of course, you can use photo lenses, but it's so much pain. More flaws and more time.

- Cine zoom lenses must provide a fixed point of focus when you are zooming. This leads to a more complex mechanism.

- Different cine fixed lenses in one project usually must have identical image quality. That is why they are produced in series (for example 'XEEN PRO Cinema Lenses') with the same technologies.

- Anamorphic lenses... They should exist. They complicate lens production because a stable quality (for series) of an aspherical lens can be achieved only from a central part of a large glass.

- Focusing is the process that often requires a separate person (focus puller) and additional machinery (follow focus system). All cine lenses have exactly the same standard focus wheel. There is no such standard for a photo lens focus wheel.

Nikon F has very few cine lenses and has no series of lenses. Nikon Z has nothing. Thanks to the closed very secret, unique, perfect, bla-bla specification of Z mount and zero collaborations with other manufactures.

Lightroom has some critical problems limiting professional use.

* Forced lens profiles. (And more. There are reports of double application of profiles)

* Color and light correction also changes untouched parameters (it's ok but there is no workaround). If you need to do a more accurate job then use C1 or Photoshop.

Looks like ears are unchanged but it's a strong identifier.

https://github.com/Odomontois/Tincat Not exactly you asked for but the only one I know.

> so you never really have expensive context switches

It can be possible only if there are no more "physical" threads than cores. And anyway a switching between async routines on the same "physical" thread requires a switching of routines contexts (go to the memory and update cashes).

It's secure if so was written in description.