C# 3.0 is a really nice language. It seems to have gotten generics correct making for some really nice code, especially were the database layer is concerned. We are using LINQ to SQL and we have been able to implement a single class for the repository which works with whatever model object type we give it. I also really like the inclusion of Lambdas and delegates, which make for some very clean code constructs and are much cleaner then anonymous methods in Java.

The second new technology to me is ASP.NET MVC. This allows us to do ASP.NET without actually using ASP.NET. Currently, it is still in preview releases, but it is definitely heading in the right direction. Everything (with the possible exception of views) is completely and easily testable. This means no more having to hide functionality behind presenters or controllers and hoping it works in the code behind. Controllers are completely testable right down to testing what views or redirects they return.

The last new thing I am using is jQuery. I fully understand why it is becoming the defacto Javascript library. To do most things only require a few lines of jQuery Javascript and its AJAX and JSON capabilities are incredible. One nice thing about ASP.NET MVC is that it is capable of returning JSON results with a single line of code. This makes working with jQuery seamless.

If you are starting a new .NET web project, definitely check out ASP.NET MVC, C# 3.0 and jQuery. If you are new to C# 3.0 then check out the book C# in Depth. It highlights all the changes since 1.1 in a nice concise format that will bring you up to speed quickly.

Hopefully, they will put some of the sessions from the conference online as well. Google, if you’re listening, I would like all of the AppEngine sessions put online, please.

Prerequisites:
You will need to have XCode installed as mod_passenger.so needs to be compiled.

Installing Passenger Gem

The first thing is to install and build the Passenger gem.

$ sudo gem install passenger
$ sudo passenger-install-apache2-module

The second line will compile mod_passenger.so and launch an installer script. At the end of the script there will be 3 lines that you need to add to your Apache configuration in order for anything to work. Copy these lines directly from the install script as they may be unique to your computer.

Configuring Apache httpd.conf

In this section, we need to configure Apache so it can properly use mod_rails and access your Virtual hosts, which we will setup later. The lines you copied in the previous step need to be added to one of two files - /etc/apache2/httpd-conf or your personal configuration file, in my case /etc/apache2/users/chrisjohnston.conf. it doesn’t matter which one you pick. In getting this all running, I used both files and things worked fine. In the end, I picked my personal config file because it kept things cleaner.

To open the file, use the following:

$ sudo vim /etc/apache2/users/chrisjohnston.conf

This is what my file looks like. I will explain the various parts after the snippet.

LoadModule passenger_module /Library/Ruby/Gems/1.8/gems/passenger-1.0.5/ext/apache2/mod_passenger.so
RailsSpawnServer /Library/Ruby/Gems/1.8/gems/passenger-1.0.5/bin/passenger-spawn-server
RailsRuby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

RailsEnv development

<Directory "/Users/chrisjohnston/Sites/">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

<Directory "/Users/chrisjohnston/Dev/">
    Order allow,deny
    Allow from all
</Directory>

The first three lines load mod_passenger.so and set it up. The RailsEnv development line is needed in order to run the server in development mode. If this is to be a production server, then you can leave this line out as it defaults to production.

The next important part of the file is

<Directory "/Users/chrisjohnston/Dev/">
    Order allow,deny
    Allow from all
</Directory>

This gives you access to all the files below the given directory. This is important if you want things like stylesheets or images to load. We will also come back to this when we set up virtual hosts for the site.

Setting up Virtual Hosts

The next thing to do is to set up a virtual host for your website. In order for this to work, first open the apache httpd.conf file

$ sudo vim /etc/apache2/httpd.conf

and ensure the following line is uncommented, otherwise, nothing else beyond this point will work.

# Virtual hosts
Include /private/etc/apache2/extra/httpd-vhosts.conf

Once you have uncommented line, open up the httpd-vhosts.conf file and add a virtual host pointing to where you rails app is. Also, ensure that NameVirtualHost *:80 is uncommented.

$ vim /private/etc/apache2/extra/httpd-vhosts.conf

Here is what mine looks like:

#
# Use name-based virtual hosting.
#
NameVirtualHost *:80

# Rails apps
<VirtualHost *:80>
    DocumentRoot "/Users/chrisjohnston/Dev/studio_gallery/public"
    ServerName dev.studiogallery.com
    ErrorLog "/Users/chrisjohnston/Dev/studio_gallery/log/error.log"
</VirtualHost>

There may be two dummy virtual hosts listed in the file. Either comment these out or delete them. They will cause errors when you restart the server.

In the snippet above, you can see that I have set up a ServerName for my site. In order to navigate to this (without ending up searching for it on the net) we need to modify the /etc/hosts file. You need to add a line that tells your computer to associate the domain you created with your computer.

# Virtual hosts on this computer
127.0.0.1       dev.studiogallery.com

Now we can restart Apache.

$ sudo apachectl restart

And if everything goes well, when you navigate to your virtual site, your Rails app should come up.

From the highgroove Studio’s The Napkin website, I also added the following to my .bash_profile file:

# Use this in any RAILS_ROOT dir. That restart.txt file tells mod_rails to restart this app.
# You'll want to do this when (for example) you install a new plugin.
alias restart_rails='touch tmp/restart.txt'

# By default, your app's error log now goes here. Unless you configure your apps otherwise,
# it's helpful to have an alias to take you to your error log quickly.
alias apache_logs='cd /private/var/log/apache2/'

# You'll be adding to your vhosts configuration everytime you introduce a new Rails app.
# Might as well make it a shortcut
alias vhosts='sudo vi /private/etc/apache2/extra/httpd-vhosts.conf'

# Dito with hosts
alias hosts='sudo vi /etc/hosts'

# You'll need to restart apache whenever you make a change to vhosts.
# You can also click System Preference->Sharing->Web Sharing, but this is quicker.
alias apache_restart='sudo apachectl restart'

References:

• highgroove Studio, The Napking - Development with Rails + Passenger (AKA mod_rails) on Mac
• Fingertips website - Using Passenger on OSX for Rails development

The last client I worked with had a factory style, compartmentalized view of software. They spent months working on the design and when they thought they had it right, they sliced it up into small components and farmed them out to the lowest bidder. When it came time to integrate those pieces back together, they were stunned when they didn’t fit and the application refused to run. Six teams then spent months fixing everything up to release a very fragile, but working, product.

Part of the problem was that they tried to implement and solve too much too quickly (well, in combination with the whole lowest bidder thing). The final application basically implemented the same thing four times. Instead of solving the problem for one product line and implementing a working, stable solution then moving on to the next product line, they did all four at once.

Moving this idea forward to two-pizza teams, I have a fear that companies could do the same thing. One trick to making small teams work is how you divide the problem. Each team, and thus each problem, needs to be completely atomic. Therefore, no two teams are implementing the same ideas.

If you have an application that does basically the same thing across multiple product lines, have a single team do the initial vertical implementation (i.e., end to end across all integration points). Once the initial implementation is completed and working, other teams can then build upon it sequentially, implementing the remaining product lines upon a proven solution. This will also provide business value back to the company earlier rather then later and give the user’s something to test.

I think the best way of dealing with this is to be constantly breaking up teams and not letting any team work on more then one problem together. As soon as a team has solved their problem, that team is disbanded and the team members move on to new groups. This way, you maximize knowledge sharing and allow everyone to learn about what that team did.

The idea behind this is that you shave off small problems and give them to small teams to solve. The team is completely autonomy and owns both the problem and the solution. This allows the team to innovate and create the best possible solution. In addition, since the team is so small, communication is fast and everyone stays on the same page throughout the project.

I think there are a few other advantages to having small teams which are:

• There is nowhere for anyone to hide. It is easy to recognize the dead wood and build small, efficient teams of highly skilled people
• There is no space for specialization. Everyone on the team has to become proficient in every area within their discipline and beyond. A specialization represents a possible bottleneck, so everyone has to learn how to do all the different jobs. For example, you wouldn’t want a dedicated DBA so all the devs needs learn how to work with the database. The result is poly-skilled workers who are able to move from team to team and from technology to technology and have richer tool sets with which to solve problems.

The best anecdote I have heard comes from IBM. Apparently, there were two teams at IBM both of which were trying to develop the same software. One was large and the other small. The software was non-trivial, something like an operating system. Software that you would expect a large to team to have to handle. In the end, the large team was over budget, over time and did not meet all the requirements while the small team met everyone of their milestones and their version contained all the features. (I believe this is properly documented in The Mythical Man-Month)

In reading about this idea, I came across several blogs that basically said there are some problems that must be solved by large teams. I think the above example proves this wrong.

One last thought about this is that teams should always have an odd number of people on them. This way, there is always someone to break the tie.

Other links:

• 37Signals - 3 people for version 1
• 37Signals - If you’re working in a big group, you’re fighting human nature
• FastCompany - Inside the Mind of Jeff Bezos
• Paul Graham - You Weren’t Meant to Have a Boss

Setting your git email account is really easy. There are two different ways of doing it. First, you can directly edit your .git/config file and add a section like this:

[user]
	email = you@example.com
	name = Your Name

The second method is by using the following command from the root folder of your project:

git config user.name "Your Name"
git config user.email "you@example.com"

The app will allow photographers to create galleries for clients, uploading photos from photo shoots. Once the gallery is created, clients can log on and select the photos they want to order. Other features include the ability to rate photos and filter by ratings as well as pick the size of print to be ordered.

The project is just beginning, so nothing exists for it yet except the Github repository. I will putting up a Trac site or Wiki for it soon.