For years we’ve seen a trickle of really interesting home automation projects that use the Node-RED package. Each time, the hackers behind these projects have raved about Node-RED and now I’ve joined those ranks as well.
You can get this up and running in less than an hour and I’m going to tackle that as well as examples for playing with MQTT, setting up a web GUI, and writing to log files. To make Node-RED persistent on your network you need a server, but it’s lean enough to run from a Raspberry Pi without issue, and it’s even installed by default in BeagleBone distributions. Code for all examples in this guide can be found in the tutorial repository. Let’s dive in!
If you write software, chances are you’ve come across Continuous Integration, or CI. You might never have heard of it – but you wonder what all the ticks, badges and mysterious status icons are on open-source repositories you find online. You might hear friends waxing lyrical about the merits of CI, or grumbling about how their pipeline has broken again.
Slack is either an online collaboration tool, or a religion, depending on who you talk to. Naturally, it’s accessible across all manner of modern platforms, from Windows and MacOS to smartphones. However, some prefer to go further back. At a recent company hackathon, [Yeo Kheng Meng] decided to create a Slack client for Windows 3.1.
Programming for an older OS, in this case, Windows For Workgroups 3.11, requires setting up a viable development environment. Visual C++ 1.52 was pressed into service in this case, being the last version capable of targeting Windows 3.11. The development environment is run on a Windows 2000 virtual machine running on a Mac laptop. This was chosen for its ability to run 16-bit apps, and its Samba compatibility with both Windows 3.11 and Windows 10 and modern Macs.
There were several challenges to face along the way. Old school Windows simply isn’t capable of dealing with HTTPS, necessitating a proxy to handle the exchange of packets with Slack servers. Additionally, memory management was a hassle due to the limits of the 16-bit architecture. Thankfully, an old programming manual from the era was of great help in this regard.
At the end of the hackathon, a usable Slack client was up and running, complete with garish colors from the early Windows era. There’s a few key features missing, such as the ability to resolve user IDs, but overall, the concept works. We’ve seen [Yeo]’s work with this vintage OS before too. Video after the break.
Does the complexity of modern computing ever get you down? Do you find yourself longing for the old days, where you could actually understand what your desktop machine’s hardware and software was doing at any given moment? You aren’t alone, but unfortunately running a 40+ year old computer as your daily driver isn’t really a viable option.
But that doesn’t mean you don’t have options. [Kostas] writes in to tell us about the “CB2 micro”: a diminutive open source retrocomputer kit that can be built in as little as 30 minutes thanks to its through-hole construction and exceptionally low parts count. When completed the miniature computer is an all-in-one BASIC development platform; just connect up a display and a PS/2 keyboard, and you’ve got everything you need to write you own programs or run games and applications developed by the community. You don’t even need a floppy, as the ATmega644P powered board has enough internal flash to store eight programs for easy access through its graphical menu system.
For many in the audience, a cheap little board that you can assemble yourself and use as a stand-alone BASIC experimentation platform is appealing enough. But thanks to a collection of hardware add-on boards, the CB2 micro can be augmented with some interesting capabilities.
Some are fairly obvious such as adding additional flash storage or RAM, but you can also run the computer on AA or AAA batteries, or add an S-Video port. [Kostas] even explains how to assemble a special serial cable that allows you to network multiple boards together. If you take the plunge and start building your own hardware modules, the sky’s the limit.
Expiration dates for computer drives? That’s what a line of HP solid-state drives are facing as the variable for their uptime counter is running out. When it does, the drive “expires” and, well, no more data storage for you!
There are a series of stages in the evolution of a software developer as they master their art, and one of those stages comes in understanding that while they may have a handle on the abstracted world presented by their development environment they perhaps haven’t considered the moments in which the real computer that lives behind it intrudes. Think of the first time you saw an SQL injection attack on a website, for example, or the moment you realised that a variable type is linked to the physical constraints of the number of memory locations it has reserved for it. So people who write software surround themselves with an armoury of things they watch out for as they code, and thus endeavour to produce software less likely to break. Firmly in that arena is the size of the variables you use and what will happen when that limit is reached.
Your Drive Is Good For About 3 Years And 9 Months
Sometimes though even developers that should know better get it wrong, and this week has brought an unfortunate example for the enterprise wing of the hardware giant HP. Their manufacturer has notified them that certain models of solid-state disk drives supplied in enterprise storage systems contain an unfortunate bug, in which they stop working after 32,768 hours of uptime. That’s a familiar number to anyone working with base-2 numbers and hints at a 16-bit signed integer in use to log the hours of uptime. When it rolls over the value will then be negative and, rather than the drive believing itself to be in a renewed flush of youth, it will instead stop working.
Egg on the faces of the storage company then, and an urgently-released patch. We suspect that if you own a stack of these drives you will already know about the issue and be nervously pacing the racks of your data centre.
Some people love Amazon, while others think it has become too big and invasive. But you have to admit, they build gigantic and apparently reliable systems. Interestingly, they recently released a library of white papers from their senior staff called the Builder’s Library.
According to their blog post:
The Amazon Builders’ Library is a collection of living articles that take readers under the hood of how Amazon architects, releases, and operates the software underpinning Amazon.com and AWS. The Builders’ Library articles are written by Amazon’s senior technical leaders and engineers, covering topics across architecture, software delivery, and operations. For example, readers can see how Amazon automates software delivery to achieve over 150 million deployments a year or how Amazon’s engineers implement principles such as shuffle sharding to build resilient systems that are highly available and fault tolerant.
The Amazon Builders’ Library will continue to be updated with new content going forward.
[Michael] volunteers with emergency services, and sometimes has to monitor radio traffic. Sometimes there’s a lot to review, and to make it easier he wrote a noise gate — think of it as a squelch — to break apart recorded audio into parts. Rust has been gaining popularity for writing low level software, and that’s the language he uses. However, you’ll see even if you don’t know Rust, it is pretty easy to figure out.
For test data, [Michael] took some publicly-available recordings of air traffic control. Using some ready-made audio processing functions and a simple state machine makes the code easy to write.