Then… Along came Subversion (everyone might have known – but it came along – into my life). And I was amazed once again! It was CSV – but better! Oh my gods! Better! Than CSV! If I had a scale I needed a new one – this was off the charts! Every project I have worked on since then have used Subversion. It’s amazing. Ok – I admit it – it has some… ehm… let me get back to that – for now: Subversion is great! I even have my own repository for my @home projects – very neat. I don’t really share them with anyone – but they are in a Subversion repository – and that is great!

Ok – I admit it! Subversion has some odd bumps. Branching and merging is one. I read a small tutorial about it and went for it! No problem! Well… Until we had to merge some changes in the stable version to the development branch – how was that done. I have to say – I need to look merging branches up every single time I need to do it. That is ridiculous! I’m a developer! I use a tool written by other developers! To be used only by developers! And the way everyone develops software is by having at least one stable branch and one development branch (if you don’t – then we need to discuss something completely different! If it is because merging and branching sucks – please read on). Why is this so hard!? To tell you the truth – it’s not!

Let me nail this to the wall: BRANCHING AND MERGING IS EASY!

It is a 3-step process:

1. Get rid of your old version control system!
2. Get Mercurial (or Git)
3. Branch/merge happily hereafter!

Easy!

There are several things I’d like to point out – more of that in a later post!

First you should go learn the basics – I recommend: Hg Init: a Mercurial tutorial, by Joel Spolsky.

I am using Visual Studio 2005 so this might have been resolved in 2008 or 2010 – but non-mandatory program suites call for previous version updates! (This is why our rather limited team of developers solve this by supplying mandatory updates via subscription)

Anyway – My solution has a few projects (a main .exe and a few DLL’s) and one of these holds some settings and resources which is accessed through the ‘standard’ interface. We’ve simply double clicked the right place and added settings and resources. It works! It’s magic!!

The problem occurred when I wanted to change the default namespace for the project containing the settings and resources. VS2005 refactor my settings and resources to the new namespace – which is great, that was what I wanted – but in EVERY place where these are referred I need to change the reference manually! That was a LOT of work! Luckily it required no thinking at all!

I find it very ridiculous that the namespace is changed for the settings/resources but isn’t changed throughout the rest of the code – this is actually a feature that the normal ‘refactor’ function handles nicely without much trouble and something that a simple search and replace can solve…

Our main program queries a server with the version number and receives an address from where the newest installer can be fetched. The program then launches a browser that downloads and runs (on the users request) the installer – bam! Updated!

So we thought – but it turns out that we made a minor mistake (I’m gonna claim that it is a browser misbehaving ’till the end of days!) that caused the older version to be downloaded instead. The case was this:

We always point a user to a static address containing the newest version. The static address is a PHP script redirecting to the right/newest version. The redirect was done with a HTTP 301 (moved permanently) and therein was the error! See (this is tested in Chrome and Chrome only) when the browser sees that the address it is GET’ing is moved permanently it decides to cache the multi-MB install file. When the user returns a week-or-so later GET’ing the same static address (now redirecting by 301 to a new address) the browser (Chrome!) don’t really bother actually performing the GET – it just assume that that address has moved permanently and therefore we GET the address that it was previously resolved to!

Ouch! Users where stuck in an endless update cycle! I wrote a short piece about it on our company weblog to help users update properly.

Needless to say we changed the PHP script doing the redirect – and made some small adjustments to do avoid this type of problems!

Running Eclipse in DDMS mode will enable a console where coordinates can be typed and sent to the debugger – very nifty. Except it didn’t work! During the first try, only the first location change came through to the UI. Later tests showed that location (regardless of input) at 0, 0 – which equals ERROR!

After spending some hours searching the internet and verifying that location changing worked by manually telnet’ing to the emulator and typing coordinates the mystery unfolded and the solution presented itself!

The problem is Eclipse locale handling (please not that ‘locale’ in this context has nothing to do with ‘location service’). In a classic case of parsing decimal strings the problem occurred in Eclipse and not in the emulator. The solution to the problem was to add a line containing “-Duser.language=en” to the eclipse.ini file (on Mac OS X this means opening the App-folder or vim’ing it from the command line). Problem solved – happy developer!

Even the smallest amount of programming I do go in my repository, and I wouldn’t want it any other way – the luxury of being able to roll back and forth, branching, merging and suddenly sharing with other developers if the need arise is very nice!

One of the main issues though – especially when working in a team – is how often and how much to commit. During the past few years I’ve realized a few key points:

• You can never commit too often! (Given that:)
• You should never commit code that doesn’t compile!

Following these points is easy, important and gives you very high flexibility. I bend the  second rule a bit, and add the following:

• Branches are for experiments and long hard deviations, and
• Only trunk needs to be compileable at all times

This comes from the (well known) trunk/branches/tags-model which we established when we started using Subversion. We reserve trunk for the place from where we can always release a new version. Code in here should always be compile-ready – no exceptions to this rule at all!

Our branches are used for experimental development, new versions etc. and the compile-issues in here shouldn’t be to the annoyance of the other developers but generally no more than one day’s work should go in each commit (see the first rule)!

Needless to say I follow these rules very precisely all other projects, even the ones where I’m alone and working at night.

The problem with the whole idea is that Google App Engine don’t allow me to handle data requests larger that 1 MB without going through the Blobstore interface. This would be now big problem for me except the fact that to use the Blobstore API my account should enable billing. The… Setup… Process… Of… Billing… And… Quotas… Is… Long… And… Hard… Geez! There are various (personal as well as non-personal) reasons that I just don’t feel like enabling billing on my Google App Engine account just yet…

So for now – this project has been shelved – at least for the Google App Engine platform – I am (as you would guess) still keen on the whole idea and will look into a more traditional development environment ASAP.

I am writing a simple file-sharing service – I tend to use the term ‘drop-box’ a lot when explaining about it. The concept has now been proven (sending e-mails back and forth – log-in – upload – storage etc.) so now I am looking for some cool graphics/icons on iconfinder to make it look good.

I will post a more thorough description of the application – with links – as soon as I’m done with the first public version.

The file format that our software uses for saving and loading projects are basicly a ZIP-archive containing XML. We started noticing some strange error reports that all pointed in the direction of the save-method. This is one part of the program that have never really caused any problems before. The exception being thrown said something about “surrogate character”… More specificly invalid high surrogate… This was the first time I’d heard that term so I quickly googled it and found the answer: Something in the string being saved in the XML-document was in an invalid byte range. How nice…

This is particular funny because the input data came from Excel 2007 files, which is also ZIP-archives containing XML… Which means that the .NET conversion from XML to unicode string and back to XML was failing… ! The solution was to sanitize the strings before putting them in the XML-document for output – something that seems like a nasty hack I didn’t really need if the XML-output code in .NET would encode the strings properly.

Or to put it in other words: Silverlight – I don’t get what the fuzz is about!

We already have applets (Java) and flash… To be honest – the only real reason to add another technology to the list of shockingly overlapping solutions is that it is powered by .NET and backed by Miscrosoft…

(ok ok – I know – Silverlight isn’t new – not even by a long shot – but I really still find it kind of redundant)

I have been researching web technologies and programming languages for a future project – and the overwhelming array of redundant technologies left we with a slightly confused feeling. Anyway – I know what road to take – I suspect that I actually did before doing my research.

The game was first announced in 2006 which means it has been in development for at least 3-4 years. In the entertainment and gaming industry this is a very long time. This long wait is comparable to the development time of Gran Turismo 5. But why are these games taking so long?!

Well – actually they have something in common. They are both the first installment on the new platform (PlayStation 3 / Xbox 360) in the brand new era of HD gaming. Both series have been known to deliver bleeding edge graphic experiences since the PlayStation days (look – no version number on the PlayStation – that’s how we did it back then!) pushing the consoles capabilities beyond known limits.

To fully achieve this in the current market with the current consoles obviously required a lot of work. A lot of hard ground building work. But since the known capabilities of the consoles are currently a moving target the development might have been affected by sliding requirements. I don’t have any sources that backs this claim but I certainly hope that the new installments are build on top of some robust engines that will allow scalability for some years. Thank good HD-tv’s don’t go beyond 1080p now they’ve delivered games with that performance.