Improving Your AIM

One of my biggest treats of No Fluff, Just Stuff symposia is the conversations you get into before and after. On the way to the airport in Orlando, Glenn Vanderberg, David Bock, and I shared a crowded airport shuttle (with a bunch of vacationers who didn't share our conversation). Glenn talked about some fascinating writing he's doing with feedback loops in Extreme Programming and David talked about the Agility Index Measurement. My contribution? A interested but dazed stare.

David has since blogged about AIM (nice acronym, very managerial) here. He's soliciting for people to help him develop a more or less objective measurement of just how agile a team really is. To quote: "the point is I WANT A WAY to compare the capabilities of teams implementing these [agile] processes." If this topic interests you, wander over to his blog and put your own $0.02 for what categories should be measured.

Riffin' at No Fluff, Just Stuff

One of the early histories of Saturday Night Live talked about the first meeting of the writers. Even though they had never met one another, and were from different parts of the country, they had a common language and thought that the same kind of things were funny. It was compared to jazz musicians, who can jam with one another even if they've never met, because they share the same vocabulary (and, dare I say, are familiar with the same problem domain).

The same thing happened last weekend at No Fluff, Just Stuff in Orlando. One of the speakers became ill at the last minute, and the organizer had to scramble to find speakers to fill his spots. I filled one of the talks, about fallicies in enterprise architecture, after never having seen the talk and having a whole 10 minutes to look at the slides for the first time. However, the talk came off really well -- I managed to talk for the entire ninety minutes, and got good scores. Because the problem domain was familiar, I was able to extemporize the talk, bringing my own experience to bear. This talk wasn't about tools or APIs, but about common fallacies developers face in enterprise situations. Well, I've seen a lot of that. Of course, I'm sure my rendering of the talk is no where nearly as good as the original and that the stories and experiences I bring are completely different from the original speaker. However, it reminded me of a jazz trumpet player showing up to a gig and saying "'Girl from Ipanema', extra solo after the chorus, and watch me for the finish. A-one, and-a Two, and...".

The Next Revolution: Language-oriented Programming and Language Workbenches

If you subscribe to Martin Fowler's blog, you've probably already read about Language Oriented Programming and Language Workbenches. He has very nicely encapsulated and clarified some of what I've been thinking for a while and added some badly needed organization to the topic. I've been doing a No Fluff, Just Stuff talk this year about Building Domain Languages atop Java, and it has been received very well in the cities I've where I've given it. Now, I'm about to revamp it and make it a Language Oriented Programming talk instead, taking the material I already have and adding discussions about LOP in general and workbenches. I'll also start showing JetBrain's (the makers of IntelliJ) cool new MPS meta-programming tool. It's still rough around the edges, but still very interesting. You have to have the early access version of IntelliJ (code named Iridia) and the MPS plug-in, but you can download all these goodies at JetBrains' site.

Centralized Help in Eclipse

As further proof that I embrace all IDE's (besides my beloved IntelliJ), I have just published an article on IBM developerWorks site about building centralized help in Eclipse. One of the really cool things about Eclipse is that everything important, including the help system, is built as a plug-in. This article shows how you can externalize both the built-in help and help you download with plug-ins into a central place. You can also turn the Eclipse help into a kind of wiki or other kind of collaborative document management tool without too much effort. The help system is quite flexible, as this article shows.

Windows eats itself?

I think my computer was trying to tell me something the other day:



So even Windows doesn't trust Windows Explorer anymore. Hmmmmm...

What You Know You Know, What You Don't Know, and What You Don't Know That You Don't Know

Blogs are a great way to show what you know and also a great way to show what you don't know (and can learn). I blogged yesterday about how to chain 2 ant calls together via Bash. Several comments showed that there is definitely more than one way to do this. You can use the "&&" in Windows to chain commands (which I had seen in the past and promptly forgotten). This also works in Cygwin's Bash because most of the stuff that works in the Windows command prompt also works there (Reason #432 to use Bash). However, I didn't know that you can chain targets together on the command line for Ant! I've been using Ant since early 2001 (I know the time frame because I wrote the first Ant article for Java Developer's Journal in June of 2001), but I didn't know about this handy-dandy little trick.

This illustrates, to me, one of the best reasons to have a public forum like a blog. You inadvertently learn all sorts of stuff if you are brave enough to try to teach others what you already know -- including stuff that you didn't know that you didn't know.

Reason # 431 Why You Should Use Cygwin/Bash Instead of the Windows Command Prompt

I'm working on a project right now that has a huge number of classes, and a corresponding huge number of tests. The whole thing builds via Ant (big surprise there). Currently, I'm writing code in a fairly isolated part of the project, and I've been working a few days on getting a new class Just Right. Getting it Just Right, of course, means unit tests and test first coding. The upshot is that I find myself needing to run the build target and then the target that runs the test suite over and over. I like to run both ant targets at the same time, but I need to know if the build doesn't work (e.g., if I get a compiler error, I don't want to run the tests). Rather than monkey with the ant build file to add this transient behavior, bash comes to the rescue. More and more, I do all my command line stuff in bash for reasons like this. Here is the command I invoke 30 or 40 times a day (all on 1 line, it may wrap here):


if ant; then ant runatest -Dtesttorun=com.thoughtworks.logging.AllTests; fi


This runs the default ant task (which builds everything). If the return code is 0, it then runs the "runatest" target. The test runs only if the build was successful. This little trick takes advantage of the fact that ant is smart enough to tell the underlying OS (regardless of the shell) if it passed or failed. The "fi" at the end is the "end if" indicator for bash.

Yes, you can create the same kind of little batchy kind of thing in Windows, but I never think to. It seems somehow more natural to me to think in terms of automation, shell scripts, and command chaining in bash than it does Windows. Maybe it's because bash is far, far more powerful than the command line tools in Windows. I never run anything in a Windows command shell now that I unless I'm forced.

Notes from Singapore, Part 1

When talking to the natives in Singapore, I and a friend (Terry) heard about Durian ("Stinky fruit"), which is a local fruit. I always ask about local foods from the natives to see what I can try that I haven't had before. It is against the law in Singapore to take a durian on public transport. And it is forbidden to take the fruit inside most buildings. However, several locals at the table said they really liked it. My new mission: try some durian. We ate one night at Newton food court, which had fresh durian, so we got one. Tom, who lives in Bali , is a big fan, so he would eat it if we didn't care for it. Well, they cut it open and Tom insisted that we eat it essentially holding our nose -- the flavor and the smell are only loosely related. So I tried it. Frank said it best -- it's like a mixture of vanilla pudding and onion, with a kind of fruit-flesh/fishy texture. I tried it. It was durian-like. OK, I've tried it. The problem is that, even though I only had a bite, I kept trying it -- the taste would not go away. I ate some other stuff. Still there. Drink water, beer, whatever -- durian. After a while you can sort of get rid of the taste until you have the misfortune of burping. Durian. Stronger than ever. It keeps growing. It was well into the next day until I could taste something else. It took Terry even longer. In fact, he developed a semi-permanent association between Tiger beer and durian taste. He may never appreciate Tiger beer again. The other interesting aspect of this fruit: it smells. And it gets stronger and stronger. It was still at our table because Tom (for whom I have new respect mingled with pity) was gradually eating the leftover durian (all the durian except for one bite each from the other victims). Ingo (one of the speakers) kept asking Tom to move it further away, because the smell, while not exactly the same as the taste, is the olfactory equivalent of the taste. After you have smelled it, you smell it everywhere. For the rest of the trip, we could tell anytime we got close to durian. Terry and I would look at each other at the same time: durian. Every open air market you come to sells that stinky stuff. And you always notice it if it's near. You have been warned.