Growl Maven Integration

Well, not really. I am copying and pasting something directly from Lars Trieloff that shows a bash script that wraps the mvn executable, pipes its output to awk, and sends selective notices to growl. You will need to have the growlnotify exectuable installed to use this.

#! /bin/sh
/usr/share/maven/bin/mvn $* | awk '
{
print;
if($0 ~ ".*ERROR.*") system("/usr/local/bin/growlnotify -n mavenError -t Maven Error -m\""$0 "\"")
if($0 ~ ".*BUILD SUCCESSFUL.*") system("/usr/local/bin/growlnotify -n mavenComplete -t Maven FTW! -m\""$0 "\"")
} 
END {
}'

Pretty neat.

Paying Attention Outside of your Discipline

I have a problem of staying too focused on what happens inside my own discipline and industry. For example, my list of RSS feeds that I try to read daily is composed of about 95% technology and software news - with the remaining 5% devoted to feeds from Slate and xkcd. Basically, I am up to speed on software news, a couple of national and world editorial pieces, and a funny geek-centric comic. In other words, I think I fit the stereotypical reading pattern for a developer who doesn't leave his editor/IDE... ever.

Well that might be detrimental and keep me (or you, if you have the same reading pattern) from reaching our full potential for creating awesome stuff. Here is why - read this article on Wired about a ophthalmologist named Edward Chaum. The gist of the article is that Dr. Chaum visited a semiconductor research laboratory, saw how automatic image analysis helps find defects in hardware that humans otherwise would have a hard time finding based on, what I am assuming to be, some case-based reasoning machine learning. Dr. Chaum then applies the same technology and techniques to retinal scans. His retina scanning devices are now being placed in communities in rural areas (the Mississippi Delta, for instance) where ophthalmologists are not exactly accessible and diabetes rates are high. Given that diabetes if left untreated can cause blindness, there is an urgent need to be able to supply such detection to those who otherwise would not find a reasonable way to see an eye doctor.

Pretty cool huh?

So how does this apply to us software geeks? Well, Dr. Chaum's idea most likely would have not come into fruition had he not visited a semiconductor research lab. Practically speaking, an ophthalmologist under normal circumstances has no reason to be visiting a semiconductor lab - what has that got to do with being an eye doctor, one might ask? "Probably very little", would have been my answer five minutes before reading the article.

However, Dr. Chaum's case is one of someone crossing over to a different discipline or industry, seeing what is happening over there, and finding a way to apply those developments in a beneficial way to his own field. Perhaps we as software writers should do more of the same? I get the impression that many of us write software or facilitate software development for the love of the technology and the mental stimulation it brings us, but not for what the technology enables. I hypothesize that this is because we have not tried or just simply do not draw inspiration from other fields, typically. I most certainly do not at the moment, I'm afraid to say. If we learned and explored a variety of disciplines, even at the basic level, our creativity might be spurred to go out ourselves and enable something like Dr. Chaum has and apply our own expertise to using existing technology to real problems faced outside of own little bubble of thinking of only frameworks, languages, tools, etc. etc.

What do you think?

<barbie>deployment is hard!</barbie>

Except that Barbie is not kidding. Here is a link to an excellent post by Mr. Dan Diephouse (you know, the fellow who is responsible for XFire and is presently employed over at Mulesource).

For one, it is very refreshing to see a developer publicly acknowledge that deployment is a hard problem. I often get the impression that deployment gets taken for granted, or it is at least not publicly talked about or given much attention. It should though - what good is software if you can not get it installed and running on the target environment.

One of my primary functions at the day job is owning all technical aspects related the deployment of several web applications and web services with a fair number of interdependencies. While the post Dan made highlights the usage of some tools to help automate things, I have to admit that even getting to a point where you can automate can be pretty tough - especially in an environment where you have many dependencies to worry about (and to coordinate across multiple groups, such as DBAs since I have been instructed to not touch the data tier directly). At this point my automation is crude - a set of scripts that can pull down a build from a local maven repository and install it in a given container. It is ok, but because of certain things needing to happen in a certain (variable) order, most of the process remains manual.

What I would be curious to know is what other folks in the build and deployment business do to automate deployment to the environments in a full-proof (if possible) manner when there is variable sequential order involved? Any takers?