Whenever someone asks me at the end of my git presentation about what tools to use with git my answer was always be the same:

Learn to use the commandline. It’s by far the most convenient way to get stuff done. That’s the way git was intended to be used, and with msysgit and Powershell you get a pretty powerful shell to do your stuff. I work exclusively from the commandline, rarely using gitk to take a look at the history.
Unfortunately the basic Windows commandline (cmd) is just awful and outdated. And while some people swear by the MinGW stuff, I loathe the Unix commandline. So Powershell was the only good way for me on Windows to use git.

Now, thanks to some great work from Keith Dahlby, Jeremy Skinner and Mark Embling using git from Powershell just got a whole lot more comfortable with Posh-Git.

Documentation is still a bit sparse, but Posh-Git at it’s core gives you two things: It modifies your Powershell prompt to display relevant git information (branch name and staged/unstaged changes) and adds tab-completion to all git commands. Tab completion also works on branches so you can even hit tab on a git checkout and it will auto-complete to a branch. Really really nice I have to say.

Here is how my git shell looks like now with Posh-Git:

Once you have changes it will display them also on the prompt:

(Meaning: 1 new file, 1 deleted and 0 old ones changed)

Installing

Unfortunately not everyone is a Powershell buff like Keith and friends, so I had a bit of trouble finding out how to set up Posh-Git. Actually, it’s dead simple, but nobody told me: Just put all files from the Posh-Git repository into the folder:

C:\Users\<username>\WindowsPowerShell\

And rename the file profile.example.ps1 to Microsoft.PowerShell_profile.ps1. If you already had a PowerShell_profile.ps1 file set up with some custom settings, you can just add the code from profile.example.ps1 to your existing profile (assuming you didn’t change your prompt before).

After that, restart your Powershell prompt and enjoy!

Important:

The latest Posh-Git is only working with git 1.7.1 and higher, so if you are still running the 1.7.0.2 release you have to use the v0.2 Posh-Git release.

I needed one simple thing: Delete all .svn folders from a repository so I can send it to my customer. While searching most of the results I got where either wrong, or completely besides the point, so I decided it may be worth sharing:

get-childitem -Include .svn -Recurse -force | Remove-Item -Force –Recurse

It was pretty inevitable that Google Wave would fail after being hailed as the solution to all our problems. Still, looking at a defeat gives me a feeling of malicious joy.

Let’s start at the beginning: I got my invite almost 3 weeks ago, and after an initial: wow cool. I found out that nobody I care about had Wave.

After another week or so I finally got 20 invites to give out (if you want one send me an email, I’ve got 13 left) and finally managed to get the most important people I communicate to into Wave.

And, we had a lot of fun watching each other’s cursor spit out text live on the screen. Unfortunately, that was the only thing we found useful, and it was only funny for about 20 minutes. After that, we went back to our lives and that’s it. I’m still waiting for a reply to a Wave I sent Kristof almost 2 weeks ago.

So, what’s the problem? Wave technology is revolutionary, the idea is just not. It’s at heart:

Awesome technology looking for a problem to solve

Wave fails in most/all of it’s goals:

Replace Email: Ok, so Email is everywhere and it works (thanks to GMail). I get mails pushed to my Android phone, and all in all: It does everything I want flawlessly and most importantly: EVERYWHERE.
Wave on the other hand: Only inside my browser, no notification tool whatsoever. Pretty much equally useless as Facebook Messaging.

Replace Chat: Instant typing is funny, but using the tool for IM just does not cut it usability wise. Live and Skype are great at that too, and even ICQ had that instant typing thing going some versions back (nobody wanted it). Wave once again misses all the major points here: No mobile client, no notifications, no desktop client.

Replace Message Boards: Try running a public community off Wave: It’s impossible. Since you have to add people to the wave one by one, there is no way to spawn a new thread unless your community is really really small. Public viewing (the main purpose of most messaging boards) is impossible, thus the whole thing is not suited to replace a message board.

Replace Wiki: Again, who cares about a wiki if it’s not publicly available? I know really few people who have a wiki for <5 people, and even those few won’t care for Wave’s wacky and really laggy Playback feature.

Be a collaboration tool: Well, Wave does that pretty well. Only that I don’t really see any online collaboration happening anytime soon, since most people are just too used to sending Word documents or Excel sheets around, they won’t dumb down to using a Wave just because they see each other’s cursors.

Well, and that’s about it. Wave tries to do a thousand things, and succeeds at not one of them. It’s totally useless without having any sort of desktop integration and mobile device integration. And once it has all of that, I still see myself sending more “Hey check your wave” emails than receiving a answer through wave.

What I want now? I want Google to use the awesome technology they created with Wave and bring it over to GMail. I want to be able to drag&drop files to my GMail and have them be attached to my mails. I want this incredible spellchecker inside GMail and I want it now. That’s all. I don’t care for your revolutionary shiny thingy that does everything but nothing.

Let me say one thing upfront: Setting this up has been a HUGE pain in the ass (PITA for short), and I really hope this gets fixed sometime in the future, because those 3 hours I just spent getting this done are never coming back..

Ok, just to make sure everybody understands: dotless is built using a PSake build script that has to be run through Powershell. The script itself calls out to git and therefore relies on git being installed into the PATH.

First: Git-Teamcity

Since our build relies on executing a git command during build the official JetBrains plugin doesn’t cut it (it only copies the sources, not the .git folder). So I downloaded git-teamcity from GitHub and built it using maven (at least something worked).

After that I followed this tutorial on how to install the plugin on TeamCity:

• package the plugin by following the steps outlined in file pkg in the Git plugin folder: create a foldergitAgent/lib in the folder target, copy all the .jar files (should only be Git-vcs.jar) to this folder, and then zip gitAgent to gitAgent.zip
• deploy the plugin by following the steps outlined in file deploy in the Git plugin folder: copygitAgent.zip to \webapps\ROOT\update\plugins, and copy Git-vcs.jar to\webapps\ROOT\WEB-INF\lib

Well, after setting up a new VCS Root inside TeamCity the most important part is to set the VCS checkout mode to “Automatically on agent (if supported by VCS roots)”

Warning: Also make sure that you have git installed at C:\Program Files\git, because that is the only place git-teamcity will look for the bin (unless you change the code).

Second: Execute Powershell

Apparently there is some major bug with the ConsoleRunner inside TeamCity so all attempts to simply run the Powershell didn’t work. Directly invoking Powershell led to the build timing out. After some digging I found this thread that explained the problem and hinted at a possible solution: Touble with Powershell and NAnt during build

So, I created a .bat file called TeamCity.bat that calls Powershell directly from it’s full path (C:\Windows\System32\…) like this:

C:\WINDOWS\system32\windowspowershell\v1.0\Powershell.exe .\psake.ps1

But this doesn’t work due to the above bug in TeamCity. The build kept hanging and eventually got terminated due to an timeout. So I had to change it to something like this:

echo abc | C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe .\psake.ps1

Putting echo in front of it made it work, I have no idea why, but id worked.
Now the next problem came up: although I explicitly ran Set-Executionpolicy on the box the runner’s executionpolicy was not set. So I added the Set-Executionpolicy to the .bat file:

echo abc | C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe Set-ExecutionPolicy remotesigned
echo abc | C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe .\psake.ps1

Now, finally the script was executing, but due to no environment variables, my buildscript could not locate git (due to the ConsoleRunner not having ANY environment variables present).

The final version of my TeamCity.bat then included a change to the PATH variable and it finally worked:

Set "path=%path%;C:\Program Files\git\bin" 
echo abc | C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe Set-ExecutionPolicy remotesigned
echo abc | C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe .\psake.ps1

At that point the build was finally executing and I then only had to tell TeamCity where to find the build artifacts and I was done.

Conclusion

Now that it works, I’m glad I took the time to set it up. But the process could have gone smoother.
Anyway, the good news is:

You can now get a release version from every future commit to the dotless repository right from our dotless TeamCity server!

When developing a library that should be used by 3rd parties one major concern is dependency versioning. Meaning, if your code uses a common library like Castle.Windsor, things will get ugly if your users also use Castle.Windsor in another version.

Especially with very popular infrastructure libraries like Castle you can’t expect all your users not to use it, after all you’re probably using it for the same reason they do: Best of breed solution to a common problem.
To avoid trouble, many library authors decide not to take external dependencies so they won’t see versioning issues, while having to re-implement some infrastructure themselves.

Coming up with something simple usually isn’t that hard. If you just need a very limited feature set you can build your own Inversion of Control container quite easily without relying on external libraries. Yet, if you do you still have to spend time building, maintaining and extending the thing over time.

The other option is to use the fabulous tool ILMerge by Microsoft that allows you to munch multiple assemblies into one DLL. This is also handy if your product consists of many assemblies that you want to bundle, but in this case there is one cool thing ILMerge does: /internalize

ILMerge usually is called from the command line and works like this:

ILMerge.exe <main-assembly.dll> [<library1.dll> <library2.dll>] /out:<output-file.dll> /t:library

Now if you add the magic parameter /internalize ILmerge will hide all type names inside <library1.dll> and <library2.dll> from assemblies that reference the output assembly.

So in ElmsConnector’s case where Windsor is used internally the ILMerge call looks like this:

ElmsConnector-partial.dll is the original output dll from my msbuild process while ILMerge will merge all of these Castle assemblies into the output ElmsConnector.dll.
Now the real magic here is that if I open the resulting assembly in Reflector it still lists all Castle assemblies:

But inside Visual Studio none of the Castle.* namespaces exists because they are hidden.

This technique allows us to use our favorite tools in libraries without having to think too hard about versioning.

Now, obviously there are also some things to consider here:
If you want to expose any class that is inside one of the internalized assemblies, you have to tell ILMerge so through the exclude file (an example of this can be seen with Rhino.Mocks). Once you exclude one type and your users try to use that type they will see a “ambiguous type” compile-time error. That’s why Rhino.Mocks also comes in a unmerged flavor

Another thing to remember is (especially with web-apps) that your users can’t see any internalized assemblies, so any configuration you put into your web.config for them won’t work. Best example may be the PerWebRequest lifesyle for Windsor: It relies on a httpModule to be registered through the web.config, you can’t make that happen with the externalized assembly (and it leads to versioning problems once you exclude it).

While browsing a bit through the GitHub guides section I noticed a wonderful git cheat sheet that outlines the most used commands with some basic usage instructions created by Zack Rusin.

I have a love/hate relationship with cheat sheets because most of the time I print them and then they usually merge with all the trash that’s laying around my desk so I hardly ever get to use them (except for when I really need them and they are laying face down below my mouse pad).

So the obvious place for that sheet would be my secondary monitor so I can refer to it when needed. Only problem here is that I really don’t want to run a browser window all the time just to see a cheat sheet, and setting it as my wallpaper would mean no more beautiful images changing every 10 minutes (I love Win7 for this!).

Now, what is between your applications and your desktop? Right: Windows gadgets.

By following the guide from the Microsoft developer center I very quickly ended up with a quite nice gadget that now beautifully floats above my desktop with all the common used git commands I need to check while scratching my head (dementia I hate you).

Pair this with the awesome Aero Peek at the desktop from Windows 7 (if you hit Win+Space all Windows become glass and you see your gadgets + desktop), and you can quickly glance at the cheat sheet without having to run any application or change your wallpaper. And if I don’t feel like doing git I just close the gadget with one click.

As said above, the cheat sheet is done by Zack Rusin. Thanks for this gem! The code for the gadget and the download is on GitHub and is licensed under the ASL-2 (yeah I like that license a lot).

The GitHub repository is at: http://github.com/Tigraine/git-cheatsheet-gadget

And to just download the gadget hit the downloads section within GitHub (or directly)

Oh and please excuse if GitHub is down sometimes right now. They are in the process of moving their servers to a new hoster and hopefully they will be reliably back up by Monday.

After almost two weeks of waiting for it I finally picked up my Wacom Bamboo today.

So, here comes the obvious for a programmer:

So, I got myself a pen tablet. Why would I do something like that?

First: Rest assured, I didn’t jump on the designer bandwagon, I still suck at drawing and that Hello World up there took me 3 tries and still looks bad.

It just happened that I loved Jon Skeet’s presentation slides he had for the OS Jam at Google London on C# 4 and DLR. The idea is just brilliant. Almost no real content on the slides, just some pointers in a very “human” style.

While I was preparing for this years summer-camp at the University (I’m instructing some kids on XNA game programming again) I used a CintiQ 21UX we have sitting at the company to try this with some pretty cool results:

Obviously, a bunch of 16 year olds isn’t the perfect gauge for presentation slides, but almost everyone who saw that slide deck loved it. It’s so totally different and less formal and tense that it was totally worth the work. I just didn’t want to make a habit out of using other people’s PCs at work so I obviously needed something similar, yet much cheaper. And that’s where the Bamboo A6 really came in handy: 70€ at my local DiTech store was quite a bargain. (Although it took them 2 weeks to order and deliver that thing!)

On the Bamboo side of things, it just works. You plug it in and it works. After installing the driver I had around 30 minutes of trouble finding the settings dialog to make the tablet not target my whole screen (A6 pointing at a 24” screen is just awful), but once I reduced that it became a joy to work with. Recognition is very sharp and very precise, the different pressure levels are nice in Photoshop.

I’m also amazed about how well the Windows Vista handwriting recognition has become. Obviously as a programmer I’m still a thousand times faster when using the keyboard, but it’s nice see it working.

Another application besides presentations is obviously my blog. I hate UML modeling software with all my heart. So much that my drafts folder has accumulated 3 different rants about how clumsy and slow it is to throw together a UML with the current tools. I usually end up writing code to generate a class diagram instead of trying to model a class without coding it.
With the power of a tablet I can just throw together a raw sketch out the UML to illustrate my point without having to jump through all the hoops current modeling software puts you through. So in the future, expect some of these:

Btw: Thanks for all the feedback on the iC-Website design (if you didn’t already vote, please tell us what you think)!

After posting my tools list today I got asked why I didn’t list any testing frameworks. Obviously, I love testing, so why no testing tools like Gallio, NUnit or Testdriven.NET etc?
The answer is rather simple, Resharper runs my tests for me.

By default Resharper can run NUnit tests, if you install Mbunit it can run those too, and if you just copy over the resharper support library from the XUnit contrib project to your Resharper/Plugins directory it can also run XUnit.

Also, almost all open source frameworks out there include their test runner in their code tree, so you don’t need to worry about what exotic test frameworks are out there, you’ll be provided with the appropriate runners.

On the testing framework side I recently (~4 months) switched over to xUnit as it’s syntax felt much better than that of xUnit or Mbunit.
Also I am currently looking into maybe using a BDD testing framework like MSpec.

I always thought that I am up and running the moment Visual Studio is installed on a machine.
Unfortunately, life isn’t that easy any more and I thought it might be interesting to share what I consider essential from my toolbox.

IDEs

1. Visual Studio 2008
2. Resharper 4.5
3. Notepad++

Although some people say they can work with other IDEs in .NET, I consider Visual Studio a absolute necessity. Not so much for the Studio itself but as a shell for Resharper, the very best tool I have yet come across. It’s so damn convenient and increases productivity by such a margin that I simply can’t use Visual Studio without it any more. Although Resharper isn’t free, I strongly suggest you try it out for 30 days. I feel it’s a good investment.

And Notepad++ is one of many great simple editors that make editing and reviewing of files easy.

Source Control

If you plan on working with open source tools, be prepared to bring their tools to the party. Nothing is worse than needing some source and not being able to access the SCM.
I usually install the following:

1. TortoiseSVN – Subversion right from the Explorer right click menu. Very good and very mature SVN client.
2. SlikSVN – Unfortunately TortosieSVN doesn’t install SVN binaries, so if you want to be able to run SVN from the command line you better get the conveniently packed SlikSVN subversion binaries.
3. TortoiseHG – Same idea as with TortoiseSVN but for Mercurial, but it installs the hg binaries so you can use hg from the command line.
4. msysGit – A GUI for git together with a custom git command line that emulates a *nix shell for git operations. Not so convenient as HG, but Fluent Nhibernate and most tools by Jon Skeet use git.

Build tools

Getting the source is usually not enough, sometimes you need to be able to build it too.
While most projects can be built by simply starting up Visual Studio and building, others require you to run a build script like NAnt.

1. NAnt – NAnt is a free .NET build tool. In theory it is kind of like make without make’s wrinkles. In practice it’s a lot like Ant.

Download the latest NAnt release and unpack the zip to some convenient folder. Then create a file called nant.bat in your C:\windows folder with the following content:

@echo off
"C:\Program Files\NAnt\bin\NAnt.exe" %*

(Obviously you should change the path to your NAnt executable).

Now whenever you encounter a project with a *.build file you can simply start a command line window and type nant to start building the source (that’s how you build the the Castle Project and NHibernate).

1. Rake – I don’t use rake, but I sure know Fluent NHibernate does. Rake is the build tool used for Ruby projects, but it’s gaining popularity. On windows installing it was rather simple, just get the Ruby One-Click Installer from their downloads page and install it with gems (gems is used for installing extensions and libaries).

If none of the above apply, usually every project has a howtobuild.txt that instructs you on how to run the build.

Database

Hugely depends on what tools you use. But it never hurts to have the following:

1. Sql Server 2008 Management Studio Express – It’s free, and allows you to run queries and create databases. Nothing fancy as reporting or real server administration, but what developer really wants to do a DBAs job?
2. NHProf – If you are using NHibernate for your data access needs (and I believe you should), you will find this tool well worth it’s money. It’s by no means cheap, but it will watch all your database queries, analyze them and point out possible performance bottlenecks for you.

Others

1. Sourcegear DiffMerge – A very good and free diff tool in case the ones in TortoiseSVN don’t cut it.
2. .NET Reflector – Sometimes you don’t have access to the source code, or you don’t want to get the source just to look at one file.

   .NET Reflector allows you to look at all the types inside an assembly, and if it’s not obfuscated it allows you to decompile it into your language of choice and look at the code (you could decompile VB programs into C# for example).

Please note that there are myriads of other tools lists out there, and if your are a web developer you’ll need some more tools for debugging HTML/JS. The above are the ones I consider essential to do .NET desktop/backend development when using open source libraries as Castle or NHibernate.

While creating a Windsor XML configuration for a new project today I found myself looking too much at the reference to get started. I figured this may be because of the lack of a schema that would provide me Intellisense in Visual Studio. Shockingly I couldn’t find a xsd schema file for the Windsor configuration.

I then looked at some w3schools tutorials and figured out how to do a xsd schema myself and tried to remodel the Windsor configuration reference.

You can grab the xsd schema file here: windsor-configuration.xsd

I’ll post a little tutorial on how to load it inside Visual Studio later.