There were quite a wide range of entries – some that looked like they were done in 5 minutes, and others that clearly leveraged an entire team (China National Weather Service, I’m looking at you!). Interestingly, many entries did not put links to the live site in the details for their videos. If you entered the contest and your entry is not on the playlist here, just leave me a comment (and check the keywords on your entry!)

So, ch-ch-ch-check’em out…

ESRI 2010 Mashup Challenge YouTube Play List

Or, sit back and watch’em all right here…

Some quick searching took us to a census report stating that the median household income in the US was $50,233 in 2007. So, comparing compensation packages in the 10’s of millions of dollars in a way most people can relate to was going to be a challenge.

The Data

Any compelling mashup needs good data. After some Googling, we found “Pay at the Top” at the New York Times web site. This page listed the 2008 compensation packages for 200 executives at public companies. Now, a web page is not usually that convenient a data source, but this one in particular was built using reasonably clean html. We just grabbed the page source, cut out the section we were interested in, slapped in an XML header, and Jeff Germain went after in using LINQ to Xml, and loaded the data into two tables in SQL Server.

Next up was finding some aggregate income data. Since we wanted to show this on a map, and have the display make sense, we needed to find total income by county. Conveniently the IRS has just such a dataset. Unfortunately the last year they provide data for is 2007. But since we don’t see wild fluctuations in median income levels, this would be close enough (and it was a CSV file, which made loading it painless). Once the data was loaded into SQL Server, we created a spatial view linking these numbers to a county layer in ArcSDE. I prefer using spatial views as opposed to using joins in the map document or actually adding the fields to the feature class because I know I can mess with the data using SQL without any problems.

At this point we could make maps showing all the counties in the country in which the all residents cumulatively made less than any one executive.

Since there are large variations in median income at the county level, we wanted to show, for a given county, how many households does it take to make the same amount as an executive. We were able to pull this data from the aptly name ESRI Median Household Income service on ArcGIS Online.

Flexing the Mashup

We used the Flex API because it’s something we’ve been doing a lot of work with, and the R&D time would pay off on coming projects. The app is a pretty simple flex application, using the ESRI API. We load in a simple shaded relief tile cache as the background, and use a dynamic map service to show the counties.

Map Services

We are hosting the county income map service (http://204.133.225.169/ArcGIS/rest/services/Mashup/CountyIncome/MapServer), and it’s design is worth noting. We have two layers – one that shows the county outlines, and a second that shades the counties green. Of course we don’t want to show all the counties as green – just the counties where the total income is less than what the executive made. We simply setup the layer in the map with a default definition query of 1=0, which is never true, so no green counties will show up. When we have an executive, we use the Flex API to change the definition query for that layer (on a request by request basis) so that only those counties who’s total adjusted gross income (AGI) is less than the CEO’s compensation. This is a really handy technique which we use a lot.

Web App & Data Services

As usual, we built the back-end of the web app using ASP.NET MVC. The web app has two roles – first, it detects if the request is coming from an iPhone or Android device, and routes the request to a different view that’s optimized for those devices. The second thing the web app does is provide a set of data services to the Flex and Javascript apps (the mobile app is just HTML and jQuery). The data services hit the compensation data stored in SQL Server, and return it to the flex app as JSON.

Mobile View

As I noted the app will present a different view to for iPhone or Android browsers – this is much simpler, but still conveys the same information. The map used is actually OpenLayers, so you can pan & zoom. Mike Juniper and Brian Noyle will be talking more about this technology at their Dev Summit session (1:45pm – 2:15pm Wednesday March 24th)

The Video

In order to enter the contest, you have to submit a video on YouTube. Here’s ours:

Link: http://www.youtube.com/watch?v=a3dzn9ZxMw8

So that’s the app as it stands – I also wanted to give a shout out to Michael Hayden and Bob Binckes who did the bulk of the Flex coding for this – Thanks guys!

There is a lot more that could be done, and there are a few design tweaks I’d like to make, but given the time we had, it came together really well. Check it out and let us know what you think!

http://mashup.dtsagile.com

This year I’ve submitted two talks, and Brian Noyle and Mike Juniper have thrown one into the mix.

First up – Ruby-Fu: Using ArcGIS Server with Rails

As noted in my last post, I’m dabbling with Ruby on Rails, and so I thought I’d do a talk about using ArcGIS Server from a Rails application. The basic idea is to build a simple data view that sits in front of data hosted by ArcGIS Server. In reality you would likely pull the attribute data from a database, but in order to make it more interesting from the ArcGIS perspective, we’ll pull it from ArcGIS Server via the SOAP API. Unlike .NET, Ruby does not have much in the way of web service proxy generators that work from WSDLs. What little there is, can’t handle the complexity of the ArcGIS Server WSDL files, so we need to get a little lower-level. I’m using the Savon gem for this project, and it does a good job of handling things – I’ll go into the details in a subsequent post, and in the talk.

Now, some people would say that I should just use the REST API, and call it good. Unfortunately at 9.3.1, the REST API is still a limited (but powerful) subset of the SOAP API. And some of what I need to do (i.e. draw custom graphics on a map image) can not be done via the REST API, so SOAP it is.

I’m also going to build the app using Behavior Driven Development using Cucumber, and I’ll show how the behavior of the system can be described in plain English, and yet they run complex tests. Apparently Cucumber can be used to drive .NET tests as well, so that should be an interesting spin-off from this.

As noted in the talk description, all the code will be put up on ArcScripts and on GitHub. I plan on using the Portland Landbase service hosted by ESRI so that there is no ArcGIS Server setup required to play with the app.

Why vote for this? Ruby is a lot of fun, and offers a different point of view on development… and James Fee says you should

My second talk is titled Bloody Knuckles: Building Secure Applications with ArcGIS Server

We (somewhat) recently built an emergency response application based on the ESRI Javascript API, with lots of custom services (ASP.NET MVC if you care). When we were nearly done, we found out that “deployed on a DHS server” meant that everything had to be locked down. This means the full meal deal – all requests to the web server had to go over SSL and all ArcGIS Services used token based security. This would have been complex enough, but this particular application allows the administrators to dynamically add services from other ArcGIS Servers. Joy. Anyhow –we managed to whip this system into shape, and I’m going to run down the general ideas, and then dive into some of the code – particularly the proxy that handles the token security. You can watch a “high-level” version here http://vimeo.com/7557517  (presented at the 2009 ESRI South West Users Group). The Dev Summit version will be much more “deep dive”

Why vote for this? Who knows when you’ll find yourself needing a SSL certificate and token based security.

Brian and Mike have taken up the charge with “There’s an App for That: Building iPhone applications with OpenLayers and ArcGIS Server”

Why build a native app when you can build a pretty cool web app that leverages WebKit and the iPhone extensions? HTML5 here we come! Actually, I’m sure that Brian will have some sort of post on the details of what these guys are planning, so I’ll leave it at this for now. And, we’re going to try and work in an edge-cached, cloud front image service that some friends are cooking up. H-h-h-h-ot. We’re also going to try to get this working on Android as well.

Why vote for this? We’ll have the app up and running and you can bang along on it with us, and (if possible) we’ll be sharing the source.

So – that’s it – as usual these will be zen-style presentations, and we hope they will be entertaining. I hope you’ll head over to the voting site, check out all the talks and give us some love.

As anyone who’s read this blog in the last 2 years knows, I’m a pretty big fan of Microsoft ASP.NET MVC – it’s simple, gets out of your way, and gives you total control of the output. And it’s 1000% better than the mystery meat known as Web Forms – a nirvana so to speak. So, why would I take up Ruby on Rails?

Why Rails?

First, unless you’ve been under a rock for the last 5 years, you’ve likely heard that Ruby on Rails is *teh awesome*, so that counts for something. Then there is the fact that Andrew Turner (@ajturner for the Twitterati) / GeoCommons crew as well as Paul Bissett / James Fee and the WeoGeo team are all smart as hell, they all love Rails.

And the other reason is that realistically, Apache and Linux have won the web. Yeah there is a large slice of the pie (mainly Government) that runs Windows, but if you are starting a web based business, you’re likely going to run open source because of the costs to start and scale. Sure Microsoft is semi-mitigating this with BizSpark and a few other programs, but regardless, the difference was put in sharp contrast as I tried to negotiate may way around the Microsoft Open Licensing site while at the same time installing RedMine on Ubuntu Linux. For those who have not had the pain pleasure of dealing with the maze of Microsoft Licensing sites, they are among the least usable, obtuse sites anyone could imagine. It’s like they set out to win an award for painful web experiences. Really – I don’t mind paying for software – I love Visual Studio, but why, why, why must it be a living hell to actually login, locate, assign and activate licenses? I’m not joking here – I’m really considering changing from full MSDN subscriptions over to just buying Visual Studio because then we own it outright and don’t have to deal with this crap licensing site every year.

Anyhow… back to my point. On Ubuntu installing software is crazy simple – “sudo apt-get install <software of choice>”. Yes, the command line syntax is slightly more complex than a “Ok-Next-Next-Next” windows installer, but it’s also free, immediate and you’re always getting the latest and greatest.

When the main reason we use MSDN over just Visual Studio is for the SQL Server and OS licenses, it makes me question things – I can install MySQL in about 5 minutes, it’s 100% free and I don’t have to fight with the Microsoft sites? The OS is free, and Aptana RadRails (free) covers the IDE side of things? Why is it that I’m shelling out $15,000 a year in licensing, only to have the entire Microsoft interaction be painful? Ok this is degrading into a rant, but what the heck, I don’t rant very often, and it’s my blog anyhow… moving on

Ruby on Rails. Yeah. So, it seemed that expanding my horizons a little may be interesting, and worth some evening time. I started with “Rails for .NET Developers” from Pragmatic Press. This is a perfect read if you’re a WebForms developer, and pretty good if you’ve elevated your game to MVC. From there I moved onto “Agile Web Development with Rails” and this is a great follow up. If you like Pragmatic Press books, these are perfect.

Patterns nom nom nom…

Since Rails is  based on the MVC pattern, and a major influence behind ASP.NET MVC, it’s not surprising that the carry over from ASP.NET MVC is huge. The View syntax is very very similar, the the extent that many of the HTML helpers are very similar. This is great because I was immediately comfortable with the general structure of things. However there are some differences… namely data access (aka ActiveRecord)

Because this post is rife with asides, let’s have another… It’s interesting that Rob Conery, of Hawaii and various levels of internet fame (creator of SubSonic, an ex-Microsoftie and now TekPub.com dude) seems to have been going through a similar thought process / experience as I have, although he seems to be a few weeks ahead of me. You see, while I really like ASP.NET MVC, there is still WAY too much time spent thinking about data access. In the last year, we’ve used the Repository pattern, with a mix of SubSonic, NHibernate and plain ADO.NET. On every project there is much hand wringing and thought about how the data access tier should work – how “POCO” should the POCO’s be, what handles the transition from the data tier to the models etc etc etc. In this post about Entity Framework and NHibernate Rob makes the point that we should be waaaaay past thinking about the data tier. It should be “done” – the fact that there are still flame wars about data persistence options is sad. Isn’t a framework supposed to *help* you with the mundane stuff?

I can haz Data Nao?

I my mind, time spent futzing with the data tier is time wasted. Yes, there are projects where you don’t control the database, and some DBA’s do some really wack stuff (if we meet, ask me about this, have I got stories!), but in an ideal world you turn down those projects. Any database that makes it a royal pain to get to the data the users need, is poorly designed in my opinion. The app is about users, and it succeeds or fails based on them, not based on some idealized 4th normal form, so let the app dictate the data model!

What rocks about Rails is that data access is “just done”. No thinking, it’s just done. And it works. Let me say that again – the data access is “just done”. You can go from zero to editing data in your database in about 30 seconds. Sure the styling of the scaffold sucks, and it’s not the best workflow, but the key feature – create / edit / update / delete data in your database is DONE. All that time you would have spend thinking about NHibernate caching or optimization can be spend working out a better workflow or UI styling. Under the covers, I’m sure there are more elegant solutions, and there are likely some performance issues, but realistically 99.99% of web apps are not FaceBook or Twitter, so the performance / scalability arguments are moot – we’ve got trivial numbers of users and heinously powerful servers. Let’s NOT sweat performance mmmkay?

The other thing about Rails that’s great is that it’s opinonated. And not just mildly, it’s got some really strong opinions, but if you can work with them, and not against them things flow so smoothly. I know, I know, I heard this same speil for a few years, but I have to say it’s true. If you can live in the 80% case, Rails makes things so smooth it puts a grin on my face.

What Now Brown Cow?

So, am I forsaking all that Redmond hath wrought? Not quite – this is good kool aid, but I’m not about to throw out ASP.NET MVC just yet (we did just shell out for another year of MSDN after all!) but Rails provides an exciting alternative that’s close enough to the tooling and workflow of my day job that it’s providing inspiration and ideas about how to be a better ASP.NET MVC developer. It’s a great developer exercise to learn a new language or framework, and I heartily recommend checking out Ruby and Rails.

Anyhow, to close out this rant of a post, I’ll be throwing more Ruby into the mix here and on GeoGeek.tv. At this point I’m certainly still very NOOB in terms of Rails, but what I’ve done, I’ve liked. Alot. And as far as “on my own time” projects, I’m sensing a definite shift to the dark side. Welcome to 2010!

Projects in the Solution

SOE’s have a lot of moving parts, so let’s think about all the parts in terms of servers & assemblies.

First – the SOE project. We’ll create the actual SOE’s in here. We can have references to all the ArcObjects / ADF goop we want in here, since this will of course be running on the SOC machine.

In the “client” application (ASP.NET MVC in my case) we’ll use an interface to access the SOE. Since we’ll want the interface definition on both the SOC machine(s) and the “client” machine, we put this in it’s own assembly. Remember that anything that moves between the SOE and the “client” is really doing DCOM under the covers, so all types need to be serializable.

Next up is the Utility assembly. We have a mess of static classes in here that are pure ArcObjects. This assembly will be used on the ArcGIS SOC box, by the SOEs. An upside of keeping this code “pure” ArcObjects (by that I mean there is no ServerObject cruft in here) we can use these same utility classes in ArcEngine or Desktop development.

Finally, we’ll want that “client” application I’ve be talking about. I’m a big fan of ASP.NET MVC, so I’ve been using that to host services. It’s worth noting that you can put standard ASMX SOAP web services into an MVC project. This is nice because you can expose your SOE methods as SOAP or JSON from the same project. Remember, this project will be using the ESRI ADF library to create the connection into the SOC and get access to the SOE, so it will need to run on a box that has these libraries accessible. Note that at 9.4 the ADF components are re-distributable with out incurring additional licensing.

Building

The build process can be a little hairy. First off, make sure you have ArcGIS Server on your development box – this way your build/test cycle will be manageable. If you need to copy dll’s to another server as part of your debugging process you will lose your mind.

So – we need to register all the COM assemblies – that would be the SOE, the SOEInterface, and the COMUtility assemblies at minimum. While you *CAN* tell visual studio to register these assemblies for COM interop, DON’T! That will register the assembles in \bin\debug.

A better plan is to copy these dll’s to a separate folder, and install them there. We call ours _install_ComUtilities. We have a post-build event that copies the SOE and it’s dependencies into that folder, and does all the dirty work. Jeff Germain just threw up a good post on a Post-Build Event that does all this, but here’s the basic process:

1. Stop the ArcGIS SOM Process (SC STOP ArcServerObjectManager)
2. Un-register the dll’s (regasm /unregister…)
3. delete the type libraries (*.tlb)
4. delete the dlls
5. copy the new dll’s from the build output folder into _install_ComUtilities
6. run regasm on them to create the type libraries
7. re-start the ArcGIS SOM process (SC START ArcServerObjectManager)

Now, of course you don’t want to do this every time your solution builds, as it takes ~15 seconds, so use the visual studio configuration manager to not build the SOE project automatically.

Registering the SOE with the Map Service

Get Vish’s SOExplorer app, and use that. You can do this manually or write some code to do it, but just use Vish’s tool. It rocks. Moving on…

Logging

Since you’ll likely have a bug or two in your code, having some logging is really important. We use Log4Net on the client side, but have never gotten this to work smoothly in COM land. Again, Jeff has saved the day with a ComLogger utility that he whipped up for this. I’ve asked him to post about this, but he has not gotten to it yet. If you want this, go to his blog and hassle him.

The upside is that when debugging the app, I’ve got two logs to watch – the log on the client (MVC) and from the SOC (via ComLogger). The ComLogger simply creates a \log folder next to the SOE dll – so you have to watch for permissions on this – make sure that the ArcSOC process has write permission to the folder where you install your dll’s!

Here’s an example of what I get in my SOE Log:

12/14/2009 3:11:37 PM   INFO   LrsSOE::GetRoute   LrsSOE::GetRoute called.
12/14/2009 3:11:37 PM   INFO   LrsSOE::GetRoute   params: routeId: 002B
12/14/2009 3:11:37 PM   INFO   LrsSOE::GetRoute   whereclause: Route = ‘002B’

What shows up in here is up to you, but make sure you stuff all exceptions into the log because that’s where this will save you a ton of time. If you don’t you’ll just get an InteropException on the client side, and that’s completely useless. Also worth mentioning, I use NotePad++ and just keep these two files open in it. When they change, and you change focus to Notepad++, it will ask if you want to refresh the files. Vish is a big fan of BareTail, but from what we’ve see, it’s got wacky behavior on multi-monitor setups. Moving on…

SOAP and JSON in MVC

As noted above I needed to provide services to different clients – one is a Flex app where JSON is convenient, and the other is another MVC app that can speak SOAP fluently. To do this, I just created a standard MVC project, and created a /SOAP folder, inside of which I created a standard asmx web service. By default MVC maps all urls to routes, and so /SOAP would normally route to a class called SOAPController. However, we don’t want that behavior, so we tell MVC to ignore anything under /SOAP (this is in global.asax.cs)

        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
            routes.IgnoreRoute("SOAP/{*pathInfo}");
            routes.MapRoute(
                "Default",
                "{controller}/{action}/{id}",
                new { controller = "Home", action = "Index", id = "" }
            );
        }

For the Json stuff, I setup a JsonController and thus we have routes like http://server/json/getroute?routeId=25b, which of course maps to a the GetRoute method on the JsonController, passing in a routeId of 25b. The logic in the JsonController is pretty simple – we just pass the arguments over to the SOE, and return the response.

Getting the SOE

Getting the SOE itself is a two step process. First you need to get a server context – ideally one that has your SOE registered with it, and then get the SOE from that. We’ve written a lot of these things, so we have lots of handy utilities to handle configuration sections, Identity etc etc. But it boils down to two methods:

public static IServerContext GetServerContext(string arcGISServerName,
                                            string serviceName,
                                            string serviceType,
                                            ESRI.ArcGIS.ADF.Identity identity)
{
    //Connect to ags
    ESRI.ArcGIS.ADF.Connection.AGS.AGSServerConnection agsConnection
        = new ESRI.ArcGIS.ADF.Connection.AGS.AGSServerConnection(arcGISServerName, identity);
    agsConnection.Connect();
    if (!agsConnection.IsConnected)
    {
        agsConnection.Dispose();
        return null;
    }

    //Get the som
    IServerObjectManager som = agsConnection.ServerObjectManager;

    //Get the server context and the mapserver
    IServerContext serverContext = som.CreateServerContext(serviceName, serviceType);

    return serverContext;
}

and…

private ILrsSOEInterface GetSOE(IServerContext serverContext, string soeName)
{
    //Get the server object extension
    IServerObjectExtensionManager serverObjExtMgr = serverContext.ServerObject as IServerObjectExtensionManager;
    if (serverObjExtMgr == null)
    {
        throw new ApplicationException("Failed to get the ServerObjectExtensionManager from the server context.");
    }

    IServerObjectExtension serverObjExt = serverObjExtMgr.FindExtensionByTypeName(soeName);
    if (serverObjExt == null)
    {
        throw new ApplicationException("Failed to get the ServerObjectExtension by extension type name" );
    }

    ILrsSOEInterface lrsSOE = (ILrsSOEInterface)serverObjExt;
    if (lrsSOE == null)
    {
        throw new ApplicationException("Failed to create a reference to the {0} server object extension.", soeName));
    }

    return lrsSOE;
}

Notice that the second method returns the SOE typed as the interface we defined in the interfaces assembly.

Serialization

The last step is to get the results from our SOE back to the client. This is easy for simple types, but as usual Geometry is a pain. The Geometry we get back from our SOE is the SOAP Value type geometry. And as far as we know there is no open API for converting this into a Json geometry. Of course, using Reflector you can *see* that ESRI has all the handy methods you may want to use for this in the REST assembly, but alas they are all internal. What’s a dev to do? I’ve asked ESRI to provide public methods for this, and Morten mentioned being able to do this using the WPF components, but again, the needed methods are internal (and they don’t handle the SOAP value types). If you are working with GeoJSON, the Vish (did I mention Vish rocks?) whipped up GeoJson.NET, which you can get from SVN at Assembla (http://svn2.assembla.com/svn/GeoJSON/) . It cleanly handles the ESRI –> GeoJson formatting. All hail Vish.

So – that’s a pretty shot-gun style round up of SOE related stuff. If you have questions or ideas, just drop me a line and I’ll see what I can do.

The downside of this ease of re-use is that we are seeing a new wave of cookie cutter sites out there. It’s great that these sites can the whipped up so quickly, but it’s pretty clear that (for the most part) little or no thought is given to how the user should interact with the site. We see hordes of menus and tons of widgets, all gloriously trying to pseudo replicate ArcMap. Let’s be clear – if your users need ArcMap, give them ArcMap. If they actually know the data model to the point that an ad-hoc query tool will be useful, chances are they will need more functionality than you can build into the Flex app anyhow. Right tools, right place and all that…

Where was I… oh yeah… remixing the sample viewer. When I’m designing an application, I want to build it as focused as possible. Every mouse click and menu drop down I can remove, the better it is for the user. So – here are a few of the things that I wanted from a UI/behavior perspective…

• I want top level menu items that do something on-click. I don’t want a pull down with a single item on it – I want a print icon that opens the print dialog when it’s clicked.
• The shortcut menu is a great idea, but I want to have things that “only” appear on the short cut menu. Having something in two places in a UI is counter intuitive in most cases, and wastes UI space.
• I want to have a limited set of base maps available, and I want them to be displayed as top level icons on the menu. Clicking them will turn on the layer. Active layer should have a “glow” indicating that it’s… well… active.
• I want widgets that can’t be closed. One thing I’ve seen when letting clients run a Flex app is when they close widgets they are confused about how to re-open it. Thus I want a sub-type of widget that can only be minimized and not closed.
• I want a full width banner across the top of the page – providing more room for top level items.
• I want a search box in the top banner so it’s easy to search.
• I want a zoom to / book mark tool on the top bar so it’s easy to jump to commonly accessed extents

And I want all the same level of flexibility in terms of configuration, and the ability to leverage existing widgets. Now.

Design Sketches

In coming up with this list of things I wanted, I did some sketches…  (apparently my scanner is crap!)

In the past I’ve used visio or balsamiq to create wireframes, but more recently I’ve been getting back into sketching simply because it’s so fast. I’ve been using Jason Robb’s wireframe templates as a starting point (article and direct download of pdf).

More Tile Caches…

Since ESRI is changing their caches over to Web Mercator, I wanted to start working with some web mercator tile caches. ESRI has *some* services available now (google search here), but realistically most of these are pretty weak for base maps. So, I created tile layers for OpenStreetMap and CloudMade. Once I finish a few tweaks to these layers (need to display the copyright statements on the map) I’ll release them – likely to the ESRI Code Gallery, but I also want them on a SCM somewhere. Maybe GitHub? Thoughts?

Let’s take a peek…

Things are not fully dialed in yet, and I really need to focus on detailing this out for my client, but this is the generic starting point. I’ll post some live links when my client’s site is ready for beta testing.

This shows the full width banner, the address search, zoom to drop down (needs skinning), an “Always Open” widget, the two base map icons, and the top level print widget. The tiles are from the CloudMade Midnight Commander cache.

This one shows the locate dialog that’s opened by running a search from the banner bar. As you can see there are still a few issues with this widget. Since “locate” is not the key focus of the app, this widget can be closed. I’m also going to work on the actual search logic – right now it’s parsing out the address based on commas, and then sending to the ESRI geocoder. I may look at using another service that has more matching logic on the back end so I don’t have to figure out how to de-construct the address.

This shows the print widget, accessed by just clicking the printer icon (no drop down required). Oh, and the Open Street map cache in the background.

What’s nice about this is that the user does not need to go digging around in menus to access the functions they need. This template will be used for very focused applications – do one thing, and do it well is the mantra for the project – and so keeping things up front will really help out.

Behind the Scenes

So – the real question is – can we share this? Good question! I’ll be blogging more about how we (big shout out to Jeff Germain who whipped up the “toolbars” stuff) created various aspects of this, and at the very least, you can re-implement most of this stuff pretty quickly. We had to hack at the core of the Sample Viewer (specifically ControllerManager.as) and added a bunch of additional controls for our “toolbars”. At this point things are “working” for the scenarios we need right now, but I suspect we’ll have some refactoring in our future. I’ve got at least 3 apps that will build on this, and by the time all 3 are released, we should have tracked down all the weirdness, and have something that supports all the out-of-the-box Sample Viewer stuff, as well as our extensions. Stay tuned!

It’s up on Vimeo at http://vimeo.com/7557517 or you can just watch it below…

Usability for Emergency Response Applications from Dave Bouwman on Vimeo.

Turns out it took all of 5 minutes to get it working, so here’s the how-to (there’s some sample code at the end)

Get log4net

Get log4net from http://logging.apache.org/log4net/download.html – simple.

Add the Reference

Now that you have the log4net zip archive, copy the log4net.dll from the \log4net-1.2.10\bin\net\2.0\release folder in the zip file into your \lib folder. I always have a \lib folder for external assemblies that are used in a project. This is preferable to storing these in a central location because the \lib folder get’s stored in source control along with everything else that your project required. So – if you don’t have a lib folder, make one!

Now that it’s in the create a reference to log4net from your project in Visual Studio.

Configure It

The easiest way to use log4net is with the standard log file appender which just writes to a text file. In order to configure this, we need to edit the ArcMap.exe.config file (located in \ArcGIS\bin). Of course you can store the log in other places (databases etc) – just Google for the details.

By default, this configuration file is almost empty, so you’ll need to add in the configSections as well as the log4net section.

<configSections>
  <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" 

       requirePermission="false" />
</configSections>

…lower down in the file…

<log4net>
  <appender name="LogFileAppender" type="log4net.Appender.FileAppender">
    <file value=".\\Logs\_log.txt" />
    <appendToFile value="true" />
    <lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline%exception" />
    </layout>
  </appender>
  <root>
    <level value="ALL" />
    <appender-ref ref="LogFileAppender" />
  </root>
</log4net>

Now we have to wire log4net into our code. In order to be useful, we’ll want to have access to the “logger” throughout our class, so we’ll make it a private member. Ideally we’d pass in the logger from a dependency injection framework, but we’ll keep things simple for this example (sometimes DI *is* overkill). Thus, we’ll setup the logger in the constructor of our class.

private log4net.ILog _logger;

/// <summary>
///Constructor.
/// </summary>
publicLRSEditTask()
{
    log4net.Config.XmlConfigurator.Configure();

_logger = log4net.LogManager.GetLogger(typeof(LRSEditTask));           
}

Logging

Would not be very much help if I did not show how to actually write to the log! Now that we have _logger, we can just pump data to it. There are a number of levels you use to send out data, depending on the severity. During development, I’ll use the Debug(<info>) method to see what’s going on inside the code, but you’ll also want to use the Warn, Error and Fatal methods when your code experiences errors. Using the different methods allows you to control what’s output to the log file via the configuration section. This way you can leave all that debug stuff in the code, but not have log files piling up on production systems.

In the sample code, I’m just pumping out examples of each type of log.

public void Activate(IEditor Editor, IEditTask oldTask)
{
    _logger.Info("Task Activated.");
}

public void Deactivate()
{
    _logger.Warn("Task Deactivated.");
}

public string Name
{
    get { return "Log4Net Example Task"; }
}

public void OnDeleteSketch()
{
    _logger.Fatal("On Delete Sketch Called");
}

public void OnFinishSketch()
{
    _logger.Error("On Finish Sketch Called");
}

In the log file you’ll see something like this…

2009-10-15 15:32:25,631 [1] INFO  Log4NetDemoTask.LogEditTask [(null)] – Task Activated.
2009-10-15 15:32:29,205 [1] ERROR Log4NetDemoTask.LogEditTask [(null)] – On Finish Sketch Called
2009-10-15 15:32:33,003 [1] FATAL Log4NetDemoTask.LogEditTask [(null)] – On Delete Sketch Called
2009-10-15 15:32:38,182 [1] WARN  Log4NetDemoTask.LogEditTask [(null)] – Task Deactivated.

Post Build Tasks

This is a subtle thing, but as far as I can tell, if you want your code to be able to “see” the ArcMap.exe.config file, your dll must reside in the \bin folder right beside ArcMap.exe. This is easily accomplished by adding a post-build event in Visual Studio

copy $(TargetDir)*.* “c:\program files\ArcGIS\bin”

Now, every time you build the project, it will copy your dll and any dependencies (log4net in our case) into the \bin folder.

A final note – when you start using logging, you’ll want to be able to look at the log without re-opening the file all the time. Thanks to Vish I’ve been using BareTail for quite some time now – this app will let you watch the file as lines are added to it.

Here’s a simple sample editing task, along with an ArcMap.exe.config file. Have fun!

I’ll be giving an updated talk on Usability as related to “GeoWeb” applications on Thursday  morning at 10:30am (Room “MR 4/5”). This will draw from some previous usability talks, but without the hard-core developer content, and more focus on the process of arriving at a usable application using ESRI technologies.

On Friday morning at 9:30am (also in room MR 4/5), I’ll be giving a talk for my usual accomplice, Brian Noyle (he got an elk tag, so he’ll be up in the mountains stalking large animals) that will also be about usability, but in the context of an emergency response application we built. I’ll go into the design decisions, the application architecture, and some of the complexities we ran into when building a highly configurable, high-security application that can consume remote map services. If you want to see how far you can push the ESRI Javascrip API, drop by.

Assuming the wireless is stable, we will also be streaming some of the sessions and hope to chat with people on GeoGeek.tv. At the very least, we’ll be recording my talks and hosting them somewhere.

I’ll also be tweeting about the various happenings using #SWUG09 as a hash tag, so you can follow along that way.

Hope to see you there!

Tomorrow, Oct 9th, we will be chatting with Royce Simpson, the developer who built the award winning City of Greeley “ORIGIN” mapping applications.

(Royce is on the right, Brian is on the left, and Jack is givin’ out the hugs)

We’ll talk about his background as a developer, what got him interested in Flex development, we’ll have him take us through the app and discuss various tools and how they were implemented.

Check out the apps, and join the chat to ask questions.

When: Oct 9, 2009 4:00pm MT

Where: http://geogeek.tv/live.aspx 

Follow Royce: @roycesimpson