• How I Learned to Stop Worrying and Love the New Axis of Evil (Oracle) | Lessons of Failure
  
• Rugged(er) Android Units On The Way | AndroGeoid
  
• Number of humans who have ever lived – Wikipedia, the free encyclopedia
  
• Captured: America in Color from 1939-1943 – Plog Photo Blog
  great photos, via The Endeavour
• Dark Roasted Blend: Dwellers In The Abyss: Ugly, Monstrous Fish
  via The Endeavour
• YouTube – What different sorting algorithms sound like
  via The Endeavour

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

• Simplicity vs. Choice – Joel on Software
  
• Getting Started with MonoTouch – Marcus The Blog (by MarcusTheBold) – Los Techies : Blogs about software and anything tech!
  
• The First Thing You Should Do With Facebook Places: Don’t Let Other People Tag You
  
• Twitter Data – A simple, open proposal for embedding data in Twitter messages – Home
  
• New Android-Related Website: AndroGeoid
  
• Android: The Future Of Consumer GPS – Part I
  

• Wikipedia’s Lamest Edit Wars
  
• paper.li – read Twitter as a daily newspaper
  
• Apple’s rechargeable AA batteries are rebranded Sanyo Eneloops? — Engadget
  
• How Oracle might kill Google’s Android and software patents all at once — RoughlyDrafted Magazine
  
• The Map Room: Map Watches
  
• Fuel efficiency in transportation – Wikipedia, the free encyclopedia
  
• Initial Thoughts on Oracle vs Google Patent Lawsuit – Miguel de Icaza
  

• YouTube – How Open Source Projects Survive Poisonous People (And…
  
• List of OSM based Services – OpenStreetMap Wiki
  
• OSM Ticker
  shows you OSM map edits live. Quite nice!
• The Map Scroll: Russia’s Portentous Summer
  
• Google Streetview without People | Geospatial Talk
  
• Flattr
  
• Designs | jQuery Mobile
  
• How to Avoid Being the Asshole Architect | Lessons of Failure
  

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 http://maperitive.net/download/

Enjoy!

• YouTube – Robots with a mind of their own
  
• Package management for .NET: Nu
  
• Current Packages – nu-net | Google Groups
  
• MF Bliki: UtilityVsStrategicDichotomy
  
• <angular/>: A Radically Different Way of Building AJAX Apps
  

• NASA – First-of-its-Kind Map Depicts Global Forest Heights
  
• Continuous Delivery is Now Out
  
• Vodafone distributes Mariposa botnet | Panda Research Blog
  
• Degrees of reality in sample code – Jon Skeet: Coding Blog
  
• Amiga: 25 Years Later
  

I’ve just released Maperitive build 924 which has two new commands:

• generate-tiles: http://maperitive.net/docs/manual/Commands/GenerateTiles.html
• generate-hypsometric: http://maperitive.net/docs/manual/Commands/GenerateHypsometric.html

• e-book formats — The Endeavour
  
• Leonardo da Vinci’s Resume
  
• Damn Cool Pics: The 40 Most Bizarre Google Earth Images
  
• RIM, HTC, Nokia want no part of Apple’s "self-made debacle"
  
• The 5 Most Impractical Aspects of Superhero Costumes | Cracked.com
  
• Coding Horror: Groundhog Day, or, the Problem with A/B Testing
  
• If it worked for Leonardo da Vinci, maybe it could work for me.
  
• File:Tartan Ribbon.jpg – Wikipedia, the free encyclopedia
  Tartan Ribbon, photograph taken by James Clerk Maxwell in 1861. Considered the first color photograph
• Food and Cooking – Stack Exchange
  
• The Agnostic Cartographer – John Gravois