For some time I have bee using Spotify as a music service. And it have worked out very well. With one account as a premium account and then some extra free accounts its easy to play around and create some playlists and the connect and play from the premium account.

The other thing I use a lot at home for music is my Soundbridge, when I bought it, roku labs was making it. Then it was sold through Pinnacle, unfortunately I think its discontinued now. Anyway, when Windows 7 came I could also just look up a what music I like to play, and just send the along to play to my Soundbridg. Compared to other locked in standards, that is just brilliant.

The problem

But now that I have one device and one service that I really like, I would want them to play nice together, I want the full catalog of Spotify accessible from my Soundbridge. What I really would like is to have Spotify as a uPNP server implementation, then you could easily search the full database and have the playlists ready directly. But that’s maybe for the future,

The second best thing, however, would at least to be able to stream what you got from your server to the Soundbridge, or any other streaming device for that matter. After reading several hacks and looking at a lot of solutions I found two that works for me.

Two streaming solutions 

The first is for my work computer, where I alternate from OS X and windows 7 and when I’m on OS X, I can use a commercial app called Nicecast from rogue amoeba (the also make airfoil). It’s very easy to set up but you need to start Spotify from Nicecast and you can't just execute it as usual. What more is that it doesn't code the current song name and artist to the stream. Aöpart from that it works well, it even supports streaming to the world so it means more than one receiver. But for my setup I have Windows machine as a server, so why spend $40 to only stream from my work computer?

So I go with the second and even simpler solution, a little DirectSound wrapper called dsbridge. What this does it taking the output, encode it using lame ENC and then streaming it out. It even shows the current playing song and artist together with the source (Spotify). It’s quite intelligent to, if a receiver connects to the port it silences the local output and if you stop the streaming it just restores the normal output (can be configured). It's an early hack - single stream only but sound quality is ok, and there is something to its simplicity I really like. Very nifty. 

Hope you will be helped with this if you are looking for a similar solution.

// Håkan Reis

PS: Is there anyone with a solution on how to remote control Spotify from an iPhone? :)

Update:  Spotify Remotless is an iPhone app that works together with a helper and remote controls Spotify ($4). Doing a decent job, but the effect is a bit delayed due to the re-coding dsbridge needs to do before it streams it out. It even enables you to tweet the current song, nice twist.

For quite a while I have been working at Dotway, as developer and UI guy. We consist of a group of highly specialized companies Jayway, Dotway, Testway, Leadway, and Realway. But this also created confusion, what way are we coming from. Anyway (pun intended), we decided to collect all our efforts under one name - Jayway. But rest assured, we will keep our focus on things we love and there will be a .NET team within Jayway. And soon you might also see a UX team emerge...

Here is the press release:

Five ways become one - Jayway

Dotway, Jayway, Leadway, Realway and Testway gather under one name.We now simply call ourselves Jayway. As one company we become more visible and distinct and we will be able to offer our clients an even stronger package. We are the same passionate experts working with the same intense commitment and we will continue to deliver the same first class services. You will meet the same people with the same courage and pride. And a new fish - Jay!

Like Jayway, the blowfish is unique. It swims fearlessly in unknown waters and is a rare delicacy – the best of its kind. On the surface Jayway’s offer might not be rare, but the way we solve your problems is unique. Effectively, passionate and uncomplicated.

// Håkan Reis

In the first part I wrote about how to get the version number that is available in TeamCity into the assemblies that are built and also how to maintain the dynamic unit testing feedback. I will now continue to explain how to get the complete chain working up until naming the finished package.

Propagating the version number

I left out one bit of MSBuild script that is vital for the next step. How can you transfer a version number from one project to another? Well, it’s actually quite simple, just save it as a text file among your artifacts and you can read it back up in a property in your MSBuild files. This is what it looks like in the MSBuild script:

<WriteLinesToFile File="SoftwareVersion.txt" 
                  Lines="$(BUILD_NUMBER)" 
                  Overwrite="true" />

This gives you a file named SoftwareVersion.txt that you can save as an artifact and use in the following build projects, how simple some solutions are.

File renaming and creating a package

The good thing about about MSBuild is all the extra things around just executing builds, in combination to the WriteLinesToFile there is of course a ReadLinesFromFile, and as you guessed this will read lines from files. These lines can be stored in an item collection (for many lines) or a property (that’s what we are after) like this:

<ReadLinesFromFile File="$(ReleaseDir)\SoftwareVersion.txt">
  <Output TaskParameter="Lines" 
          PropertyName="Version" />
</ReadLinesFromFile>

Now we have what we need to get the version that was built in one project to control the name of a file in another project. The renaming part is easy.Actually there are no rename task but you can of course execute a command directly with the Exec task so renaming will look like this:

<Exec Command="rename $(ReleaseDir)\SoftwareServiceSetup.msi
               SoftwareServiceSetup-$(Version).msi" />

Transferring TeamCity versions to Subversion tags

Last is to get the labels created back into subversion (as it is that I’m currently working with, it is what I know well). It is easy to just add the labels in TeamCity. The settings are placed under Version control settings in Build Configuration step two.

However, there might be a mix-up on where you want to save your tags, this is set under the VCS root configuration. The default is set to trunk=>tags but this hasn’t worked for the setup I have. Instead I have to set this to /trunk=>/tags, and remember, don’t checkout the trunk locally it will be a big checkout…

So there you have it. Version numbers that follows every build from development, through testing and ending up on the subversion labels and the package names. Traceability that will make a configuration manager cry with joy.

// Håkan Reis

Last time I posted on MSBuild and TeamCity I showed how you could use it to deploy remotely in Deploy with MSBuild and custom targets Part 1 and Part 2. There are one issue that’s always a part of professional projects - version handling. I will show you a way to let the version get into the assemblies and trickle through all build steps all the way to the production package. In the first part I will concentrate on getting the version number into the assemblies while keeping unit test feedback, where currently running tests are directly visible in TeamCity.

Setting the version in TeamCity

First off is to set the version and build number in TeamCity. This is one of the easiest parts. Just go into the General settings for the project and set up the version number format and the build counter setting. like this:

Now we have something to base our versioning on, the first part 1.0.2. are static and you update that manually as you start a new release, etc. The last {0} will give you a build number, you get the idea.

Getting the version number to the assemblies

Next step is to make sure the version number from TeamCity is used to build the assemblies and added instead of the Assembly, File and Product Version set in the visual studio project properties. But first some background.

When the assemblies are built version values are automatically set from AssemblyInfo.cs files. If nothing is set, it will get the value of 0.0.0.0, file version will get the same version as in Assembly Version and application version will follow the file version. More about this in Assembly version, File version, Product version. The basics is that if we want to control the version we must make sure the AssemblyVersion attribute  is in there. I would suggest setting it to 0.0.0.0 to make it easy to identify if anything fails to update. You could even have safeguards for it in code, aborting execution if the version is zeroed.

Now you have to make sure you change this number after the checkout but before the build has started. This calls for a shift from solution building to using MSBuild. But for the basic solution to build you only need one line of MSBuild script:

<MSBuild Projects="Software.sln" 
  Targets="Rebuild" 
  Properties="Configuration=Release;" /> 

That’s easy enough. Moving on to the version, we first collect the AssemblyInfo.cs files in the solution and then rewrite the version number with the TeamCity number. As it happens, there are a build property available containing the TeamCity number: $(BUILD_NUMBER). To get the build number into the assembly info we can use a task called FileUpdate that is part of a collection of open source MSBuild tasks, it will look like this:

<!— Collect the Assembly info files in the solution –>
<ItemGroup>
  <AssemblyInfoFiles 
    Include="**/Properties/**/AssemblyInfo.cs;" />
</ItemGroup> 
 
<!—Identify current AssemblyVersion and replace -–>
<FileUpdate Files="@(AssemblyInfoFiles)" 
  Regex=’AssemblyVersion\(“.*”\)\]’
  ReplacementText=’AssemblyVersion(“$(BUILD_NUMBER)”)]’ />

This will get the desired result, with all assemblies carrying the correct version number. However, it will also give as a new problem; we now loose the unit test feedback in TeamCity, but we can solve that in the next step.

Unit testing with feedback

When you move from solution based execution to MSBuild based, the first issue you come across is that the unit tests are missing. The natural step is to make the MSBuild script execute them. Normally you would call nunit-console or maybe the NUnit task. But that will only give you a file to display as an artifact. Not the direct and continuous feedback you get from TeamCity. Fortunately TeamCity will provide a unit test runner task that can be used instead. The following lines need to be in the MSBuild script:

<!-- Integreate with TC's nunit runner –>
<UsingTask TaskName="NUnit" 
  AssemblyFile="$(teamcity_dotnet_nunitlauncher_msbuild_task)" />
 
<!-- Select the assemblies to test –>
<ItemGroup>
  <TestAssemblies Include="**/release/*UnitTest*.dll;" 
    Exclude="**\obj\**;" />
</ItemGroup>
 
<!-- Execute the tests –>
<NUnitTeamCity Assemblies="@(TestAssemblies)" />

Read more about the NUnitTeamCity task on the TeamCity wiki, where you find information on how to execute it in 32bit, categories, on specific versions of NUnit, etc. Now we have all the parts to handle versions and still get the feedback. This also opens up some more opportunities as we now execute the build from MSBuild. We can do some pre- and post-processing around the build like zipping up files or exchange files or data after checkout but before build.

Next step is to get the version numbers across to the next project and use it for packaging as well as labeling our builds in subversion.

// Håkan Reis

Ever since Microsoft first introduced the “My” in every folder I have hated it. I know it’s my documents and my music, hell I paid for most of the music anyway and created the documents myself. So why do they continue this, even win Win7? If you look at the real name in the folder structure it is actually C:\Users\[username]\Documents not C:\Users\[username]\My Documents?

I know it can make some sense when you compare My Documents and Public Documents but I don’t like it that way, especially since the real folder name is in fact Document.

So I started to look into it and experimenting, searching through registry values and stuff with no luck. Searching the web also came up empty handed (just a lot of references to how you change the default My Documents folder, etc).

But actually it was much simpler that I expected, I just selected the damn thing and changed the name in properties. Renamed it to Documents and now it really make sense again. So I can have some peace.

// Håkan Reis

Head over to Gustaf Nilsson Kottes Blog for: 

Some code, some agile, and some muda

 Very good source of all the above, read with caution :)

 // Håkan Reis

We are deep in the planning of the next Øredev and boy is it going to be good. The full program will be shown shortly but I thought I should give you a few teasers. There will be a full day of UX tracks, among the the session you find titles like Tap is the new click and GUIDe for Saving Face: Developing Killer GUIs with Agile Methods. We are very proud to have all of the speakers with us but a couple names will be revealed shortly.

But the full day of sessions is not all we will have a fun filled day with UX workshops as well. Covering both rich internet application design and gestural and multi touch design with two really great workshop speakers.

More to be announced really soon, be sure to watch the Øredev site for the full program.

// Håkan Reis