Published by breki on 11 Sep 2010

Storing Your Source Code

bb source
Creative Commons License photo credit: eisenrah

UPDATE: I received a very helpful comment, which seems to invalidate some of my statements in the post. Be sure to read the comment. I’ll make further updates when I do some more investigating on the matter.

For the past three or four years I’ve been using Subversion installed on my local development machine. Initially I used a custom installation on Apache, which took me quite a few hours to set up (basically if you want to have more than one repository, Apache is a must). Later, after couple of years, I started using VisualSVN Server, which is a great free self-contained SVN server installation.

This all works great, but the biggest problem is accessing the repository from the outside world, both in terms of security and in terms of me not wanting to have my SVN repository computer running all of the time (I’m a believer in keeping machines turned off if you’re not using them).

On the other hand, I started using distributed VCS systems like git and Mercurial for my open-source projects. The biggest benefit I see in the fact that you keep your own repository on your development computer, so you can have the history of changes, which isn’t really an option when you’re working with SVN in an offline mode.

So I started thinking about experimenting with a commercial VCS hosting solution like Assembla or for my closed-source projects. Apart from the decision on which provider to use (they both seem to get good reviews), the biggest question is: which VCS?

Although git and Mercurial are all the rage now, I don’t see much benefit in using them for a one-man projects on a VisualStudio platform. Let me explain why.

Integration With VisualStudio

I got so much used to AnkhSVN, that I simply cannot work without it. Renaming files, moving them around the solution, automatic refactoring using Resharper, that’s all handled pretty well by AnhkSVN. I still use TortoiseSVN for commits, but in VisualStudio, Ankh is the king. I never use SVN from the command line and I don’t need to. AnkhSVN is simply a great productivity booster.

And this is why using git or Mercurial is such a pain in VisualStudio. I frequently use “Rename class” refactoring in Resharper and it renames the class file, too. This gets undetected by git and Mercurial and I end up with “missing files” when committing.

Local Repositories

While having your own repositories on development computers is a truly great thing, not having them isn’t such an issue if your online SVN repository is available most of the time. And the problem with VS integration far outweighs other benefits of a distributed VCS when you’re running a one-man shop.

Decisions, Decisions…

So I’ll probably start using a commercial SVN hosting option, at least as a trial. Most of the providers offer limited free plans, so it’s a good place to start…

Published by breki on 06 Sep 2010

Random Thoughts

I feel I’ve been neglecting my blog lately and it’s a shame. It is not that I don’t have stuff to write, it’s just that I’m so immersed into developing various projects (mostly Maperitive) that I don’t seem to find the time and energy to take some time to write something interesting.

Yes, I know one of the first rules in writing blogs is not to apologize for not writing. But anyway, I’ve decided I should write something more regularly but deliver it in smaller packages. This way writing shouldn’t look so intimidating and it should make it easier for me to write.

How’s Maperitive

There has been a lot going on behind the scenes in Maperitive. I’ve been opening many different fronts, but I’ve mostly worked on improving the GUI. Maperitive started out as a (more or less) command line application and now I’m slowly trying to improve its usability. Right now the GUI is still too intimidating for a non-technical user and a lot of work is still needed to improve this.

Like the most of other code in Maperitive, the GUI framework has been written mostly from scratch, with some reusing of the existing code of Kosmos. I had to reinvent the wheel on each step, since there aren’t many good WinForms GUI frameworks out there (in fact I only know of one which is a beast and I didn’t feel the urge to invest a huge amount of time to try to learn it). The advantage of this is that it forced me to get to know the problems I’m trying to solve and not just sweep them under the rug using some 3rd party library.

All in all I’m quite satisfied with the new architecture. One of the main reasons I decided to pull the plug on Kosmos and start with clean code was to ensure the new architecture allows me to add new features more easily and to make the whole code base more manageable. I think I’ve achieved this, mostly by sticking to dependency injection and using Windsor Castle, an inversion of control container.

The application framework being built for Maperitive is generic enough to be reusable for other desktop applications, which could come in handy if I find the time to work on anything else. But right now I have so many ideas for new features in Maperitive that I doubt I’ll run out of work in the next year (or more).

Published by breki on 02 Sep 2010

Fresh Catch For September 2nd

These are my new delicious links for September 2nd:

Published by breki on 24 Aug 2010

Windsor Castle: Strange Resolving Behavior

A user reported a bug in Maperitive – it throws

Castle.MicroKernel.Resolvers.DependencyResolverException: Could not resolve non-optional dependency for ‘Karta.DataSources.OsmFileMapDataSource’ (Karta.DataSources.OsmFileMapDataSource). Parameter ‘fileName’ type ‘System.String’

I tried to reproduce this behavior using a simple unit test, but I couldn’t, so I’m posting the actual code. This is where the exception occurs:

return windsorContainer.Resolve<OsmFileMapDataSource>();

And this is how OsmFileMapDataSource constructors look like:

        public OsmFileMapDataSource(
            string fileName,
            IFileSystem fileSystem,
            IMapDataLayerFactory layerFactory)

        public OsmFileMapDataSource(IMapDataLayerFactory layerFactory)

Needless to say, both IFileSystem and IMapDataLayerFactory are registered in the container (IMapDataLayerFactory is registered as a typed factory, by the way). OsmFileMapDataSource is also registered as an implementation of itself. And I’m using version of the library.

What’s strange about this is that if I move the second constructor in front of the first one, the component is resolved without problems. I’m not sure if this is intended behavior, but I doubt the order of constructors should be a determining factor on how components are resolved.

But as I said, I couldn’t reproduce this behavior using a simplified test code, so I guess I should start debugging it instead.

Published by breki on 20 Aug 2010

Fresh Catch For August 20th

These are my new delicious links for August 20th:

Published by breki on 18 Aug 2010

Fresh Catch For August 18th

These are my new delicious links for August 18th:

Published by breki on 15 Aug 2010

Fresh Catch For August 15th

These are my new delicious links for August 15th:

Published by breki on 06 Aug 2010

Maperitive: Enhanced Usability & Scripting Support

Maperitive running scripts

For the last week or so I’ve been busting my fingers with one of the harder things to implement in a desktop GUI: application responsiveness when executing longer-running tasks. By longer-running I mean something that takes more than a couple of seconds.

Simple desktop applications tend to run everything synchronously: when the user presses a button, the action gets run. After the action finishes, the control is given back to the user. Simple, but totally crappy. The problem is that the action gets run on the same thread that services the GUI, so until the action finishes, the application will not be able even to refresh itself or respond in any meaningful way to user clicks or key presses. And since there is no refresh, you cannot show any progress indicators to the user. I know I wouldn’t want to wait half an hour for something to finish without some reassurance that the application is still alive and not waiting for the electricity to run out.

Maperitive already had a lot of responsiveness code implemented, but it was still an “under the construction” design. The additional complication was the fact I want Maperitive to have a good script runner and scripts can take a very long time (downloading OSM data, generating tiles etc.). After a lot of trials and errors I finally managed to implement the whole thing in a consistent package. And believe me when I say it was not easy.

So what is new:

  • When running scripts (or longer tasks), Maperitive draws an indicator on the map (see the screenshot above) and launches a “sort of modal” mode – most of GUI controls are disabled so the script doesn’t get confused by some inadvertent user action. However, the application is still responsive: you can view the progress of the script in the command log.
  • Aborting scripts: as the indicator says, you can press the escape key to abort the script. If you prefer torturing your mouse instead of your keyboard, there’s an “Abort task” button in the bottom right corner which does the same thing.

Not all of running tasks have been switched to the new system. Loading OSM files is one example of a task that will still block the GUI, but I will gradually improve these things.

You can download the latest release at


Published by breki on 05 Aug 2010

Fresh Catch For August 5th

These are my new delicious links for August 5th:

Published by breki on 31 Jul 2010

Fresh Catch For July 31st

These are my new delicious links for July 31st:

« Prev - Next »