If you're in trouble and cannot find an answer to a question which goes beyond Stack Overflow...
If you have a not-so-usual solution for your problems but need to justify it to your boss...
If you like to think on your own rather than blindly follow "common wisdom" and "profound truth"...
...then 'No Bugs' Hare on Soft.ware might be the right place for you.
Your mileage may vary. Batteries not included

When architecting a system, it is inevitable to make certain high-level design decisions.

Some of these decisions, if they’re wrong, can lead to the re-architecturing and re-writing of the whole system some months later, so there is an incentive to keep things rather generic. On the other hand, trying to make system too generic is just another recipe to disaster (usually expressed in terms of missed deadlines and unmanageable code).

IT Hares try to describe certain not-so-obvious architectural decisions, and some considerations which should be kept in mind while making them.

Design Decisions, page 1:

Bringing Architecture of Operating Systems to XXI Century – Part IV. First Draft

posted by

Quote: “While L3 kernel can STILL run on MMU-less RAM-constrained MCUs, it provides responsiveness which is comparable to that of multi-stack kernels.”
Another Quote: “multi-coring is essentially a special case of balancing shared-nothing nodes”
[→]

Unchecked Exceptions for C++

posted by

Quote: “‘unchecked’ std::errors are treated as ‘something which should never ever happen, but in practice MAY occur as a result of potentially-recoverable bug'”
Another Quote: “Failing-Fast does NOT mean we should necessarily Fail-Hard(!). In certain (production!) cases, Failing-Fast-AND-Soft IS a substantially better alternative.”
[→]

The Importance of Back-of-Envelope Estimates

posted by

Quote: “trying to optimize out a 3e-7 performance hit is very rarely worth the trouble.”
Another Quote: “With 4S/4U boxes having typical MTBFs of 3–5 years, the next question we should ask ourselves, is "Hey, will we really be able to write software which crashes much more rarely than that?"”
[→]

Gradual OLTP DB Development – from Zero to 10 Billion Transactions per Year and Beyond

posted by

Quote: “to make an efficient representation usable for OLAP – we need to modify our data on its way to OLAP replicas”
Another Quote: “Each of the DB Server Apps is a replica master, but all replica targets are within the same Replica DB”
[→]

Representing The Same Data Structure in SQL and NoSQL (from Classical Codd-style SQL to Key-Value NoSQL with SQL-with-XML and Structured NoSQL in between)

posted by

Quote: “while duplication MAY indeed improve performance – undue duplication also MAY hit performance pretty badly”
Another Quote: “NoSQL will usually call for another denormalisation on top of what we’ve described above for SQL-with-XML.”
[→]

OLTP. Compiling SQL Bindings.

posted by

Quote: “If we’re speaking about millions transactions per day over just a few hundred of different SQL statements – compiling those statements a million times (instead of a few hundred times) will be a dramatic waste of resources.”
Another Quote: “Once upon a time, I observed the largest C++ file in my career – it was a 30’000-line file(!) consisting merely of ODBC bindings (and that was just for 300 or so SQL statements)”
[→]
Copyright © 2014-2016 ITHare.com