All things old are new again

Russia has allowed itself to slip back towards totalitarianism. That's too bad. Hopefully, they'll be able to change course soon. I hope the Europeans and the Americans will stand up for Georgia---a country whose leader and people embrace liberty.

Stupid Car

Yes, the time has come in America where we've been forced to turn away from large gas guzzlers to smaller, more fuel-efficient vehicles. To capitalize on the new trend, Mercedes has introduced the "Smart" Car. It's a two-seater that looks like it took a wrong turn at hole 9 and somehow ended up on I-495. It seems like it would be an economical and intelligent choice in these times of inflated gas prices. But by simply looking at the specs, you'll see that this car is nothing more than a status symbol for green elitists.

First, look at the fuel-efficiency rating: 33mpg city/41 highway. Not bad until you realize that only two people can fit in this car with very limited cargo space. It ought to get about 60mpg based on it's minuscule size. Second, it costs around $15,000. Mercedes should be charging about $20K to the green fanatics who buy it. They'd still make a killing.

What other cars are in that price range and offer comparable fuel-efficiency? The Toyota Yaris (29/36), Honda Fit(28/34), and Mini Cooper(28/37). All of these cars are probably twice the size of a Smart Car. This means that you can actually take other people with you in your car. Alternatively, you can carry more cargo. Of course, the Mini Cooper will cost you more. But then again, can you really put a price on the environment?

The only place I can possibly imagine a Smart Car being practical is for someone who lives downtown and almost never ventures outside the city limits. But the problem is, most of the Smart Cars I see are being driven in the suburbs! This leads me to the conclusion that the people buying these cars certainly aren't doing so for reasons of need or practicality (the Toyota, Honda, and Mini are all more practical for the suburbs). They also aren't buying the Smart Car for performance reasons and certainly not reliability (after all, it is a Mercedes brand). The only reason for someone in the suburbs to own this car is to brag to others that they are somehow more environmentally sensitive than everyone else. You know what? You can keep your stupid Smart cars to yourselves. Normal American's will stick with more practical subcompacts.

The Goal

I was standing in the line at Subway today. The guy in front of me placed his order but was unable to move down the line because of a backup somewhere in the toppings portion of the line. So, the order-taker had me shout my order over the shoulder of the guy in front of me. After that, he asked the guy behind me to shout out his order. To be honest, I was uncomfortable shouting out my order over someone else. I don't want people to know what I'm ordering (Can you believe that guy wants Tuna with Pepper Jack? What a loser.).

I would expect this kind of thing at Original Ray's Pizza in New York. But a corporate beheamoth like Subway should be a highly-tuned sandwich making machine. I read a book called The Goal which is a fictional account of a guy who is put in charge of a failing factory. With the help of an old college professor, he figures out how to overcome the plant's problem with inventory among other things. One of the key messages in the book is the importance of identifying and eliminating bottlenecks.

Clearly in Subway's case, there was a bottleneck in the sandwich production process. Having visited this Subway about 200 times so far this year, I've noticed that sometimes, the Toasting Oven has a backlog of sandwiches. This means that people can't proceed forward in line until the sandwiches are finished being toasted. So, why does the order taker continue taking orders if there is a backlog of untoasted sandwiches? That's precisely my point! He's basically adding work-in-process inventory for no reason.

I think he keeps adding inventory because, once the oven is ready for a new batch of sandwiches, he is prepared to stuff in as many sandwiches as possible. Makes sense from his perspective I guess. But after the oven is emptied, the people at the toppings station are overwhelmed by all of the freshly toasted sandwiches. There are only two sandwiches that can be processed at the same time in the toppings station. So, if four sandwiches come out of the oven, two will be waiting in the queue.

The bottom line is, Subway has some problems with their assembly line. I would at least suggest that they use a conveyor belt style oven instead of the closed door style they currently operate. This way you don't have to wait for one batch of sandwiches to be done before starting a new batch. This won't completely eliminate the oven as a bottleneck, but over time should make the process flow more smoothly. Also I think that adding a third toppings station would be beneficial. Lastly, they need to have a roving sandwich maker that can help with either toppings or initial sandwich creation as needed.

However, these suggestions need to be weighed against additional fixed and variable costs (the new oven and the addition of a rover). Furthermore, the store is space constrained and it is unlikely that it could be reconfigured to add a third toppings station. But they may be able to add an additional bin for the two most popular toppings--lettuce and tomato. If placed centrally, a third topping worker could share the other toppings on his/her left and right with the other topping workers.

The end result will be that I can get my sandwich during the lunch rush more quickly and without having to shout my order over the backs of other people.

I Hate Flying

I hate flying, but if they ever produce one of these planes, I'll take a ride. I saw this on Digg, but the picture is from a Popular Mechanics article from a while ago (I hear). These planes are based on a Boeing blended wing design which supposedly provides a lot more passenger room than traditional "tube" designs.


Check out this other design from Boeing called the Sonic Cruiser. If produced, it would have flown at nearly the speed of sound. It was abandoned for the crappy-looking airplane below (Boeing 787).

Rich Clients need Rich Components

2008 will be a defining year for desktop Java development. If all goes well, we will see a slew of new libraries and toolkits for developing rich client applications---stuff like video, audio, animation, graphical effects, etc. Combined with performance and ease-of-use enhancements to the Java platform itself, developers should have all of the tools they need to create compelling applications. While I am really excited about the prospect of having all of these new tools available, I'm a little skeptical that they will emerge---at least in a form that will truly inspire developers to create rich applications using Java.

What got me thinking about this today is a side project I've been working on where I am trying to add validation 'overlays' to components in a form. Kirill at the Pushing Pixels blog has compiled a fairly comprehensive set of ways to accomplish validation overlays. After going through his examples, I got to thinking that all of the solutions are overly complex. But first, let me explain what a validation overlay is. A validation overlay is basically a visual decoratation of an input component with an icon or some other graphical indicator to inform a user that the value in the field is invalid. For my project, I wanted to apply a blurred red border to a text field. To achieve this, I used the LayeredPane approach as described in Kirill's blog. This works great until you resize the form or place the text field in a scroll pane. There are too many quirks that make this approach very unfriendly. There are other approaches (using a JXLayer or JGoodie's IconFeedbackPanel) but, in my opinion, they are still too complex.

Here's my point: Rich Clients need Rich Components. Client toolkits should make it easy to develop modern client applications. Achieving rich client effects in Java Swing is currently too cumbersome. I think the JavaFX Platform will address this to a certain degree. But the component-level is what is really lacking in Swing. Things like text fields, dropdown boxes, sliders, lists, and tables. These components look and behave as if they were designed in the year 2000 (which they were, coincidentally). What we need now are simple and flexible ways to, for example, decorate components with validation glyphs or highlights. Or how about providing a stock JList that is animated either by default or as a simple config option. And how about making it pluggable so that the animation or effect can be swapped easily.

Animated lists and field highlights are not new ideas. MacOS has had them for years. I'm not discounting the entire Swing platform as old and busted---it's just in need of some major overhauls to bring it up to par with current UI trends and technologies. And it needs to be done in a way that makes it easy for developers to take advantage of.

Google Android

When Google announed their Android platform for mobile devices, I was barely interested. As a Java developer, I was variously intrigued by their language framework which is essentially Java but not branded as such. I watched the demos and thought they were interesting but still not up to the level of the Apple iPhone. But after taking a trip to the local Verizon and AT&T stores, I changed my mind.

My wife and I have mobile phones that are over two years old. The battery in my LG-free-with-the-plan phone lasts about 20 minutes. My wife's phone is a Nokia which lasts much longer but definitely sports an outdated look. Since our original two-year contract has expired, I figured I'd look around at new phones that I could get when signing our next contract.

Talk about a disappointing experience. I looked at every phone at both the Verizon and AT&T stores. Most of the phones are flip phones (which I don't like), but beyond that, the user interfaces of these devices are unappealing. It seems that even the more expensive models share the same stodgy and difficult UIs of their lower-priced siblings. One feature I particularly wanted was a built-in mp3 player. I tried this feature on several phones and was met with difficult-to-navigate, unintuitive, and uninspiring interfaces. In the end, I liked the look of the LG Chocolate the best, but disliked the software that runs it.

I now believe that Android is positioned to be the common mobile platform of the future. Mobile phone makers can get out of the business of making phone OSes and concentrate their efforts on user experience. It really makes sense. The core competency of most mobile phone makers is making and assembling hardware. For whatever reason, they don't have the resources to design and develop and effective mobile OSes. With Android, phone makers are now able to combine their efforts to create a basic OS so that more effort can be devoted to creating a good user experience. In fact, mobile phone makers may be able to get out of the OS business altogether and rely on a third party to build the OS (some, in fact do this to some degree). The phone companies themselves can even craft their own OSes based on Android. I'm really looking forward to an Android-based phone that will (hopefully) offer an easier and more appealing user experience.

Beyond mobile phones, I think that Android could potentially become the platform for a number of small electronic devices. Think about having an Android-based thermostat or an Android-based car computer system. Thermostat manufacturers could take advantage of the developer-friendly features of Android to reduce development costs for their devices.
Car makers could base their in-car applications on Google's Android (Ford has already teamed with Microsoft to create its in-car computing platform).

There are a lot of opportunities that the open, community-based Android can bring to companies whose core competencies do not lie in developing complex operating systems. Since Android is essentially Linux underneath, Google is building on a solid tested platform. Google has the clout and resources to make Android succeed in a segment that has traditionally been dominated by smaller companies and home-spun solutions.

The thing I don't like about Shale Clay

I'm new to Clay, so forgive me in advance if any of these comments are said out of ignorance. Before I proceed with my gripe, I would like to say that I think Clay is pretty slick in its capabilities. Actually, I quite like Clay overall. In essence, it allows you to use 'standard' html to create dynamic web pages. When a page is served to a user, Clay replaces page content placeholders with dynamic markup. Pretty cool.

My main problem is the fact that 'standard' markup is not really standard after all. For example, to define placeholder html that should be replaced with dynamic content at runtime, you must specify a jsfid attribute inside whatever html tag you wish to make dynamic. The mere act of adding this simple attribute breaks the possibility of strictly conforming to the XHTML specification. If you run your page through a conformance check, it will obviously result in errors anywhere you use Clay-specific attributes. I also have to put up with numerous underlined warnings in my html editor telling me that the jsfid tag is 'undefined'.

Those who understand Clay and Java web development are thinking, "How else can you tag a component so that it can be replaced at runtime?" Well, you can't. And maybe that's my problem---that the XHTML spec doesn't allow extensions such that programmers can use dynamic scripting or other features without breaking strict XHTML convention.

So what's the solution? I don't really know. I guess you could say that I'd like to see the XHTML specification written in a way that both designers and developers can benefit. In the meantime, one way to mask (but not fix) the problem would be to create development tools that understand the semantics of Clay or other dynamic web technologies and toss out the warnings and errors instead of deluging the developer with them.