So what’s so special with this map? Maperitive offers the export-bitmap command, which basically exports the currently visible map portion to a bitmap file. What’s new is that you can set a higher (> 1) scale for the export:

export-bitmap scale=3

which will produce a bitmap with higher resolution, but with the rendering rules applied to the original zoom level. This can be useful for printing maps in higher quality.

In future I plan to introduce a SVG export command, which will make map post-processing even easier.

I’ve also created a dedicated Google Group for Maperitive to make discussion and help seeking easier. You are welcome to join in.

The next thing is to start to write some documentation, since I know this is the main problem right now.

And expect Maperitive updates (in fact I’ve already released one this morning).

I’d like to stress that work on Maperitive is far from finished. This release is just the first one I felt confident enough to send to the public, both in terms of stability and in terms of functionality it offers.
I’ll be posting more on how to use it, but let’s first take a look on what it currently provides and what it lacks.

The Good

OK, first some of the stuff I think you’ll find interesting:

• New rendering rules system: it’s more powerful, more flexible and (I think) easier to write.
• Linux, Mac: due to improvements in Mono and also due to the new code, Maperitive now seems to be working on Linux and Mac without any major problems.
• Scripting: everything Maperitive offers is available through scripting commands. This makes automating stuff much easier.
• Auto-updating: I’ve devoted a lot of effort on making Maperitive update itself automatically when a new version is available. There are some glitches on Mac, however.
• Querying: you can now use the same query “language” used in rendering rules to look for stuff on the maps.
• Relief contours: they’re back! Since I started working on Maperitive, I simply didn’t have any time to fix contours generation on Kosmos.

And last, but the most important: Maperitive right now is more of a framework than a finished product. What does this mean? The main reason I started rewriting Kosmos code was to make it easier to add new features. This has now been achieved, to a large extent. What comes next is actually adding these features.

The Bad

Now the bad parts:

• GUI: as you will see, it’s pretty vacant . A few months ago I decided not to spend too much effort on making Maperitive look like Kosmos. That would have taken me at least a couple of months of more work before I could actually release anything. But that doesn’t mean the user interface will not improve in the near future!
• Features: Maperitive does not offer everything Kosmos did. Again, the number one task for me right now is to add all Kosmos stuff to Maperitive.

The Ugly

Yes, it’s GUI again . Linux and Mac users will have to suffer a pretty ugly interface. I guess this is the price of cheap portability: Maperitive currently runs on different platforms with virtually the same code base (again, thanks to Mono guys). If you notice any big issues, please write (you can use send-feedback command in Maperitive to write to me directly).

Off to write some code.

• BSON Serialization – Karl Seguin – CodeBetter.Com – Stuff you need to Code Better!
  
• NBuilder – Rapid generation of test objects for .NET
  
• MF Bliki: VcsSurvey
  
• Stop Apologizing for Being In Business. | Startup Daddy Home Business Development
  
• Chile quake may have tipped Earth’s axis – CNN.com
  
• Blind man plans to hike AT end to end » Knoxville News Sentinel
  

• An Overview of Shareware Registration Services
  
• Why the internet will fail (from 1995) « Three Word Chant!
  
• Sysi: the ultimate administrators toolkit
  
• YouTube – Why Larry Ellison hates Cloud computing
  
• Miss Universe Pageant Winners
  

The white-ish lines represent OSM ways. The green color depicts OSM areas. The rules for this are quite simple:

features
    lines
        all lines : 
    areas
        all areas : 

properties
    map-background-color : #181818

rules
    rulefor : all areas
        define
            fill-color : green
            fill-opacity : 0.1
        draw : fill

    rulefor : all lines
        define
            line-color : lightgray
            line-width : 1
        draw : line

Anyway, I’m still hoping I’ll be able to fix all the “todo” stuff from my list within few weeks, but I cannot promise. It seems that for each item I remove from the list, two new items appear. I guess I’m another victim of the Ninety-ninety rule.

photo credit: wok

In the previous post we discussed various relationships between singletons and transients in an inversion of control container. I introduced WindsorContainerInspector, a little utility class for analyzing the container and showed a sample unit test which looks for singletons that rely on transient objects.

Now I’ll show a few other checks that I think are good to perform on the container. They involve disposability of objects.

Disposable Transients

Let’s say we have a transient service IWebClient:

public interface IWebClient : IDisposable
{
    void DownloadMeSomething(string somethingUrl);
}

As you can see, the service implements IDisposable. Now let’s say we have a class DownloadData which depends on this service:

public class DownloadData
{
    public DownloadData (IWebClient webClient) {...}

    ...
}

Note the constructor dependency on IWebClient. What’s wrong with this picture?

What happens when the DownloadData is no longer used? The webClient is not disposed. We could hold up some valuable system resource by not disposing of such an object. And since we know IWebClient is defined as transient in our IoC container, we can be pretty sure that DownloadData is the only one using the received IWebClient instance. So we are responsible for this instance!

In other words, our DownloadData should also be disposable. We can say that, in general, components that depend on disposable transients should also be disposable:

[Test, MultipleAsserts]

public void TransientsThatRelyOnDisposableTransientsShouldAlsoBeDisposable ()

{

    Type disposableType = typeof(IDisposable);

    IList<KeyValuePair<ComponentModel, ComponentModel>> dependencies = inspector.FindDependencies (

        (a, b) =>

        {

            return a.LifestyleType == LifestyleType.Transient && false == disposableType.IsAssignableFrom (a.Implementation)

                && b.LifestyleType == LifestyleType.Transient && disposableType.IsAssignableFrom(b.Service);

        });

    foreach (KeyValuePair<ComponentModel, ComponentModel> dependency in dependencies)

    {

        Assert.Fail (

            "Transient component {0} relies on the disposable transient component {1}, but it itself is not disposable",

            dependency.Key.Implementation.FullName,

            dependency.Value.Implementation.FullName);

    }

}

Some might say that this kind of check can be done by static analysis like FxCop. FxCop will detect this only if DownloadData stores the IWebClient in a class field. But we could have used IWebClient parameter just within the constructor and then forget about it:

public class DownloadData
{    
    public DownloadData (IWebClient webClient) 
    {
        webClient.CheckConnection();
    }    
}

In such cases no warning will be issued by FxCop.

Disposable Implementations Of Non-Disposable Services

What if we had another service, called IMailChecker:

public interface IMailChecker
{
    bool AnyNewMail();
}

and we implemented a GMailChecker:

public class GMailChecker : IMailChecker, IDisposable
{    
    public bool AnyNewMail() {...}
    public void Dispose() {...}
}

Notice GMailChecker implements IDisposable in addition to IMailChecker interface. But IMailChecker itself is not defined as disposable. How will the user of IMailChecker service know whether the object it holds should be disposed or not?

One way would be to use reflection to determine this. But this is very cumbersome and easy to forget when coding. My way of thinking is that if there’s reasonable possibility the implementations of the service will require disposability, you should declare the service interface as disposable. We can check for this condition with the following unit test:

[Test, MultipleAsserts]

public void TransientsThatRelyOnDisposableTransientsShouldAlsoBeDisposable ()

{

    Type disposableType = typeof(IDisposable);

    IList<KeyValuePair<ComponentModel, ComponentModel>> dependencies = inspector.FindDependencies (

        (a, b) =>

        {

            return a.LifestyleType == LifestyleType.Transient && false == disposableType.IsAssignableFrom (a.Implementation)

                && b.LifestyleType == LifestyleType.Transient && disposableType.IsAssignableFrom(b.Service);

        });

    foreach (KeyValuePair<ComponentModel, ComponentModel> dependency in dependencies)

    {

        Assert.Fail (

            "Transient component {0} relies on the disposable transient component {1}, but it itself is not disposable",

            dependency.Key.Implementation.FullName,

            dependency.Value.Implementation.FullName);

    }

}

Below is the updated the implementation of WindsorContainerInspector. Next time we will be discussing issues (= mostly problems) around disposing stuff received from the Windsor container.

public class WindsorContainerInspector

{

    public WindsorContainerInspector(IWindsorContainer container)

    {

        this.container = container;

    }

    public IList<KeyValuePair<ComponentModel, ComponentModel>> FindDependencies(

        Func<ComponentModel, ComponentModel, bool> dependencyPredicate)

    {

        List<KeyValuePair<ComponentModel, ComponentModel>> dependencies = new List<KeyValuePair<ComponentModel, ComponentModel>>();

        foreach (GraphNode node in container.Kernel.GraphNodes)

        {

            ComponentModel dependingNode = (ComponentModel) node;

            foreach (GraphNode depender in node.Dependents)

            {

                ComponentModel dependerNode = (ComponentModel)depender;

                if (dependencyPredicate(dependingNode, dependerNode))

                    dependencies.Add(new KeyValuePair<ComponentModel, ComponentModel>(dependingNode, dependerNode));

            }

        }

        return dependencies;

    }

    public IList<ComponentModel> FindComponents (Func<ComponentModel, bool> predicate)

    {

        List<ComponentModel> components = new List<ComponentModel>();

        foreach (GraphNode node in container.Kernel.GraphNodes)

        {

            ComponentModel component = (ComponentModel) node;

            if (predicate(component))

                components.Add(component);

        }

        return components;

    }

    private readonly IWindsorContainer container;

}

• The Map Room: Relief: Dynamic 3D Interactive Map
  
• Footprints | Cartogrammar
  
• CeBIT 2010: German police to use open source Navit navigation
  
• Older Developers: Habits Are Going To Kill Your Career | Lessons of Failure
  
• Please Rob Me
  

• Apple vs HTC: a patent breakdown – Engadget
  
• ReSharper’s Hidden Gem
  
• The Map Scroll: Pacific Tsunami
  
• Pivotal Tracker – Free Lightweight Agile Project Management & Team Collaboration, from Pivotal Labs
  
• Satnav is to blame, says driver rescued from swollen river | News
  

• ReSharper :: What’s New in ReSharper 5.0
  
• Map Font Basics (Article 1): Typography
  
• Pricing software
  
• jsFiddle – Online Editor for the Web (JavaScript, MooTools, jQuery, Prototype, YUI, Glow and Dojo, HTML, CSS)
  
• Domain Events – Salvation