Mental Pandiculation

I’m currently trying to get some unit tests written around a bunch of JavaScript code and I’m using JsTestDriver to do it. So far, I’m pretty impressed though there are some little gotchas here and there. It’s been a really good framework for basic testing assuming you aren’t doing a ton of work with other libraries like Prototype.js and script.aculo.us which of course I am. I’m sure there are ways around it but it’s going to take some digging to figure out what they are.

One minor thing that has been different for me from the documentation is that when I try to run tests, I need to specify the server explicitly on the command line even though I have a server running and a browser captured. The documentation says you can do this:

java -jar JsTestDriver.jar --tests all

.

However, I’ve found that I need to do:

java -jar JsTestDriver.jar --tests all --server http://localhost:9876

Where the server value may be different according to what server you started up.

Now I’m off to figure out how I can mock some of the Prototype.js dependencies.

This has been around a long time but I just heard it today. Text is here and audio is here. Very amusing.

I am just beginning to play around with Git and so far I’m pretty happy with it. One thing I love about it is that the concept of branching is just part of the model. Branching is critical to successful software configuration management (SCM) and it’s a topic that strikes fear into the heart of any developer who has never done it. The idea of having all these branches that you have to eventually merge and bugs to fix and AAAAHHHHHHH!

Sigh. Of course this comes from the fact that most of our SCM tools have been craptacular at dealing with branches and merging. This craptacularness is built in to most of them because of the centralized server concept (though Perforce is spectacular, the opposite of craptacular, at branching and merging). On top of that, most Microsoft developers first and often only exposure to SCM is SourceSafe which is like driving a Pinto for your entire life. SCM in a robust environment is necessarily complex but it doesn’t have to be impossible and using the right tools changes the game. The new distributed source control tools like Git and Mercurial (which I have a soft spot for since it’s written in Python) are the future of decent development practices.

All this comes from reading a great article detailing how to use Git successfully to manage software development. The author details exactly how his team has been using Git to successfully branch and manage software changes. I haven’t begun to need all the ideas that his team is using but I hope to one day. Plus I thought my audience of 4 might find it useful.

Glenn Reynolds talks about a shortage of geeks and one of his readers comments that a key contribution to this is when computers stopped shipping with BASIC. Glenn makes the plea to computer makers to include BASIC on the computers as a public service. Of course, Macs already ship with both Python and Ruby, surely superior languages to BASIC and excellent learning languages as well.

On a Mac, all you have to do is fire up a terminal (Apple Key + Space Bar and then type “Terminal”), type “python” in the new terminal and you have a place to start learning programming. Work through the Python tutorial and you’re well on the way to becoming a novice Python programmer.

Of course, on a Windows machine you’re going to have to do a little more work because, well, it is Windows after all.

So I finally broke down and installed ViEmu, a VI emulator for Visual Studio. Matt has been using it for quite awhile and seems happy with it. I’ve been slowly trying to improve my Vim skillz every week, working through the cheatsheet at ViEmu above, learning 5-10 new commands every couple of weeks (yay for Shift-A, so much better than i-Right Arrow key).

I have no idea how good I’ll get at it but since I’m in Visual Studio all day long, surely my productivity will start to increase.

So at my new job, the main development machines are Macs. Previously, I knew a ton of people doing Windows development on Macs though most of the work was done in Parallels, Fusion or Bootcamp. I haven’t been on a Mac since probably sixth grade when I wrote a program I didn’t find on the internet to output Alfred E. Neuman’s face to the terminal. Suffice it to say, I’m out of touch. So I spent 2 hours yesterday just trying to get MacVim installed and bent to my will. This series (where series may be anywhere from 1 to N posts) will throw little tidbits of knowledge out into the interwebs regarding my trials and tribulations with becoming a Mac convert. This will be old hat for anyone with any Linux or Mac background but for someone coming from a purely Windows environment with only a tiny bit of self-taught Linux history, maybe it will help other total beginners.

Lesson 1 involves getting MacVim to correctly recognize Python files with pretty indenting and whatnot. I downloaded MacVim and so far have just left it in the Downloads folder which I’m sure is ridiculous but at least I know where it is. Once that was done, I spent a ton of time getting a .vimrc file set up, mostly because files starting with . on a Mac are system files and hidden by default. This page helped a lot in that regard.

Once that was done, I set about getting MacVim to deal with Python files with pretty indenting and whatnot. One thing to understand right off the bat with MacVim is that “filetype”, “plugin” and “indent” are disabled by default on installation. Before you go creating your own plugin files and indent files, it’s helpful to add “filetype plugin indent on” to your settings file and see what happens. You may not go to the trouble I did overwriting all the defaults. But that’s just how I roll.

I found this helpful post dealing with Python syntax and indenting. The key is figuring out where to put those files. When you install MacVim (or lots of other apps on the Mac), you get a folder typically named .app. You can drag this into your Applications folder and have access to it there instead of leaving things in Downloads. With MacVim, you are going to put your indent and ftplugin files in MacView.app/Contents/Resources/vim/runtime/indent or ftplugin. Once I figured that out, I dropped the files from the link above in the correct folder and of course, everything worked like a champ.

Now if I could just remember that on a Mac keyboard, you copy and paste using the Command key instead of the control key, I’d be set up.

I just installed git, pulled down the latest Clojure code. Thinking about getting a github account and moving some of my Subversion code there just to play. There just aren’t enough shiny jangly things in my life.

I’m a gardener. It’s in my blood I think, something that goes back to both my grandparents who had gardens. My mom has beautiful roses in her backyard. People in my family garden. Like most pursuits, gardening gives back what you put in, oftentimes in multiples as long as the input is over a certain threshold. If you put in the absolute minimum, you can still receive great paybacks as long as you choose plants and flowers that are OK with little help in surviving. If you’re like me, you can greatly increase what you get back out of your garden by constantly improving the process, finding new ways to increase efficiency or productivity, tinkering with results, etc. Regardless of what kind of gardener you are, as long as you don’t give up, your gardens will typically survive.

However, if you stop doing the bare minimum, you will no longer receive any results at all, at least as it relates to producing flowers or vegetables. If you give up or reduce your effort below a threshold necessary to achieve a standoff with nature, nature will quickly take over and your carefully cultivated gardens will return to their natural state, one of abandon and disarray. There may still be rare successes but they are random and always under attack from weeds, drought and pests. A rose left at a country house long abandoned may continue to bloom for many years but the plant will constantly be surrounded by weeds and pests.

Software projects are not unlike gardens in this regard. Different types of projects require different levels of attention but they all must have a leader of some sort. There is often talk of self-organizing teams that turn out solid results but these teams were typically either brought together by a leader who remains engaged in some way or are comprised of individuals who express leadership in different ways within the group. If a software project does not have a leader or the leader is distracted from the needs of the project and team, the project will begin to deteriorate. Almost immediately, the entropy of nature will set in. Weeds begin to sprout up. Edges begin to deteriorate. The structure of the project erodes and dirt seeps out of the cracks. Without leadership, no project can stand up to the force of natural entropy. Once that entropy takes over, it takes an inordinate amount of work just to get the project back to a functioning state.

This is an aspect of all methodologies, but specifically Agile (big A), that is often overlooked and undersold, that of strong leadership. The literature often talks about the team, self-organizing, Gestaltic, productive. But no team survives that way without leadership though the leadership can come from within the team instead of the typical all-knowing leader. Someone (singular seems preferable though I know of teams that have 4 leaders and 1 team member that work reasonably well) has to turn on the sprinklers, pull the weeds, mulch the ground, apply small dosages of fertilizer so that the team can become more than the sum of its parts. Without that strength of will and character, the team will almost always devolve over time into an incoherent mass of movement, undirected and inefficient.