Mac OS X & Windows in Parallel

The first most natural reaction for a Mac guy like me is "Ick! Windows on my Mac?!". And yeah, it is a bit disgusting. After all we all know that Mac OS X is obviously the superior operating system, right?

Well even if you don't necessarily agree with that assertion, you have to agree that if you're any kind of web developer you can't ignore Internet Explorer. Despite all its warts and laughable standards adherence, it is the browser that most people use. So if you care about giving those users the best experience when visiting your site you need to view it in IE.

My solution was to use Windows 2000 (with SP4 and IE6 installed) within Parallels and I've been pretty happy. W2K runs very well and being able to seamlessly run my webapps in IE while continuing to work in Mac OS X gives me exactly what I need. So here's the recipe:

1. Install Parallels (get a demo from Parallels to try it out). You might also want to give the beta 3036 version a try (I did). It has some great features like the "coherence" view that lets you mix the W2K windows in with your Mac OS X windows.
2. Create a Windows virtual machine and install Windows (take a deep breath its a little surreal)
3. Once you have the VM open go to the Parallels Action menu and choose "Install Parallels Tools...". This improves performance, mouse support, the graphics capabilities and lets you drag files to the Windows desktop (and probably a bunch of other stuff too).
   
4. Set Windows' screen resolution, colour depth, font antialiasing, and be sure to set "Show window contents while dragging". The last option is important if you use Parallels' coherence view.
5. Start up your web server in Mac OS X, and be sure to open the necessary ports in your built-in Mac OS X firewall to let Windows see your server (e.g., Tomcat is 8080 by default and WEBrick is 3000 by default).
6. Type in your Mac's IP address in IE and enjoy! (Well hopefully enjoy, IE has a tendency of frustrating a lot of developers).

Passionate Development

A lot of people seem to have a real passion for developing software. So why is it that we have so much bad code? Well I have my own theories. So without further ado I present my most-wanted list of culprits, in no-particular order:

New coders

New developers are great. They're happy to have a job and are excited and keen and want to change the world. But they don't really know what they're doing. Hey sorry, but I've been there, I know. You can always do better the second time. And when you're new you write a lot of code. You do the first thing that pops into your head. That's not usually a good recipe for creating good code. I've said it before and I'll say it again, mentor these people and give them training. They don't mind learning and usually take constructive feedback well.

Gung ho Project Managers

Project deadlines are very rarely made with developer input and even if they are, deadlines are never adjusted to account for unanticipated problems or changing requirements. The usual solution is to throw more coders at the problem. To write code under the obligation to create software to help someone do their job is one thing. To do it under duress is completely another. Project Managers love to be "under budget" and "on-time". A lot of them don't care what it takes to get there. Tie some of their compensation to creating maintable systems and they'll help do the right thing.

Heroes

You know who I'm talking about. Every place has at least one of them. An environment that routinely has ridiculous productivity expectations seems to attract the evil genius who works his ass off to produce a solution. Like the new coder, this guy writes a lot of code and lives for the pat-on-the-back and the "attaboy". But he isn't really interested in producing an elegant bit of code. Rather he lives for the hack that will make things work at the last minute and "save the company". The problem with this guy is that he perpetuates the bad productivity expectations and increases the brittleness of the environment. Keep some kryptonite handy to slow him down.

The Architect

You know that fat dude from the Matrix who talks in riddles that nobody understands (says shit like "vis a vis" and "ergo"). Picture that guy and make him an IT architect and you'll get my drift. Architecture is a good thing and somebody needs to think about it, but a lot of these enterprise architects have no accountability to anyone and dream up all kinds of crazy impractical things to do. Take for instance all this SOA, Web Service stuff... Good Lord what a mess! But talk to an "architect" and he'll have tears in his eyes when he explains the world he sees through his rose colored glasses. If you're gonna have people called "architects" (regardless of how bad that analogy is for software development) then assign them to projects and make them responsible for something. (btw: I was a technical architect once so save your hate mail. I know what I'm talking about, vis a vis)

The Academic

These guys are aspiring architects. They love to look for the next great solution and somehow work it into their latest projects. There is such a thing as the progression of technology and you should upgrade the technology in your project so that it doesn't become a backwater for discarded frameworks. But you need to be careful. If you blindly adopt the latest and greatest all the time then you'll spend more of your time working the bugs out of these frameworks than you will actually developing your own software. The elusive silver bullet will often shoot you in the foot.

Support Developers

A lot of places I've been devote some developers to supporting the applications in production. They're motivated by the desire to fix bugs and enhance the application to meet ongoing user demand. So while that's a good thing, they usually have to support 20 applications simultaneously, don't really understand how any of them are put together, and only have to touch the code every so often. So what happens is that the application code (no matter how lovingly crafted during development) slowly decays over time. The solution? Make sure the people who developed the application are resonsible for maintaining them. There's nothing like knowing your own code may come back to haunt you, to keep you focussed on writing good code.

DBAs

These characters live in an alternate universe of sets, joins and intersections and they rule this kingdom. They institute all kinds of rules that don't always make sense from all perspectives. Understandably, they want to enforce certain conventions so that things are consistent and easier to maintain. But every once in a while these guys need to stop defending the battlements and adopt the prevailing wisdom of the land. For example, DBA purists will usually get pretty hostile if you talk about using surrogate primary keys to ease the object relational mapping burden. They'll get all academic about composite natural keys. And while their argument may make absolute sense from their perspective, they need to undertand that their unreasonable rules can result in less elegant code. Don't even get me started on the "law" about only updating tables through stored procedures.

Summary

Nobody sets out to create nasty tangles of code. Most people are at least somewhat passionate about what they do. They want to have pride in their work. Now it's easy to fall into the trap of negativity and start believing in the futility of trying to make things better. (Lord knows I've fallen in there once or twice). But in the end that's what you have to work with. Greenfield development seems to be a rare commodity. So recognize the poor behaviors, try to understand the motivations behind them, state your opinion, make good decisions (or at least try to influence the decision makers) and do what you can to make your coding world better. And for god sakes, stop writing crap code! ;-)

Java Compiler Woes

To cut a long story short, I lost a couple days of effort to discover that you should always use the version of the Java compiler that matches your production environment. Take for example this little piece of Java code:

import java.math.BigDecimal;

public class BigDecimalTest {
 public static void main(String[] args) {
  BigDecimal big = new BigDecimal(100);
  System.out.println(big);
 }
}

Compile it and run it in Java 1.4 and it prints out "100". Compile it and run it in Java 5 and it prints out "100". But now take that Java 5 compiled class (e.g., javac -target 1.4 -source 1.4 BigDecimalTest.java) and run it in Java 1.4 and you get:

Exception in thread "main" java.lang.NoSuchMethodError: 
        java.math.BigDecimal.(I)V
        at BigDecimalTest.main(BigDecimalTest.java:5)

The problem is that Java 5 introduced a new constructor for BigDecimal that takes an int. So once compiled in Java 5, the class expects to find a constructor to match that signature and when run in Java 1.4, it blows up spectacularly. Nasty little mess.

Airmiles with that?

The latest edition to my family of computers is slowly making it's way around the world. It started its life in China, then Anchorage, then flew straight overhead to Memphis, and is now getting acquainted with Canadian customs in Mississauga. Unfortunately, more than half the shipping time has been spent there waiting for some customs official to give it the green light to move on. If only I could get air miles for the trip perhaps I'd have a little more patience for this delay. C'mon you guys, get a move on!

P.S., Ain't Google Maps cool?!