On having good examples when learning
At the early 2000s I dropped out from my university studies for multiple reasons, but one of the major ones was a lack of motivation. I was learning theory, tons and tons of theory (and in quite a few cases, already obsolete), with some labs and assignments but usually exercises that were dull and boring. That's why I decided to start working meanwhileI studied (and finally, quitting before finishing the degree), to find that motivation and drive that I was seeking during my studies.
I've since then regretted not finishing, but not because I need the degree or anything like that. I think that a university degree shapes your brain, gives you some pillars over which to build everything else. You can learn about networks, data structures and operating systems on your own, but without the basics it won't be much different from driving a car without knowing how a combustion engine works: you use it as a tool but inside it is a black box. And I feel that in certain areas, it helps a lot to know how things work, not only how they are used.
Going back to the studies topic, one of the areas that I feel could be vastly improved is the examples and uses of each area. Sure I can memorize all the syntax and keywords and rules of ANSI C, but that way of learning C is hard and prone to me getting bored. It's way better to learn each keyword by doing some exercise, and maybe then try to build something bigger, and then something more complex, and so on. At one of my optional subjects I learned some OpenGL basics, and we were given an assignment of rendering a rotating 3D earth (with a single, nice texture). It really wasn't hard to build, but the "wow" feeling of watching that rotating 3D Earth was so great that I wished I had more assignments like it.
As I cannot go back in time and ask my teachers to give us harder but better examples and/or exercises, I'll instead just write a few cases that I came up with.
Operating systems
Learning about how operating systems work I almost only see two choices of the best and most rewarding and practical exercise: either learning MINIX, or directly learning Linux basics.
I was taught Windows NT back in the days and, while interesting on its own, I firmly think you should learn a free and opensource language available to everyone, and then decide and branch to wherever you want to go.
Digital Electronics
Logic gates, multiplexers, EPROMs, high/low voltages... There are lots of logic circuit simulators, but what I would have really loved to see is how to build an actual PC component, like a VGA graphics card. Sounds incredibly complex but simply watch those videos. Less than one hour and it will display a 100x75 32 color image via VGA cable. Simply amazing, and exemplifies that, while reality is way way more complex, the simple scenario is still cool (actually, it is awesome!) and the entry level comes to just knowing basic electronics and logic gates, nothing really advanced.
Computer Architecture
In this subject I did built some basic programs with Assembler, but it is a pity that you get to peek at so many concepts but only grasp them, having to just believe that your computer is simply a much more complex version of what you're told... or use one of those prehistoric 8086 emulators and just visually see all CPU registers and the like. If instead I was tasked with learning how the Nintendo Gameboy handled console hardware worked I would have seen a slightly more complex but still degree-level hardware design, complete with I/O, a rough graphics system, RAM and ROM...
When I learned about the Gameboy internals a few years ago I was surprised that I could understand mostly everything. Its Assembler instruction set is reduced and simple, all the schematics, CPU cycles cost per instructions, interruptions, memory addressing ranges,... everything is published (~ 200 pages of a single PDF reading), and there are lots of emulators (even Javascript ones) that you can use to see it in action and debug how it works.
Compilers
You're learning how a compiler works, how to translate to machine code, building an abstract syntax tree, what's a symbols table, etc., so to me, the best example to properly learn the subject is to build a compiler for a simple language.
This one I actually semi-did: back in the early 2000s we were tasked with building a kinda-Assembler to real Assembler compiler in C. "Transpiler" would be more correct in today's terms, as the initial output was a .ASM, but still a good exercise.
Maths
I wish I knew more maths, but never take the time to dive deeper except for specific formulas. A good example to encourage someone to study them, at least for me would be building a pretty simple software-based 3D renderer, then adding some rough physics. Even if it's just rendering wireframe polygons without textures or colors, something like that would have already been quite appealing. In general anything game-development related ends up touching some area of maths so binding both seems interesting.
So there it goes, I'm pretty sure there are better examples, as mine are way too biased towards the topics I like, but... you can get the idea 😉
Book Review: WRONG! Retro Games, You Messed Up Our Comic Book Heroes!
Review
Title: WRONG! Retro Games, You Messed Up Our Comic Book Heroes!
Author(s): Chris Baker (Author), Matthew Waite (Illustrator)
I picked up this small ~150 pages ebook because most compilation of videogames are "best of": Best Nintendo games, best first-person shooters ever, best strategy games from the 90s... But a book about games that got superheroes wrong? Not only I'm in, I'll probably know one or two!
And indeed I was right: From a purple NES Batman, to a can't fly Superman or un-recognizable super-villains, the book nails it with the (few) titles that I knew, plus a lot more. Written in a humorous tone, stating one or two facts of a game, then explaining why it's incorrect, and filling it with additional details (or a few times, mentioning why despite the flaws the game is fine), I liked the structure, the content (a must to read in a color device like a tablet to appreciate the pictures) and the videogames chosen.
My only complaint is that you will finish the book so quickly you'll want more. A fun recommended read.
ACID, BASE and CALM
Most developers will be familiar with the acronym ACID, which stands for Atomicity, Consistency, Isolation & Durability regarding database transactions. ACID is well known and applicable for single database instances, but cannot be uphold for distributed transactions. Regarding the CAP theorem, it chooses Consistency and Partition tolerance. Building an application with ACID capabilities mostly requires just wrapping critical paths under transactions and properly configuring the isolation level of the database system.
With the NoSQL movement appeared another acronym, BASE: Basically Available, Soft state, Eventual consistency. It provides the Availability and Partition Tolerance from CAP, but eventual consistency requires deeper architectural and even product changes in any system (e.g. your clients can see stale or transitional data, or fail to see recently created data units).
Today while reading about distributed systems and consistency I came across a third acronym, CALM. Apart from the obvious jokes around "keep CALM and ...", while far from easy as the article "Keeping CALM: When Distributed Consistency Is Easy" implies, it is interesting regarding two key points:
- It proposes that "A problem has a consistent, coordination-free distributed implementation if and only if it is monotonic". By reasoning about program outcomes, rather than mutations to storage, and avoiding linearity and ordering, theoretically we can build software that doesn't needs to coordinate at all (with the concept of "confluence" to a final correct result).
- It observes that "Coordination-freeness is equivalent to availability under partition", thereby fulfilling all 3 CAP properties for those cases where problems are monotonic.
So, if we found a solution to distributed agreement, why is not so known? Where's the catch? Well, non-linearity and confluent operations are very hard to implement with imperative languages, they are more apt for functional programming. Up to the point that the theorem authors created the Bloom programming language, with the purpose of build distributed systems software. So here the cost of implementation is as huge as probably requiring a full rewrite of parts of the system (and of course in a functional paradigm).
I left on purpose well-known consensus protocols like 2PC, Two-Phase Commit, and the Paxos family, because they bet strongly on agreement mechanics to achieve CAP, while BASE and CALM propose and/or provide approaches that that "skip" or workaround consensus.
But I wanted to mention CALM also because the ACM article represents an interesting journey on traditional distributed systems problems, with examples using familiar scenarios like a distributed shopping cart. I'd like to keep at hand a list of terms and a few notes about the topic, so this small post does the job.
FIRE (Financial Independence, Retire Early) Misconceptions
I recently came across FIRE: Financial Independence, Retire Early, got interested and reading about it found some misleads and not-so-true claims, not in the theory but in posts and articles about "success stories", and wanted to dump my thoughts on the subject.
Most definitions (sample) include the two critical pillars that support this movement: savings and investment. FIRE is about earning money, then spending part of it to somehow have passive income source(s), so that you don't need to work. To not actively work at least.
And precisely in the "passive" adjective is where I see the problem, because seems to be either confused or just switched with self-employment (probably to click-bait, because profiting from blog posts or related books is an income source too 😉). Let me showcase two examples:
a) Stock Investing: If you invest passively, you contract an investor, a fund or any similar broker that deals with your assets and generates you income. If you actively choose the stock, what to buy, when to sell, check markets, etc., then that's actual work, it's active work. You became a small stock trader.
b) Real state renting: If you invest passively, you buy a house (or more), then contract someone to handle the management (repairs, finding tenants, etc.) for a fee. If you're the one in charge of any problem/repair, even if it's just calling the insurance company, then it's not passive, it's an active job (a property management services company of one). This is easy to notice if you get more work each property you add, if it's passive shouldn't have any effect other than regarding money.
Yes, I've read there are variants of FIRE in which you keep a part-job, but then that's not early retirement, it's partial retirement.
Until recently I had for a few years a small property that I rented and, while it mostly required low attention, when there were issues it did require time and effort, and sometimes totally understand why there exists services that handle these scenarios and wonder if should have taken that path. I didn't just because overall was easy to handle and near my home.
This is just my subjective interpretation, but few things in life are really free.
Freedom to spend your time while earning income usually has a cost, often in the form of somebody taking care of some assets, ensuring an income and dealing with any issue that might happen.
Book Review: The Economics Book - Big Ideas Simply Explained
Review
Title: The Economics Book - Big Ideas Simply Explained (Audiobook format)
Author(s): Dorling Kindersley Ltd (DK)
Continuing with non-technical leaning, I just finished another DK audiobook, this one about economics. Similarly to The Business Book from the same editorial, in around 16 hours of we'll be given a historical tour of economics presenting multiple economic models, theories and ideas (according to the description, around 100 of the those).
Some of the topics we'll learn about are: monopolies, oligopolies, competition, markets, predatory marketing (and other types), economic bubbles, inflation and employment, economic models, rationality, crisis, how banks work and what "bank runs" are... And, as you might imagine, some are not trivial, while others feel simple to understand once properly explained.
Another quite interesting title, of course not a deep dive but neither shallow, probably a good starting point to then focus on the models that appeal. Of course considering that I have no clue about the topic, so I might be wrong, but I felt I learned a lot.
Previous entries