A Prompt You Can Stand

For the past four years, Windows has been a very sophisticated operating system. It has provided stability, efficient pre-emptive multitasking, solid memory protection, POSIX compatibility, an acceptable (though unimpressive) file system, good multi-user support and increasingly good development tools (Visual Studio is truly fantastic nowadays).
However, one aspect where Windows comes short of its free competition is its command shell. Windows always had some level of support for batch files, but not the wealth of command line tools to fully exploit automation. In addition, the shell interface is horrible. The configuration settings are limited, and the window width can not be dynamically changed. Having briefly played with the betas of Microsoft’s next generation shell, codenamed Monad or MSH, it looks like the user interface will continue to be poor for the next few years even though scripting capabilities will be fantastic.
However, there is a better alternative available. Cygwin, a popular port of Unix scripts, APIs and tools, provides Windows users with the power and convenience of traditional Unix tools like grep, and an alternative command terminal that can host bash.



Personally I have found this to provide a good alternative to the standard Windows command prompt. You get a highly responsive terminal, with tab completion and history, and the ability to change the window size whenever you want to. All of the Unix tools that you expect are here (or can be automatically downloaded). Some of the downsides that I have found include a really ugly non-standard scrollbar, and an inability to drag files onto the shell from Explorer to automatically obtain their path. Some people even run GNU/Emacs in this environment. I tried the same, but noticed that the bottom-most line would disappear. Very annoying.
All in all, I have been happy to trade my dusty old MS-DOS prompt for a shiny new bash prompt.

Review: Design Patterns

For the past three years or so, I’ve been hearing increasingly more about software patterns. Some regard them as the best thing since sliced bread. If you dig through the hype, you will find a clever way of describing common software constructs in a de-facto standard vocabulary with which an increasing number of software developers are familiar.
If you have any experience with software development, you probably at some point devised a mechanism by which interested object instances could register to receive events emitted by other objects. If you’re anything like me, you probably did not know at the time that you were actually implementing a variant of the Observer pattern. Similary, you may have created a class returning new instances of appropriate subclasses of abstract objects without knowing you were using the Abstract Factory pattern. And you may not have known that the iterators of the C++ Standard Template Library were designed around a pattern later to be known as the Iterator pattern.
As with most new software development methodologies, patterns were — in my view — excessively hyped for a period. Now that things have calmed down, it is possible to evaluate patterns on their own merits — and those merits do not necessarily constitute providing revolutionary new design principles. Rather, they provide a way to express common programming constructs in a language-independant way, which must be a Good Thing^TM.
If you have somehow missed the patterns hysteria and would like to get into it, I really recommend the excellent book by Gamma (as well as Helm, Johnson, and Vlissides), one of the authors who pioneered the concept (and who later created the very useful JUnit unit testing framework).
The book provides a useful summary of all established patterns on the first few pages, and then goes on in subsequent chapters to explore each pattern in great detail, providing examples and plenty of motivation for the design decisions made. This book is the reference to software patterns and you should probably consider getting one for your bookshelf.
If you prefer a more concise summary, there are some excellent pages available on-line that provide just that — in Microsoft’s excellent C# language, no less.

Review: Code Complete

Following countless good recommendations on-line, I couldn’t resist the temptation to purchase Steve McConnell’s Code Complete. This thick bible of almost a thousand pages sets an ambitious goal: it wants to be “a practical handbook of software construction”.
It should be emphasized right from the start that this book does not teach how to create software. It does, however, attempt to teach how to create software well. Assuming the reader is a fairly experienced programmer with at least a few programming languages under his or her belt, the book covers a staggering area that includes good requirements and design specification, how to weigh competing goals, software testing, and how to use all of the different programming language features in a way that promotes readability and maintainability. There is even a chapter on personal character!
More than anything, the book drives home the message that the over-reaching goal of software design is managing complexity. The goal is always to create abstractions and modules that allow developers to focus on as small segments of the code as possible at any given time. A number of interesting design metrics are introduced and the book covers virtually all ways that code can be structured, and comments on different approaches from a variety of perspectives.
The book relies heavily on scientific studies of real-world software development projects to determine what practices work best, exposing highly interesting statistics about the efficiency of different development and testing approaches. Usually pragmatic in his advice, McConnell emphasizes readability over “clever code”, and explains his preference for making simple designs and document them well, over complicating a design to maximize run-time performance or future flexibility. The importance of doing things right from the start, as opposed to leaving bugs and design quirks for discovery further down the chain when they are an order of magnitude more expensive and difficult to fix, is emphasized repeatedly.
While reading through the book, I found the majority of advice to be self-evident, much of the rest to be highly interesting and thought-challenging, and a small portion to question whether it was I or McConnell that had gone completely crazy. Some of advice in the latter category is cleverly left in a somewhat religious, isolated chapter about coding layout and style which the authors recommends avoiding if you have high blood pressure. The code samples in the book are in C++, Java, C#, and Visual Basic, largely evenly distributed among the languages except for samples in C# which is a recent addition to the book with this second edition.
I had high expectations for this book and found them largely satisfied. I did not really expect the book to provide revolutionary new insight, and it doesn’t — what it does offer are many bits and pieces that are valuable when combined. Most of the issues touched on are things that I had previously thought about at one point or another, but I found it highly satisfying that so many of them were listed in this book together with in-depth investigations and argumentation.
I would like to have seen a little more in-depth treatment of some topics, like software testing in general and unit testing in particular — however what’s there is still plenty, and the book ends with a comprehensive bibliography for further reading. All in all, I consider this money well spent.

Java Still the Ugly Duckling

I had heard that the Windows look and feel had been improved in the more recent releases of Java, so I decided to download the developer’s kit for the Java 1.5 Release Candidate and have a look myself. In the true JDK tradition, a number of impressive samples accompanied the kit. The 2D sample demonstrates smooth animation, clipping, composition and a number of other effects.



The old Swing set demo was also present. Curious about graphical and behavioural changes, I quickly selected the Windows look and feel to see what, if anything, had changed.



At first glance, the interface looked a lot like other Windows XP applications. However, menus did not render with the user-selected effect (in my case smooth fading), and MDI child windows felt slow to move around. This suggests that Swing retains its custom drawing routines and still does not map to the standard Windows controls. I think this is unfortunate, because nothing annoys me as much in user interfaces as applications that just don’t quite “feel right”.
I know a lot of people feel that the Swing library was over-engineered. I was never particularly bothered by the class design in Swing — on the contrary, the flexibility and elegance appealed to me. I think if Sun would have aimed for an ambitious mapping to the Win32 API right from the start (I do not count AWT as “ambitious”), they would have had a winner on their hands. As it is, I feel like they missed the boat. I’m not going to weep anymore about what could have been, and should have been. Instead I’ll just continue happily using the .NET Framework whenever and wherever I get the chance.

Good Bye, FreeBSD

A few weeks ago I replaced FreeBSD on my old server box (Pentium II 350 MHz) with the first test release of Fedora Core 3. FreeBSD had been serving me very well for years, happily protecting my Windows machine with its native firewalling and NAT capabilities, as well as providing limited server functionality with virtually no downtime (the occasional power outages provided the rare exceptions).

Meanwhile, the open-source alternative to Microsoft’s .NET framework, Mono, had been making steady progress. It had finally reached a stage where I felt it deserved serious testing (read: playing with). Unfortunately Mono is not well supported under FreeBSD due to some architectural issues that I’m not familiar with in detail. Thus, it seemed my only option was to explore a Linux based distribution.

Having used Debian briefly in the past, I felt tempted to select that operating system again. However, Debian in my experience required quite a lot of time to set up in a satisfactory way, in part due to the ever-present package dependancy nightmares that most Linux distributions suffer from in varying degrees when complex software packages like desktop environments enter the picture. I decided, instead, to give the latest Fedora Core release a test run.

I downloaded the DVD and burned it — the installation went flawlessly, and I was greeted by a nice graphical login screen. Although I’m a bit of a KDE fan, I decided this time to install only GNOME to conserve disk space. GNOME is, I believe, better supported under Mono at the present time than KDE is.

As you may be aware, Fedora Core is a popular community developed operating system based on Red Hat. Back in the days of the last Red Hat releases, a decision was made to improve consistancy across desktop environments by providing default settings and themes in both KDE and GNOME to deliver a uniform user experience. This is something I took issue with and I am still not entirely happy with this decision, even though in general I applaud efforts to improve usability and consistancy in Linux. Nonetheless, as this was to be my server box — sitting alone in a cupboard — the user interface was of minor importance.

Fedora Core provides a number of useful applications for configuring common services, such as Samba and FTP. This went fairly well. I had no time or desire to learn how Linux managed firewalling (having invested significant time doing the same for FreeBSD once), and chose to use the excellent graphical configuration tool known as Firestarter. It provides nice wizards and dialogs to configure IP masquerading (NAT) as well as packet filtering. As Firestarter launched, it output a message in the console from which it was launched to the effect of having detected NETFILTER. I was somewhat concerned that this was a non-standard firewall tool, but as was pointed out to me, iptables is actually used for the filtering. Within a matter of minutes, the firewall was configured the way I wanted to (with appropriate port forwarding) and Firestarter had automatically modified the rc.d init scripts in order to auto-launch during each boot-up. After minor hurdles, I also had Samba up and running for easy file sharing between my Windows XP machine and my FreeBSD machine.

I was now anxious to install the software I was interested in — Mono, in particular. I initially tried the traditional route; using rpm. I had downloaded all of the Mono packages and tried to install them one by one. Unfortunately, my worst fears came true — a number of packages were missing and the installation could not continue. I then discovered another option for package management which had surfaced on this platform in recent years — YUM. YUM is an automatic package dependancy resolver and downloader. With minimal effort, I was able to download Mono from their YUM repository. The next step was downloading MonoDevelop to provide a somewhat nicer interface to Mono and its documentation. Unfortunately a dependancy problem surfaced again, but after a quick Google session I was able to find a solution (which involved re-installing the Mono packages — again, using YUM). I finally had Mono up and running and could not resist compiling an Hello World application and try to run it in Windows. It worked flawlessly! I then tried the opposite — compiling another Hello World in Windows to run it in Linux using the Mono run-time. That, too, worked great.

Layout Hurdles

I first read about MyXaml months ago on OSNews (the successor to the great BeOS related news site). It’s an open source effort to provide an XML based object instantiator similar to Microsoft’s upcoming XAML (to deput in the next Windows release Longhorn). Although MyXaml is not tailored to work with any particular types of objects (as long as they follow some rules), it was primarily devised — as was its inspiration XAML — for use with user interface specifications.

I have not yet played with MyXaml but I am delighted that we do not have to wait for Longhorn to use XML in .NET applications. However, it’s quite tedious to have to keep track of the absolute position and size of controls. Something that really stunned me was the fact that Microsoft chose not to include tools for dynamic layout management, similar to those provided by countless frameworks before such as AWT/Swing in Java, MUI and BGUI in AmigaOS and XUL in Mozilla. Those frameworks allow developers to specify the relative position and size of controls in a cunning way — by grouping controls into nested hierarchies where special layout managers manage child controls. Java’s BorderLayout is a particularly powerful example — by nesting objects managed by this layout manager, it is possible to specify a user interface of almost any complexity.

In early 2001, as part of an engineering thesis, I set out together with a friend to create the under-pinnings of a simple platform-independant widget library with dynamic layout facilities (with proof-of-concept implementations provided for Windows and MacOS). We decided at the time to call the library BORG, for Basic Object-oriented Responsive Graphics (the name was not at all inspired by Star Trek, we promise!).

I feel tempted to dig up the old source code and provide similar layout managers for .NET. I have a feeling that something like that, together with MyXaml, could be a killer combination. Thankfully Microsoft has had the foresight to provide hooks for layout management in the .NET framework.