MeIrz.net

See Randomness

Don’t see purpose where there isn’t — Paul Graham / Greek

Radon Test – Don’t Waste Money in Ontario

Recently, I started worrying about radon exposure in my house. So, after a quick trip to Home Depot, I picked up a short-term radon test kit for about $20. The clever marketing got me—I thought I was buying a complete kit. Well, turns out I was wrong. To actually get the results, you have to pay another $40 for lab analysis. Lol, “paid envelope included” – yeah, sure, the envelope is free, but the test results aren’t!

When I got my results back, I was horrified—radon levels were almost four times the recommended limit. Naturally, I wanted to retest before jumping into any drastic (and no doubt expensive) solutions. But spending another $60 on another test? No thanks. So, I started researching my options.

Turns out, instead of buying one-time test kits, you can get an electronic radon detector for around $150. A much better option, especially if you want to test multiple locations. Sure, you can find cheaper ones, but who knows if those cheap Chinese knockoffs actually work or just make you feel better? So, my thought was: either buy a proper one or nothing at all. But then I wondered—do I even need to buy one? Can I rent instead?

Do NOT Buy or Rent If You Live in Ontario!

Here’s the best part: you can borrow a high-quality radon detector for free from a public library! Apparently, radon became a big enough concern at some point that the government provided libraries with free detectors for public use. All you need to do is go to your local library, register (if you haven’t already), and borrow the device for up to three weeks.

I found this program through the Windsor-Essex County Health Unit, but I’m pretty sure it’s available across Ontario and possibly beyond. So, don’t buy, don’t rent—just borrow it for free from your library!

Hope this helps!

Email with custom domain

I remember a while back when you could purchase your own domain and connect it to Gmail for free. Unfortunately, that’s no longer the case. However, it appears there is a workaround. It requires some effort and navigating through Gmail’s deep settings, but the option is still available and functioning.

I’m including a link and backup here in case someone wants to connect their domain name to their Gmail account – How to user your own custom domain with Gmail for free.

Backup Download

Inequality and Risk

I’ve been slowly making my way through Paul Graham’s essays, and for the most part, I’ve been enjoying the journey. Recently, I came across his essay, “Inequality and Risk,” and it gave me a few thoughts. As Paul said: “The word ‘essay’ comes from the French verb essayer, which means ‘to try’”, so let me try.

“Like many startup founders, I did it to get rich. But not because I wanted to buy expensive things. What I wanted was security. I wanted to make enough money that I didn’t have to worry about money. If I’d been forbidden to make enough from a startup to do this, I would have sought security by some other means: for example, by going to work for a big, stable organization from which it would be hard to get fired. Instead of busting my ass in a startup, I would have tried to get a nice, low-stress job at a big research lab, or tenure at a university.

That’s what everyone does in societies where risk isn’t rewarded. If you can’t ensure your own security, the next best thing is to make a nest for yourself in some large organization where your status depends mostly on seniority.”
Paul Graham

I understand that startups are incredibly risky—it’s a fact. People investing in startups also take the same risk as founders, or perhaps even more. So if the reward isn’t worth it, then investment—and therefore startups—won’t be worth it, which means development stagnates. I agree with this argument.

But here’s my question: does progress and development only happen with big rewards? Paul says it isn’t about the money but about security. There are different ways to achieve security: one way is to make lots of money, and another is to get a secure job—a low-risk, low-stress position that’s stable and reliable. So if there’s no risk and no reward, does that mean all brilliant minds would gravitate toward secure jobs in big companies, research institutions, or government?

What about Albert Einstein? He made it. Now, for the sake of argument, what if security were already provided? Let’s wave a magic wand and imagine you receive enough money to live well. Wouldn’t you then want to dedicate yourself to what you do best—perhaps to development and innovation? Maybe one could be driven purely by a desire to innovate, rather than by the promise of big rewards or security. Not everyone becomes a doctor just to make loads of money. Some people genuinely want to help others and improve lives. Shouldn’t pure curiosity and the desire to improve be enough motivation?

I get it—there’s no magic wand. There’s resource competition. Effectively, this is all about security and resources: if you don’t secure yours, someone else will. It’s funny (and sobering) how quickly the argument can devolve back to a Stone Age-level mentality—it’s either you or them. But that seems to be what Paul is describing in his essay. We need inequality and risk to drive development and stay ahead, which in turn allows us to secure and gain more resources.

I’m not saying Paul is wrong, and I don’t claim to have better ideas. I’m just pointing out these dynamics and wondering out loud if there’s a better way. Ultimately, it might be the only way—our technology, biology, and language may simply be inadequate for any other existence.

The word “essay”

The word “essay” comes from the French verb “essayer”, which means “to try”. An essay, in the original sense, is something you write to try to figure something out. This happens in software too. I think some of the best programs were essays, in the sense that the authors didn’t know when they started exactly what they were trying to write.
Paul Graham

The Chronicles of the Fallers

The last time I picked up a Peter F. Hamilton book was about a year ago. Unfortunately, Misspent Youth wasn’t very impressive compared to the rest of the Commonwealth Universe. However, it gave me a goal: to finish all the books in the Commonwealth Universe. Jumping ahead, I must say: I love the Commonwealth Universe. It might start slow with Misspent Youth, but it picks up steam quickly in the following books and doesn’t stop until the very end.

The final series, The Chronicles of the Fallers, consists of two books: The Abyss Beyond Dreams and Night Without Stars. The story takes place both within the Void and outside it, recounting the tale of humans trapped with a highly hostile alien race and their desperate struggle to survive. The author masterfully weaves an intriguing story about a society that once thrived on advanced technology but is forced back to 21st-century tech levels as it attempts to return to the Commonwealth—all while fending off the Fallers.

The series brings back two main characters: Nigel Sheldon and Paula Myo, who both work to rescue humans from the Void and the Fallers. Hamilton expands on the inner workings of the Void, giving the story an exciting twist while managing to keep the Void series on its own unique path. Additionally, he delves into how the Void’s mechanics became so convoluted and expansive by the end of the Void series.

I enjoyed The Chronicles of the Fallers immensely. It connects beautifully with the previous books while developing a new, exciting storyline. The entire Commonwealth Universe is a sublime experience, and I wish Peter would continue working on it, but otherwise, it is a great place to stop.

I know I haven’t discussed much of the plot, but I feel I wouldn’t do it justice. The Chronicles of the Fallers must be read as a sequel to the earlier stories. That way, you’ll be fully immersed in the experience. If you enjoyed the previous books, you won’t be disappointed—I certainly wasn’t.

In a nutshell:
+: Well-written and easy to read
+: Continuation of the Commonwealth Universe
+: Old characters in a new setting
+: New and exciting storyline
+: A wonderful finale to the entire universe
=: Excellent books, but I highly recommend reading them only after finishing the previous series

Title: The Chronicles of the Fallers
Author: Peter Hamilton
Cover:

The Software Architect Elevator

I never read books about architecture or architects, and reading this book wasn’t my idea. However, once I commit to something, I see it through. I purchased the book a few months ago, new, for about $66 (Canadian dollars). I’ll come back to the price later. The book itself is relatively small and short, a bit over 300 pages with a well-sized font, ample space between chapters, and the smallest page area I’ve ever seen in a technical book.

I’ve never held an architectural position, and in fact, I have a fairly limited understanding of an architect’s role in the first place. With over a decade as a software engineer, I tend to see architects as people to avoid whenever possible, as they often say “no” to technical or design proposals more than “yes.” Granted, software engineers can be overly eager to make unnecessary changes or introduce new shiny tech that ends up causing more problems or becoming redundant. But to this day, I only approach an architect when all other options are exhausted and never with new ideas or proposals.

“It is often easier to ask for forgiveness than to ask for permission.”
Grace Hopper

Given all of the above, expressing an opinion on this book is challenging, as I have nothing to compare it to. However, I’ll share my thoughts and feelings about it

The Good: The book is easy to read and understand. The author does not waste time stretching out discussions unnecessarily. The list of topics is solid and covers many critical areas of any IT organization. I found a few nuggets that resonated with me, such as automation, standardization, version control, diagrams, and feedback. While I have minor disagreements on automation, I generally align with the author and hope modern IT organizations follow these ideas and recommendations. The book also includes plenty of references to other materials, books and movies.

Ugly bits: While the references to other resources are appreciated, there is an underlying irony: if you’ve read some of the books mentioned, you likely don’t need to read this one at all. Kent Beck, Robert C. Martin and Martin Fowler, for example, provide enough practical knowledge, discussions, and examples that render many subjects covered here self-evident and redundant. Furthermore, while the book covers a broad range of topics, it often lacks depth and detail. It feels like reading an abstract with a bit more substance; the subjects are clear and touched upon, but there’s little practical detail to learn from. It feels like a lot of knowledge but practically little comes to fruition.

The Bad: The author frequently explains concepts through analogies, drawing from non-tech areas. While analogies can be effective, some of these were poorly chosen. Occasionally, the analogies were overly simplistic; at other times, they were unnecessarily complex. In rare cases, the analogy was worse than the technical explanation itself. For instance, the author used forensic/police sketch artists as an analogy for architectural mapping/diagrams. This was frustrating—it felt irrelevant, and I have no interest in, nor do I understand, police work. Another annoyance was the inclusion of URLs for diagrams in a printed book. Why not print them? The chapter on diagrams seemed interesting but ultimately uninspired, as if the authors added just enough content to make it feel important but not enough to fully explore the topic or provide more examples. I found it perplexing that the book relied so heavily on unrelated analogies, considering it isn’t targeted at novices. Surely, any software engineer or architect reading this book would have a baseline understanding of IT. The author could have used this space to provide more detailed discussions and practical examples instead. Lastly, the book’s treatment of hiring and staffing was minimal. While it mentions the importance of interactions across organizational levels, it barely touches on better hiring practices and only in passing. It’s ironic that the author can talk about communicating between the “engine room” and the “penthouse” but neglects to elaborate on Human Resources.

So, what’s the verdict? Let’s go back to the $66 price tag. For that amount, I expected at least 400 full-sized pages of deeper, more practical knowledge. I’m not sure who this book is for. Is it for the ivory tower architect who lost touch with tech a decade or two ago? Or for the new architect who has only heard of Git, pipelines, and containerization in passing at a conference? The book isn’t bad, but I can’t say it’s good either. Would I buy it again? No. Would I recommend it? No. You could gather the same knowledge by locking yourself in a room with YouTube for 10-20 hours and watching IT conference talks by top industry architects. I would give the book a green light for $20, as it is short and has a few valuable nuggets, but not for $66.

In a nutshell:
+: Easy, fast, and short read
+: Covers various relevant IT topics
+/-: Includes many references and broad topic coverage
-: Heavy reliance on analogies, not all effective
-: Lacks depth, details, and practical discussion
=: Don’t waste your money. If you can pick up the book for $20 and are interested in the topic, go for it. Otherwise, spend time on YouTube learning from top industry architects for 10-20 hours, and you’ll likely be better off.

Title: The Software Architect Elevator: Redefining the Architect’s Role in the Digital Enterprise
Author: Gregor Hohpe
Cover:

The-Software-Architect-Elevator-Notes Download

Assembly: An Outdated Course in CS

Recently, I had the chance to peek at a university computer science program (at my local university), and I was a bit surprised — not much has changed since my time, which made me feel a bit sad and wonder. You see, I work with young graduates, and essentially, they need to be taught everything. They don’t even know half of the stuff a developer needs to know in order to get or do the job. Mind you, I work for a company that is pretty far from the technological bleeding edge. And even then, most students entering the workforce don’t have enough skills and knowledge for the job, so they have to learn on the job.

There is nothing wrong with learning on the job, however, I do wonder: why do young people pay tens of thousands of dollars only to be taught outdated subjects, skills, and practices? The traditional answer from any CS university department would be, “We are teaching science here…,” but that’s not entirely true. Many of the courses are not focused on science; they are focused on software development. Those courses will teach you how to sort an array in five different languages — that doesn’t seem very scientific to me. Ironically, these are the courses that will get you a job or at least give you the chance to learn on the job, because without that knowledge, no one would even take a chance on you.

Let me pick one course that really grinds my gears: assembly. This particular course is horrifically outdated. Twenty years ago, when I was studying at university, the assembly course was already old and riddled with generations of mistakes that the professor refused to correct. Now, 20 years later, the same nonsense has only gotten worse.

First, the course is taught only in Microsoft Macro Assembly (MASM). So you must get Windows and install gigabytes of software, libraries, and other stuff just to run a simple, one-page assembly code that wouldn’t even add up to a kilobyte once compiled. If you are running Mac or Linux, well, you’re out of luck. The course guide recommends you use virtualization to run Windows and install all the necessary software. The course suggests a couple of alternatives, such as using NASM, which will not be supported or explained by the teacher, or using a Docker container, which is created by students, untested, and once again not supported by the teacher. Remember, you’re paying for this! Isn’t it marvelous?

Why can’t the software be organized in a simple VirtualBox image or, better yet, a Docker container that contains all the instructions, examples, and runs on any OS? Is a student taking this course supposed to learn how to install Windows and set up Visual Studio with all the dependencies? It took me nearly five hours to get everything installed and configured, and I’m no stranger to this. Let me say, teaching students how to install and use virtualization is far more useful and important than teaching them how to install Windows and Visual Studio.

Second, why do computer science students need assembly? Let me be blunt: I learned it, passed the course, and forgot it, never to remember it again. I don’t think an assembly course is needed for a general-purpose computer science degree. There’s no use case. The industry is working towards replacing the C language, and no one even considers assembly for any meaningful work. Yes, there are cases where people are still using assembly, such as Steve Gibson. Perhaps CS students with a cybersecurity focus must know/understand assembly, or perhaps video game developers might find assembly knowledge useful, but for most, learning assembly is a waste of time.

Instead of an assembly course, perhaps students should be taught to use VCS like Git. Git is useful, and its design is fascinating from a CS point of view (graph theory and such). Another useful topic would be build systems, such as Maven. It’s hard to imagine a company that doesn’t use a build system for continuous integration and delivery. Unit testing is another good subject that is both useful and applicable to any language. Process automation is yet another important subject. From a programming perspective, software design, functional programming, and refactoring are much more valuable knowledge than assembly language. In fact, all of these topics could be combined into a highly useful course instead of learning a useless assembly language.

Ironically, computer science programs keep teaching the same old and sometimes flawed material without any regard for the current state of the computer industry. It’s quite interesting to observe that only the professors who have worked in the industry understand this and organize their courses differently — I’ve seen it! But they’re 1 in 10. The rest teach outdated material from papers written 30+ years ago…

The Last Journey

Immortality is not an option, so we must face the music sooner or later. On a grand scale, the life of a person is not very noticeable; thousands of people embark on their last journey every day. Yet, those closest to us feel particularly special. I’ve been told that everyone processes such an event in their own way, and I’m no different.

For some, the journey starts abruptly, while for others, the beginning stretches out, like trailers in a movie theater before the main show. The prolonged ones seem to be the most difficult. Horrible pain and suffering, without even a glimpse of hope. Can you imagine being sick—having an endless flu, a fever that never breaks, constant headaches, muscle pain, coughing, and a runny nose? And along with all of this, you know, you understand, there is no getting better. There is no recovery. This will end in only one way. Now, multiply that pain several times over.

Departures are always sad. We miss loved ones, even when they embark on a great journey, yet these departures aren’t typically accompanied by excruciating pain that lasts for months on end. After all the pain, suffering, and goodbyes, the journey begins. So shouldn’t we rejoice that our loved one has finally embarked? Shouldn’t we feel some happiness, at least for their sake? Not for our own selfish feeling of being left behind, but joy for their journey—for their release, for the end of their suffering, when nothing more could be done. I don’t know the right answer. I just feel serene, with a trickle of sadness and joy. In my mind, it is not about me; it is about them, wherever they are now.

Rest now, Aunt Zoya.