Getting TFS to use P4Merge isn’t difficult but neither is it intuitive. For a merge operation P4Merge expects four files to exist:

1. the original, base file
2. file with conflicting change #1
3. file with conflicting change #2
4. final, merged file

Unfortunately TFS doesn’t create the merged file (#4) until after the merge tool is invoked. A simple batch script will solve the problem though. Save this as p4merge.bat.

@ECHO OFF
COPY /Y NUL ""%4""
START /WAIT /D "C:\Program Files\Perforce\" p4merge.exe ""%1"" ""%2"" ""%3"" ""%4""

This script will create the merge file and invoke p4merge.exe.

Now you can configure TFS to use P4Merge by running this command from a Visual Studio command prompt: tf diff /configure

That will bring up a dialog:

If an entry already exists for the Merge operation you can add it. Otherwise just modify the existing entry to point to the batch file we created:

Note that you must set the command to be your batch file, not the executable.

And that’s it! Next time TFS launches a merge tool, it will use P4Merge.

As a software version control system, I dislike TFS intensely.

In the short time I’ve been using TFS I’ve had several problems with code that was merged incorrectly. I’ve seen problems where TFS silently allowed older versions of code to overwrite newer versions. I could probably fill an entire blog post airing grievances with TFS but I thought it would be more interesting to describe how I use git on top of TFS to solve some of these problems.

First, to use git to track a TFS repository it is really important that all your source code be on a Fat32 partition. TFS locks files and NTFS respects that lock. Fat32 will track the lock but doesn’t enforce it. This allows git to modify files (change to different versions of files) without necessarily having those files checked out in TFS.

Using TFS I checked out all my code into s:\src. I then created a new git repository in that same directory and added everything into the git repository.

For working I maintain at least two branches. My master branch always matches TFS. When I need the latest code from TFS I switch to the git master branch, pull from TFS then commit all changes into git. My working branch contains my current code changes. I also have one branch dev that contains a single commit consisting of all my debug code that should never be checked in to TFS.

When I’m ready to start coding I get the latest code from TFS and commit those changes into git’s master branch. I create a new git branch, working. I cherry pick my development code from dev into working. Then I do all my coding on that branch. When I need to get code from TFS I can swtich to master, update from TFS, check that code in to git then either merge or rebase the changes back into working.

Once all of my changes in working are complete I need to merge the changes back into master so that I can commit them to TFS. I can’t do a straight merge becuase my cherry-picked dev code would be included. So I have two ways of doing this:

1. cherry-pick changes from working, applying them to master
2. backout the development code (using git rebase -i) then merge changes back into master

After going through one of these two options I end up back on master with all of my code changes. I then commit the changes to TFS. Once that is done I delete working and recreate it from master next time I need it.

Working like this has been great for me. If there are conflicts when merging my code changes, git takes care of it. This way I can almost always avoid having to let TFS merge anything.

This is my general way of working but you can easily see how to apply these same principles when you want to work on multiple different changes using multiple different branches in git.

One thing to note: When you’re working like this git’s history isn’t great. This isn’t like git-svn where you get a seperate git revision for every svn revision. For me, using git with TFS isn’t about being able to track my changes over time. I just want to make sure that my changes aren’t lost and I don’t want to clobber anyone else’s changes.

WARNING: Gross generalizations and simplifications below. I’m not trying to offend anyone, just describe my experiences.

Most of the contract work I’ve done has been for people who are not technically savvy. They come to me with a very vague idea of the software they want. They expect me to tell them how much it will cost before we’ve discussed specific requirements. When the requirements are incomplete or incorrect they expect that I’ll just fix it without additional cost to them.

Not all of my contract experience has been negative. In fact, most of it has worked out quite well. Usually both my client and myself are pleased with the software and the cost of building it. But I’ve had enough negative experiences to be careful when considering a new job.

Part of the problem is that it is nearly impossible for anyone to completely define the scope of a project. There is always some miscommunication or misunderstanding, there is always some unforseen problem.

“You want me to setup a blog for your company? No problem, I can get WordPress setup for you in an hour.”

“Wait, I didn’t realize that by ‘blog’ you meant store front application that can accept payments, handle accounts payable, accounts receivable and inventory tracking. That will take slightly more than an hour.”

That kind of situation actually isn’t bothersome to me. As a contractor it is part of my job to understand what you want before making a bid. If a potential client obviously doesn’t know what they want, I can either decline to bid on that job or I can adjust my bid to account for a large amount of unknown. I don’t love it, but that type of risk is manageable.

The part of contract work that I dislike is being forced to compromise quality. When I’m working on a fixed cost contract, it is in my best interest to deliver exactly what is specified, as quickly as possible. As long as my client is reasonably happy with the deliverable, I am going to get paid $20k regardless of whether it took two days, two weeks or two months to create. I don’t get additional money for clean code. I don’t get extra for having good test coverage.

When I complete a project more quickly than I had anticipated there is no problem. I can spend time verifying that the code is tight and that everything is working as expected. But if I am running behind schedule, it becomes more difficult to care about testing the code or fixing “little” bugs.

There may be a bug in the code where order totals aren’t calculated correctly, but what are the odds that my client will notice the bug before he signs off on the project? If he does find the problem and I correct it, will he think to test for that same bug in every release?

This is the dilemma that makes contract work difficult for me. If I see a bug in my code, I’m going to fix it. If I’m writing a tricky or important calculation (like calculating totals), I’m going to write a test. I need to have confidence that my code is doing what I expect. I’ve never shipped any software that didn’t have a list of known bugs but I have also never shipped any software in which I didn’t have a high level of confidence that it was working correctly.

For me, doing the bare minimum isn’t an option for two reasons:

1. Quality is extremely important to me. I can’t just hack something together that meets the contract requirements. When I write software, I want to deliver my personal best.
2. Most of the time, the fast/crappy way of implementing something simply doesn’t occur to me.

I understand a company’s need to understand cost before approving custom softare. But if you want me to do contract work, pay me on an hourly basis. I’ll give you a projected timeline for project completion.

With an hourly rate, you only pay me for the time I actually spend working. With an hourly rate I know that I won’t lose money just because I insist on high-quality code. We’ll both be happier in the long run.

The tools that I use for C#.NET are pretty standard:

• Microsoft Visual Studio 2008 (with ReSharper)
• SQL Server Management Studio
• .NET Memory Profiler to chase down memory leaks
• AQtime to help locate performance problems
• Outlook and Skype to stay connected to coworkers
• Team Foundation Server (TFS) for tracking work items and for version control
• cygwin to make the command line in Windows behave somewhat normally

The one thing that is sorta strange about how I do my C#.NET work is that I do everything on a Mac Pro with XP running in VMWare Fusion. I’ve had a similar setup at home for a couple of years but I’ve only had this setup at work since January.

There are definitely a few quirks that I had to get used to, working in Windows running in a VM on OS X. But the benefits of this setup far outweigh any inconvenience. The ability to take snapshots of the entire VM is awesome! If a program screws with my registry and Windows starts acting funky I just roll back to the last snapshot!

The other huge benefit to working in VMWare is memory. Unless you’re using 64-bit Windows (which can be problematic for many reasons) you are limited to 2 GB of memory. Windows sucks at managing virtual memory so I always try to keep my open applications below that 2 GB limit. Since my Mac has 12 GB of memory, if I need to do something else, I can just boot up a second VM.

Most of the software that I’ve written for OS X has been personal projects. Nothing fancy, just various tools to scratch some itch. Since getting my iPhone I’ve been doing more work in Objective-C and Cocoa.

Because I’ve done so much work with managed and interpreted languages, it feels a little weird to work in unmanaged C/ObjC. But it is kinda cool too. Objective-C is a fairly simple language and Cocoa is a very nice framework. There are some things that I don’t like about Obj-C (not having namespaces and gimpy string manipulation come immediately to mind) but I really appreciate being able to actually use Cocoa controls for UI work. It is almost unthinkable to do GUI development for Windows without buying a set of third-party controls.

My must-have software for writing Mac/iPhone applications:

• XCode and Interface Builder
• Instruments
• MacPorts to install all of the software that is missing from the base OS X install
• Mail.app, Syrinx, Adium and Colloquy to keep in touch with other developers

And finally, a few additional pieces of software that are invaluable to me. These are helpful regardless of what type of software I am writing.

• OmniFocus to help me Get Things Done
• git for source control (don’t tell anyone but I keep my TFS repositories checked into git too)
• Terminal.app for a whole bunch of things
• PathFinder because Finder doesn’t always cut it
• GeekTool to keep an eye on logs
• vim
• screen
• Photoshop
• iTunes to help keep me in The Zone!

When I’m working in Java I always prefer to use JetBrains’ excellent IntelliJ IDEA. However, this past year I didn’t have a license for IntelliJ. I tried every free IDE I could find and wound up choosing Eclipse. I’ve used Eclipse periodically over the last several years. I don’t really like it but I dislike it less than the other free alternatives.

My work was completely server-side and didn’t involve developing a database component. Most of my development was done on OS X but I was deploying to Ubuntu so I did work there also. I used maven to build, test and deploy. I’m not a unit-test fanatic but, in this case unit testing was invaluable.

My setup for both PHP and Python is the same. When I’m working on Mac I use either TextMate or vim. I haven’t done a great deal of Python work but over the past several years I’ve tried to find a PHP IDE that I like… I’m still looking.

I started out doing my Ruby work using TextMate and Terminal.app. I didn’t have any major complaints. There are some nice plugins and various tricks that are handy. But personally, I prefer an IDE. I’ve heard some people say that IDEs make us lazy. Ok, I’m lazy. But I’m also far more productive when I have a good IDE. When JetBrains started issung beta releases of RubyMine, TextMate was history!

RubyMine’s GUI for easily stepping through code in the debugger is great. The inline code analysis is nice for quickly catching typos and the code completion can be useful too. But for me, the best part about having RubyMine is the navigation and documentation.

When I’m working with other developers (or even with frameworks that I didn’t write), I don’t always know exactly what a method does. Being able to instantly bring up documentation is awesome! If I need more information, I hate wasting time trying to hunt down a method buried in code that I am not familiar with. With one key-stroke RubyMine takes me to the code I’m looking for.

I am definitely a fan of JetBrains’ production. IntelliJ is awesome, RubyMine is awesome, and VisualStudio is just broken without ReSharper. There is certainly a learning curve to these tools but once you’ve memorized the key strokes, the code you need is always right in front of you. And the best part part is that the key bindings are the same across each of JetBrain’s products!

One last application that deserves to be mentioned is Navicat. Navicat is by far the best application that I’ve found for working with MySQL or PostgreSQL. Unfortunately, that’s not saying much. I have spent a lot of time using SQL Server and Microsoft’s related tools and, as far as I can tell, there is nothing for MySQL that is even in the same league.

Don’t misunderstand me. Navicat is a great tool. Allowing me to save connections to different servers with many different login credentials is a lifesaver, especially the ability to tunnel the connections over ssh. Being able to do basic server management via a GUI is nice too. But when I need to design a database, I always turn back to SQL Server Management Studio.

When I first discovered Puzzle Master the running contest was:

To enter the contest, upload to our fan photo album, a screenshot of your desktop and development environment (including as many editors and tools as you can, and your desktop wallpaper) along with a short essay of 250 words or less explaining why and how you use it.

I don’t generally participate in this type of contest but I always find it interesting to see how other developers work. There were some cool prizes available and not many entrants so I decided to upload a screenshot of my desktop.

I was disappointed because the picture was scaled down so much that the apps were indistinguishable. So, I decided that it might be fun to do a few posts on my development environments.

First up… my physical setup!

The picture is a link to flickr where I’ve attached some notes to the image.

• MacPro (2 x 2.66GHz Dual-core Xeon) with 8 GB and ~2.5 TB
• Two 24″ Dell monitors, both at 1920×1200
• Mac OS X 10.5
• VMWare Fusion running XP SP3

This is my home office but my work setup is similar. At work my MacPro is 2 x 2.8 GHz Quad-core. It has 12 GB memory and a single 500 GB disk. Maybe I’ll try to update this post later with a picture of my desk at work.

Update:
Here’s my desk at work!

I didn’t immediately grok git because it is fundamentally different from subversion. Subversion tracks the history of files whereas Git tracks the history of content. That difference may seem minor, but the shift brings a lot of flexibility. You can expect a small learning curve, but don’t give up! If git works as well for you as it does for me, you will not want to go back to subversion.

So, what are my favorite things about git?

• Branching: Coming from a CVS/SVN background, I didn’t think git’s “cheap branching” would matter to me. I am not exaggerating when I say that it has dramatically changed the way I work. Because branching and merging are so easy, I create a new branch for each feature or bug I’m working on. I am never tempted to check in broken code just because I want a checkpoint.
• The index: It is really nice to be able to just check in a portion of the changes in my code rather than having to commit the entire file.
• git stash: If I’m in the middle of some big change and need to fix a small bug, I can hide my outstanding changes, make the fix and restore my changes without a checkin.
• git rebase: Sometimes it is really handy to be able to rewrite history.
• Git is a DVCS: My work isn’t crippled when I am not connected to the network. I can check code in and out. I can branch and merge. I have a full history of the repository. Awesome!
• Very flexible workflow: With git I can push/pull to a central server like CVS or SVN. Alternatively, changes can bypass the server and be sent directly between working repositories.
• Git is fast: Neither CVS nor SVN come close to git’s speed.

Is git perfect? No. Off the top of my head, here are some things that I would really like to have in git:

• git checkout -i: Sometimes I want to rollback a few changes in a file. I imagine this would work very similarly to ‘git add -i’.
• git stash -i: Sometimes I only want to stash some of my changes. This too would work like ‘git add -i’.
• Local tags: Local branches are great; local tagging would be too.
• Track empty directories: I understand why this doesn’t currently happen, but it can be obnoxious.
• Comments on branches: It is easy to make a lot of branches but unless your branch names are super descriptive (and therefore super long), it is also easy to forget what each of them is for.
• Better/more documentation: In general I am able to find what I’m looking for, but I still don’t know what the “fetch-all” in git svn fetch --fetch-all actually does.
• Windows support: Not that I’ve actually tried it, I’ve just heard that it doesn’t work well.
• GUI options: Most of the time I work in the cli but sometimes a gui is more convienent. I’ve heard multiple people ask for a tool that would allow them to branch and tag without checking out code. gitk and gitx just don’t offer all the flexibility that some other tools do (e.g. WinCVS, SmartSVN, TortoiseSVN, etc.).

Why do you like (or hate) git?

The project I was working on needed to access that data but would never need to modify it. Perhaps I was being overly paranoid, but I wanted to specify that everything from those databases was read-only to make sure nothing was accidently changed.

ActiveRecord is one of the coolest things about rails. With almost no work I get data models, including dead-simple CRUD, in my applications. But the inability to designate a model as being read-only is really frustrating to me.

I know that rails can mark individual instances with :readonly, but I wanted to ensure that every instance of these objects was read-only. Here’s what I came up with:

class FooBar < ActiveRecord::Base
  # Prevent creation of new records and modification to existing records
  def readonly?
    return true
  end
 
  # Prevent objects from being destroyed
  def before_destroy
    raise ActiveRecord::ReadOnlyRecord
  end
end

And that’s all there is to it! FooBar objects are now read-only.

# You will not be able to create new records
>> fb = FooBar.create(:name => "zork")
ActiveRecord::ReadOnlyRecord: ActiveRecord::ReadOnlyRecord
 
# You will not be able to save modified records
>> fb = FooBar.find(:first)
>> fb.name = "plugh"
>> fb.save
ActiveRecord::ReadOnlyRecord: ActiveRecord::ReadOnlyRecord
 
# You will not be able to destroy existing records
>> fb = FooBar.find(:first)
>> fb.destroy
ActiveRecord::ReadOnlyRecord: ActiveRecord::ReadOnlyRecord

For the sake of simplicity the code here is in a regular rails model. But if you’re working with a large number of models like I was, you might consider extracting these methods into a new class “ReadOnlyActiveRecord” which can then used as the parent for the other models. DRY, right?

Depending on your situation, you may need to lock down the record more tightly. With this code you could still create and manipulate new FooBar objects in your code. The exception isn’t thrown until you try to persist to the database.

I certainly don’t consider myself an expert on rails. If anyone knows a better solution to this problem I’d love to hear it.

I started looking and, on one of my first phone interviews, was asked, “What is an interface?”

I know what an interface is. I’ve written new interfaces; I can create a class that implements IComparable, IDisposable and IMakeMillionsFromCrazyIdeas without breaking a sweat. I can talk at length about why multiple-inheritance is pure evil and how single-inheritance, combined with interfaces, will solve every problem known to man. If you would prefer, I can argue the inverse. But, when asked, “What is an interface?” I babble like an idiot:

Oh, an interface is a thing that classes have and they start with an ‘I’ in C# anyway but it’s by convention not a requirement and they come after the class name and a colon and they help us to do things so that when other classes want to do something they know that our class can be used to do that thing because our class implements the interface.

I’s a rel gud programur. I got teh 1337 h@X0r skillz. yeah…

I knew the answer, but on the spot, I couldn’t figure out how to intelligently convey that knowledge. I hadn’t been asked to verbalize that knowledge for a long time. Since I don’t like feeling like an idiot, I spent some time googling “interview questions.” I don’t remember which site recommended the book, but I ended up buying Programming Interviews Exposed: Secrets to Landing Your Next Job, 2nd Edition.

Programming Interviews Exposed was a good purchase. If you you’re not already familiar with some basic concepts of computer science I doubt this book would be very useful. But for me it was a great refresher on concepts I use regularly, but hadn’t consciously thought about for a while. Who thinks about the nuts and bolts of programming when you’re in the zone, and it’s just flowing?

As you would expect from a job hunting book, there are chapters on the basics of job hunting: how to decide what companies you want to work for, how to find job opportunities, how to work with headhunters, how to negotiate offers, etc. I wouldn’t necessarily consider myself an interview-pro but, many of these tips just seemed like common sense.

The book describes methods for solving riddles and how to answer questions. It doesn’t just provide a bunch answers to memorize but discusses ways to convey your knowledge and experience to the interviewer (hint: keep talking and explain what you are thinking). The chapters that I found most useful were the computer science topics: linked lists, trees and graphs, arrays and strings, concurrency, etc. The book gives questions that might be presented in an interview then explains the answers.

To date, I haven’t been asked any of the questions presented in Programming Interviews Exposed. Reading examples of various ways to traverse trees and reverse strings was useful. The interviewer does not want return new string (Array.Reverse ("xyzzy".ToCharArray()));. It was useful enough that, when asked to calculate the weight of tree nodes and return a specific node in O(n) time, I felt confident in my answer.

Programming Interviews Exposed will most likely benefit those who are already familiar with basic computer science concepts. It’s a quick read and quite effective. Good luck with your next interview!

• To start a new project, use subversion to download the latest stable release of WordPress
• Add that entire directory, including the .svn folders, to git. To keep subversion happy, make sure that all of the svn tmp directories are in git (use an empty .gitignore file to force git to add empty directories)
• Before you make any changes, create a new branch in git called wordpress_base. You should never do anything with this branch other than update the WordPress code from subversion.
• Switch back to master and change whatever needs changing (e.g. add themes, plugins, etc.). To make upgrades go as smoothly as possible you shouldn’t modify the base WordPress files more than you absolutely have to but, adding themes and plugins should be no problem.
• When everything is tested and ready to deploy, commit everything to git and push to the webserver

The command line will look something like this:

$ cd ~/Downloads
$ svn co http://svn.automattic.com/wordpress/branches/2.6/ new_blog
$ cd new_blog
$ git init
$ git add .
$ git commit -m "Import WordPress 2.6"
$ git branch wordpress_base
## Get the site completely setup, commit everything to git and
## push everything up to the server.

When you’re ready to update WordPress:

• Checkout the wordpress_base branch
• Either ’svn up’ or ’svn switch’ to get the newest code
• Check all of the changes in to git
• Merge wordpress_base back in to master (I generally rebase then merge)
• After everything in git has been committed, push, pull or do whatever fits your process to get the updated code from your development machine to the server
• Don’t forget to upgrade your blog database after the new code has been deployed by going to: http://myblog.com/wp-admin/upgrade.php

$ git checkout wordpress_base
$ svn switch http://svn.automattic.com/wordpress/branches/2.7
$ git add . && git ls-files --deleted | xargs git rm
$ git commit -m "Updated WordPress to version 2.7"
$ git checkout -b integration
$ git rebase master
$ git checkout master
$ git merge integration
$ git branch -d integration
## Make sure all conflicts have been resolved, test the new site and
## update plugins. Commit changes to git and push them to the server.