Monday, June 4, 2007

Development Environment

Well, the weekend didn't go entirely as hoped in terms of getting a stable development environment setup in Windows. The reason for this is the current state of the installer that I'll soon be taking over. The issue is with how it handles systems that already have some of the dependencies installed. However, I can outline some basic things that I require to develop software on a Windows platform (aside from patience, alcohol, and a very, very, very good reason...)

1. Netbeans / Eclipse

Some people don't like Netbeans; I do. I use it exclusively on Linux for all of my development. We could get into the IDE war, but I see no reason. People should use the tool that works best for them, and for me, Netbeans hits the mark. It is a bit slow on start up, depending on your system specs, but my machine is a beast, so no issues there. I prefer to use Netbeans for all of my file needs under Windows. (Wordpad / Notepad leave miles to be desired...) Netbeans has also recently released a C/C++ addon pack that offers all of the goodies for those languages - code completion, standard library reference, syntax highlighting, header files, makefiles, etc. My original draw to any sort of IDE was simply syntax highlighting and automatic indention; I never used it to complete code for me or anything like that. In fact, I always felt hindered by code completion because I felt I had to actually do MORE thinking to get something done rather than just knocking it out by hand. As time has progressed, I have found it useful having a reference to my own classes that I've created so I don't have to switch back and forth to see the variable names I used and whatnot.

2. Mingw32

I was recently turned on to this UNIX emulation environment because I wanted to have access to gcc/g++ under Windows. There is a one-click binary installer floating around on the net somewhere that gets you up and compiling with gcc/g++ in a matter of minutes. You also get some other basic UNIX tools and utilities, like vi, make, etc...

3. Command aliases

Good habits are pointless to break, so I make sure to alias all common file system navigation commands in Windows to those in UNIX. For example, ls, rm, cp, mv, etc... This just involves making various .bat files with the UNIX command as their name, and having them execute the Windows version of that command using the "%" to signify the command arguments. Really basic and simple. Of course, with Mingw32, you don't have to do this.

4. Path Variables

I always fight with path variables in Windows, so I have to go in and make sure all of my java commands are in my path, as well as the above-mentioned alias commands. It may be a good idea to make your own folder for the aliased commands and add that to your path, as opposed to dumping all of those .bat files into system32.

That's about it, really. As long as I can type commands I'm familiar with, edit files easily, and have them compile easily, I'm happy. Essentially, it can be summed up into about 2 downloads depending on how you do it. Via the Java website, you can get Netbeans bundled with the Java SDK, and then you're set with Java. Then, Mingw32 is one download and you're set with all of the UNIX tools, including gcc/g++. The other things are just basic configurations.

I hope this has been helpful for those of you that develop primarily on a UNIX based system, as I do. I honestly feel I get stupider when sitting in front of a Windows computer. I've got 2 Windows certifications and I've been involved in administration and tech support (hardware and software) for about 7 years now, but I'm always more productive and comfortable (and happy) sitting in front of anything with a BASH prompt.


1 comment:

Unknown said...

I actually do use Eclipse - but I still wish OpenMRS too used Maven/Maven2 project files to:

1. standardize builds (cross-project that is - run e.g. "mvn install") - though using Ant isn't that bad :)

2. your source can become IDE-independent (Maven can generate project files for Eclipse and Idea through plugins, there's a Netbeans module too, and I heard Netbeans would support Maven project files built in soon) - meaning you can avoid commiting those .classpath and .project files.

3. avoid all those jar-files in the repository - Maven downloads them to a local shared repository on your computer - meaning I would probably have avoided downloading most of the dependencies as I already had them. In Maven you just specify artifactid, groupid and version of a dependency for a module/project and then Maven fixes the rest.

Not 100% sure it would be painless to move OpenMRS over to Maven though, those Ant-scripts do a lot of things. Maven works well for DHIS though. :)