Building for Change: Configurable by Default

Sometimes you do something for so long that you just assume everyone else is doing it, and then one day you find out that may not be the case. Recently I had this experience related to building applications that are “configurable by default”.

For at least the last 5 years, all the web mapping apps we’ve built set themselves up based on configuration information. That is to say, we don’t have hard coded layers / mapservice references in the application code – all that is passed into the app.

I think we really started using this pattern when the first ArcGIS Viewer for Flex came out. It standardized this model, albeit with Xml files. Since then both we’ve migrated both the Flex viewer and our own javascript bootstrap code to read json based configuration. 

In cases of statically served apps (.html pages) this is simply written into the page. In apps that are hosted in larger server side frameworks (ASP.NET MVC) during initialization, the javascript or flex code makes a call back to a json api, which returns the configuration based on the credentials of the user. Still other times we inject the json into the page, again creating the configuration based on the user credentials.

An Example…

The exact format of the configuration data changes from project to project. For example, the “Compare” viewer that’s part of the Esri Change Matters Landsat viewer application has a pretty complex configuration because it is defines base maps, multi-temporal Image Services, including defining raster functions, and corresponding legend chips, as well as additional configuration parameters for the mobile versions.

Change Matters Legend created via configuration

This screen cap shows the “legend” that is setup for each of the 6 Image Services so that users know what these false color images mean. You can view a “pretty” version of the json in this jsfiddle, or view source on the Compare Viewer and see it in-lined into the page.

Configuration: Not Just for Maps!

Once you start working and thinking this way, the pattern starts to seep deeper and deeper into the code. The Colorado DOT Highway Data Explorer that I talked about at JS.GEO (video here) in January 2013 makes heavy use of this same technique. The configuration on this app includes all manner of things, down to hashes for setting up table columns.

Highway Data Explorere Configuration

But It’s Harder…

Of course it is! Anything worth doing tends to be difficult, but in this case it’s only marginally more complex. And any extra effort pays off when the you are asked to “just add this one more layer”, or “can we switch layer x and y”. The more we rely on configuration, the more the core code is reusable between applications. Using json for this is great because it’s so easy to adapt as you develop the code – need something else passed it? No problem – just edit the hash!

For those wondering, when we need to lock things down, but still keep things simple, we usually just put this information into json files in a secured folder, and then have the app look at the user’s roles, and then stream down the correct config file. 

Have fun configuring your apps!

Posted in javascipt, Software Development | Tagged , | Leave a comment

Upcoming Webinar: HTML5 and WebMaps: A 2013 Update

At the 2011 Esri Developer Summit I put together a talk on HTML5 and it’s impact on web mapping – (you can watch the video here).

However, things have marched forward significantly in the last 2 years, and I’m going to give an updated talk on HTML5 as part of a URISA webinar on January 18th 2013.


We are going to cover the current state of the art in terms of Responsive Design, css3 and related pre-processing (LESS/SASS), javascript advances and some truly amazing mapping capabilities coming from non-traditional areas.

This webinar is being hosted by Florida URISA chapter – the session is free for FLURISA members, and it costs $25 to sign up and join.

Posted in Uncategorized | Leave a comment

ASP.NET MVC Bundling and Pre-Existing .min Files

Just a quick note for others running into the same problem I had.

Scenario: Setup a new ASP.NET MVC v4 project, and dropped in Twitter Bootstrap and update the markup in my layout. I then setup some bundles as usual, and include bootstrap…

        public static void RegisterBundles(BundleCollection bundles)

            bundles.Add(new StyleBundle("~/public/css/css").Include(


As I’m working on the site, I make some changes to bootstrap.css, and all is well. Until I deploy it to a test server – where the site looks like the vanilla Bootstrap theme. It seems like the bundler is not working in release mode… thus I begin sleuthing.

When running in Debug mode, two files get served – the bootstrap.css file and the site.css file. When running in Release mode, the bundler minifies the css into one file – handy-dandy. However, the dirty little secret is that it’s also “smart” – so smart that if a .min file already exists, it will serve that RATHER than minifying the css file that’s specified.

Put another way, even though I specify ~/public/css/bootstrap.css in the bundle config file, if ~/public/css/bootstrap.min.css file exists it will be used instead. And since I simply unzipped the bootstrap files into my project… yep, there was a .min file and it was being used.

Now – I can see why this is useful – allows people to use all kinds of other tools to create the minified CSS etc etc. HOWEVER, it’s not obvious, and quite frustrating to sort out.

Bottom line: Remove any .min files that you are not actively managing.

Anyhow – hope this helps someone else.

Posted in mvc | Leave a comment

Open Letter To Recruiters: Do your job

I just sent this email to a recruiter who is trying to find us a web developer for our Orlando office (contact me if you are interested). Names have been removed, but that’s all. If you are a recruiter, maybe take a moment to read this so you don’t get a similar email.


Thanks for sending [candidate]’s resume over to me to review… couple of thoughts here…

That’s a mighty long list of web sites – helpful, but what would be really good is knowing what role the candidate played in building that site. Did he just add a jQuery widget, or build a content management system from the ground up using Node.js and MongoDB? It would be useful to know what technology is the site built on? Did he do the design or just implement someone else’s design?

Now, that would be a lot of work for all 40+ sites, so let’s shoot for his top 5 that he built entirely and his top 5 that are .NET. Quality over quantity.

I’ll also say that resume’s / candidate sheets that are laundry lists of every software package and programming language are useless and waste everyone’s time. Maybe that works for giant companies who have openings for 6 “FTE” droids who are interviewed by a clueless HR department so all they are looking for a catch phrase or technology name, but for a smaller company, I’d really recommend focusing on the tools and technologies the candidate uses daily, and is actually competent in. 

i.e. I’m pretty sure [candidate] is not using “DHTML”, as that term was dead circa 2005. And while “ajax” is a design pattern, and “json” is a loose data format, listing them tells me nothing beyond someone knows some buzzwords.

While I’d love to believe that your candidate can “hit the ground running” in any of Javascript, VB.NET, VB Script, C#, Java, JSP, PHP, ASP, C and C++, you know that’s not true. More likely he has worked with these languages at some point or maybe taken a class. And you also know that if your candidate really did kick ass in all those languages, he’d be tracked down by head hunters with openings in-hand, and his resume would not be wallowing in your candidate database, being presented to some random company while working at a local university. 

Sorry to be harsh, but I’m really busy, and looking at yet another “great candidate that’s got a great personality, and can hit the ground running”, while all I see is a laundry list of every web related technology from the last 15 years… yeah… you are wasting my time. The entire key idea behind using a recruiter vs. in-house hiring is that the recruiter will save us time in the process. Sending me a resume like this is literally the least you could possibly do. You are putting the onus on us to do all manner of checking if this person actually knows anything that’s on that list. And for that we should pay you how much???

All I’m asking for is the meat. Strip out all the crap filler and tell me what the candidate is good at today. The web moves very quickly, so if he worked with something 3 years ago, whatever that technology was has likely changed dramatically, or been completely obliterated. 

I want to know what get’s this person excited to go to work, why they give a shit about writing software, and why I’d want to work with them every day. You write me a 1/2 page that summarizes that, and you’ll have my attention.


Posted in Uncategorized | 8 Comments

Real-Time Services Talk & Demo Update

At the 2012 Esri Developer Summit, we gave two talks on building real-time apps – the first used Node.js and, and persisted the data to a feature service. The second used ASP.NET MVC and SignalR, and stored the data points in a simple SQL table with x,y values.

During the talks we invited the ~100 people in the room to beat up the apps, and here’s what we found.

First – both services withstood the inbound load without issue.

Node.js and

Demo site:

This was running on an AWS Micro-Instance, and there were no issues handling the load. Over the 4 hours from when we opened it up, 999 points were added to the system.

In the first 10 minutes, 780 points were added, and looking at the timestamps we had several points where there were 10, 12 15 points added per-second. Not bad for a wee little instance! Here’s a screen cap from Brian Noyle’s phone after the session was over. Down to 3 users, but you can see all the points stacked up.

Node loaded

What we did find is that once there were a lot of points, the system hit a snag querying them back out and sending them to the clients. Although we could have had the clients query the ArcGIS Server FeatureService directly, part of the experiment was to do that work in Node, and then push the features to the client. This all worked smoothly except the FeatureService got slower as the number of points went up (we are still looking at why this is), and the timeout in the Node xhr request was set to be 1 second. Thus, the request timed out, and newly connecting clients did not get the “current” crop of points. Newly added points worked just fine.

At this point things are working smoothly again – and that’s because the query only pulls points added in the last 24 hours, and there are very few points added on any given day. I have not had any time to replicate the issue, but I expect that extending the timeout would fix things. A better idea would be to cache the data in something like Redis, and then lazy-write it into a geodatabase or feature service – maybe there would be a second or so lag between the two, but I think the user experience would be better.


ASP.NET MVC and SignalR

Demo site:

This was running on a server in our Fort Collins office, and although overloaded, it’s a pretty powerful box, so there were no issues with the load. Over the first 4 hours, 536 points were added to the system. In the first 10 minutes, 426 were entered, with a peak of 5 per second. We can’t compare this directly to the numbers for node as there is now way to tell if more or less people were entering data. However, we can safely say that the server easily handled this load.

This version of the app simply stored the points in a SQL table with x,y values, and interestingly there was no issue with scaling this up – mainly because there was no xhr in the mix to time out, and because direct sql access is much faster than going through a feature service, which then hits the database.


Videos of the Talks

We recorded screencasts of the talks as we gave them, and they are now up at Vimeo.

Node & Socket.IO:

SignalR & ASP.NET MVC:

Posted in mvc, DevSummit, NodeJs | Tagged , , | 2 Comments

HTML5 Webinar April 11th, 2012


After years of being told we should use plug-in technologies such as Flex or Silverlight for our web applications, the seemingly sudden switch to HTML5 has left developers and organizations with many questions…

  • What is HTML5?
  • How does Javascript fit into this?
  • When should we stick with plug-ins?
  • When should we use HTML5?
  • What is CSS3 and how can we use that to create amazing interactions?
  • How do we serve different versions of an app to different clients?

On April 11th, 2012, Brian Noyle and I are doing a URISA webinar where we will cover how DTSAgile builds geospatial HTML5 apps that work on desktops, tablets and smart phones. We’ll be covering a lot of ground in this fast-paced talk that is aimed at both developers and managers.






Posted in HTML5, javascipt | Tagged , , , | 3 Comments

DevSummit Presentations

Just a quick post about the presentations we (DTS) are giving at the 2012 Esri Developer Summit

Talking Tech: Presentation Zen for Everyone

1pm Wednesday, Mojave Learning Center (Dave Bouwman and Brian Noyle)

Let’s face it, most technical presentations leave a bit to be desired. Myself and Brian Noyle will talk about our journey from power-point hell to something better. We’ve got ~100 slides and 30 minutes, so join us for a fun session that will make your next presentation rock.

Zen peek2


Have a Little BackboneJS

4:30pm, Wednesday, Mojave Learning Center (Brian Noyle and Mike Juniper)

This fast paced talk will introduce the GIS community to the Backbone.js framework in the context of existing ESRI web technologies.  We’ll start with some MVC and HTML 5 love and explain the Backbone.js code structure and implementation pattern with a focus on maintainability and unit testing.  We’ll take a few ESRI examples from the JavaScript API and show developers how to implement them using Backbone.js. We’ll also look at a large and complex development initiative and illustrate how Backbone.js has made our lives easier.


Getting Real-Time Part -1: Node.js and

10:15am Thursday, Mesquite B (Dave Bouwman)

Some scenarios (i.e. zombie flash mobs) require the ability to keep all users view of the data in sync, in real-time, without requiring an update or page refresh. In this talk we will look at a simple demo application the DTSAgile team created to investigate real-time technologies. This Damage Assessment demo app uses real-time communication to allow users (desktop or mobile) to share real-time “state” as different types of assessments are completed. The idea being that when an “injury” is reported, appropriate medical teams can be dispatched to the location.

Node peek

In this part, we will show a simple node.js app that uses to send notifications between clients and the server, as well as sending the point locations to an ArcGIS Server feature service. Bring your notebook/iPhone/iPad/Android devices and let’s see how many sessions we can run on an AWS micro instance before we crash the wireless network, or overload the server!



Getting Real-Time Part -2: ASP.NET MVC and SignalR

11:00am Thursday, Mesquite B (Mike Juniper)

In this session, Mike Juniper will show how to implement the same Damage Assessment demo app, but this time, working on the Microsoft platform, using ASP.NET MVC and the fast evolving SignalR library.  Finish out the Dev Summit with a bang and go back home armed with ideas on how to easily add real-time capabilities to your existing apps.

Code: (coming soon!)


Posted in Conferences, DevSummit, Esri, javascipt, NodeJs | Tagged , | Leave a comment