Tehdasi

Hmm, but the problem with having in-memory objects rather than a db is you end up having to replicate alot of the features of a relational database to get a usable system. And adding all these extra features you want from those dbs end up making a simple solution not very simple at all.

> They then claim that pure "Scrum" or "Agile" has never been implemented anywhere.

They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.

Basically, yes. A shader is basically a function which passes in the x,y coords and spits out a color, and this is done for every pixel on the screen.

So a simple shader would be something like (in pseudo code):

function shader( x, y ) { if( x > 0.5 ) return white; else return black; }

would color one half of the screen black, and the other white.

That's the punchline, nobody knows what it does or why it was needed.

"The software serves the business' bottom line period."

Making big assumptions about what the software project here. Given the article was mostly complaining about software developed for developers by developers, I don't think we can blame the suits for this one.

> Agreed. Tweaks: I don't think C++ is going to be relevant for much longer, Rust solves the problem space better.

I would say that in the domain of game development C++ (which is where I'm guessing that most new C++ development is done) has such a moat that Rust in it's current form will not be able to displace it.

I'm sure in every educational system you can use some form of metric to exclude low SES students and conclude that the system isn't behind or failing.

> Rules are rules are rules, and they must be followed,

Contra, "rules" are only effective when they are enforced, and when push comes to shove, most of the keepers of the rules will just discard them when it gets in the way of things they really care about.

Getting the enforcers of stupid rules to waive away rules so things can get done is a valuable skill in anyone's tool chest.

In the article's case, the teacher was being a pain. He didn't consult the team when the disqualifying issue was found, nor did he consult with the TSA to clarify or get an exemption from the rule. The real lesson is to avoid or work around these types of people in any endeavor, they don't want to work with ppl to advance the cause of their organisation, they just love their rules.

> Even they will carve out some niche and pretend (even to themselves) to be doing useful work. ... You'll find the odd developer that's maintaining some internal app by themselves.

In my experience, internal apps need far more love. Maintaining internal apps is far more useful than most 'real' work, just because it can be a multiplier on so much other 'real' work.

Tangentially related, but I remember reading years ago a piece from a graphics driver developer (nvidia maybe?) that one of the reasons why the opengl driver was slower than their directx driver (I believe) was that the structure of OpenGL was such that you had to put a massive switch in the code which really hurt performance.

> And they value engagement over content quality, which is the entire reason comment-tree/vote-based systems have been pushed heavily over web-1.0 threaded forum discussions as well.

While they certainly do value engagement over quality, I suspect that the systems are put in place because they don't scale in terms of manpower, and they don't trust their users to do formalize the structure of the site.

Still has the issue with screwing up mechanical objects. In their demo checkout the wheels on the skateboards, all over the place.