Ramblings of Narc

Leo Notenboom of Ask Leo! has written a thoroughly useful article about wireless Internet connectivity. In the comments section, a reader pointed out the omission of satellite Internet from the list. The comment read thusly:

Great subject! Informative answers! But don’t forget about Satellite internet. The prices are comming down. I live in the country and have only dial-up. I’ve checked some different options and I found I can get broadband high speed for about $15 a week and not have to buy anything.

This was my reply, and I considered it so good (and long-winded, but that’s another story) that it was worth reposting on this blog (with some cleanup and additional formatting):

Satellite Internet is, indeed, another wireless connection type, and it’s a somewhat older one than most of the ones discussed in this article, thus we could say the technology is “proven”. However, its low adoption rate is not solely because of its price.

Satellite connections suffer from some limitations which can be hard to live with, depending on exactly how you’re using your Internet connection:

• firstly, and most importantly, satellite connections suffer from high latency. This is a function of basic physics — the satellites are far enough away from any point on the surface of Earth that it takes a non-trivial amount of time for data in the form of electro-magnetic impulses to reach them, reach the other point, and return. My current Internet connection gives me latencies on the order of 150 milliseconds, on average, from Romania (Eastern Europe) to the United States. By comparison, for satellite access you could be looking at latencies as high as 1 or 2 seconds (thousands of milliseconds!) for a round trip to a server that might be just a couple of miles away. And that’s on top of the pre-existing round trip from the other end of the satellite connection to the server you’re trying to reach.
• secondly, weather: as documented on Wikipedia, “[satellite] communications [are] affected by moisture and rain in the path of signal”; meaning, effectively, that a rainy day in the summer might leave you with a crippled, if not completely non-functional Internet connection. Add to that the likelihood of snow build-up on the satellite receiver dish, and thus the requirement of continuous maintenance, and it makes for a somewhat unreasonable connectivity solution.
• the third, least important but still potentially crippling disadvantage is that most satellite Internet providers tend to offer one-directional access only. That is, download-only (from the Internet to your computer). But all communication on the Internet, by virtue of the design of the TCP/IP protocol, is bi-directional: all packets sent must be acknowledged, and don’t get me started on the three-way handshake. What this all means is that you might still have to keep your dial-up connection and use it for the opposite direction, which will effectively slow down your communications to the rate at which your dial-up connection is capable of routing the acknowledging packets, which, although obviously smaller than the primary communication ones, are still a limiting factor.

There is also the further limitation of line of sight, specifically the communication-dampening effects of vegetation, meaning more continuous maintenance to ensure a tree (or, in a city environment, a building!) doesn’t come between your receiver dish and the satellite it’s trying to reach.

But the trifecta of latency, weather, and unidirectionality provides strong incentives to stay away from satellite connections except as a last resort. I’m also suspicious of your final statement of “not [having] to buy anything”, since contacting a satellite absolutely requires the existence of a satellite dish, but perhaps you already have that for TV.

If you’re curious, the uni-directionality limitation results from the fact that satellite communications are generally optimized for TV-like systems, wherein there is a single sender and many recipients. By contrast, an Internet connection by design is point-to-point, there being a sender-recipient pair for each such connection. This effectively results in satellites being a very poor method of transmission, having a very limited number of channels, which accounts for the relatively high cost of connection. Simply put, a satellite with, say, 1,000 channels could broadcast 1,000 TV programmes to potentially millions of viewers (who are all receiving the exact same data), or it could provide Internet access to exactly 1,000 people. Some magic is probably possible by splitting the channels into smaller ones, but the result of that will necessarily be a lowering of speed, and you may end up with a bandwidth the same as a dial-up connection but with a much higher latency.

---

I didn’t mean for such a long treatise of satellite connections, but I feel I’ve done a reasonable job of describing the pitfalls there. I’d like to restate that it could still be a potential option, just not one that is likely to be reasonably priced — either in upfront or hidden costs.

I’m sure any half-decent software developer has had this drilled into their minds many times over, but perhaps it’s worth repeating (otherwise, feel free to skip this post): don’t repeat yourself!

Now, I’m probably a statistical outlier in that most of my programming education (and computer education in general) has been of an informal nature: I taught myself. So when trying to get points across to others I tend to refer to my experiences for examples of what can go wrong. So here’s how I ended up learning the “don’t repeat yourself” rule:

Way back in 2005, I was trying to figure out how I could standardize my PHP applications’ layouts on disk. I’d started in early 2004 with a single firm idea: that includes went into a separate subdirectory, from whence they could be referenced by any script the application was comprised of. From there, I got the idea of doing the same for images, stylesheets, and so on. By early 2005, I’d set up a simple template system I still use today, consisting simply of text files with placeholders for variable data. For example, this would be a valid template text:

Hello, {{UserName}}, and welcome to {{ProgName}}! Where do you want to foo today?

The bits between curly brackets are the variables, and they can get filled in with basically any text you want. For instance, set “UserName” to “Narc”, and “ProgName” to “CMBlog”, and you get:

Hello, Narc, and welcome to CMBlog! Where do you want to foo today?

Simple, clean, and surprisingly fast, at least in my use case.

I liked this so much that I decided to use it in all my personal projects. And that’s where I started running into trouble.

You see, what I ended up doing was copying the code from one project to the next, but then I’d find a bug in it and have to update all the copies. Can you say, oops? But wait, it got worse: I had some ideas for improvements, extra features that would be handy, like automagically including other templates into the current one by using a special version of the curly brackets placeholder. But whenever I thought of it, I either added the improvement only to one version of the code (whichever the latest project I’d been working on had been), or I didn’t add it at all because of this duplication tax.

Now, clearly, the tax is not that high, after all, I only needed to copy some files from one place to the next. Maybe I’m just too lazy for my own good (though there is some belief that laziness is a good feature for programmers, but that’s a topic for another post), but clearly the multiple copy model wasn’t working for me.

So I decided, instead of making these multiple copies, I would keep all the interesting, reusable bits of code in one place, and just include them as needed. But I also knew that reading in all those bits of code would be a performance hit if they weren’t needed, so they had to be split up into segments of functionality. Like the template system I just described above, or a set of functions that make database interactions less painful.

What I ended up creating was a very interesting (to me) system of includes driven by a bunch of configuration variables. You could set a variable (a key of a well-defined and standardized array) and the bits of code you’d need would be included, and you could use the functions you needed without including any of the dozens of other functions (the current count is 176, if you’re curious), and thus without wasting CPU time waiting for unnecessary resources to load from disk. That system is now called NeoFW and I still love it very much. It lets me make changes in one place, and have them show up instantly in all the places it’s used.

Let me restate that, in case I haven’t bashed you over the head with it enough: I make one change in one place, and it shows up everywhere!

On top of that, this code provides an interface for user-handling functions, meaning I can have a user log in only one time in one application, and have him logged into all of them at the same time. This is a wonderful change from the previous implementation where I had to be careful to use the same session variables across all applications, and the same session storage method, and heck, the same code, for that matter. Which is why it was perfect for this system.

Generalizing from this example, we find that it’s a very good idea not to duplicate code when you can help it. Don’t repeat yourself. When you repeat yourself, one of two things (or a combination thereof) is bound to happen: either you’ll end up with synchronization issues (some versions of your code work differently than others), or you won’t want to make any more changes to your code because it’s so much of a hassle to keep track of where else that same code exists.

If I’d started with a Linux server, I’d probably have ended up using a lot of symlinks, and then I wouldn’t have made NeoFW, which would be a shame, because I’ve learned many useful things while putting it together. But I couldn’t have failed to learn this lesson: that the best number of repetitions of your code is one. Not two, not four, but one. And, of course, five is right out, as Monty Python taught us.

---

This is the second of hopefully many “personal experience” posts, where I detail the things I’ve learned and how I came to learn them. The previous post was Recognizing Failures, about not biting off more than you can chew. The next is Blogging For The Perennial Lurker, a slightly meta expression of my experience as a habitual information consumer, as applied to the inherently productive medium of blogging.

(or, just how much can you chew?)

Way back in late 2005 (a lifetime ago, as far as I’m concerned), a friend of mine came for a visit one day. He was coming to me on behalf of a (non-mutual) friend who needed a programmer because he had an application in mind. He tried to explain the application to me, and on the face of it, I didn’t think it was a particularly difficult one. I still don’t, actually, but that’s a purely academic distinction at this point.

So because I didn’t think it was going to be that difficult, I went ahead and told him to have his friend contact me; he did, and he did, and we met, and I got to sketch out a reasonable idea for the program both in my mind, and hopefully in the client’s mind as well.

And then things got bad.

I strongly suspect I was right, that the project was not particularly difficult. I also suspect that, just as I couldn’t finish (or even start) it then, I would be completely unable to finish it now. It’s just beyond my capabilities.

The first hint of this “too big to chew” property of the project was when I tried to start writing some kind of database abstraction for it and kept coming up with flaws in that abstraction. I had gotten a number of details on what the final application would have to deal with, and even though I had decided (together with the client) that the initial version would be limited to some much simpler-to-model data, it became more and more clear that this initial iteration would have to be thrown away almost entirely after its implementation.

And here’s where I went wrong: I could have created the initial, very limited application. It would’ve had to have been (at least partially) thrown away after its launch, and the next iteration would probably have been more complex, but it would have been something tangible, more than just a concept in our heads, but something that could be interacted with, could be tested, could be considered for the recycle bin or for the improvements treadmill. Instead, I froze. Almost literally. I couldn’t write the code. I couldn’t make it happen. All I could think of was how complicated an architecture would be required, and how it was so completely beyond me because man, I’ve never written something like this before and I’m so fucked; I told this man I’d deliver something and now I can’t deliver, I can’t do it, and I’d rather die than see this man again and dash his hopes after I made it sound so good…

Now, if that sounds like I’m maybe hiding the fact that I couldn’t bear the shame of not being able to write something, and I’m lying to myself (hello, armchair psychologists out there on the Interwebs!), the fact is I’m not. Yes, I was ashamed, but not that I couldn’t do it — I was ashamed that I’d ended up lying to my client about being able to do it. And, to be honest, I don’t think I even ever said I would be able to do it, but I’d made it sound so good, like it was just a few steps away from being real… which, of course, it never had been — except in my head. Before I’d really thought about it, that is.

So, the lesson I took from this was: don’t promise you can do something you’ve never done before, and don’t make it sound like you can. Because if you end up biting off more than you can chew, you’ll make a liar out of yourself, and your client will not only not want to hire you again, but they will also tell their friends that you’re unreliable, that you make promises you can’t deliver on, and that will fuck you more than anything. Obviously, this is just after-the-fact reasoning, the real reason for me was that it made me feel like shit — but it also happens to be true, and my feeling made me look at that, analyze it, and see it for myself. And now I can share it with you, anonymous reader.

---

This is the first of hopefully many “personal experience” posts, where I will detail the things I’ve learned — some good, some not so good. Merry Xmas, Internet.

The next post in the series is One Is The Most Important Number, and refers to the age-old programming concept: “Don’t repeat yourself”.

So I recently got pointed towards Pointilism, which is “a style of painting in which small distinct points of primary colors create the impression of a wide selection of secondary and intermediate colors.”

Before I continue, an example:

(sourced from harley.com; copied to local storage to avoid hotlinking)

If you ever get the chance to take a close look (the painting is Sunday Afternoon on the Island of La Grande Jatte by Georges-Pierre Seurat), you’ll see each “dot” is actually made up of several smaller dots that, from a distance, “form a single hue in the viewer’s eye”.

Relevance? TVs and computer monitors work the same way. Especially LCDs.

Firstly, a bit of background. An LCD monitor works by shining a light through a grid of pixels whose opacity can be controlled individually. Stop. Look at that again — the only control over a pixel is its opacity. You can’t control its color. For examples of this, look around you; find an LCD clock. Or use this one I found on the Web:

Look at it carefully. See the digits? They’re made from these:

Remember how I told you before you can only control the opacity of each pixel? Well, each segment of that 7-segment display (the image above) is a pixel. How do you make the number 1 on that? Easy: turn on pixels B and C, turn off all the other ones:

Look familiar? Let me show you the number 2, as well:

Yeah, by now you’re thinking “okay, I’ve seen those a million times before; they’re everywhere. What’s your point?” My point is: the same technology (or, rather, the same basic idea) is at work in your LCD monitor.

One more time — an LCD monitor works by shining a light through a grid of pixels. The only control over the pixels themselves is their opacity. So why aren’t LCDs black & white? Because the pixels are colored. In fact, each pixel your computer sees is actually three pixels on your monitor: a red one, a green one, and a blue one.

Why red, green and blue? Because these are the primary additive colors. When light of these colors is emitted, it can be merged together to form any other visible color. The only thing you have to control is the brightness of the light. And to control that on an LCD? That’s right, you control the opacity of the pixel the light is shining through.

Here’s a simulated view from up close on an LCD:

If you take a powerful magnifier and put it up close to your LCD monitor, you’ll see something very much like that.

Want to make black? Make the three pixels (red, green, blue) completely opaque. White? Make them fully transparent. Any other color? Vary the opacity. Red, green, and blue are easy — fully opaque the ones you don’t need. But yellow?

Well, yellow light is a combination of red light and green light. So? Make the blue opaque, the others transparent. You get yellow very much like this one.

But wait, that only gives us 8 colors: black; red; green; blue; cyan; yellow; magenta; and white!

Well, not exactly. Unlike that seven-segment display, the opacity of a monitor pixel isn’t either “on” or “off”. It’s anywhere in-between. Want “12% opaque”? You’ve got it. How does that help you? Let’s take this color here:
this is a sample color

That color is defined on a computer as: 80% red, 86% green, 0% blue. As you can see, it’s a bit darker than our yellow from earlier.

And that’s the magic of LCD monitors: through controlling only the amount of light that can shine through a colored piece of glass, you can obtain any of about 32 million colors. Isn’t that awesome?