As for the chatbot, I’ve recently added a link logging feature.  Any URL sent to the chatroom now gets logged to the sqlite database.  Users can query the database right from the chat window by entering /links <number of previous links to return> and the links, timestamp and the person who sent it will be sent in an individual IM to the requestor.

Going forward, the two areas that I think need the most improvement are installation and documentation.  The majority of the questions and feedback that I have received are setup and configuration related.  Improving the installation and documentation stories at this point make the most sense and would be worth the effort. 

On the technical side of things, I am considering making a Chatsworth plugin for Windows Home Server.  Currently I am running the service from my home server and, given the always on nature that suits the chatbot and the low/no maintenance needed to running once it is setup, the pairing seems natural and could help provide a little better setup and configuration experience.

I hope to work on this more over the holidays and please feel free to reach out with a question or feedback.  Enjoy.

My pet app project requires some pretty basic multi-level tabular data visualization, so that was the first thing I attempted to tackle.  I started my learning endeavor by reading the view controller programming guide from Apple’s ADC and working through a few of the tutorials listed on the Monotouch site.  One of the example tutorials listed was for a basic RSS reader.  Armed with his guide, I got up and running with a basic table view allowed me to drill down one level deep and return to the root via navigation button.  This was a great introduction and the easy to follow steps combined with the screenshots certainly hit the mark; however, this was not quite the layout I was looking for.

The data that I wanted to display calls for more than just a list-view-to-detail-view relationship that the RSS reader implemented.  As a beginner trying to figure out how to wire up my custom table controllers to each other and the navigation controller all via Interface Builder resulted in a lot of thrashing and a lot of ugly code.  I eventually was able to roughly approximate the behavior I wanted, but it was pretty obvious to me there had to be a better way.

I set out to see if I could find more Monotouch examples to see if I could pick up some tips and stumbled across Craig Dunn’s blog.  Craig not only put together apps for the Monospace and PDC conferences (and graciously provided the source) but also posted a Roget’s Thesaurus app that was just what I was looking for.  It was a simple app, but it had all the elements in play that I was looking for and an incredible diagram that tied it all together.

One of the key tips and tricks I picked up from Craig’s code was how easy it was to cut out the Interface Builder from the process.  I also generally tend to avoid using the designer whenever possible in Visual Studio but here it was a key factor in my understand.  This isn’t to say that I’d never use the Interface Builder again or that it doesn’t have its uses because it does but there was too much magic going on in how Monotouch links up the XIBs to their backing C# classes.  It wasn’t until I started explicitly creating views and view controllers instead of trying to wire them up after the fact did I start to understand how things were supposed to interact.

To implement a custom UITableViewController you need to set two properties with custom classes and override a method which is invoked by the framework when the view controller is loaded.  You’ll need to set the TableDelegate and DataSource properties on the controller with your own implementations of UITableViewDelegate and  UITableViewDataSource.  The implementation of the table delegate allows you to customize how the table will respond to certain events and the data source implementation provides not only the data the table uses but also how that data is to be displayed within the table.  Typically the ViewDidLoad method is overriden to perform the view setup work needed during initialization of the view controller.  Within the method the TableDelegate and DataSource properties can be set.

Example setting the TableDelegate and DataSource via the ViewDidLoad method:

namespace MultiLevelTableView
{
    [MonoTouch.Foundation.Register("RootViewController")]
    public partial class RootViewController : UITableViewController
    {
        class DataSource : UITableViewDataSource { /* Impl Here */ }

        class TableDelegate : UITableViewDelegate { /* Impl Here */ }

        public override void ViewDidLoad ()
        {
            base.ViewDidLoad ();

            TableView.Delegate = new TableDelegate (this);
            TableView.DataSource = new DataSource (this);
        }
    }
}

Example setting the properties during UITableView construction:

namespace MultiLevelTableView
{
    [MonoTouch.Foundation.Register("RootViewController")]
    public partial class RootViewController : UITableViewController
    {
        UITableView tableView;

        class DataSource : UITableViewDataSource { /* Impl Here */ }

        class TableDelegate : UITableViewDelegate { /* Impl Here */ }

        public override void ViewDidLoad ()
        {
            base.ViewDidLoad ();

            tableView = new UITableView()
            {
                Delegate = new TableViewDelegate(this),
                DataSource = new TableViewDataSource(this),
            };

            //You can set more properties here like size and
            //location in the frame etc.

            this.View.AddSubview(tableView);
        }
    }
}

The meat of the table view controller falls in the implementations of the DataSource and TableDelegate.

A basic DataSource setup involves overriding two methods used by parent controller.  The RowsInSection method tells how many rows need to be displayed in the table and the GetCell method returns a cell view which was customized for display by setting the text and display properties.

class DataSource : UITableViewDataSource
{
    static NSString kCellIdentifier = new NSString ("MyIdentifier");
    RootViewController tvc;

    public DataSource (RootViewController tvc)
    {
        this.tvc = tvc;
    }

    public override int RowsInSection (UITableView tableView, int section)
    {
        return tvc.RootData.Count;
    }

    public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
    {
        var cell = tableView.DequeueReusableCell (kCellIdentifier);

        if (cell == null)
        {
            cell = new UITableViewCell (UITableViewCellStyle.Default, kCellIdentifier);
        }

        cell.TextLabel.Text = tvc.RootData.ElementAt(indexPath.Row);
        cell.Accessory = UITableViewCellAccessory.DetailDisclosureButton;
        return cell;
    }
}

The TableDelegate is where the behavior of the table to various events is defined.  It is here in which we load up the next view to display when a user clicks on a cell.   A basic implementation of a table view delegate involves overriding the RowSelected method with instructions on what to do with the row now that it has been selected.  If the node selected happened to be a leaf node for example we might load up the detail’s view to display the nodes properties or if the node was the parent of more child nodes we would load another list view to continue to drill down into the data.  In our case we want to drill down to the next layer of data which is managed by the SubGroupViewController.

class TableDelegate : UITableViewDelegate
{
    RootViewController tvc;
    SubGroupViewController sgvc;

    public TableDelegate (RootViewController tvc)
    {
        this.tvc = tvc;
    }

    public override void RowSelected (UITableView tableView, NSIndexPath indexPath)
    {
        // get info from selected row
        string selectedGroup = tvc.RootData.ElementAt(indexPath.Row);

        // load up new controller to display
        if(sgvc == null)
            sgvc = new SubGroupViewController(selectedGroup);

        // push the controller on the navigation stack
        tvc.NavigationController.PushViewController(sgvc, true);
    }
}

The hang up for me with using Interface Builder to try and get the multi-level table views wired together was mostly due to not being familiar with the objects I was dealing with and not understanding what properties are needed to be initialized so the framework can display them correctly.  Approaching the problem via the Interface Builder created a lot of noise that made seeing what was really needed to wire these table view controllers with the navigation controller difficult.  In this case the the pre-packaged templates and generic layouts provided by Monotouch and Interface Builder were more of a hindrance than help but that is to be expected while learning a new technology.

I’ve packaged up my implementation of a multi-level table view app and put it on github.  If anyone is looking for straight-forward, simple example of nesting table views hopefully this will help.

I also recommend checking out the following links which helped me immensely:

• Alex York’s Monotouch posts including the RSS reader 
• Sabon Rai’s Sample Code for UITableView
• Craig Dunn’s Blog

The goal of Tree Surgeon was to make setting up and laying out new projects using best practices dead simple.  All the major tools and libraries that typically find their way into your .Net source trees are provided for you.  In addition to laying out the directory structure for your source and libraries, a solution file gets created with three main projects to get you started.  The basic project setup includes a console app, core library and unit test project.  The build scripts come pre-wired to have NCover run your tests and generate reports from the results and also do things like packaging your build artifacts into zip files for deployment.

The whole process, start to project generated, is very easy.  Download and run the installer.  Launch the program, select the version of Visual Studio (2003, 2005, and 2008) and the flavor of testing framework (NUnit or MbUnit) and then hit generate.  The files and directories, built out in your Documents folder, are then created and ready to be used.

There are two slight issues I ran into that I’d like to point out.  Both issues had already been noted in the project forums and were easy to fix.  When generating a source tree with MbUnit selected as the unit test framework, the build script generated has the unit test assembly referenced is named incorrectly.  You will have to change it to match your project’s unit test assembly name.  The second issue has to do with running NCover and NUnit on x64 machines.  I found that in order for NCover and NUnit to work on x64 machines I had to add two calls to the CorFlags utility to make executables work.  This was accomplished by making the modifications to the ‘run-unit-tests’ target below on lines 5-8.

   1: <target name="run-unit-tests">

   2:     <mkdir dir="${build.dir}\test-reports" />

   3:     <exec program="regsvr32" workingdir="tools\NCover" commandline="/s CoverLib.dll" />

   4:     <!-- Need the CorFlags Commands For x64 -->

   5:     <exec program="C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\CorFlags" 

   6:         workingdir="tools\NCover" commandline="NCover.Console.exe /32BIT+" />

   7:     <exec program="c:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\CorFlags" 

   8:         workingdir="tools\NUnit" commandline="NUnit-Console.Exe /32BIT+" />

   9:     <exec program="tools\ncover\NCover.Console.exe" 

  10:         workingdir="${build.dir}\Debug\UnitTests">

  11:         <arg value="//w &quot;.&quot;" />

  12:         <arg value="//x &quot;..\..\test-reports\Coverage.xml&quot;" />

  13:         <arg value="&quot;..\..\..\tools\nunit\nunit-console.exe&quot;" />

  14:         <arg value="&quot;MyProjectName.UnitTests.dll&quot; 

  15:             "/xml:..\..\test-reports\UnitTests.xml" "/nologo"" />

  16:     </exec>

  17: </target>

Even though I am pretty late to the party with Tree Surgeon I am very happy to have stumbled across it.  The whole source tree and build script setup process is the perfect thing to script out and I am really glad the project creator and contributors have taken the time to do this.  It is a big help and I highly recommend you try it out the next time you are spinning up a new source tree for a project.

The only pitfall PartyChat has to do with stability.  PartyChat is a free service used by a large number of people, and it is run off the project creator’s computer in his apartment.  I do not know exactly why the service goes down intermittently, but the recipe of home server plus lots of users cannot be helping.  While it stinks that PartyChat isn’t always up, I understand I have no right to demand or expect 100% uptime, so I decided to do something about it.  I leveraged some of the knowledge I picked up about XMPP, the protocol that Jabber and GTalk use, from another project and wrote a simple group chat bot called Chatsworth to improve the availability of group chat that my friends and I use and depend on.

Chatsworth is a windows service written in C# that provides basic chat room functionality.  It does not have all the features that PartyChat has, but it does offer people the ability to setup and manage their own chat bots.  Additionally, if you are concerned about having all your chat logs being available not just to Google but also to the people running the PartyChat servers, then Chatsworth is the group chat provider for you.  Chatsworth is fully functional but still immature and under development.  I plan to add some additional features, take care of a few loose ends and provide more unit tests in the immediate future.

Admittedly I could’ve just downloaded the PartyChat java source, compiled it, and ran it on my own set of servers, but where is the fun in that?  I figured rolling my own chat bot would give me the opportunity to do more than address some of the availability issues I was having.  Starting up Chatsworth provides me a non-trivial project that I can use to explore different software development concepts and techniques as well as get some code and design samples out on the web.  So if you’re in the market for group chat in GTalk, give Chatsworth a try.  I am looking forward to building this project out further and would love to hear any feedback.

The moral of Uncle Bob’s story is that the only way to clean up messes in your codebase is to do via incremental changes iteration by iteration and release by release.  If I would have read this post six months ago, I might have argued that this is an overly simplistic take and that exceptional cases exist that make big redesigns necessary.  Having just gone through a big redesign; however, I am confident that fixing your messes iteration by iteration is the only way to fix your codebase issues for the long term especially if your team is trying to develop with agile processes.

My redesign change of heart did not come because of a spectacular failure or the system ending up in a worse shape than before.  I like to think our sob story about how terrible our legacy codebase was made a pretty compelling case for a redesign (doesn’t everyone?) but I’ll spare you the back story.   When it comes down to it, even the best reasons and intentions don’t justify a full blown redesign.  Here is why in big bold letters:

You are not addressing the root causes

A codebase does not fall into disrepair over night.  Having the Tiger Team do all the heavy lifting and making all the design decisions might solve the problem righthissecond but none of the problems that got you in this bind will have been addressed. Also, if the redesign is radical enough, you could actually be reducing your teams ability to manage and maintain your codebase even further.  Choosing to solve your team’s problems by delegating cleanup to a Tiger Team is the software management equivalent of giving a man a fish instead of teaching him how to fish.

Having a big redesign short circuits everything that the agile process tries to address.  If your team is ignoring the feedback it is getting from having to work with brittle code, not delivering on user story commitments, and rising incidents counts, then what is the redesign buying you other than masking these problems for your team a little longer?  If your team is considering doing a big redesign, do yourself a favor and address the real problems your team has.  Just say no to the big redesign.