The second half of the meeting was an open discussion that revolved around practices of Agile teams. There's also an entertaining rant by I'm-still-Brad in the middle.

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

I like Twitter.  Unfortunately every day when I log into I never know what I'm going to get.  This is what I see about 50% of the time:

At first I thought it was something wrong with Twitter, which is not all that crazy given their impeccable service record *grin*.  After a closer look with Firebug it's clear that the problem is on my end.

403 errors on the CSS files and jquery pretty much assure that my user experience is going to be pretty minimal.

Looking at request for screen.css we can see that the website, in this case a stylesheet resource, was blocked.

This is an error that I'm very familiar with.  When I try to visit anything on Jason Bock's site I'm greeted with:

"Games"...really?  The same thing is happening with some of the backing files to the twitter site, they are being blocked.

So how can you get around this?  Well Firebug allows you to edit the rendered html directly.  I've found that for some reason anything from assets1.twitter.com is blocked, but anything from assets2.twitter.com or assets0.twitter.com is not.

To get twitter to work, all I had to do was change the html:

Immediately after changing the URL for the css file, firebug goes off an fetches the unblocked css file and applies it's rules, making the page look correct.  Doing the same thing for the js files, behavior is once again in tact and my twitter looks normal.  I'm thinking if anyone out there has any experience with GreaseMonkey (firefox plugin) you could school me real quick on how to do this automatially.

• Part 0
• Part 1 
• Part 2 

Application Architecture

I'm going to back up a bit discuss my overall approach to structuring this WPF project. So far the solution consists of four projects:

• ChumChase is the actual WPF project.
• FriendFeed is the official .NET api I downloaded from here, and patched so that it would compile. :-)
• IntegrationTests is for testing the bits of the application that interact with the FriendFeed api.  I separated this out because it is much slower to run than my Specifications tests, and goes beyond the trust boundary of the app.
• Specifications is the bulk of the unit tests for the project. I'm influenced by the whole BDD approach, and I like to think of my unit tests as executable technical specifications.

Project Structure

In the main project you'll find the following:

• Presenters - This folder contains the presenter classes. I usually name these classes with the suffix "Presenter, though that's a bit of a hang over from other frameworks (MonoRail, RoR). This directory is where I have the HomePresenter class we've been discussing.
• Views - These are usually user controls or some derivative thereof. I name them to correspond to their presenter. So you would expect, since we have HomePresenter, to find HomeView.xaml. (Actually, I goofed and the current source has the view named HomeFeedView.xaml).
• Model - This is the object model that represents the "business problem" I'm trying to solve. In this case it happens to mirror the actual api quite a bit.
• Repositories - Here I am influenced by Eric Evans' book on Domain-Driven Design. Repositories are classes that allow me to access/persist data in a way that makes sense to my business domain. It's also a place where I can hook in orthogonal concerns such as logging, caching, or security. Repositories differ from the traditional data access layer in that there is an emphasis on the domain model (as opposed to following the semantics of a relation database).
• Services - These are supporting classes. They are not necessarily part of the business or problem domain. A classic example is an SMTP provider. Classes in your model or presenters might utilize these.
• Framework - These support the framework of application, but don't have anything to do with the business concern. If we need to create a base class for views, we'd put it here. Currently, I have a class there that is going to assist us with binding to commands. This is code that could likely be pushed out to a reusable library.

Aside from these folders you will also find:

• App.xaml - This is the starting point for the application. It will kick off our Windsor configuration, and launch the first window for the application. Eventually, we'll include some application-wide resources in the xaml, primarily for styling.
• Shell.xaml - This is the main window of the application. I call it Shell, because there is very little to its UI. It's content is bound to view of our current presenter. This class might have some logic in it's code-behind if we need to do some things like managing a set of tabs. It also provides the overall layout of the application.
• ApplicationController - I briefly mentioned this in the last post. Honestly, I've waffled a bit on what to call it. It's responsibility is to coordinate the presenters for the application. For example, if presenter X needs to load presenter Y it passes that request to the application controller. In this, it also handles some statefulness for the overall application. This will become more clear as we begin to work with the class.

What's Not Here Yet

There are several other things that usually appear in my projects. I often end up with a base class for test fixtures, though I think the new Rhino.Mocks features might affect that. However, the big piece that's missing is the folders and files related to organizing the XAML.

It's common for me to have the following:

• Colors & Brushes - I typically have a  resource dictionary dedicated to defining the colors and brushes used in the application.
• Default Styles - When I provide a completely custom style for an application, I'll have a resource dictionary that defines all of the default styles for controls. It useful to note that I avoid putting control templates inline in this dictionary.
• Control Templates folder - In this folder, I will have a file for each control template in the application. I'll usually have a "manifest" resource dictionary where I merge in all of the individual templates. This helps to keep the structure clean in other areas. These are the control templates that are referenced in my default styles dictionary.
• Data Templates folder - Inside the Views directory, I will have a sub-folder for data templates. Data templates really are views.

What Happens at Runtime?

A synopsis of what happens at runtime, well, what will happen once we've finished:

• App.xaml starts off.
• In its constructor, we configure our container, which in this case is Windsor.  The container is told how to resolve resources, such as where do I find the actual implementation of IFriendFeedProxy.
• Still in the constructor, we then request an instance of IApplicationController, and call StartApplication().  Note that we don't set the StartupUri in the XAML for App.
• StartApplication() might handle some things like loading up user preferences, but mostly it will initialize and open Shell.xaml.
• Somewhere around here we'll request the HomePresenter from the container, and inject into the shell.
• As the user interacts with the application, presenters may be removed and new ones injected (probably into a tab, or new window). The shell's code-behind has the code for actually placing these presenter's views into the layout.
• The presenter will have use commands as properties that can be bound to in there views. These commands are coordinators of individual activities in the application.

I'm certain that parts of this are confusion, but I believe it will make sense as we continue to build the application. As always, your feedback is welcome.

More to come!

[Post publish note - 8/19/08:  Frank Laub has provided a tip, in the comments below, for alternatively configuring your router for port forwarding rather than setting up a new listener port for each computer.  This is exactly why I like to blog...for others to tell me an easier way to do things!]

I often have a need to remote onto one of the multiple computers on my home network from offsite but am too cheap to get more than one IP address.  Instead of getting more IP addresses (and without installing a third party tool), you can easily accommodate this by modifying the listening port, from the default of 3389, of each computer on your network.  You'll then be able to remote desktop into each of your computers via <your IP address>:<custom listening port number>.

To make this possible, take the following steps (performed on Windows Server 2003 with Windows Firewall enabled):

1. Enable the computer to accept Remote Desktop connections
1. Right click the My Computer icon and bring up System Properties and go to the Remote tab
2. Check the Enable Remote Desktop option
3. Select users which will have Remote Desktop access to the computer
   
2. Change the listening port of the computer you'd like to remote desktop onto (http://support.microsoft.com/default.aspx/kb/306759):
1. Start Registry Editor
2. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
3. On the Edit menu, click Modify, and then click Decimal
4. Type the new port number, and then click OK
5. Restart the computer
   
3. Expose the new port through the Windows Firewall
1. Open Network Connections
2. Open the properties of the Local Area Connection and go to the Advanced tab
3. Click the Windows Firewall Settings button and go to the Exceptions tab
4. Click Add Port... and provide the following:
• Name = "Remote Desktop (<custom listening port>)"  (What you name this is arbitrary, but this helps to identify it.)
• Port Number = <custom listening port>
• TCP should remain checked
• Change Scope should be set to Any Computer (if you want to remote desktop over the internet), My Network (if you only want to be able to remote desktop from internally - but then there's no point in changing the listening port), or Custom List
4. If you are using a hardware firewall as well, you'll also want to poke a hole in it for the custom listening port and have it redirect traffic on that port to the respective computer.

And that should do it!

Billy McCafferty

Here's a conversation I just had with another developer who is struggling to get his team to adopt some agile practices:

developer: if you were starting from scratch, which would you think is more important to setup first? CI or a unit testing process?
me: unit testing
developer: wow
developer:  ok
me: why is that surprising?
developer: i look at the mess i'm in everyday and i'd think getting a good build system in place would be first...
me: I think unit testing provides more value in that it allows you to add features knowing you haven't broken other features
developer: testing above a development process?
me: yes
me: testing provides more customer value

Let me be clear in stating that I think both are great value and a necessity, however the challenge was to choose one, presumably the most important.  I chose unit testing because one of the reasons I enjoy writing software that meets someone's needs.  As a developer one of the most nervous moments is when your code is released into the wild.  Will it work?  Will users they use it how you intended?  As a developer one of the most satisfying experiences is watching a user fire up a program you've written and it works flawlessly.  I think most customers would agree with that as well.  Having code that works is what they want.  Having code that works builds their confidence in you and reassures them that know what you're doing.  Testing provides this for me.  In advance I can test different scenarios and program that in and put my program through it's paces.

Now let me speak a bit about CI.  While I believe that testing is a component of CI, the developer in this instance meant a build server that kicks off automated builds.  While an automated build is nice, it doesn't nearly provide the value that unit testing does.  It's the things your build server does that increases it's value.  One of those things in our build system is running automated tests.  If you remove automated tests from a build server all you have is a dummy machine that compiles code.  That provides some benefit, but minimally.  You can replicate the behavior simply by updating your code often and doing a compile on your own machine.

As an agile developer I seek deliver value to stakeholders.  When viewed through that lens, I think unit testing clearly wins.

What about you?  Would you test before build server?  Or would you choose the build server?  Why?

A long while ago I got a licence for NDepend ... I had used it previously but only on the trial version, where it had proved very useful in giving me a some pretty graphs that made sense to managment when my words did not.

I haven't actually got around to using it until this morning, when I thought I would run it over our current project to see where we were at. There isn't a hell of a lot of code in the project, so I wasn't expecting too many surprises - and largely I didn't receive many.

I was pleased to see our assembly dependencies were the right way around, and very pleased to see they were very near the centre line on the "Abstractness vs Instability" chart.

The only very mild surprise was to see this flagged up in multiple CQL checks:

RegisterforUpdates(String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String, String)

Obviously there is something wrong here ... and a quick word with the developer who wrote this established that he didn't know about the Binding Helpers in ASP.NET MVC so had passed every form field back into the controller via the parameter list. A quick hyperlink to him of Rob Conery's excellent tutorials on ASP.NET MVC and we have a much nicer method on the controller.

One small win for NDepend ... I look forward to many more as time goes on!