Loose coupling/tight coupling: When things go wrong

I was thinking about coupling this morning. Loose coupling allows for one part of a system to change without impacting other parts of the system. The other parts are shielded from the impact because the coupling point is a contract. As long as the change happens behind the coupling point and the contract is fulfilled correctly, a change in any particular module will not affect any other module that relies on it.

But that's not really what I was thinking about this morning. I'm thinking more about trains, and the Tokyo train system specifically.

Every morning I take the Tozai line from Minami-Gyotoku to Nihonbashi. The "東西" line is one of the few train lines that, as its name suggests, travels the entire distance of Tokyo from East to West.

Before I get too far ahead of myself, I have to explain a little about the train system in Tokyo. There isn't just one train company here. There is the well-known JR lines (pdf) which has the famous Yamanote line which circles the heart of Tokyo and connects at many stations with other lines. There is also the very popular Tokyo Metro (pdf) of which the Tozai line is one (the blue line running from east to west). Still relevant and convenient is the Toei Transportation system which runs several trains (see the Tokyo Metro map) and a host of buses around the city. Less well-known lines like the Tobu lines and the Odakyu lines are also here.

What brought on this thinking of coupling wasn't the coupling of trains, but the coupling of train lines. If you look at the various maps, you will see that many train lines intersect with each other. These are prime points for coupling, and indeed many of those intersections are coupled by means of a shared station.

By "loose coupling" here, I mean that the passengers must unboard one train and reboard another to make the transfer. This is very convenient, though sometimes the rush to change trains is overwhelming with so many people needing to transfer at the same station. Also, it requires that the passengers actually leave one train to change direction. This is the standard way this works, and it works well.

But there are other points in the system that are much more tightly coupled. This means that more than just sharing stations with each other, multiple train lines may actually share the same track. The Tozai line is a prime example of this with its endpoint on the western end shared with the JR Sobu and Chuo lines. The Sobu and Chuo lines themselves share tracks from JR Ochanomizu westward. If you take a close look at the train maps, you'll even notice that the Tozai line and the Sobu line are connected at their endpoints and diverge in the middle, providing a wider area of service with the same terminal stations.

The benefit to the passenger should be obvious. By being able to board a single train and not have to transfer at stations, the passenger can relax and not be bothered until he reaches his station. From the passenger's point of view, it is less hassle and potentially faster than a series of transfers which loosely coupled train lines would require.

The downside, as I encountered this morning, is that a system failure in a shared area leads to a total system failure across all coupled systems. I get on the train at Minami-Gyotoku, as I mentioned before. It is on the east end of the Tozai line. An accident on the Chuo line, far on the west end of the lines, caused backups all the way through the entire Tozai line. As a result, I was late to work.

In a loosely coupled system, I would not have been inconvenienced since the Chuo line is really of no consequence to me personally. Passengers of that line would naturally have problems, but the other lines would run normally (as the Ginza line did when I transferred at Nihonbashi). Loose coupling would have prevented the impact of an event that occurred far away from affecting me.

But we don't live in a loosely-coupled world. In fact, the world which we live in is highly coupled. Tight coupling adds convenience while potentially compromising the stability of the system as a whole. How many people benefit from the tightly coupled train systems? How many people were harmed by events like today's backups? Where do you draw the line and say "Common convenience with occasional outages outweighs minor inconvenience with guaranteed service"?

XP Taskbar covers popup text

For a few days now I've been noticing a problem with my WinXP taskbar. The taskbar is forcing itself to the top of the Z-order, so it is always on top. Now, this wouldn't normally be a problem. I don't use the auto-hide feature, so it's not a big deal to have the taskbar always visible. However, with the taskbar at the top most visible layer, stuff like popup text is covered up by the taskbar.

If I hover my mouse pointer over the Messenger icon, I expect it to show me a little box indicating my login status. I can kind of make out that there is a box being displayed, but since the taskbar covers the box, I can't read the text at all. All context sensitive text bubbles are unreadable.

I tried auto-minimizing the bar, but since I can only hover my mouse over the icon when the taskbar is shown, that is not a solution.

I can drag the taskbar to the sides of the screen, and that seems to fix the problem, but I don't like having the taskbar all the way over there.

Microsoft is patching a bunch of things today. I wonder if this is something they broke earlier and will fix in this update. I can only wait and see.

Java Japanese font troubles

I am trying to get Netbeans working correctly on my PC.

As you already know, I'm in Japan, so my OS is WinXP Japanese language edition. In default mode, the locale is set to Japanese. Java takes that information and passes it along to Java apps. If an app, like Netbeans, has an internationalized config file, it will load the appropriate language strings and fonts.

If, on the other hand, a user does not want Japanese menus, the default system locale must be changed to English. This causes Java to interpret the environment as an English system, and all English strings and fonts are loaded. However, this has the side-effect of making Japanese fonts unreadable. Little boxes are displayed where Japanese characters should be. In Netbeans, this is first obvious in the File->Open->Browse dialog where "マイコンピュータ" should be displayed, but instead "□□□□□□□□" is.

On top of that, the editor itself ceases to be able to display Japanese fonts as well.

I was able to work around the editor problem by setting the editor font to MS Mincho, but I would much rather have the fixed-size fonts available for coding. Unfortunately, this still doesn't fix the problem of broken fonts in the system dialog boxes, but I can probably live with that.

I know I'm not the first person to run into this problem. The Sun support boards have the same problem repeated several times. It looks like "won't fix" is Sun's plan for this bug.

Which server-side technology?

Since joining UIEvolution, I've been dabbling with webserver technologies. This is a huge switch for me, coming from a mostly embedded systems background where the only languages available have been Assembly, C, and C++, and the only technologies were those provided by the hardware makers or self-written.

When the choices are limited, the boundaries are well-defined and it's easy to focus on the problem at hand. But with servers, there are so many choices that I don't know which direction to go. I started, I suppose as everyone does, with Apache. I'm running on an emulated Debian machine via Microsoft's Virtual PC software. Debian is really nice with their packaging, so Apache automatically came with PHP. It just worked right out of the box (or out of the apt-get, so to speak).

But then I wondered what else was out there. My experience with Perl gave me the bright idea to get Perl CGI working on the Apache server. After a bit of hassle, I finally figured out how to get the scripts to run correctly. Unfortunately, I can't figure out how to get CPAN to work properly, so my scripts have to run without modules. That kind of sucks. Seeing the ease with which PHP is molded to Apache, I figured there had to be a better way. Perl, despite its goodness, just wasn't going to work out for me.

But what, then? There are two obvious roads that this question leads down. The first is to stick with CGI (Perl, PHP, Python, Ruby) or to get acquainted with Sun and Java (JSP). Seeing as how I had already messed around with Apache and was pretty fed up with dealing with script locations and file permissions, I installed Tomcat, the Apache foundation's Java Servlet web server software.

First thing you notice after apt-getting tomcat5, it doesn't work. Without the Java JDK, you can't do anything with Tomcat. There are no nice apt packages for Java, so the solution was to download the self-extracting JDK from Sun and install that. This requires updating the /etc/profile file to define and export the JAVA_HOME environment variable. Log out, log in, voila the envvar is now set. Tomcat works! Hooray!

Now what? Um... Struts? Inline coding? And hey, did PHP stop working? No, it just doesn't work with Tomcat.

I went to Google with my question. Apparently there are more technologies than problem spaces. Every technology has its adherents, but nothing seems welcoming. Ruby seems to be generating a lot of excitement. Perl seems to be collapsing under the weight of the next version. Python seems to have gone into hibernation. JSP doesn't seem to be anyone's cup of tea. And PHP gives my Perlish brain seizures with its haphazard API. It's all a big mess of technologies, but without any particular one being any better than other ones.

For the time being, I'll be focusing on JSP since the UIE server-side components are written for JSP and come with some special tags and other niceties that aren't immediately available in other languages. But my question is looking more towards the future (my future). Where is server technology heading? What are the technologies that are in use now telling us about what sorts of technologies we'll be using in the future? What should I study now as to put myself on the front face of the technological wave?

I just got a message from a friend. He suggests C#.