Wow – time flies when you are having fun! Just over a year ago, my team and I joined Data Transfer Solutions and opened the Fort Collins office. I’m pleased to say that things are going really well. As I’ve posted in the past, we’ve got all the geek goodies – amazing workstations, great chairs, a sweet office, and a 60 inch flat-screen (no X-Box yet, but that will come)  

Since leaving, our team has switched from VB.NET to C#, from desktop based enterprise GIS systems to spatial web applications heavy on the javascript and Ajax. We’ve done a wide range of work, from Virtual Earth based visualization systems, to integrating ArcGIS Server and SAP, to some very shiny applications based on the ESRI Javascript and REST APIs (more on these in the coming weeks!). We are pushing forward with our vision of how software should be created – incrementally, in an agile process, backed by a pragmatic amount of automated unit testing and automated builds. Our entire team cares about “software”, and I think that shows through in our work. Consequently we are currently up to our ears in work, and having a blast.

As for the rest of the team, Mike Juniper has been really getting into the client side of things, cranking out great stuff with Dojo, OpenLayers, Virtual Earth, and the ESRI Javascript API, as well as writing the bulk of our first ASP.NET MVC application.

Jeff Germain got some bloody knuckles street-fighting with the Web ADF for the first half of the year, but once he’d won that battle, he’s jumped into the deep-end of the javascript pool with some great work with the ESRI Javascript API, and some custom Dijits. As always, he’s the king of server side development, building out the custom ArcGIS Server services that power a number of apps we shipped this year.

Unfortunately, two of our original team have moved on – Vish left to join the Timmons Group in Virginia. I’m really glad Vish is still blogging, because this way I still get to learn a ton of stuff from him. After a long courtship, Rally finally made Chris Spagnuolo and offer he could not refuse, and now he’s a full-time agile evangelist / trainer.

While I would not say we’ve managed to “replace” Chris and Vish, as that would be impossible, we have added two more exceptional developers to the Fort Collins team.

Mike Hayden brings us some mad javascript chops and a background in PHP and MySQL. He’s been working with us for a few months now, and he’s really getting into Dojo and has an uncanny ability to hunt down those little nitty cross-browser bugs that always crop up with web development. He’s also threatening to start blogging.

Brian Noyle has returned to our team (he worked with us while at our previous employer, but left a year before the mass exodus). He’s working on software and system architecture, some project management, and like all of us, slings a lot of code.

Have we achieved nirvana? Maybe not, but we’re all having a lot of fun. We’re winning great contracts, making friends and contributing to the company and the community – not sure how much more we could ask for.

Ok, not really for the kids, but this is some great stuff if you are a parent that wants their children to be competitive in the global economy.

Check out this video presentation called “ShiftHappens”, (also known as “Did You Know”). Excellent information on the rapidly changing global landscape that we and our kids will be/are competing in. While the U.S. public school system varies widely across the country, the one thing that every parent can do is be informed about what’s happening in the world, and then challenge their school to ensure they are preparing our kids for this. This presentation is a great starting point for having a discussion with your child’s teacher or principal. If they have not see this yet, send them a link. If they have, ask them how you can help – they are our future – lets make sure they are setup for success as global digital citizens!

Updated for 2008

This is an updated version of the original content – slightly edgier, but with updated stats in places. Worth checking out even if you’ve seen the original before.

Get Involved!

Not that you are informed, head over to the ShiftHappens Wiki and join the conversation.

Happy Holidays!

Hard to say how this will take off, but I like the idea – kinda what I envisioned for ArcExperts.net, but never quite found the time to carry through with. Anyhow, I had to blog about this as someone felt that my little corner of geo-geekdom deserved a place on the front page (Thanks who ever you are!)

As I’ve mentioned a number of times, I’m a big proponent of keeping solutions simple. While doing some reading over the weekend, I ran across this presentation (pdf file) by Neil Ford of ThoughtWorks. This was his keynote at eRubyCon in August 2008.

Along with a brief history of software development, and his theory that software productivity would massively increase if the worst 30% of developers were fired, he talks about the relationship between essential and accidental complexity and summarizes it like this: 

• Essential Complexity: We have a hard problem
• Accidental Complexity: We have made a problem hard

I think this is a really clean way to describe the difference – sure some software projects actually are complex. But many are not, and the challenge for developers and designers is to keep both kinds of projects as simple as they can be. If we use that as a guide, the resulting software will be much easier to build, debug, test and maintain.

Geospatial applications are inherently more “complex” than standard “forms over data” applications. Regardless of the business logic being applied, at the very least we have that pesky geometry to deal with. Add to this, complex spatial API’s, limited spatial support in many “forms over data” power tools (NHibernate, SubSonic, Entity Framework etc), and systems that believe that they should control ALL the data (yes geodatabase I’m looking at you). Thus, keeping things simple is even more important, and I’d go as far as saying it’s crucial for our industry.

I’ve gotten a few people asking for some good resources for learning Dojo – so here goes. Both of these are good books that our team uses on a daily basis. Although they roughly cover the same ground, the do so in a different manner, which can be helpful when sleuthing around for solutions to some odd problem or another.

Dojo: The Definitive Guide (OReilly)

This was the first book we got on Dojo, and it’s a good one. It covers all the basics (ajax requests, dom navigation etc), and more advanced stuff like creating your own widgets, which is where we really found this book useful. They get into the whole widget lifecycle, the default file/folder layout for widgets & templates etc etc. This is stuff that you’d really have to dig for on the Dojo site, so it’s much easier if you have the book.

Mastering Dojo (Pragmatic Programmer)

I really like all the Pragmatic Programmer books that I’ve read, and this one is no exception. Like all the books on Dojo, it has the basics, including a clear explanation of dojo.hitch. What sets it apart is that it has some application examples. This is nice because it lets you see how someone actually hooks a whole app together.

While I’m talking about books, if you are going to be doing any work communicating to your own services, I would also recommend RESTful Web Services – this is a great book that gives you the low down on all that HTTPGoodness you’ll need to work through the weirdness you are sure to encounter.

Earlier this year I was asked to do the technical review for a new Wrox Press book on Dojo by Leslie Michael Orchard. This was an interesting foray into the world of publishing and will make me think long and hard before I consider writing a technical book – just the technical review took a lot more time than I’d expected! Anyhow, I got my copies of the book yesterday. 

It lives up to it’s name – it’s a concise, and very readable intro to Dojo, and does get into building composite widgets, animations, and some dojox stuff.  You can get a copy over at Amazon.(and no, I don’t get a cut on this!)

Continuing my series of posts on using Dojo with the ASP.NET MVC framework, this time I’m going to focus on sending a “complex” object back to a controller. In my previous article, I “posted” an object to a controller by simply decomposing the object into a set of properties which were sent across as Form elements (name and age in the example), which were then matched up to inbound arguments with the same name. While useful, this can become limiting if your RIA is doing more complex things, and you want to send back more complex data – i.e. a class that has a property that’s an array of objects.

In this example, I use the same “simple” employee object, but instead of decomposing it, I send it across as a JSON string which is then re-hydrated back into a full .NET class.

Dojo Code

function SendEmployee(){

    var responseNode = dojo.byId("responseComplex");
    var payLoad = {
        "Name":dojo.byId("usernameComplex").value ,
        "Age":parseInt(dojo.byId("ageComplex").value)
        };
    var request = {"employeeJson":dojo.toJson(payLoad)};

     dojo.xhrPost({
        url: '<%= Page.ResolveClientUrl("~/Service/CreateComplex") %>',
        handleAs: 'json',
        timeout:3000,
        content: request,
        contentType: "application/x-www-form-urlencoded",
        load: function(person,args){
            responseNode.innerHTML ="Response: " + person.Name + " " + person.Age;
        },
        error: function(error,args){
            responseNode.innerHtml("Error!",error);
        }
    });
}

Controller Code

Instead of having multiple arguments on the Controller method, we just has one string argument – employeeJSON. ASP.NET MVC still maps up the posted form element to the argument name, and passes it in for us. One the string is in the method, we need to de-serialize it. For this I’ve used the DataContractSerializer

/// <summary>
/// Creates the complex.
/// </summary>
/// <param name="employeeJson">The employee json.</param>
/// <returns></returns>
public ActionResult CreateComplex(string employeeJson)
{
    DataContractJsonSerializer ser = new DataContractJsonSerializer(typeof(Employee));
    MemoryStream ms = new MemoryStream(Encoding.Unicode.GetBytes(employeeJson));
    Employee e = (Employee)ser.ReadObject(ms);
    e.Age = e.Age + 5;
    return Json(e, "text/json-comment-filtered");
}        

DataContractSerializer is quite easy to use – just include System.Runtime.Serialization, and markup your class with the [DataContract] and [DataMember] attributes as shown below.

using System.Runtime.Serialization;

namespace ajaxmvc.Models
{
    [DataContract]
    public class Employee
    {
        /// <summary>
        /// Gets or sets the id.
        /// </summary>
        /// <value>The id.</value>
        [DataMember]
        public Int32 Id { get; set; }

        /// <summary>
        /// Gets or sets the name.
        /// </summary>
        /// <value>The name.</value>
        [DataMember]
        public string Name {get;set;}

        /// <summary>
        /// Gets or sets the age.
        /// </summary>
        /// <value>The age.</value>
        [DataMember]
        public int Age{get;set;}

        /// <summary>
        /// Initializes a new instance of the <see cref="Employee"/> class.
        /// </summary>
        /// <param name="name">The name.</param>
        /// <param name="age">The age.</param>
        public Employee(string name, int age)
        {
            _name = name;
            _age = age;
        }

        /// <summary>
        /// Initializes a new instance of the <see cref="Employee"/> class.
        /// </summary>
        /// <param name="name">The name.</param>
        /// <param name="age">The age.</param>
        /// <param name="id">The id.</param>
        public Employee(string name, int age, int id)
        {
            _name = name;
            _age = age;
            _id = id;
        }

        /// <summary>
        /// Initializes a new instance of the <see cref="Employee"/> class.
        /// </summary>
        public Employee() { }
    }
}

Code Smell…

Although this works, I’m not a big fan of having controller methods that accept serialized strings – this makes unit testing more painful. However, a trade-off of sorts can be made in that you can have a strongly typed controller method, and a JSON version of the same method. The Json version accepts the serialized Json string, de-serializes it and passed it over to the strongly typed method. You can then write all sorts of useful unit tests against the strongly typed version. In an ideal world, we’d have the Json de-serialization occur somewhere in the pipeline before we hit the controller – I’m hoping that this may be achievable via custom ModelBinders, but have not had a chance to research this yet.

Every project is different, so it makes sense to revisit the available tools and select the right one for the job. Here’s the landscape as I see it. But first…

Guiding Principal: Keep it simple!

I think this should be everyone’s starting position, but it’s important to reiterate the importance of keeping things as simple as possible – both for you as a developer and for the end users. Adding in extra “stuff” is not a good idea. Take a read through “Getting Real” by the 37Signals team. They are all about building less, and keeping things simple. This is a major “Web 2.0″ idea – keep a tight reign on features – make them prove their worth before letting them into the app.

With that in mind, here’s how I look at things…

1) Can I use Google Maps or Virtual Earth?

Since the general public is most familiar with these systems, it makes sense to build on them if you can. Sure there are licensing/advertising issues, but that’s to be expected – there is no free lunch when it comes to high-resolution global data sets.

The thing I look at next is data – can the problem be solved with push-pins? If so, we’d write custom data services against a SQL table with Lat/Lon columns. This is blazing fast, and a great solution if it works for your problem.

For non-point data, I’d see if we are talking about lots of features or just a few at a time. If it’s just a few at a time, we can send them as geometry (GeoJSON etc) otherwise we’ll need a rendering engine to create images, and I’d look at using ArcGIS Server (9.3!) or GeoServer (which incidentally now has support for SQL Server 2008). You can create tile caches, or (with Google) dynamically render a layer. Since the UI and server calls are all under your control, the sky is the limit in terms of what you can do.

2) Can I use OpenLayers?

Even if you are using the ESRI platform, OpenLayers is still a compelling front-end. It can natively consume other WMS/WMS Cache services, GeoRSS, GeoJSON, and a whole host of other things. It has vector editing tools, and support for WFS-T if you have a back-end server that speaks that dialect. It is also open source, has a mountain of unit tests, and is pretty easy to develop with. I’d expect to see someone write extensions for this that can consume layers and features from the ESRI REST API.

3) Can I use the ESRI Javascript API?

If you don’t need to pull in non-ESRI external data, then the ESRI Javascript API is pretty compelling. The ArcGIS Online tile caches make for a good starting point, and the map control itself is very nice to work with. To do anything complex, you’ll need to get serious with the Dojo Toolkit, but that’s worth it regardless of the map canvas you choose. The REST back-end is pretty smooth for simple apps, and when things get more complex, you can always roll your own services (you can read more about that here.)

4) Must I use the WebADF?

Although 9.3 has led to some performance increases, the API is still a huge maze. I think that the breadth of knowledge required to get started with the javascript options often scare off developers. From our experience, while the initial learning curve for the javascript options may seem higher, the effort of developing and debugging even a moderately complex WebADF application vastly exceeds learning  javascript, Dojo/jQuery/ExtJs/YUI, the zen of REST, miscellaneous “HTTP Goodness” and JSON Web Services.

Developing complex sites any any platform is complex, and I’d argue that at least with the javascript options you can “see” everything that’s going on (although this has *improved* with 9.3), and have much more control over the UI and service tiers.  Some may disagree with me on that, but that’s how I see it. I’m sure you can build a high-performance, user friendly, rock-solid application on the WebADF, but I have not seen such a thing (send Urls if you know of any).

Conclusion…

Keep an open mind, and accept that to build compelling Web 2.0 app, you are going to get some javascript on your shirt. Use some good tooling (Aptana or Visual Studio have reasonable to good javascript support) and it’s just not that daunting. Whatever you do, do not pick a technology because it’s easier to “get started” with. Look at the longer term, and accept that you’ll have to gain some new skills – it’s actually pretty fun

Hey – What about Flash/Flex/Silverlight?

Honestly, I’m just not a Flash/Flex/Silverlight kinda guy – while these technologies can do some compelling things, I’m just not “feeling” it. With the performance increases in Javascript (John Resig compares V8 and TraceMonkey – the “guts” of the newer javascript engines), and the large community of developers working on jQuery, Dojo, YUI, ExtJs and other frameworks, I just don’t see a need to graft a client-control into the page. This is not to say you should not do this – if you like it / need it, go for it!