Tachyon Book Club - Designing Data-Intensive Application - Chapter 2

After the introduction chapter, chapter two is first things, first. When talking about data-intensive applications, front and center is the data itself and how it is stored. 

When I first learned databases around the turn of the century, SQL was pretty much the only game in town. Other types of databases existed besides relational ones, but I rarely saw them in the wild.  Only within the last decade did I begin encountering NoSQL document databases, so reading this chapter, which covers several non-relational databases, was an eye-opener.

During the design process, much thought has to be given to not only how to store the data but how the data will be used. Does all the data live together and will be pulled by a key? A Document DB like MongoDB. Is the data a graph like a Facebook friend list, then a Graph DB like Neo4j. No fixed schema? Maybe Document DB, maybe Relational with blobs. Will the data be pulled using an SQL query or MapReduce functions? Do you even need a separate database process/server or can you use a single tenant SQLite3 instance?

There are a lot of design considerations because the database isn't a junk drawer but an integral part of a system that needs to match algorithms and system design.

A lot of performance improvements that I have made in my career have come from reducing the number of database calls (and their I/O), as well as optimizing queries with planners and indices. It affects both back-end and front-end development. You can write the cleverest code imaginable, but if the application spends three seconds retrieving data from the database, your code will seem slow and clunky.

Which database challenges have you encountered in your projects? What hard lessons have you learned?

Clock Web App

 If you have been following the blog, you know I created my own clock using LED strips and an ESP32. The clock runs an HTTP server for programming. A while back I wrote a REST API in Flask to talk to the clock but didn't have a frontend. 

With the help of GenAI, I have created a Vue.js frontend for the API. 

The app lets you create a list of different commands for the clock. In the picture above, the clock displays the time in a 24-hour format, first in red for 2 seconds, then in green for 4 seconds. Other functions include a 12-hour clock, date display, minute and day countdowns (which I used for my wedding!), minute and second timers, and a timezone function for showing the time in a different timezone. I have more ideas for future functions, but I'm not ready to share them yet.

One of my biggest challenges was styling and relearning how to use a flexbox. If you're also looking to improve, I can't recommend Flexbox Froggy enough. I'm still not happy with the UI for the day countdown, as it needs the cardinal date. If you look at the source code, there's a to-do to add a date picker. I'm looking forward to learning how to implement that using Vue.

Check it out over at my GitHub, Clock Vue.js App

Tachyon Book Club - Designing Data-Intensive Application - Chapter 1

I decided I need to revisit this highly ranked and indispensable software engineering book. I'll share insights and questions chapter by chapter. 

The first chapter introduces the three big ideas that run through the book: Reliability, Scalability, and Maintainability. These three answer the question of what is the difference between a coder (or vibe coder) and a software engineer. The answer is that the software engineer creates a product that is reliable, scalable, and maintainable. 

Reliable, Scalable, and Maintainable

A reliable application will be tolerant to hardware faults, software faults, and human errors. All of which are unavoidable. What happens when these errors occur? Are they detected? Is someone notified? Does the software fail in the least disastrously way? Do errors cause the business to lose money or to be liable to legal action? 

A scalable application will be able to handle increased loads or react in a safe way. How is the load being monitored? Should performance  be measured as response times or as throughput? Are there SLA's (Service Level Agreements) or SLO's (Service Level Objectives) at risk of being violated? Can the application handle twice as much business without having to be re-written or put on expensive infrastructure? 

A maintainability application can have features added and bugs fixed without taking forever and costing an entire budget. Most of the maintenance tasks should be able to be performed by junior engineers with a little help and guidance. 

Engineering

Engineering is the ongoing conquest of complexity. It is an engineer's job to reduce complexity or at least not make it worse. 

Throughout my career I have seen countless hours wasted and engineers burnt out by code that was needlessly complex and opaque. 

When I and other senior engineers join a project, these three concepts, along with documentation and security, is how we judge is an application is well written or not. Next step is talking with Users and Product to determine pain points and overall experience. Make a wish list of things to fix, level of effort, and cost/benefit. Identifying high impact / easy wins is the role of an experienced engineer. Senior engineers should not just be people who have been junior engineers for a long time. Senior engineers need to be able to use their experience and lessons learned to create business value. 

Conclusion

That's the biggest value of this book to me, it's not a cookbook but a way to level up and take your career to the next step. This is why I decided to re-read this book and why I decided to make it the first book to be featured for this book club. 

Thrift Shop Find

The other day while browsing the electronics at Goodwill I found an old calculator for $1. The screen wasn't working correctly but I thought I could fix it. I used the opportunity to dip my toes in the YouTube waters. I present to you Tachyon's first video, enjoy. 

Throw the Coding Interview into the Trash

Despite nearly every company having coding interviews as part of their hiring process, poor developers get hired. Somehow having people write code from college exams in web-based IDEs while a clock is ticking is failing the industry. The reason for that is that it doesn't resemble the everyday reality of a software developer. 

Writing code is such a small part of development having a candidate to do it in a game show environment isn't going to provide much helpful information. Ask a software development what they do all day long and typing code into an IDE would probably be less than 15% of their job. A good developer has been able to look at a code base that he hasn't written, gain a working knowledge of what it does and how it does it, and somehow make a change without breaking everything. 

I don't have any official data but I am willing to bet that 99% of the time that code change is not inverting a binary tree in under thirty minutes. 

According to Frederick Brooks' inescapable Mythical Man-Month, the average developer spends half of their time doing some kind of testing. How many coding interviews involve writing a unit test? Has there ever been a coding interview that asked a candidate to dig through an APM or log aggregator to find the reason an API call is failing? Instead of pulling a hard question off of LeetCode, could we just give a candidate several hours to fix a failing Maven build and get better hiring decisions?

Enough complaining, what is the solution? What is the NFL Combine of the Software Development world?

It's the GitHub Open Source Pull Request. 

The biggest poorly kept secret in the software world is that also every commercial software product relies on a myriad of Open Source Software and the second biggest poorly kept is how overworked and underappreciated Open Source contributors are. 

Critical OSS projects, like log4j, have hefty backlogs of bug fixes and security issues. What if we could help address those issues and improve the hiring process? 

It begins with the hiring manager selecting an appropriately sized and difficult fixes for OSS that the company depends upon. The candidate would have the opportunity to read requirements, learn a code base, follow a build and testing regiment, and conform to a submission process. Ultimately having a group of their peers accept the PR. 

The standard interviewing process often produces little to no value. The code is thrown away as no one needs a solution to a non-existent problem. The PR Test creates actual value and that value is not owned by the hiring company so there is no awkward feeling of exploitation. Whatever happens with the job opening, there will still be some value created and released into the world. 

Imagine if log4j was fixed by a candidate before it was exploited. Imagine if developers had an intimate understanding of the libraries they use because they were part of the development effort. Imagine finding out the guy who can solve the Towers of Hanoi in 5 lines can't solve a simple bug without re-writing several modules from scratch? 

After the PR test, in the follow-up interview questions should be asked about challenges and design decisions. This helps gain insight into the candidate's thought process and also an indication if they actually did the work themselves. 

There is one missing piece though, the acquisition of new knowledge. Pick a topic that the candidate is unfamiliar with and give them a week to learn it. A thought exercise in an interview could ask the candidate to use the topic in a hypothetical problem. Not a pass/fail but doesn't provide insight into how the future employee could be directed in their professional development. Pro tip: people can learn how to learn better. 

Better developer interviews lead to better hiring decisions and better professional development. For an industry that believes in better efficiencies and less waste, that should be reflected in the hiring process. 

Multiple Versions of Java

Java is a very popular language for application development for many reasons, including speed and portability. Java applications are compiled to Java bytecode which is in turn run by the Java Runtime Environment, more commonly known as the JRE. To avoid problems from the JRE not being installed or the wrong version being installed, many applications install their own copy of the JRE in their own folders. 

There are many problems with this approach including 

• never updated to fix security patches
• may be many years out of date with many known security issues 
• almost guaranteed not to be configured to be secure

Another case is believing that you are safe from known java vulnerabilities because you keep your JRE up to date. However, malicious code or a malicious actor can use an older, insecure JRE residing on your machine that you're unaware of. An analogy would be a heavily secured front door but an unlocked window. 

The solution begins with independently installing the latest version of the JRE SE 8 and if possible applying the STIG. The STIG can be found here at STIG Viewer. Even if you don't apply the STIG you should still set up deployment.config and deployment.properties files as detailed in the STIG.   The next step is to locate all versions of the JRE by searching for the file 'java.exe'. For each 'java.exe' run 'java.exe -version' and record all the locations and versions (1.8 is version 8). For example, the Arduino IDE comes with its own JRE located in 'C:\Programs Files (x86)\Arduino\java\' and the version is 1.8.0_191 which is Java SE 8 Update 191 and was released on Oct 16th, 2018. As of Jan 10th, 2021, the latest version is Java SE 8 Update 271. You can find the 234 CVE's associated with Update 191 at the National Vulnerability Database.

If you find versions 9, 10, or 11 you may need to install JRE SE 11 as versions 9 and 10 are no longer supported. Anything later than 11 install the latest version of the JRE. Some Java 8 programs don't work with later versions so that is something to be mindful of. As of January 2021, only the Java 8 and 11 JREs have long-term support and therefore should be used if possible. Further information is at the Java Release FAQ page.

One by one, back up and delete the java folders, testing each application as you do so. If the applications don't work, it may mean they need a specific major version e.g. 8, 9 , 10.

Another possibility is that the application needs not just the JRE but the Java Development Kit (JDK) as well. The JDK includes tools to build java programs including javac.exe which is the java compiler. If it does, then there are many more security more considerations. 

If the system does not have strong application whitelisting then having the JDK on a system allows the user to compile java source code they have written, but has not been evaluated,  and run that java code on the system. In non-development environments, systems should not have the JDK (or any other development kit) kit installed useless under extraordinary situations. That is a topic for another post and another time. 

Out-of-date Java runtimes are a large and common security risk on a PC but the preceding steps should make having Java on your machine much less dangerous and more manageable. 

Clock Update

Until this week, the clock was programed by curl'ing octets to the web server on the ESP32 controller. I decided that I wanted a REST API interface to the clock but I didn't want to implement it on the ESP32.

Since I've been trying to get better at python, I decided to put together a python app for it, found a good REST API Python Tutorial and got to work.

It took most of Friday night but it was a great success. This afternoon I built a Docker image for it and now I can run it on any random raspberry pi I have on the network.

If you're interested in the code, it's on my GitHub:

ClockRestApi on GitHub

Next step is a React app to talk to the REST API and maybe even a phone app based on that.