Uncle Bob has posted a nice video covering basic usage of the new SLIM framework within FitNesse. It appears to streamline some (but not all) of the annoyances of the current FitNesse processing.
I have yet to try it, but it certainly looks promising, especially for people writing tests for multiple platforms.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
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:
Anyway, for those who are interested, here are the abstracts that I submitted:
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:
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).
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.
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!
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?
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!
Thanks!
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!
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?
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.
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:
-showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -Xms256m -Xmx1024m -XX:MaxPermSize=324m
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.
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!
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: org.apache.maven.wagon.Wagondav.
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):
http://repo1.maven.org/maven2/commons-httpclient/commons-httpclient/2.0.2/commons-httpclient-2.0.2.jar http://repo1.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar http://repo1.maven.org/maven2/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar
(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!)
Subscribe via Email
Subscribe in a reader
