This video was captured at the Chicago ALT.NET August 13th meeting. This first video is the Cruise presentation.

This month's Chicago ALT.NET meeting was pretty awesome and it was all caught in video. As soon as I have some time to do some post-production on the raw material (read, just stitch pieces together) I'll make it available somehow.

As previously mentioned we started off with a presentation of ThoughtWorks Cruise, where Robert Norton explained the idea of CI server, Agents, Pipelines and went through many of Cruise features, system requirements, and futures. He also clarified his company's position regarding CruiseControl.net, which will most likely not receive a lot of attention in terms of funding, being left for the community to keep it going.

Cruise seemed promising to me but it's clearly a typical version 1 product that needs some work to get enthusiastic thumbs up from me. Hopefully they move quickly and release a few updates before the year is over to make the product top notch. I don't mean to say Cruise in unusable. It's definitely usable and does things in a very smart way. Given time I'm sure they will take care of the rough edges and have a chance to answer customer feedback. My particular concerns tend to be on the side of ability to integrate with other systems in the enterprise, like your bug/feature tracker.

After the presentation portion we all sat together for an open discussion. The fallback topic was CI practices but what the group really wanted to talk about was Agile teams and their dynamics, so that's what the discussion became. As usual, that's my favorite part of the meeting and it's a pity that only 50% of the attendance stuck around for it.

It's nice when you go to a meeting like this and can take home a lot of new knowledge.

As you may have heard, ThoughtWorks, home of CruiseControl.net, has just released Cruise, their commercial product for CI and beyond.

As soon as we heard that news we immediately thought: It would be great if we had someone from TW give us the scoop on that product — especially considering that they already host our meetings. ThoughtWorks was completely on board with that idea and immediately offered to have someone fromt he Cruise team talk to us.

I think we will have a very good presentation and debate. If you are in the area, come join us.

Continuous Integration with Cruise

6:00 pm
Pizza and networking time

6:30 pm
Come see Robert Norton, tech lead of ThoughtWorks Cruise CI/Release Management product, talk about Cruise and how it helps managing software builds and deployments. ThoughtWorks is the force behind the Open Source CruiseControl.net and this new product is their commercial offering in this segment.

7:45 pm
After the Cruise presentation, let’s delve into more discussions about CI and configuration management. Bring your questions and experiences.

• How complete should CI be?
• How frequent?
• How fast?
• What tools are we using for CI?

by: Darrell Mozingo

December 2006 was a low point. The company had lost some good developers, projects were stalling, morale was low, and the outlook simply wasn't good. It was the usual story, probably heard thousands of times before and still lived by thousands more: cowboy coding in continuous crunch mode. Page behind line counts were climbing into the mid four digits and the simplest changes had huge rippling effects across not only the current project, but other systems that were so tightly coupled together they were all fused at the hip. I was in the process of flirting with a few other companies at the time too, but after realizing I didn't want an almost hour drive each way every day, I decided to stay and try to help turn things around.

Coincidentally, something also changed in management around this time – perhaps they saw the sharp morale decline in recent months, or read an article that got them thinking, or who knows – and they too decided things had to change. So, the first step was talking them into getting us some quality training, and not just the ‘ol Advanced ASP.NET training, but some more basic and helpful training, like Object-Oriented Design & Analysis. They agreed, and everyone was thrilled afterwards. We saw all of our current pain points laid out with corresponding ways to counter them using solid OO designs and techniques over the week long course. Sure we all had our OO classes in college, but we'd never really seen how to properly apply them to business applications. First thing after the training, both management and all the developers sat down to lay some new ground work for our future course.

Books were ordered to rebuild our then defunct library, including plenty of juicy OOD books and some old McConnell classics. Online articles started getting sent around between developers for more reading. We started pushing back on clients (who were, in a way, internal clients) to give us time for development. Management loosened the budget for new hardware and software. Things started looking great, and it all happened in only a few months time. It was amazing. Sure, there were still things that needed to change, but we were definitely heading in the right direction.

Before "the transformation" had even began, several of our internal clients had been wanting complete new systems (some were still running classic ASP, some had completely changed their business model, etc), but they weren't quite ready yet. So we kept chewing on existing work that needed done. For almost a year afterwards we tried the various techniques we learned, along with some new ones, on existing projects and several smaller new ones. OR/M's, small scale unit testing, decoupling, CI, and more were all being tried and accepted within the teams. With these large, green field, development projects looming ever closer, though, we were still hitting pain points using these new techniques. Clients weren't completely happy, and there was still something just not sitting right with us developers.

One of the newer developers – not junior, just new- had been looking into adopting RUP at his old company. IBM agreed to come in for a quick one day assessment of our current lifecycle process, where they'd sit down and talk with our clients too, and give us suggestions for improvement (sales pitch, anyone?). When they gave their review, though, it hit me like a ton of bricks. We were using good development techniques, sure, but inside an almost pure waterfall structure. We all knew waterfall wasn't the way to go, but we were totally wearing blinders to the fact that we were even doing it. Whoops! Oddly enough, IBM pushed a very agile form of RUP on us afterwards, so we took a look.

Since then, some teams have adopted a more formal RUP framework, while others, like mine, have gone with styles leaning heavily towards agile. I'd done tons of reading for quite awhile, and a bit of playing in my off time, with test driven development, so I pitched it along with the new ASP.NET MVC framework, and they took it. The team I'm on is small, with only two other developers working on a large, green field payroll application, so acceptance is usually easier to get.

We're now on iteration 3, developing in a completely test-driven way (though we still catch ourselves doing some test-after-development, but we're working on it!), delivering functioning software to the users a little bit at a time using as "many practices" from the ALT.NET community as we can. We're not completely agile – we're not really doing user stories and planning as, say, an XP team would, but I'm sure we'll fall into that eventually. One piece at a time we're converting over. We're also very interested in BDD and DDD, too, and are looking into it while adopting some of those practice's lower hanging fruit.

So far our users are thrilled with the software, we're very happy with the design and testing being built around it, and I'm absolutely loving my job again. We've come a long way in a relatively short amount of time, and things continue to get better every day. To think, I almost quit.

Chicago ALT.NET meets this Wednesday, July 9^th again at ThoughtWorks. You can register and get more information about the event at the link below.

Mock Objects In Practice

6:00 pm
Pizza and networking time

6:30 pm
This month's topic is Mock Objects, or simply "mocking". The agenda to guide the discussion is not set yet, but below is a list of items we'd like to cover. Feel free to add more to this list by making your suggestions in the mailing list.

• We want to see code, not just talk
• What and how hard or easy to use mocks are?
• Are they just for testing?
• Aren't they just noise?
• Tools
• How to do mocking well
• Does the habit of using mocks lead to good design? Or the reverse?
• Is TypeMock evil?