GT!Blog

Remember the days before everyone had a mobile phone? Although it’s hard to imagine these days, but back before everyone had a mobile phone, public payphones and public phone booths were a massively important part of public infrastructure as a form of primitive mobile telephony for making phone calls. But what about data? Although the first battery-powered laptops came out in the 1983, digital mobile phones did not appear until 1992. In a lot of countries, there was no data equivalent of the public payphone and so you were stuck without connectivity until you could get back to your office or home. In Japan, however, things were different.

Read the rest of this entry »

One of the things that people love talking about these days is technical debt. This is usually treated as a bad thing, as if it would not occur if only we had been more attentive during our design or programming stages, or spent more time getting better specs from our clients. This is then accompanied by a desire to throw everything out and start from scratch. While technical debt certainly can accumulate in these ways, I feel that these discussions often miss the point. A lot of the things that happen that create technical debt are not only foreseeable, they are virtually inevitable in the lifecycle of any code project of just about any scale or complexity. If our current design and programming practices are so fragile that we need to throw everything out and start again after these kinds of inevitable things happen in our code, then perhaps it is time to look at changing how we construct code instead of falling apart once that code has fallen out of some arbitrary definition of elegance. I wanted to write about a few different ideas in regards to this topic, but in this post I want to simply outline the kinds of inevitable changes that I think should be considered as normal parts of the development process and not as technical debt that somehow needs to be eliminated from a project.

Read the rest of this entry »

One of the foundations of computer code is the humble loop. Going back at least as far as the beginning of C in the early 1970s, the two mainstays of loops in procedural languages have been the while and the for loop. Unfortunately, I think it’s fair to say that they also contribute to the kind of complexity in code that can be a source of technical debt. I’m going to look at one of the problems with these loop constructs.

Read the rest of this entry »

One of the topics that people like to talk about is technical debt. However, when you actually get into what creates this technical debt, you find a lot of simple repeating patterns that reduce code readability. So, I decided to run through a pile of them to see if there are any simple fixed. The first one I want to look at is the use of boolean types. Booleans are an extremely useful construct in programming, but they are also a source of hard to catch errors. Here I just want to look at the problems that bools can create, and also propose a set of guidelines for reducing the perceived technical debt they create.

Read the rest of this entry »

The easiest way to understand the current state of encodings is to look at the history of how we got to where we are today. The pre-ASCII days are not particularly relevant, but they are interesting, so I have run through the various encodings that preceded ASCII from a technical perspective here if you are interested. The story of Unicode really starts with ASCII. Note that since Windows and UNIX are the only two types of operating systems of interest to most modern programmers, I’m only going to discuss them. (Linux, iOS, Android, etc. are all UNIX-based). First I’m going to go through all the problems of the various pre-Unicode ASCII based encodings, and then I’ll provide some programming pointers for cross-platform programming. You can skip the pre-Unicode stuff if you’re not interested in the history

Read the rest of this entry »

While various flag and signal based encoding systems have existed since pre-history (signal fires, smoke signals), true digital encodings were not needed until attempts to communicate via electrical signals in the form of the electromagnetic telegraph. The early telegraph systems in the 1830s and 1840s were extremely limited in terms of electric components, with basically only batteries and electromagnets available. In another running theme throughout technology, there was also a desire to make the systems usable without the operators having to learn complex codes, and this placed further constraints on the systems. With these components, three basic systems were invented.

Read the rest of this entry »

It’s 1887. The only electrical components you have access to are electromagnets. And you want to build a digital to analog converter. What do you do?

Read the rest of this entry »

This device is somewhat of a revolution in telegraph technology from the 1870s. It uses a fixed-length 5-bit binary encoding, the kind of encoding that we would expect to see in silicon-based electronics equipment. Baudot created a receiver that resembles a mechanical computer to perform the decoding and printing. Looked at in modern terms, it uses a 5-bit latching transfer register and a second 5-bit decode register for actually printing the received codes as human readable characters instead of squiggles or dots on paper. The encoding used by the device is named after its inventor Emile Baudot. I’ll run through the entire device, although it is the receiver where things get interesting.

Read the rest of this entry »

Here is one of the early patents for electroacoustic multiplexing of telegraph signals. (Note that this is not the same as electroharmonic multiplexing, which used multiple frequencies as carrier waves to achieve multiplexing.) I like this one because it really shows the acoustic component of the system. Here is a picture of a quadruplex system.

Read the rest of this entry »

This is an early attempt at an isochronous distributor-based multiplexing telegraph from 1873. It demonstrates the problematic nature of using Morse code with this kind of multiplexing system. First, let’s have a look at the top view of the device.

Read the rest of this entry »