HN user

npstr

457 karma

https://npstr.space

[ my public key: https://keybase.io/napster; my proof: https://keybase.io/napster/sigs/1DYMjeTxF3HkRhxXM_0iHIP9wTgJl3Vb-sXCh57AQf8 ]

Posts5
Comments97
View on HN

Seems easy to counter all of this. I study at a German remote university, and they require, next to the front camera, a second camera to record the screen + hands and arms of the student while taking exams, and before the exam starts a complete video of the room, below desk areas, ears, etc. I don't see an angle how to reliably cheat in such conditions, and have seen nothing mentioned by any other student. So I would say it's up to the university if they want to allow fraud like that...they could easily stop it.

What are you basing this on? The announcement literally says the people doing the work want to focus on the work and not the bullshit, so they are firing the bullshit people.

Engineers in particular have expressed their desire to focus their time on engineering, without being hampered by slow process flows, and restore the fast-moving culture that has made us so successful.

Yes, they absolutely are the bad guys, if they are the reason that the Engineers - the ones actually making the product - are unhappy. Did you miss this part of the announcement?

Engineers in particular have expressed their desire to focus their time on engineering, without being hampered by slow process flows, and restore the fast-moving culture that has made us so successful.

I had some RSI at the start of corona from too much home office + gaming, what actually helped was getting a trackball (Kensington Slimblade Pro) for $work tasks.

Tried a Moonlander and hated it. My hands don't work with ortholinear. And I hated having to learn layers and layouts. Besides I have a real job and I use a proper IDE so I need my F keys, I like to use the Home/End/Page Up+Down keys, I learned to use the numpad efficiently, etc. I think most of what is told and sold in ergonomics is snake oil. I don't believe ortholinear is any good for it, and minimizing movement also seems really questionable to me. I'm working with comfortable 30-40 wpm and am still one of the most prolific and productive engineers at $work, typing speed is not important for many jobs.

I would like to continue be able to use regular keyboards efficiently and with little annoyance. Too often I'm traveling and stuck with the laptop keyboard. I have to accommodate Linux ($work), Windows (gaming), Mac (personal projects, open uni). That's already challenging enough to get these have similar shortcuts. I use a keychron K5 pro that supports all OSs. I can work efficiently in all situations, with all OSs, with just a single screen. Having a more specialized keyboard (or otherwise setup, like relying too heavily on multi-monitors), wouid overall surely be detrimental, during the times I could not use it.

What I've learned to avoid pain: Wrists should be straight. For me, a slim keyboard helps to achieve that, flat on the table. Hands should have some room apart, open chest. Small keyboards are bad for that, you'll want a 100% one, or a split. Do some lifting, have some muscles. Try a trackball, you might love it. Switch how you are sitting. The best sitting position is the next one. Get up to think, go for breaks. Don't overly specialize into some local/global optimum that is a moving target over your lifetime. Use defaults. Mostly boring setup with some minor personal tweaks can go a long way.

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.

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.

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.

I can see a lot of hate in the comments about the original Spring Project / Java language. You are absolutely right, it's the worst. Please go away, nothing to see there =)

On a different note though, when I was a Junior, building my first few projects, I didn't get it either. You'll get it when you make it to true Senior level :) Just last year I took over a project at work where 2-4 engineers (including "Senior"s, especially the one who came up with the infrastructure) were very busy reinventing their own framework/platform instead of building the actual product, for about 3 years. They had their own protocols and their own transaction management and two webservers (cause they were trying to use VertX websockets in addition to HTTP but due to a skill issue couldn't serve them from a single webserver) etc etc. What they did not have, was a working product. I got buy-in from management up to C level to rewrite that burning garbage dump. Now, about a year later, after management moved those people off and me in, the product is actually live with all the missing features, has about 50% less LoC than at its peak, and does no longer exist as a distributed stateful microservice agglomeration. Instead it's a Spring Boot monolith. Including Spring Security. It was the first time any of my software got a security bug found by external researchers and only because I did not add Spring Security immediately along Spring Boot because I thought we can go along with the homegrown auth code for a while longer.

Anyways, serious people who have built some serious (web) products will appreciate the battle proven tech that has integrations with just about any other relevant software on the planet and implements production ready patterns for you to immediately use.

If you don't, may I suggest you ask yourself: maybe you've just been building only toy projects, or solving too much leet code problems? Maybe you've only worked on projects meant for your resume or promotion dossier, rather than actually putting a product live to millions of users?

I applaud the Rust ecosystem taking one of the best pages from the Java ecosystem book, although the focus on "lightweight" does not make me optimistic that the author has truly understood what value, and how, Spring delivers.

There is plenty of money for bridges in this country if would stop taking it away from productive citizens that create value and giving it to unproductive citizens that just further reduces willingness to pick up a job. Working full-time vs living on benefits roughly evens out here in Germany, so I fully understand fellow citizens who stop working. Not only that, it justifies giant government departments that deal with determining each citizens needs and generally administering this redistribution that adds absolutely zero value. We need to fix these incentives.

Why not simply use an example that isn't confusing? Many developers, and especially academics, love wasting effort and time on solving issues they made up but that have no real life examples. When using examples that have trivial alternative solutions, it does not help me as a reader to distinguish whether this is a real problem, or something made up.

Idk to me this looks like a modeling issue of the data. There should be a team table that contains team specific data such as the skill level, then these two queries wouldn't run into any problems.

given what constraint 2 says the level is actually a team level, not a player level.

Then it's bad unnormalized data design that is the problem here. If that is a team level, it should be in the team table, not the player table.

Nature does not refactor. There's the laryngeal nerve somewhere in the neck of mammals that has to go around a blood vessel. On Giraffes, this runs all the way down the neck, around said blood vessel, than back up, all that just to connect two places in the upper neck that are inches apart. Evolution writes the ultimate spaghetti code.

More info: https://berto-meister.blogspot.com/2011/08/unintelligent-des...