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.
To some extent I think this is an "if all you have is a hammer..." situation. Relational DBs are often not a great fit for how contemporary software manages data in memory (hence the proliferation of ORMs, and adapter layers like graphql). I think it's often easier to write out one's relations in the data structures directly, rather than mapping them to queries and joins
To clarify, as I think some people have misunderstood: we used an existing library called bknr.datastore to handle the "database" part of the in-memory store, so we didn't have to invent too much. Our only innovation here was during the Expand phase, where we put that datastore behind a Raft replication.
> 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.
I dunno about the GP, but it's a JPL guideline to never use dynamic allocation after initialization. So it's not unthinkable. I'd suspect that many microcontroller programs might have to be really careful about using the heap just because they just don't have the memory to allocate that much.
https://www.perforce.com/blog/kw/NASA-rules-for-developing-s...
It's pretty easy in a lot of embedded applications to basically only have objects that live forever or are allocated on the stack. I usually aim for zero heap at all, and just have statically allocated objects for the 'forever' set (which makes it easier to see what's using memory). If you're careful you can also statically work out worst-case stack usage as well and have a decent guarantee that you won't ever run out of memory. If there are short-lived objects, a memory pool or queue is usually the best option (though at that point you do invite use-after-free type errors and pool exhaustion). I would say with this style it's extremely rare to have memory safety issues, but it's also not really suitable to a lot of applications.
Nobody knows if the author checked the commit graph, which is really where you are expected to go if you want to know why it was needed. Maybe it turned up nothing, we will never know.
The commit graph alone? That’s gonna be missing a ton of context you’d find by reference, while doing a bisect to compare the previous reference graph, and taking notes which become so self referential they never terminate. On the bright side, now you’ll solve the halting problem!
Never specifically heard about this terminology until now, but after looking, yeah, I can see why ppl prefer 'artificial' keys to natural ones.
From the animal shelter example, for people it uses email as the 'natural' key, which immediately runs up against 1,2,3 and 7 in https://beesbuzz.biz/code/439-Falsehoods-programmers-believe...
"Natural Key" actually refers to column(s) already available in the dataset you are turning into a row that is unique by row, and thus a candidate for being the key. (Subject to all the normalization, etc.).
An artificial key is a column of made-up data added to the rest of the column. It has no use other than to provide uniqueness. In most cases there is already a unique candidate key in your data.
"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.
totally agree with you. was just pointing out a statistical quirk I thought added value to the discussion.
I'll even retract my point that the US maths education system isn't failing as a whole. When two demographics (30% of the country and growing) are being left behind by the system, then the system is failing as a whole. I really hope to see this change in the future.
> 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.
