Fixing the shortcomings of Windows

I've been a willing, full-time user of Windows since 2000 or thereabouts.  I transitioned back in from the Linux world on Windows 2000, and while its start-up time was gratingly-awful, I grew to understand and even appreciate what it had to offer.  When I tried XP, I was sold, delighted, converted.

Of course, Windows has its limitations, and you don't have to look very far to find people crying them as a reason to convert to Linux.  It's not enough for me, especially since it is relatively easy to write to code to extend and modify the Shell.  I've had some fun, over the years, doing just that.  While it is not technically a Shell Extension (it started out as one and grew into its own funky thing), my utility SmokeyBox adds fun and useful features to the Windows desktop.

The latest tool in my making-Windows-better toolbox is StExBar, and I am deeply impressed  with it.  Written by the fine, brilliant gentleman who brought us TortoiseSVN, it adds an extensible toolbar to Shell windows.  It comes with many excellent features that make any software engineer's/power user's life much easier.

I can't recommend it highly enough.  Go check it out and thank me later.


Developmental Dissonance

On Friday, I downloaded and installed NetBeans 6.1.  It had received glowing praise, especially from bloggers who use it for Rails development as I do.  Most frequently noted was that it has dramatically improved its start-up time, and that was in fact my number-one beef with it.  It was epochally-slow.  Whenever I wanted to work on My Kids Library, I would double-click on the icon and go do something else for ten minutes while it woke up and crawled out of the vat of frozen molasses that it apparently sleeps in.

The installation went very smoothly, and as usual, I chose all of the installer's defaults.  Double-click, click, click, click, click, you're done.  Nice experience.  I wanted to try out one of the new features about which I was most excited: the ability to start-and-stop MySQL from within the IDE.  Previously, I'd been forced to open a command window and issue the commands to start-and-stop MySQL.  It's a minor annoyance at worst, but nevertheless, not having to do it seemed very exciting.

It didn't work, of course, and I probably slumped in my chair a bit as I watched plenty of error messages scroll through to console window in which the command being executed was running.  When the torrent had ceased, I found the first command that failed, and I saw immediately that the problem was that the space in between Program and Files had broken whatever was parsing the command, be it the windows shell or Ruby or whatever.  Bitten again by whitespacey file paths.  As I continued to explore this new version of NetBeans, I found many other features that were broken by the same problem.  I was kinda pissed and very disappointed.

Now, there's plenty of blame to go around here.  Microsoft, certainly, deserves a ton of crap for giving Windows a plethora of commonly-used paths that have white space in them: "Program Files", "My Documents", and  the wretchedness-to-end-all-wretchedness, "Documents and Settings".  Holy Dijkstra, what were they thinking?

Just as equally to blame is everyone who creates software for Windows.  We are under no obligation to install our software into that foolish directory.  Why do it, when it is a recipe for defective software?  And moreover, NetBeans, you not only installed in My Programs (OK, fair enough, all the other kids are doing it...) but also fully voluntarily put a space in your own name.  Yes, "NetBeans61" would have been absolutely, perfectly readable, but you chose "NetBeans 6.1" instead.  Is this some kind of a stealth attempt to get me to try out OpenSolaris or something?

It's not going to happen.  I am a happy little trilobite in the Microsoft ecosystem, and Windows XP is my OS.  Rails is infinitely better than ASP.NET for web development, but C# pays the damned bills around here.

So, I uninstalled NetBeans 6.1 and immediately reinstalled it to "C:\NetBeans61".  Everything works great.  I love it.  Thanks for some great, free software that really helps me be a more productive software engineer.  But do me and everyone else a favor: for Netbeans 6.2, dare to be different.  Provide a default installation path that does not have any white space in it.  Be the kid that doesn't jump off the bridge just because all the other kids are doing it.


Going Go on Windows


I admit it: I love all things Google. Gmail, Google+, Google Music, Google Docs, AppEngine, Apps for Domains, AdSense, Analytics -- I use and enjoy them all. I was very excited when I first saw the announcement about Google’s new programming language Go, but I didn’t set about learning it right away. I was deterred not having any particular project build with it, and it was not available for Windows, my platform of choice.

The first problem was solved by the addition of the Go runtime to the AppEngine platform. It was a perfect fit for a project that I had been working on with the idea of deploying it on node.js. I still think that I might build a backend for this program in Node, not only to have a backup to AppEngine but also to learn Node really well. The second problem has mostly been solved by the release of the official SDK for Windows. After downloading and installing it, I was immediately about to compile and link, but using other tools like gomake and gotest was not working. Through a great deal of trial-and-error, I eventually settled on a solution that now works very nicely for me.

The biggest hurdle to overcome is that many of the Go tools assume the existence of the standard UNIX developer toolchain, such as make. There are many packages that offer ports for UNIX: Cygwin, GnuWin32, Djgpp, Microsoft’s Windows Services for UNIX and MinGW just off the top of my head. I tried all of them and eventually settled on the MSYS package from MinGW. While it doesn’t contain an entire development environment, it has bash, make and a terminal window (rxvt) that is a vast improvement over the stock DOS command window.

After installing MSYS, you want to make some config changes to make things easier for you. In etc/fstab, you can map your long and complicated Windows paths to directories in your MSYS home directory. For instance, I like to map C:/Users/adam/Documents/Projects to /home/Adam/projects, so when I start up the MSYS shell, I can just cd projects and I will be were all my code lives. Also, you may want to modify the .bash_profile in your MSYS home directory such that it creates and exports the Go-related environment variables that will make the Go tools work correctly.

Once you have all that set up, you should be able to start up the MSYS terminal, cd to the directory where your Go project lives and use gomake and gotest to compile, link, install and run unit tests.

I have been having a great time learning Go. It is a wonderful language, and I really hope that it gains traction. I will be having a lot more blog posts in the near future about it and some of the work that I am doing with it. I already have an open source Go project hosted on bitbucket: mtemplate.