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.

My New Clock

Necessity is the mother of invention. My apartment building has an indoor swimming pool that I like to swim laps in. Some time last year, building management took down the wall clock that hung at the end of the pool. This drove me to figure out alternatives and since I could see my apartment windows from the pool I decided what I needed was a large clock.

I crack open box of my electronics stuff and start taking inventory. My plan is to use the chips I have to drive 7-segment displays to drive a home-built over sized 7-segment display. Think old school game shows before everything became LCD screens.

I start with a breadboard, add a 7-segment display and a CD4511 7-segment display driver chip, and wire it to a USB battery. Great success as I can display all the numbers I need by changing around the jumper wires.

Next step I hookup an Arduino and control the inputs that way. It looks like I have my successful proof-of-concept.

The first real problem I encounter is how do I build the clock circuitry and it looks like that's going to harder than the display component. Things change as I find out the ESP32 can be used with Arduino IDE and I can have the ESP32 call out to an NTP time server and set its own internal clock.

Now I have the clock and the display drivers all that remains is building the numbers and figuring how how to power thing without burning out my logic chips.

I start my research into different ways to drive large, bright LED displays and I come across NeoPixels RGB strips.They can cut with scissors and soldered in a chain easily. I do the math on how many LED's I need and I order a 100-LED strip from Amazon.

I get the strand in the mail and right away start playing with it by hooking up power and data lines. Nothing happens. This is real bummer, I take out my multi-meter, check power levels, check the connections, everything seems fine. After a while of confusion and frustration I come up with the idea to plug wires into the other end of the strip and everything lights up. I run sample program and it's magical, I ever think I hear music playing (probably just in my head). This will work.

Actual construction begins and the first thing I need is a box to mount the digits in. After some searching and head scratching I decide the perfect box will be the tray from a case of water bottles so I run out to Target late that night to pick up some paint brushes and black paint. After the paint dries,  I cut out paper outlines to size display, mark rectangles with pencil and then start cutting the LED strip into 4 light segments; no turning back now.

Laid out the first digit, cut the lengths of wire, soldered one segment to the next until the whole first 7-segment display built. The moment of truth comes as I mount it in the box, tape it down with electrical tape and plug it in.

And it kind of works. Re-solder some flaky joints and I have myself a device that display any number between 0 and 9. Thirty-two careful wire solders later (not counting re-solders) and I have myself a working clock display.



I finished up by moving the ESP32 and the LED power supply to the right size breadboard and mounting it to the back of the box. Wrote the code in the Arduino IDE and put it on GitHub (https://github.com/tachyonknave/NeoClock_ESP32). Final step was testing it from the swimming pool and it was perfect.

Future plans: Add a flashing dots between hour and minute. Set up a web server to control it over WiFi that will allow additional functions such as 20 second countdown for heartbeat, show the date periodically, timer mode to count up or count down, change the colors and switch between 12 and 24 hour mode.

Added wax paper to diffuse the LED's and significantly improve readability. 

View from the Pool