Skip to content

CodeMash Presentations

2008 November 13
by Nayan Hajratwala

The sessions for the upcoming CodeMash conference were announced on the email list last night. It looks like a great list of sessions that will be posted shortly on the official site.

Unfortunately, the sessions that I submitted were not selected. There’s always next year, but in the spirit of optimism there are a couple nice side effects of this:

  1. More free time since I don’t have to prepare presentations.
  2. More time at the conference to play Rock Band. Please tell me someone is bringing it. =)

Anyway, for those who are interested, here are the abstracts that I submitted:

Enterprise Build & Deployment Ecosystems

One of the most forgotten/ignored aspects of software development is the build/deployment process. Teams tend not to give it much thought until a couple weeks before actual deployment time, and then ad hoc solutions are rushed into place that sometimes create more problems than they solve.

Build/Deploy nirvana consists of:

  1. Low setup-cost for new team members
  2. Code AND Database version control
  3. Easily repeatable builds
  4. Automated release versioning
  5. Pushbutton deployments to all environments.

This session will present a set of Best Practices(TM) needed to make this vision a reality, as well as one possible implementation using Maven (Build), Hudson (Continuous Integration), and LiquiBase (Database Change Management).

ICEfaces: Ajax Interfaces with JEE Power

Tired of fighting with Javascript to build an AJAX-enabled application? Sick of developing UIs that are not easily integrated into your JUnit test harness?

ICEfaces is a fully Ajax enabled implementation of the JSF (Java Server Faces) specification. Build all your components in (testable) Java, write your pages with ICEfaces/JSF tags, and ICEfaces magically generates the cross-browser Ajax interface elements with dynamic updates.  You can leverage the full enterprise power of the JEE stack with ease. It’s open source too!

This session will present the fundamentals of ICEfaces, it’s benefits and drawbacks, as well as how you can start using it in your application.

Iterations are Bad for Your Health

2008 October 28
by Nayan Hajratwala

Well, not really, but iterations are not as important some of the Agile community makes them out to be, in the way that they are typically thought of.

Short iterations. Long iterations. Who gives a rip? The important thing is that you are regularly tracking your team’s velocity. Take this Big Visible Velocity Chart from my current project:

Ouch! That Velocity Hurts!

Ouch! That Velocity Hurts!

We track velocity weekly (using Ideal Days), only counting up the velocity for stories that are completed before Monday morning. As you can see, we seem to have developed a fairly regular cadence of slow week/fast week/slow week/fast week… So what’s going on here? Do we bring a keg into the team room every other week? Are we really bad at estimating?

Actually, the cause of this sawtooth motion is simply that we tend to not be *quite* done with things in a given week, so a lot of the stories get counted in the following week’s tally. For example, in Week 7, we had two 4 iDay stories and one 2 iDay story allocated. The 2 iDay story was completed by the end of the week, but the the 4 iDay stories didn’t get finished until the following Monday afternoon. Therefore, we counted 2 iDays for week 7, and the remaining 8 were lumped into the week 8 metric.

Now, we could get into a big discussion about how our stories are too big, or that our iterations are too short, but in reality it doesn’t really matter. What matters is that from the data we’ve collected, we can come up with a fairly accurate measure of our teams velocity. (We had a string pulled across the chart that we adjusted each week to indicate the trend line, but the tape wasn’t strong enough to hold it up). We can use that velocity to estimate our team’s capacity and deliverable dates, and have done just that on this project.

By the way, in case you hadn’t noticed, this chart is *proof* that our team’s velocity is “off the charts” 🙂

What do you think? Are iterations overrated?

Michigan Agile Enthusiasts Chair

2008 October 2
by Nayan Hajratwala

Hello everyone —

I’m running for the chair of the Michigan Agile Enthusiasts Group — If you get a chance, join up and vote for me!


CodeMash 2009

2008 July 15
by Nayan Hajratwala

The CodeMash 2009 Conference in beautiful Sandusky, Ohio was just announced.

Last year was a blast. In addition to the copious amounts of Rock Band that was played, and waterslides that were slid on, I presented a session on Continuous Integration. This year, I plan to propose a session around deployment and artifact management. Sounds exciting, right?

See you there!

Agile Dress Code

2008 June 3
by Nayan Hajratwala

Last weekend was the Agile Coach Camp here in Ann Arbor. There were a lot of very interesting folks there, and as always happens in such situations, plenty of learning happened.

On the first evening, we had Lightning Talks, during which I presented an idea that had been brewing in my head for a while. It seems a little silly at first but I think it has some merit.

Basically what it comes down to is that I want to wear shorts and sandals to work. Things may be different on the west coast, but here in the midwest, jeans are about as casual as you can go without raising quite a few eyebrows.

The fact is that if you’re not in front of customers on a day-to-day basis, it really shouldn’t matter what you wear. You and your employer should strive to make you as comfortable as possible, thereby making you more productive.

My proposal is for the Agile community to unite and suggest to clients during Agile Transformations, that a key element to reaching Agile Nirvana is to free their staff of the corporate dress code.

Now, I’m the first to say that there need to be limits, but I think we can trust teams to exercise enough self control and common sense to make it work.

Who’s with me?

Moving a Subversion Repository

2008 May 7
by Nayan Hajratwala

I had to move a Subversion repository from a really slow crappy server to a shiny new one today. Luckily I found a blog entry that made it super easy.

Preventing Eclipse OutOfMemoryError & PermGen messages.

2008 April 10
by Nayan Hajratwala

I’m always having to remember/lookup what I should put in my Eclipse settings file (eclipse.ini), and I’ve run into many a colleague frustrated with OutOfMemoryError & PermGen messages.

I also have a rather large list of installed plugins, so I’ve recently upped the max memory numbers which has provided me with some more speed & stability.

So, without further ado, here is my current eclipse.ini file:


The second XX:MaxPermSize will prevent all those nasty PermGen errors.

Note that I’m currently using a machine with 4GB RAM. You should be able to safely cut down the sizes on machines with less.

Hudson Naginator Plugin

2008 April 9
by Nayan Hajratwala

I just released my first Hudson plugin called Naginator, which allows Hudson to automatically re-queue a build after it fails. (The name was suggested by my colleague Mike Gantz)

Check it out!

Maven Multimodule deploy via WebDAV Wagon

2008 March 26
by Nayan Hajratwala

Although a single, independent module deployment worked fine, I couldn’t get my multi-module deploy working properly via the webdav wagon.

I’m talking about the simple mvn deploy command (versus mvn deploy:deploy-file), which must work if you ever expect to be able to do a mvn release:perform.

The error that I was seeing was:

Error deploying artifact: Unsupported Protocol: 'dav': Cannot find
wagon which supports the requested protocol: dav

Component descriptor cannot be found in the component repository:

In the comments section of the Maven User Guide, there is blurb saying to put a bunch of libraries in the $M2_HOME/lib directory. While it seems odd, it fixed my problem. The comments are for wagon 1.0-beta-1. Here is the minimal list of JAR files that I needed to get it going for wagon 1.0-beta-2 (NOTE — You must use the older 2.0.2 version of httpclient):

(Update 2008-04-10): Maven 2.0.9 has just been released, which includes the webdav wagon by default, and does not require any of this configuration — yay!)

Integrating FitNesse with Spring

2008 March 24
by Nayan Hajratwala

If you don’t want read my fascinating commentary, you can skip directly to the solution.

Whenever I’m working with Spring, I tend to go through the following pattern:

  1. Get annoyed at how complicated and/or tedious problem X is.
  2. Think to myself: “I bet Spring has a way to do this more easily.”
  3. Glance over the Spring Reference Documentation and determine it is indeed possible. Yes!
  4. Start implementation using Spring.
  5. Get frustrated as the amount of Spring code & XML seems to grow exponentially.
  6. Read the Spring docs again.
  7. Replace what I did in step 4 & 5 with a few lines of Spring code, since I now actually understand what is going on.

This was the pattern that I went through with a colleague at my client over the past week or so as we were trying to implement set up FitNesse to call a Spring service.

My first thought — surely FitNesse has a way to do this already. Well lookee here … the FitNesse SuiteFixture seems to fit the bill: “Each suite can provide different configuration information, such as selecting a DB or Spring configurations”. Whoops, did I mention that there are no example, and a google search reveals just about nothing.

Next — The spring-fitnesse project seemed to hold some promise… I bailed out when I read the instructions: “Compile the library: Modify to match your installation. Then start ant.” Why don’t they just distrubute a compiled library? Maybe we’ll come back to this if nothing else pans out. <nose-in-air>Plus, I’m a maven guy now, so dropping back into ant seems so last year.</nose-in-air>

Over to this blog posting: The Magic Ingredient for FitNesse, Spring … Could this be it? It’s kind of solving a different (more advanced) problem than we were having, namely getting each FIT test to run in a transaction, and rollback any data changes at the end of the test. We didn’t have this need yet, so modifying the actual Fit Server code seemed like overkill.

Finally, we ran across How to wire your FitNesse fixtures with Spring. This seemed to hold the ticket, but something just didn’t jive. I left a question in the comments (which has since been answered, and may indeed also solve the problem), and continued the quest.

By this time, it was clear that the problem was that the FIT fixtures were invoking my POJO Spring service bean outside of the Spring container, and thus none of the Dependency Injection, etc. was taking place. Going back to the Spring docs (see step 6 above 😉 ), it became clear that we were overly complicating matters, and that all we needed to do was have the fixture instantiate the Spring container and then get a Bean from it. Thus, the Fixture code ended up as:

public boolean isValid() {
    BeanFactory beanFactory =
        new ClassPathXmlApplicationContext("classpath:/spring/applicationContext.xml")
    loginService = (LoginService)beanFactory.getBean("loginService");
    loginService.validateUser(username, password);

Obviously, a lot of refactoring can go on here, including moving this setup stuff into a base class, making the bean factory static, etc. — this gets us going however!