The issue was two fold. a) My local Terminal.app was reporting itself as xterm-color instead of xterm-256color. You have to update this setting in your Terminal app here:

Once done you only need to edit your .screenrc to include the following 3 lines:

# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"
# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
# erase background with current bg color
defbce "on"
# set TERM
term screen-256color-bce

Problem is: Even if you set your .screenrc correctly, it won’t matter if your terminal is not reporting the correct version string in the first place..

But here I am and learning the ways of Capistrano and how deployments to multiple servers really should work.

Naturally I ran into issues I’ll detail a bit later, but one of my major problems with my Rails deployment was the different database.yml between my production and my dev environment.
Since the repository is in a shared location I could not put the production server mysql password into the config as it would be available to anyone with read access to the repository.
This may be something you can get away with in a corporate environment, but if you plan on ever open-sourcing your project you should make sure you don’t put production passwords into your repository .

My solution to that problem is quite simple: I ssh’d into my server and put a “production” database.yml into the home directory of my deployment user and added the following task to my Capfile:

namespace :db do
  task :db_config, :except => { :no_release => true }, :role => :app do
    run "cp -f ~/database.yml #{release_path}/config/database.yml"
  end
end

after "deploy:finalize_update", "db:db_config"

The after statement tells Capistrano to run the db_config task right before finishing the code update, but before running any migrations in case you run cap deploy:migrations (capistrano process).
And during every deployment I overwrite the database.yml from the repo with the one on the server.

I also added a assets:precompile task since Capistrano won’t run the precompilation of Rails assets out of the box (you need RVM integration for this though):

  task :precompile, :role => :app do
    run "cd #{release_path}/ && rake assets:precompile"
  end
after "deploy:finalize_update", "deploy:precompile"

Et voilá: I can now run cap deploy:migrations from my dev machine and it will automatically connect to my release server, pull the code out of the git repository, compile the assets and migrate the database to a new version.
And it will even roll-back to the old version if something goes wrong along the way.

Ps: I also struggled at one point with the SSH keys for the git repository. Since the deployment user on the server has no own private key I was inclined to generate one and add it to my git server’s allowed keys list.
But that’s apparently the wrong way to go about things. The right thing to do here is to simply enable agent forwarding so the server will forward any questions about keys to your dev machine that should have the appropriate set of keys available.

ssh_options[:forward_agent] = true

Say you don’t have a hostname associated with your server (yet), you may get bored of writing ssh root@192.168.0.1 all the time. Assuming you are using public key authentication anyways (and you should!) writing ssh myserver would be far more convenient.

Turns out you can do that by modifying the ~/.ssh/config file like this:

Host myserver
  HostName 192.168.0.1
  Port 22
  User root

Naturally, Microsoft could not include an alias for every unix command out there, so I spend a fair amount of time hunting down the Powershell equivalents to Unix commands whenever I need one.

This time it’s the time command that allows you to measure how long the execution of a particular command took. The Powershell equivalent is called Measure-Command and does exactly the same thing, returning a System.TimeSpan.

For example, to measure the execution time of a git checkout:

Measure-Command { git checkout gh-pages }

Switched to branch ‘gh-pages’

Days : 0

Hours : 0

Minutes : 0

Seconds : 0

Milliseconds : 344

Ticks : 3448544

TotalDays : 3,99137037037037E-06

TotalHours : 9,57928888888889E-05

TotalMinutes : 0,00574757333333333

TotalSeconds : 0,3448544

TotalMilliseconds : 344,8544

I considered creating an alias for Mesaure-Command to just time, but the usages are so rare that it’s not really necessary.

As you may have guessed from the title, I got myself an iPhone4 some weeks ago and love it ever since. The browser in particular is great, yet sometimes even the best browser can’t change that a website is badly designed. Too often you can’t make the content out in between all the Google Adwords, the fonts are hideous or it’s a fixed width layout that’s way too wide.

On my PC I just hit the Readability bookmarklet and through magic all the ugly stuff goes away and only the content remains. Well, since Readability is just JavaScript you can do the same thing on the iPhone too, it’s just a bit trickier to install.

Here is how a badly readable site looks with Readability (note that it does not remove images that belong to the post!):

Before – After Readability

As you can see, the width of the layout is too wide to be easily readable in portrait orientation.

Step 1: Go to http://lab.arc90.com/experiments/readability/ on your iPhone

Select all the text from the textbox on the right and copy it:

Next, just hit add bookmark on the site and save the Readability site.
Now go into your bookmarks and edit the readability bookmark.

Delete the previous address and paste the code we copied earlier.

Et voila, whenever you want to see a page clearer, just open that bookmark and it will convert any ugly site into a rather pleasant read.

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>\Documents\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.

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.

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!

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).