Ones and Zeros

Neophila: The trait of being excited and pleased by novelty. Common among most hackers, SF fans, and members of several other connected leading-edge subcultures, including the pro-technology ‘Whole Earth’ wing of the ecology movement, space activists, many members of Mensa, and the Discordian/neo-pagangeek). All these groups overlap heavily and (where evidence is available) seem to share characteristic hacker tropisms for science fiction, music. The opposite tendency is neophobia.

- New Harper’s Dictionary (via Wikipedia)

Yup, I’m a neophile. But I’m also seasoned enough to know that the new - while exciting and intellectually interesting - isn’t always better. The question is to use the right tool for the job at hand. That may be the newest thing, but it may be the old and familiar too. This requires some assessment of quality of the tool for the task. Unfortunately this is a step often skipped in the software world.

For software engineering to become a real profession, we need to recognize the following:

[Engineering is] The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to use economically the materials and forces of nature for the benefit of mankind.

- Wikidictionary on Engineering

Software engineering can’t just be using the coolest and newest things. Instead it is building software that satisfies goals in a measurable way, uses scientific and mathematic principles, and economically and efficiently uses those principles to benefit us as software users. Using the right tools at the right times is a key step in moving from software developers to software engineers.

As software geeks, we can experiment and test the new tools. That’s fine. But we need to draw a clear line between experimentation and research vs deliverable production software. Not all software is - or should be - production grade software. But for production software, an engineering approach is key. The software techniques and tools used need to be subservient to the goals of the project. It’s hard to remember that in the heat of writing code.

Two of the basic characteristics that a network has are throughput and latency.  That is how much data can you get through a network and how fast does it take to get that data through.

In the old days of networking it was sometimes better to move data on a tape or disk by carrying it (aka Tennis-shoe networking) than it was to move it across the network. Throughput might be high because the disk or tape held a lot of data, but latency was also high. In South Africa, one company found it was faster to strap a USB flash drive onto a carrier pigeon than to use the network.

Intel supposedly did this carrier pigeon trick in the 1980’s with integrated circuit masks between their Silicon Valley offices and Santa Cruz fabrication facility.  In that case it was throughput on highway 17 over the mountains that was the problem.

But over time the internet has gotten faster and more ubiquitous.  Now we can get it on our cell phones too.  At least, when AT&T’s equipment cooperates I can.  There’s a room or two in our house that AT&T just doesn’t reach.  We miss more phone calls when we’re in the living room.

Netflix is a case study in TennisNet, or PostalNet, vs Internet.  But even Netflix has a plan to move the the Internet too.  Driven by Moore’s Law, networking will eventually rule everything right?

Maybe not.  Let’s consider wireless as wired networking requires too much infrastructure.  Moving a signal a reasonable distance requires either power or an antenna to concentrate the power in a very specific direction.  If the latter, you also need to know precisely where to point that antenna.  Antennas have size requirements too.   Sometimes bigger is better.

Having high bandwidth also requires more power or better antennas for the same distance.  Due to these power/antenna issues, networking will either require some infrastructure of wireless cells in an area, or decent power and antennas for satellite communications.

Or another way to put it: there will always be areas where low-bandwidth is the only game in town.  In those cases, Netflix postal model aka the carrier pigeon model, might work better if you need high throughput.

One of our cars exceeded it’s economic lifespan for us. It required a repair that cost more than the car’s value. We’d had the new-style VW bug for ten years, but it was time to move on.

My lovely wife used to drive a Citroën 2cv before I knew her and she always liked it. The 2cv is the French analog to the original German VW bug. It’s a people’s car; easy to maintain, reliable, and cheap to run. But the 2cvs were never sold in the US. While popular in Europe it’s a niche car here.

There’s a restorer and reseller online in New Jersey: Eurocar Imports. He also sells on eBay. We drove up and met the owner and looked at a car he had. Like all 2cvs the design is from the 1930s, although this car was built in 1983. (That makes it 10 years newer than our plane.) We made a deal and they’ve been doing some restoration on it since. Here it is after priming. It will be the classic Celeste Blue.

We pick it up this coming weekend and will be a 2-car family again.

The 2cv is a small car with a small engine: 26 hp. Some riding lawn mowers are more powerful. Of course this doesn’t have to drive a grass-cutting blade either! The 2cv can go 100 kph (63 mph) and gets around the same milage as our Prius, 50 mpg. We’ll drive it on longer trips sometimes but it will primarily be an around-town car.

I’ll be able to handle the repairs and maintenance. I used to work on my old-style bug and VW bus, and will be able to work on this too. I don’t work on modern cars anymore but I’ve still got my metric wrenches.

Now that the directional gyro works it is time to get moving again with this IFR rating. It’s been over three weeks since my checkride (part I: the oral exam). So instructor M and I scheduled a ride and did some local approaches, probably some of the approaches that I’ll have on my checkride.

I was pleased that I tracked altitude, heading, and the ILS much better than I expected I would. Especially the glideslope and localizer tracking was good. My problems were, however, in procedures and planning ahead. In short the “doing” part of things is going well.

I seem to have problems with planning for the next thing or two that I will need to do. I messed up the entrance to the hold because of this, didn’t brief the approaches as well as I should have, and almost made a wrong turn on one approach. The “thinking” part of IFR flying is where I’m rusty. That turn would have been a checkride bust.

M said, “You’ll never to do that again.”. And he’s right. He also thinks I’m ready for the checkride, but I want one more flight with him first to ensure I’ve got the IFR thinking part going well. Some parts of flying are mostly mechanical skill in moving the controls correctly. But IFR has a large thinking component to it. I have to maintain a mental model of where I am in relation to the approach, airport, or course I’m holding, and more broadly, to the situation I’m in. Maintenance of that mental model is where I’m a bit rusty.

So next is some practice at home (in the home “sim”), and another flight with instructor M. Then, scheduling permitting, the actual checkride.