I've been writing some code that calls for a single instance of a class per geodatabase workspace. This is important when trying to maintain things like an Identity Map – you don't want multiple instances of a class that access the same geodatabase floating around. So, I started with the GoF Singleton pattern:

    public class Singleton
    {
        private static Singleton _instance;

        private Singleton()
        {
        }

        public static Singleton Instance()
        {
            if (_instance == null)
            {
                _instance = new Singleton();
            }

            return _instance;
        }
    }

This pattern creates one and only one instance of the Singleton class within the application. However, I want one and only one instance for each Workspace that I open. When I query for an instance of the Singleton, I need to pass in the Workspace that corresponds to the Singleton instance:

    public static Singleton Instance(IWorkspace workspace)

Internally, I defined a Dictionary that maintains a mapping of instances of the Singleton objects and their corresponding Workspaces. This mapping is maintained for all instances of the Singleton class, and so is a static member:

    private static Dictionary<IWorkspace, Singleton> _instances = 
        new Dictionary<IWorkspace, Singleton>();

Each Singleton instance maintains a reference to its own Workspace:

    private IWorkspace _workspace;

When a client calls the Instance method and passes a Workspace, the Instance method checks the Dictionary to see if an instance for the Workspace already exists; if it does, then that instance is returned; if not, then a new instance is created for that Workspace and returned.

Following is the complete code for the implementation of the Singleton per Workspace:

    public class Singleton
    {
        private static Dictionary<IWorkspace, Singleton> _instances = 
            new Dictionary<IWorkspace, Singleton>();
        private static readonly object _lock = new object();
        private IWorkspace _workspace;

        private Singleton(IWorkspace workspace)
        {
            _workspace = workspace;
        }

        public static Singleton Instance(IWorkspace workspace)
        {
            lock (_lock)
            {
                if (_instances.ContainsKey(workspace))
                {
                    return _instances[workspace];
                }

                Singleton instance = new Singleton(workspace);
                _instances.Add(workspace, instance);

                return instance;
            }
        }
    }

It's important to note that we have the right test for identity. In this example, I know that I'm using the same Workspace object to create a Singleton instance, so I can use the identity operator. If I'm not sure of that, then I would need to devise some scheme to test for identity.

So, let's make this generic for any singleton ArcObjects type:

    public class Singleton<T>
    {
        private static Dictionary<T, Singleton<T>> _instances = 
            new Dictionary<T, Singleton<T>>();
        private static readonly object _lock = new object();
        private T _internalObject;

        private Singleton(T internalObject)
        {
            _internalObject = internalObject;
        }

        public static Singleton<T> Instance(T internalObject)
        {
            lock (_lock)
            {
                if (_instances.ContainsKey(internalObject))
                {
                    return _instances[internalObject];
                }

                Singleton<T> instance = new Singleton<T>(internalObject);
                _instances.Add(internalObject, instance);

                return instance;
            }
        }
    }

According to Gartner's 2010 Hype Cycle Report, cloud computing has read the hype peak, and is beginning the descent into the “Trough of Disillusionment”:

While this may be the case, there are still new examples of cloud hype cropping up every day. Witness Microsoft's current “To The Cloud” campaign:

Is the cloud relevant to the user in this case? Nope. To the user, it's a website. That's it. I can only imagine that Microsoft wants to tie the “cloud” to the consumer market to capitalize on the hype peak. Unfortunately, this is creating a huge amount of confusion as to what the cloud is and what it's for. Over at GISUser.com, Glenn blogged about a Financial Post article describing the level of confusion among Canadian executives about cloud computing. Well, no wonder, when Microsoft is telling them that it's a website where they can edit photos of their families!

So what is the cloud? It's software services and computing resources running somewhere else, that you connect to and consume over the web, as opposed to software and hardware resources running on your desktop or on a server somewhere in your organization. That's it. It's not magic pixie dust. It's just software running somewhere else that you don't have to worry about. Why is it called the cloud? Because that's what we software people draw on the whiteboard when we want to represent somewhere where stuff happens that we don't have to worry about, secure in the knowledge that it works.

Cloud computing isn't revolutionary: it's an evolution of a set of technologies and architectures that enable the business architecture of the cloud. And, really, that's what the cloud is and why it's important: it's a business architecture. For businesses, it can do the following:

1. Shifts capital expenditures to operating expenses. Operating budgets are harder to cut than capital budgets. It's a case of “it's the cost of doing business” vs. “we'll have to tighten our belts and wait until next year”.

2. Reduces risk by converting a large, up-front, fixed cost into a series of smaller, scalable payments in the future, which can be terminated as per contract terms.

3. Eliminates the overhead of hosting the software and services in-house.

In lots of cases, the cloud computing model is a compelling business architecture. But the vast majority of end users will never have to think about it.

Finally, I leave you with today's Dilbert strip, which pretty much sums up the cloud hype cycle:

Have fun and stay safe in the cloud.

ESRI is about to launch its Technical Certification Program, which will offer certification at the Associate and Professional levels for Desktop, Developer, and Enterprise. There's been some buzz about these certifications and what they mean, and I want to get into some of the issues and concerns here.

Most of the discussion that I've seen or heard revolves around a comparison of the ESRI Technical Certification to the GIS Professional Certification. To start, this isn't the right comparison to make. The GIS Professional Certification is intended designate individuals as meeting a set of professional practice standards, whereas the ESRI Technical Certification is a certification program designed by a particular vendor around their technology. A better comparison would be to the Microsoft Certifications.

First, to certification in general. My perception is that a large segment of the community that supports certification wishes to include themselves in the “in” crowd and to exclude others, under the banner of “certification”. I sense that, in industry, having a GISP Certification doesn't carry much weight other than with other GISP's. I note that, currently, the GISCI is considering tightening the certification criteria after 6 years of offering certification. I know that this can be seen as a harsh view, and I also recognize that there are many other valid reasons to support certification. Full disclosure: I've been a certified GISP since 2009.

One of the arguments that is often given in support of certification is that it will give employers confidence in the qualifications of certified individuals. Nonsense! A Ph.D. from an accredited university doesn't guarantee the competence of the holder. I know that I've interviewed people whom have held Microsoft Certifications and whom I've thought would make terrible software developers based on a number of factors other than their certification status.

Back to the comparison to the Microsoft Certifications. The ESRI Technical Certifications seem to be closely modelled after the Microsoft Certifications. ESRI recommends some courses, you pay the fee, you take the exam, and you're certified. If we're trying to make a case for the value of the ESRI Technical Certifications, I would look at what value is placed on the Microsoft Certifications in industry. My sense is that it's not as important in the private sector, but it may be more important in the public sector. Still, I don't come across that many requirements that specify Microsoft Certified individuals. This may be because there has been a lot of churn in the Microsoft certifications over the last few years, with requirements, courses, and designations changing, which is one of the dangers inherent in a vendor-specific certifications.

Which brings me to my points of concern with the ESRI Technical Certifications. It's not the examination cost; it'll be a couple of hundred bucks. It may be expensive for new grads, but not too bad in the big scheme of things. The big cost is in the courses that you'll probably need to take in order to be able to pass the exams successfully. Training ain't cheap. Looking at the ArcGIS Desktop Associate designation, taking all of the identified courses will cost $9203 and take you 176 hours! That's where the money is. As a small business owner, this puts me at a huge disadvantage. Large IT consulting companies have long benches, and can afford to send their consultants for almost 5 weeks of training at a time, in order to be able to put “certified” resources on bid proposals. I want to see ESRI tighten up the recommended training lists rather than just throw a list of courses up on the board and letting us have at it.

As to certification in general, as a professional community we need to decide whether we want certification or something more rigorous like licensing. Here in Ontario, as in other jurisdictions, engineers, doctors, and lawyers are all governed by legislation and licensed by self-regulating professional bodies. It's important that these professions are regulated like this, and that their practitioners are held to standards of competence and ethical conduct. Do we need the same level of regulation for GIS practitioners? I would argue that we don't, but when you're talking about confidence in competence levels and ethics, this is what doing it right looks like.

Do we need certification at all? I would argue that we don't, because certification doesn't provide the desired outcomes, but I'm willing to wait and see what happens.

I attended the URISA / NENA Addressing Conference a few weeks ago in Charlotte. This is the first time I had attended this conference in a few years, the first time being in Baltimore in 2000.

The thing that immediately stuck me was that the addressing community is still talking about the same issues it was 10 years ago! And the issues are predictable. I give you, in no particular order:

• sharing data

• standards

• data quality

• reconciling multiple systems

• multiple authorities

• lack of process

So haven't we been able to move the ball forward on addressing and address data management in the last 10 years? I think that there are three main reasons:

1. People think that things are different or unique in their own jurisdiction.

2. Power politics and empire building, particularly in jurisdictions that feature multiple systems and / or multiple authorities.

3. The URISA / NENA conference is really the only forum for the exchange of ideas and information.

The thing is that, while each jurisdiction does have its own idiosyncratic addressing issues, 99% of what one jurisdiction is doing is replicated in almost every other jurisdiction. The problem isn't really what's being done, it's how it's being done.

This is the part that really floors me: across North America, local governments are responsible for delivering pretty much the same basket of services to their citizens; however, there are as many processes for assigning and managing the addresses for delivering these services as there are local governments. Consider just who assigns addresses: depending on the jurisdiction, it could be the permitting department, the planning department, the water utility, the telephone company, or even the developer.

Given that local governments deliver the same set of services, I can't think of a good reason that each jurisdiction needs to reinvent the wheel when establishing how to deliver these services. Most of the people I've met with who are responsible for addresses in their jurisdiction are just trying to do their jobs, and what they're really looking for is some guidance and best practices.

Here are the three main elements that are needed to establish guidance on best practices for addressing:

1. Standard processes. Why does the planning department assign addresses in one county, while in the next county over, the telephone company assigns addresses? It doesn't make sense. We need a best practices manual that defines the best practices for address assignment, based on a survey of existing processes and their effectiveness.

2. Data standards. The FGDC Address Data Standard is a great start. It provides a good logical model for addresses, which now needs to be further specified as a set of implementation standards.

3. Addressing tools. Addressing authorities want to follow best practices, and use accepted standards. They need tools to help them to do that within their jurisdictions. Obviously, GIS tools are going to be a big part of that.

So where are we now? We currently don't have much of anything in terms of standard processes; there are a smattering of tools available on the market; certainly we're furthest ahead on the data standards side. I hope that in the coming years we start to make some progress in the other areas so that we can finally lay some of these persistent issues to rest.