SpeakENG

Some time ago, Packt Publishing sent me a copy of Hacking Vim: A Cookbook to get the Most out of the Latest Vim Editor by Kim Shulz to review. I read through it pretty quickly and I must say I thought it was a good book for the most part. The book is definitely focused at a very niche audience as there aren't a lot of us Vimmers around. Furthermore, I can't say I'd recommend the book for the casual Vimmer or those that use only ViEmu in Visual Studio. If, however, you are a moderate to hardcore Vim user or are interested in becoming one I would definitely recommend grabbing a copy.

There is a lot of information in this book. It wastes no time or space describing the many ways to make your Vim experience even more efficient than it already is. Because of its very cut and dry style it reads more like a reference book than anything else, but I think that's perfectly fine for this style of book. It is essentially a slightly more readable, more detailed and better written version of a lot of the Vim help. It's also nice because in many of the chapters, especially the first few ("Better Navigation" and "Production Boosters") you can pick up a lot of interesting tips. I even learned a few handy commands I had no idea about.

There's plenty of good information on writing Vim plugins and customizing Vim that I wish I would have had six years back when I wrote Vim plugins. Ah, looking at that code brings back fond memories, mostly involving learning Regular Expressions through trial and error and I actually used /// comments in C# code, but I digress.

I also liked the stuff on firing Ruby from Vim--it reminded me I need to get a Ruby environment set up in Vim. Oh, and just for fun it seems, Kim even included an appendix showcasing some of the ridiculous things that have been written for Vim like Nibbles and Rubik's Cube. Heck, I just found a Twitter client for Vim (yea, I twitter now in case you care).

There are a few things wrong with it though. Some things are too close to the Vim built-in help and you're probably better off just looking there. Also, the index isn't very useful and it'd be nice to have a searchable version of the book as well, so maybe the eBook version is a good idea. I wish all book companies would bundle eBooks with paper books, but, I digress again. Like I said, there is a lot of information in this book. It's not for everyone, but I think most Vim users will find plenty of useful stuff in its pages.

One of the first things we did when we got a dedicated development server was set up a continuous integration server. The natural choice at the time was CruiseControl.NET, so Jacob set off to get CC.NET installed and configured. I can't speak to that experience first hand, but I know it wasn't a fun one. Lots of XML hell and other non-fun issues. The end result wasn't too bad--it'd email us when builds failed with a log, and we could review logs on our CC.NET site. There was really nothing WOW about it--it got the job done. It was frustrating at times because the logs it spat out were difficult to visually parse; it was basically just a verbose msbuild log with a failure mixed in somewhere... and that was if we were lucky enough to get a text log and not have to filter through the build xml log. I'm sure there are some things we could have done to filter that log down, apply xslt to our build.xml to make it more readable, or configure things to be nicer, but I'm also sure it would have involved hard work and more XML hell.

Enter the free Professional Edition of TeamCity 3.0. We'd tried out TC briefly in the past and it seriously lacked in the .NET support arena. Now they tout support for msbuild (2.0 and 3.5), sln files from 2003-2008, and even a nifty .NET duplicate code finder. They also have some pretty slick support for NUnit which I'll get to in a moment.

I decided to give it a shot again, so I set up the TC server on our Ubuntu VM. Why there? Well that's where most of our server tools are: SVN, Mingle, FogBugz and now TC. But wait, aren't we a .NET shop? Yep. The build doesn't happen on our Ubuntu VM. See, TC is set up to have a server + build agents. A build agent is basically a machine that will check out code, do the build when the server tells it to, and report back results and artifacts to the build server. This way you can have multiple Build Agents--different Operating Systems, system configurations, physical locations, etc.

Installing both the Server and the Agent were relatively straight forward. There were a few annoyances with the Agent's configuration (like I couldn't get it to use a network drive as a working directory and it took some tweaking to get things to work with our directory structure,) but after a while I got things up and running.

Setting up a build configuration in Team City is an absolute breeze. You basically have a 7 step Q&A about your configuration:

1. General Settings - Name, Description, a few options and the build number format (we use our SVN revision #)
2. Version Control Settings - You can set up multiple repos to check out with a number of tools (SVN, CVS, Perforce, StarTeam, ClearCase). I'm sure it wouldn't be too difficult to write plugins for Mecurial or Git. You can also tell it where to check out relative to your working directory and whether or not you want it to check out to the agent or on the server and then have the agent download it.
3. Build Runner - Mainly .NET and Java stuff. No Rake yet, but it supports command line so you could just use that. With MSBuild you just specify your MSBuild file, the target you want to run, and any command line args you need. It's here that you specify your build artifacts as well. Build artifacts are kept along side your completed builds and easily accessible from the TC site.
4. Build Triggering - You can trigger based on VCS changes, schedule, other build configurations completing, or automatic retry.
5. Artifact dependencies - This makes it really easy to say you want Build A to use Build B's artifacts. For example, an installer configuration that will build an installer based on the last successful CI build.
6. Properties and environment variables - Self explanatory.
7. Agent requirements - Not all your agents can run all your build configurations necessarily. This will let you set requirements. You can set these based on environment variables, machine names, etc.

Once you get things set up, you get to see the really cool stuff. TeamCity is just packed full of nerdgasm features that just work out of the box. No need to scour the web for plugins, deal with XML, or anything like that. Things just work. For example, you get full status of the build while it is happening--you can see what MSBuild step the build is on, you can see the important messages in the Build Log (it filters them quite intelligently), you can even see what threads/processes are running. If you use their NUnit runner you can even see how many tests have passed/failed/been ignored.

That's not all you can see with their test runner though. You also get a full history of each test--how long each test took each time it was run, and if one fails you can see in what build it first failed, if it has been fixed yet, and you can even click to open it in your IDE if you have the Visual Studio plugin installed. The Tests tab even orders your tests by Duration so you have an idea which tests you may need to optimize.

Then there's the Statistics tab. This tab is a one stop shop for build health. You can see how long the build takes, how often it succeeds, how many tests you have, how many fail and even how big the artifacts are. You can see our build #s jump when we switched from a counter to SVN revision.

If there aren't enough features for you, don't worry, like with most JetBrains products you can extend them to your hearts content. That is if you can stomach the lack of API documentation (surprisingly, normal usage documentation is pretty good). One of our guys is working on a Campfire Notification plugin at the moment so we can get better build notifications in our Campfire. That's another post though.

All in all, we're very happy with TeamCity. It's just as free as CC.NET for a team of our size, it's much much easier to set up, and it has way more features. How could you go wrong? I'm sure its only a matter of time before we start to see rake runners, MBUnit test runners, and many other things to make TC even better. JetBrains has a winner here.

So I recently started using the Early Access edition of ThoughtWorks' Mingle. Let me start out by saying I'm impressed. Mingle is a very clean, very powerful and most importantly, very flexible approach to project management. We all have our approach to managing our projects and Mingle allows you to handle many of those methods. I've spent a few days over the last week configuring our Mingle project to map to our newly developing process.  It hasn't been entirely smooth sailing, but it's slightly less than an R1 product so I won't complain... too much :) Here's a list of my thoughts thus far:

1. Installation - I've done an install on both Windows and Linux. Both were relatively painless. The Linux install documentation was missing a few steps but that has since been fixed. I wish that Mingle could run on IIS and/or Apache. It's a bit annoying that I have to run it on a separate port than my primary web server, though Jacob tells me we can proxy a port with Apache, so that'd be nice.
2. Creating a new project - The existing templates are nice to allow you to see what Mingle is capable of. I wouldn't recommend creating your real project using one of the existing templates as it leaves you with a lot of undeletable properties you don't need. Start out by creating three test projects, one using each of the three templates and play around with them until you know what you want to go into yours. Then create yours from a Blank Project.
3. Card properties - It's really nice to be able to specify exactly what properties you want to be on each of your cards. The property creation UI could use some help though, it'd be nice if we could specify the values we want at the same time we're creating the property--but that's just a minor nitpick.
4. Wiki - Mingle allows for you to create custom wiki pages that have nifty things like bar graphs and pie charts and tables. My biggest complaint about the wiki is lack of documentation. Not all of the samples in the documentation seem to work and the syntax is a little confusing... plus, if you type something wrong the error messages you get back are less than useless. Fortunately I've managed to get most of the things I want in our overview wiki, but it took much longer than it should have. Also, there's no way at the moment to do a burndown chart which would certainly be a nice thing to have for a lot of the agile methodologies out there.
5. List view - Mingle has some really simple filtering options for its two views. You can basically choose a value for each of your properties (or any) and add tags you'd like to filter by as well. Once you have a view you like, you can save that view. If you really like the view you can add it as a tab to the top for the whole team to see. Unfortunately there are some limitations: There's no way to give an OR for two property values and there's no way to specify that you only want to see cards with a property that has a null value. I'm hoping they will add these things eventually. There's also no way to specify "Current User" in the view... which makes views like "My Bugs" out of reach. Also, there's currently a max page size of 25, so if you want to do batch operations you can only do them 25 at a time. That's pretty annoying. In the meantime I can get *most* of my views the way I want them, but not all of them.
6. Grid view - OK, this is pretty cool. You can pick a property to group by, and pick a property to color by. Of course you can specify the same filters as you can in the list (so the same limitations). What's nice though, is you can drag those cards around into different values for that grouped property. You can move a Story Card from New to Open just by dragging it. Pretty slick if you ask me. This view allows you to make a number of cool views. You can create an Assignment view that lets you drag unassigned cards to ready and willing developers. You can create an Iteration planning view that allows you to drag cards around to different Iterations. Or even an estimation view so you can drag your cards to different story point values. If you need more detail on a card, you can always just click it. It'll pop up a nice little window with more information so you don't have to navigate away from the page. All in all pretty fancy. It would be nice if the lanes were colored... if you have a long list it'd be easier to tell where you're dragging to when you're at the bottom. Oh, and where's the sort? I should be able to sort the cards in the grid.
7. Transitions - These are cool too. These allow you to add buttons to cards that meet specific preconditions. Clicking that button will set the properties you specify in the transition. Pretty slick to kind of workflow your process. Unfortunately there are a few things missing from these as well. You can't specify "Current User" in either the preconditions or the set area. This means you can't do things like automatically set the Approved By field when something is Approved. You also can't say that only the user who a Card is Assigned To can Resolve it. Just adding that feature would make it so much more powerful. The other thing that is lacking is that the only way to "trigger" these transitions is to actually click on the transition button. This means that dragging things around your swim lanes won't trigger these. Yes, that complicates things but it'd be nice to have some sort of trigger criteria... or even a view that shows "transitionable" cards that you can drag to transition them. Obviously I'm rambling now, but I think this is a cool idea and can be expanded upon.
8. SVN Integration - Right now we use Trac as a Wiki and to explore our SVN revisions. Mingle's SVN integration looks pretty slick but is kind of broken. Take a look at this diff to the right. See all that white? Why is that white? It's not blank lines when you do a svn diff... where's my context? I don't know if this is a bug or what, but it's annoying. Other than that, Mingle's SVN integration is reasonable. I like the fact that you can define keywords so that when you add things like "#245" or "card 245" in your commit log it will automatically reference that commit with the specified card.
9. Support - Eh... It seems the best point of contact with support is either email (which I haven't had a high enough priority issue to try) or their forum. The forum is painfully slow most of the day (read: unusable, but who knows if that's a routing issue between me and them or just their forum server/software) and doesn't have a ton of activity. A few of the bugs I reported were acknowledged via email so that's good, but who knows how seriously the suggestions are taken. There's only one guy moderating the forum so I'm sure he's busy, but it would be nice to see a bit more activity and feedback.
10. Overall impressions - It's slick. It's flexible. It's... a little slow. Loading our Bug Board view just now took almost 5.71 seconds and 51 requests. Eek. Granted I'm not local right now, but it's not much faster when I'm on my Lan. That said, we're using it. We moved all our bugs off of FogBugz and we're going to give Mingle a shot for now.  It's free for the first 5 users, so why not?
11. Wish list -
• The greatest thing about FogBugz is its email integration. It can check a mail account you specify and automatically create tickets for messages in that inbox. You can reply to the senders of that mail via FogBugz interface and you can receive more correspondence through email from the original sender. It's pretty slick and great for support. Right now we're just using FogBugz for this purpose. To handle support requests. If something is upgraded to a bug we'll move it to Mingle... but the copy/paste operation will probably get tedious, so it'd be nice to have this functionality built into Mingle as well.
• I want to be able to show/hide properties based on another property such as Type. If my Type is Bug, I should see Bug Status and not Story Status. Right now all cards have all properties even if they aren't relevant. It's fine that they have them, because I could change the type, but I don't want to see them.
• I also want to create Backlogs--Priority Queues. Having just a property with a fixed # of #s for Priority is annoying at best. It's much more natural to keep things in a sorted order. I want to be able to create a new backlog with a specific filter and then drag my cards into an order that I want. I then want to be able to sort in that order. That way I can pop things off of that stack in that order and as new cards come in I can insert them. I'm very tempted to write this feature on my own...
• Triggers--I mentioned this before, but it's worth mentioning again. I'd like to be able to specify what happens when I drag a card from one lane to another in a Grid view. I'd also like to be able to gate that dragging... something can't be dragged to Ready for Development until it has an Estimate set. Now that I think more about it, I think the latter would be more useful. I want to be able to specify constraints on the Cards that will be enforced by all views and editing techniques.

Alright, that's more than enough rambling for now. I'd strongly urge you all to go take a look at Mingle. It's got a ton of potential and I think it's definitely headed in the right direction. Remember, it's free for Open Source and it's free for the first five users of a Commercial project.