I'm doing a technical review for some chapters on the Dojo Toolkit for an upcoming Wrox Press book on Javascript Frameworks. I suppose not surprisingly, the sample code for the server side code is php.

So, in order to be a good reviewer, I'm jumping into the PHP pool. I have to say that in reading the sample code, it's a lot "closer to the metal" then ASP.NET, so this should be interesting to say the least.

So - should you want to embark on a similar journey, here's the best info I could find on installing php as an ISAPI extension.

If you are running Vista SP1 or Server 2008, you can install FastCGI support and run PHP that way. The basic steps are outlined here.

Looks like things are up and running - php here I come!

It's looking really dark outside and the trees are whippin around, so I brought up the weather channel's radar map to see this...

Time to hunker down!

A reader recently asked me to expand upon the "Keep it Simple" advice in the fundamentals section of my web site. Just like my advice, I had kept this section pretty lean...

Keep it simple

Anybody can build complex software. Creating simple software that can accomplish the same task is much more difficult. In the end though, the simpler it is, the easier it is to test, which makes it easier to maintain, and easier to extend.

To illustrate the idea, I'll talk about a project that I'm working on right now. Basically I'm helping / mentoring a team through a short term project to build a data viewer application based on Virtual Earth, Dojo, ArcGIS Server (9.2) and ASP.NET.

One of the user stories in this project is:

As an administrator I want the Data Viewer to be database agnostic so that I can easily configure it to pull point data from SQL Server, Oracle or file based data sources.

Now, this is a great idea, and certainly possible. In fact it ends up being very interesting to design (plug-ins, configuration sections and Inversion of Control oh my!).

Simple works...

In looking at the project (it's very short term) and the team (new to web development) and the current problem they are trying to solve (display data from SQL Server), my recommendation to the team is that we "keep it simple" for now, and just address the SQL Server data source.

While we could define a set of interfaces, build out a whole configuration model, and create the actual data access objects for these various data sources, in the context of this project it's extraneous. To be "successful", we need to display the current data in Virtual Earth. With tight time frames and limited resources, I believe the tradeoff between building for an unknown complex future need, and applying time and effort to the core objective, is a good one. The team will be able to get the database access tier of the system completed in a short time, and it will be very simple to understand - parameters are passed to a class, which calls a stored procedure, which returns the point data. Simple, clean, and working.

But what about the "can accomplish the same task" bit? Good question - I'd suggest that in this situation, with the current data is in SQL Server, you are doing the same task - just using a simpler design to achieve the goal.

Add Complexity when it is Needed

If / when a need arises to add data from Oracle, it will be a very simple task to create another class which mimics the SQL Server class, with the only difference being that it uses the Oracle data connection classes. Should this Data Viewer become a huge hit, and is used so extensively that it must become configurable by non-developers, it could then be refactored to add in the additional complexity required to support configuration sections and a plug-in data provider model. But for now, the much simpler solution works just fine.

So - to summarize: Make choices which trend towards keeping the code as simple as possible. Don't add extra features or design elements to handle unknown or fuzzy future requirements. Add complexity only when it's really needed. While it's fun to monkey with internal design optimizations etc, keep your eyes on the prize: software that works for the user. And keep in mind who will be maintaining the software over the long haul - while you may be a whiz at generics (for example) keep in mind that for many people they tend to make understanding the code more difficult.

That's pretty much my take on this, but I'd love to hear your thoughts on keeping software "simple". How do you decide when to add complexity? How do you define complexity?

Other thoughts on Simplicity:

Joel On Software: Simplicity

The Fourth Law of Software Design: Complexity vs. Ease of Maintenance

Various Quotes on Simplicity in Software Design

I was running into a LOT of weirdness with my Windows Xp installation, so I figured I'd upgrade to Vista 64 instead of futzing with another re-do of Xp.

I've been running Vista on my notebook an home workstation for about 6 months with no issues, and with my MSDN subscription, so it's a no-cost thing - just grab the disk and an authorization code, and let 'er rip.

Hardware Compatibility is one of the first things you should be concerned about when jumping to the 64-bit platform, but we had pre-planned this to some extent. When we built out our development boxes, we followed the "CodingHorror Ultimate Developer Rig" parts list. So other than the quad core CPU, I've got exactly the same box. Since Scott Hanselman has been running Vista 64 for a long time, with few issues (here's a link to his podcast on the Vista 64 Developer Experience) this should go pretty smoothly.

One nice thing about re-paving a machine is you get to clean out all the crud that accumulates over time. So, as I re-built things, I created a list of all the stuff I could not live without.

Vista Components:

• IIS w/ IIS 6 compatibility
• Disable User Access Control - secure, but a hassle

Development Tools:

• Visual Studio 2008
• Aptana Studio - Javascript / Ajax IDE
• MyGeneration - free code generation tool
• MbUnit - unit testing on crack
• TestDriven.net - Unit Testing harness for Visual Studio
• GhostDoc - why write your own Xml comments?

Productivity:

• Office Enterprise 2007
• Visio 2007
• Slickrun  - launcher goodness
• FolderShare - sync folders across multiple systems
• Notepad++ - notepad with tabs and syntax hilighting
• FireFox
  • FireBug - must have for Ajax development
  • FoxMarks - sync bookmarks across multiple systems
  • IETab - runs IE inside FireFox - good for SharePoint

GIS:

• ArcGIS Desktop (Editor) 9.3 Beta
• uDig

So, .NET developers - what other tools do you install on a fresh box?

Phil Haack posted a comparison of MVC and MVP patterns with some zen on how these patterns work in the web.

We recently moved from using Exchange to Google Apps. The transition has gone really smoothly, but there have been a few hurdles - mainly surrounding synchronization of Mail and Calendar across multiple devices.

While the Google Apps are all web-based, accessing them in a browser is not always an option - particularly when on airplanes. Additionally - if you rely heavily on your calendar for reminders like I do, remembering to keep a browser open on your calendar page is just one step too many. ;-)

So - here's my device situation:

Under Exchange, my notebook and workstation would connect to Exchange for email and calendar, and synchronization was automatic. My phone would pick up email via IMAP to Exchange, but the calendar was synched when I connected the phone to either PC via a USB cable. Overall pretty good, but the calendar synch to the phone was a little more involved than I'd like - why not synch over the air?

Anyhow, with the move to Google, I can of course access mail and calendar from all three via a web browser. This is fine for email on the PC's, but a little less than optimal for the calendar. Needing to have a calendar open to get reminders is not good for me. Call me old school, but I like Outlook - as far as email and calendar go - it works for me. 

Connecting Outlook with Google Apps

Actually getting a single instance of  Outlook talking to GMail via POP or IMAP is pretty easy, and well documented. If you use IMAP, then you can have multiple clients systems connected and everything is synchronized for you.

The calendar is another matter. For PC's you need to run the Google Calendar Synch, which will copy items between your local Outlook calendar and a Google Calendar. It does the sync on a scheduled basis, so there may be some lag, but since you are planning things in the future, a 10-30 minute lag should not be a big deal.

On my phone, I'm using Mobile Outlook connecting to IMAP for mail, along with GooSync keeps my mobile Calendar in line with my Google Calendar. What's sweet it that this works bi-directionally - over the air - something which was not an option with our Exchange setup.

If you are thinking about jumping to Google Apps, I'd say go for it. The transition has been smooth and everything we need is working with a lot less headaches for our IT staff.

Based on the outcome of the Developer Survey, I thought I' put together some posts on the common patterns referenced in some of the questions, starting with the Model View Controller (MVC) family.

There has been plenty written about MVC on the formal side of things - here are two good sources of information - Wikipedia MVC entry,  and some thoughts from Martin Fowler.

The Basics

The MVC family of patterns are about separating the presentation of data from the business logic surrounding the management of the data. There are many other patterns based on the key MVC ideas - Passive View, Supervising Controller, Presentation Model and Separated Presentation are 4 such patterns. The differences are subtle, and all share they key idea of separating the presentation logic from the business logic, from the data itself. It's worth noting that the opposite of MVC family is called "Autonomous View" in which all the logic is in the form itself - so if this is how you are developing, now you can use a fancy name for it!

Since MVC was one of the first patterns that dealt with this separation, we'll start with it, and look at the three components...

Model:

The model is the data and it's usually a class. So in GIS-land, it could be a "Parcel" class, which may have a Geometry property. The important part is that this class has no dependencies on the presentation layer, or the controller. It's just a dumb data container. Typically this class will implement one or more interfaces, which the View and Controller will utilize. Interfaces are used a lot in these patterns, so here's a link to an article that compares Abstract Classes and Interfaces that can serve as a refresher if needed.

View:

As the name suggests the View is responsible for organizing and presenting the Model. Usually this means showing it visually on a form. In order to remove dependencies between the View and the Model, the View will interact with an interface, instead of a specific view class - i.e. IParcelFeature instead of "Parcel". The view typically raises events when the user makes changes in the interface, and exposes properties allowing the Controller to "see" the model or other state of the view. The View does not make any changes to the Model itself (in some  MV* patterns does not actually have visibility of the model - the controller sets all the control values directly, and responds to all control events). Again, the events and properties of the View are defined via an interface.

Controller:

The name conveys things pretty well - this is the business logic component that controls what actually happens to the model when an event occurs in the view. There may be multiple controllers that can work with a given class, or multiple model classes that can work with a given controller. This is where the Interfaces on the Models come in. If the Controller's "contract" is based on an Interface (IParcelFeature), then we can use the Controller with any class that implements the interface. Similarly, the Controller also implements an Interface, which is it's contract with the View.

Pulling it to all together:

In MVC, the Controller gets a model and a View. It then passed the required data to the View which renders the UI. When the user interacts with the UI (i.e. clicks a button), the View raises events, which the Controller responds to by making required changes to the Model, which is then used to update the View.

Why Bother?

So - this is nice, but why separate things out like this? There are a number of reasons. First is known as Single Responsibility. This concept basically says that a class should have one purpose, and anything not connected with that purpose should be in a separate class. In regards to the subject at hand, it would tell you to avoid mixing presentation code, with business logic because they are not actually related.

Another reason for MVC is re-use. If you model your application like this, you can plug and play the components - particularly the View. So, suppose you need to create a business application that has a windows forms client for some functionality, a web client for some other functions, and a web service API. You can build out a model, a controller, and three views - one for the windows forms application, one for a web form, and a third (more limited one) for the web service.

A final (and biggest) reason is testability. If you keep the Model (data) separate from the View (User Interface) which is separate from the Controller (business logic), writing unit tests becomes much easier. If you've implemented interfaces as the contract between the components, you can test the components individually.

The Pain of Testing

Without getting too deep into unit testing, the basic idea is to have a test harness which spins up various classes in your code, and executes methods. This gets complicated because our classes have dependencies on data - stored in databases, shape files, whatever. If we want to re-run our tests frequently, we want to be sure our test data is static - otherwise the tests break, and that defeats the purpose. So - the next best option is to create "fake" static data in our tests. The brute force method would be to create specific test classes which implement the required interfaces (ISomeView, ISomeModel etc), but just contain enough logic to complete the test. Depending on the test you would have an invalid geometry, invalid PIN number or a myriad of other conditions. This would allow you to create test "Parcels" in your unit test harness, that you could then pass to the Controller to test it's methods, without actually connecting to a shape file. You could also create a class that implemented the View interface, and use that to raise events and ensure that the Controller reacted correctly. Essentially you can write unit tests for everything but the "click" event handler in the UI layer. Since that code was likely written for you by the IDE, and it's super basic, it's not a really high priority for testing.

Easing the Pain of Testing: Dynamic Mocking

Of course that's a lot of work, and developers hate extra work, so tools were created to help out. While this is beyond the scope of this post, I'm talking about "mocking" frameworks, such as NMock, RhinoMocks or TypeMock. These frameworks can create a "test dummy" class that implements a specific  interface right in the test definition. You basically "record" some values into the Mock, then pass it into a method, and it can validate behavior.

Of course you still need to fill up the dynamically mocked Interface with valid data - and the geometries are likely the scariest thing to start with. So that's where I started a few years ago.

I can haz code?

I don't have anything lying around that's easily sharable, but I did post a sample about Supervising Controller code about a year ago. The code is in VB.NET, with a Visual Studio 2005 solution, and is oriented towards showing how to create a plug-in framework, while leveraging Supervising Controller, so that's the gist of the article. It also does not have any tests, but I'll be posting more leveraging MVC patterns and unit testing in the future.

Plug-in Framework & Supervising Controller Example (Article - read this before digging into the code)

Download Sample Code

Summary

The idea here was to introduce the main idea of the MVC pattern - separation of behavior logic from presentation logic, usually to facilitate testing. The actual implementation of this idea can take many flavors, and can vary in complexity, but the underlying concept is the same.

We just put up another "demo" site - this time working with Sanborn to provide visualization for their wildfire risk model outputs they have created for the Texas Forest Service. For information on the data, there is contact information on the "About" tab.

From a technical stand-point, we added a few new features to this viewer...

Dealing with Multiple Tile Layers

The viewer is pulling in multiple tile services, representing multiple layers in a map, as opposed to a single "fused" tile layer. This is the first time I've implemented multiple layers using the ArcGIS Server Tile Cache code, and it turns out it's currently a bit of a pain. For this site, we've got 7 tile layers, and to do that with the current tile server code, I needed to create 7 map services (mxd's), and then configure 7 tile services in the TileServer. Clearly this should be streamlined. For example, the url http://65.101.234.201/tileservice/txfirewfsi/023131001.ashx pulls a specific tile from the txfirewfsi tile service. (shown below)

However, I'm thinking that it would be nice to be able to add a layer name in the url -'parcels' in this case -   http://65.101.234.201/tileservice/txbasemap/parcels/023133.ashx. This way you could specify the fused tiles, or just a specific layer.

Adjusting Layer Transparency

This was easy, if not obvious. Adding in a Dojo.slider, and hooking up some events was pretty simple. However, it turns out that changing the .Opacity property of a VETileSourceSpecification has no effect after the layer has been added to map. Instead you need to delete the layer and re-add it with the new opacity. Since the browser is caching the tiles, this is actually very fast.

Virtual Earth 3D

This was also the first time I tried throwing things into 3D mode. It took a few quick tweaks in the javascript, and some different CSS for the markers, but for the most part - it "just worked".

There are a few issues with the dojo menus that I'm going to sort out so I'll save the Url for the 3d page until that's dialed.

So, this took about 3 days to pull together -- if you are looking under the covers, the code is VERY "demo" and has some issues - there are a few weird things with the layer list checkboxes and I have not really tested in IE7, and all bets are off with IE6. I'd love to hear thoughts & ideas though.

Just a quick note that if you've ever run into trouble keeping things positioned correctly in your browser app, take a look at dojo.coords. (ok, the doc is limited, but poke around with FireBug, and it's pretty easy to see what it does)

Basically this allows you to get the top, left, width, height, x and y for any element on your page. I was having issues with my Dojo slider control's positioning when added into the Virtual Earth control via map.AddControl. Basically the control loads just fine initially...

But when the browser window is re-sized, the control remains absolutely positioned on the page, rather than relative to the container (the VE control), as can be seen below.

Setting the CSS postition:relative, does not work at all, so the solution was to write a little code that would respond to the browser re-size event, and re-position the control. Hooking to the resize event is very easy with dojo.connect... 

dojo.connect(window, 'onresize', positionZoomSlider);

Getting the correct position values in order to calculate the correct position was also easy when using dojo.coords... here's the function that positions my slider.

function positionZoomSlider() {
            //This is needed because the dojo slider seems to always be absolutely positioned.
            //so we attach this to the browser re-size so when things move around, the slider
            //is repositioned correctly.           
            var control = $get('verticalZoomContainer');
            control.style.top =  dojo.coords(dojo.byId('contentContainer')).t + 30 + "px";
            control.style.left = dojo.coords(dojo.byId('contentContainer')).l + 20 + "px";
        }

So I've been using the Dojo toolkit for a while now, but mainly for the Dijit and DojoX UI components.  For the actual Ajax communication layer,  I've been relying on the Microsoft Ajax framework because of it's seamless integration with the ASP.NET Web Service model. Since I've got the whole mess of Dojo already being loaded into the browser, I figured I should drop the crutches, and work out how to work directly with the Dojo ajax framework.

The one downside of this is that you no longer get the client side proxies for your ASP.NET Web Services. Thus today's article - how to directly access an ASP.NET JSON Web Service using dojo.xhrGet.

Part 1: Create a Web Service

This is pretty simple - just add a web service to your web site. I tend to put the code right in the asmx file, rather than in the code-behind in app_code, but that's just personal preference.

          <%
          @ 
          WebService 
          Language
          ="C#" 
          Class
          ="ASPWebService" 
          %> 
          using System; using System.Web; using System.Web.Services; using System.Web.Services.Protocols;
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] public
class ASPWebService : System.Web.Services.WebService {
[WebMethod] public string SayHello()
{ return "Hello
to Dojo " + DateTime.Now.ToLongDateString();
} }

By default your web service will be configured to "speak" SOAP, which is fine if you are consuming it from another application, but for Ajax based browser apps, it's much easier to work with JSON.

Part 2: JSON-ify the Web Service

This is actually really simple - just include System.Web.Script.Services, and the [ScriptService] attribute to the web service as shown below.

          <%
          @ 
          WebService 
          Language
          ="C#" 
          Class
          ="ASPWebService" 
          %> 
          using System; using System.Web; using System.Web.Services; using System.Web.Services.Protocols; using System.Web.Script.Services; [WebService(Namespace
= "http://tempuri.org/")] [WebServiceBinding(ConformsTo
= WsiProfiles.BasicProfile1_1)] [ScriptService] public
class ASPWebService : System.Web.Services.WebService {
[WebMethod] [ScriptMethod(ResponseFormat
= ResponseFormat.Json, UseHttpGet=true)] public
string SayHello() { return "Hello
to Dojo " + DateTime.Now.ToLongDateString();
} }

We also add a [ScriptMethod] attribute to the WebMethod. We do this for two reasons - first, we want to specify that the response  format should be JSON, and we also want to allow access to this method via http Get's (this is disabled by default).

At this point you can hit the web service in your web browser, and get the standard Web Service browser. But if you also stick /js on the end of the url, you will get the client side Javascript that integrates with the MS Ajax Framework. But we're trying to work with Dojo, so we'll move on...

Part 3: Testing the Service in a Browser

Our simple "SayHello" web method does not take any arguments, so we should be able to just "GET" it via a browser.

The tricky bit that took me some time to sleuth down was that you also need to edit web.config to tell the web service to respond to all Gets and Posts. Add this section (just copy out the parts you are missing - do not paste this whole thing into your web.config or you will get an error!):

          <
          system.web
          >
<
          webServices
          >
<
          protocols
          >
<
          add 
          name
          ="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>

Once you do this, you will get the response back. Despite the fact that we have used the [ScriptMethod] attribute to specify that the SayHello web method should return Json, this will only occur if you sent the request content-type to "application/json; charset=utf-8". Without that, you'll still get xml.

Part 4: Create a Simple Page

For this, I created about the simplest page I could - just a button and a div that will be updated. Here's the whole page...

          <!
          DOCTYPE 
          html
PUBLIC 
          "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <
          html 
          xmlns
          ="http://www.w3.org/1999/xhtml">
<
          head
          >
<
          title
          >Dojo
to ASP.NET WebServices</title>
<script type="text/javascript" src="http://o.aolcdn.com/dojo/1.1.1/dojo/dojo.xd.js" djConfig="parseOnLoad:true,
isDebug:true"></script>
<script type="text/javascript">
function updateSampleOne(){ var contentNode
= dojo.byId("sampleone"); dojo.xhrGet({
url: "./ASPWebService.asmx/SayHello",
handleAs: "json", contentType: "application/json;
charset=utf-8", load: function(data,args){contentNode.innerHTML
= data.d;}, error: function(error,args){console.warn("error!",error);}
}); }; </script>
</head>
<body>
<h1>Using
Dojo to Consume ASP.NET JSON WebServices</h1>
<input id="btGetString" type="button" value="Update" onclick="updateSampleOne();"
/> <div id="sampleone">This
will update</div>
</body>
</html>

Breaking down the dojo code...

var contentNode = dojo.byId("sampleone");

This simply get's a the div that we'll be updating.

dojo.xhrGet({
  url: "./ASPWebService.asmx/SayHello",
handleAs: "json", contentType: "application/json;
charset=utf-8", load: function(data,args){contentNode.innerHTML
= data.d;}, error: function(error,args){console.warn("error!",error);}
});

This is the actual ajax xhr request. Since we are using a GET, we are using dojo.xhrGet.

The Url of our web service is the asmx file followed by the name of the web method. Since it's located in the same folder as this html file, we reference it as ./ASPWebService.asmx/SayHello.

The response will be json, so we set handleAs to json

We set the contentType to "application/json; charset=utf-8" as per the ASP.NET security requirements.

When the response returns, we need to do something with it, this is where load comes in. Dojo uses anonymous functions a lot, and for a simple situation like this, it's pretty easy to follow. The returned JSON is:

{"d":"Hello to Dojo Tuesday, June 03, 2008"}.

So we set the contentNode.innerHTML is set to data.d

Should an error occur, the error function is called.

Summary:

So - while this is a little more convoluted than just using the MS Ajax client library and the Script Manager, it does save us from loading multiple client-side frameworks. Since I'm using Dojo for many other UI components, it seemed a waste to also drag along MS Ajax when this is a viable alternative.

One may ask why use the ASP.NET Web Services model? Well, from the server side it's pretty easy to work with. Once a service is created you can access it via Json or SOAP. They are also easy to unit test.

I'll likely extend this with some more complex examples - like submitting a form, or sending / receiving complex types, but I'll leave it here for now.

Download the sample code

While at Where 2.0, Chris Spagnuolo and I recorded a podcast with the Very Spatial crew.

In this podcast we talk (at a high-level) about internals of the Global Avian Influenza mapping application we built for the Wildlife Conservation Society, and some of the complexities and how we overcame them (think 1-M-M-M database relationships, with complex query criteria and 300ms response times).

For those that know us, you won't be suprised that we also talked about Agile - how it fits in with the Where 2.0 crowd, and how we work Agile into our contracting. All -in - all, a fun experience.

The podcast went live today. Thanks Jesse & Sue!

This is the third and final part of a three part series summarizing the results of the 2008 Geospatial Developer Survey. For further information, be sure to check out read part one and part two. 

Use of Source Control Systems

This is where we start to see some divergence from the larger developer community.

Source control is as much a part of most developers lives as the language they use. It should be automatic and used by default. Subversion is good, and free. It's not trivial to setup, but with free subversion hosting services like Assembla.com, there is virtually no reason not use it. (btw - although I have an "Assembla" badge in my sidebar, I am not paid to endorse them - their service is solid and so I promote it).

Automated Build Tools

With more than half of the respondents not doing automated builds, we are seeing more of the separation from main-stream development.

All the choices on this question were .NET, but I also compiled the "Other - Please specify" results into a chart.

Unit Testing

There were 3 questions on unit testing, mainly because I see this as a key element raising the quality of GIS software projects. Unit testing is as much a philosophy about how you develop software as it is the actual writing of tests. Committing to doing unit testing really says you care about quality, and that you realize that manual testing, while valuable, is never as consistent as automated tests. So, with that we start with a look at what percent of projects are using unit testing.

I don't know how this stacks up to other industries, but I'd say there is room for some growth here. Everyone talks about GIS getting on the "service bus", but we need to make sure that when we get on the bus, our code does not fail!

The next question basically asked why you were not doing more unit testing.

This is actually pretty good. I'd have to question the 14% who don't think it's valuable, but I'll chock that up to them not knowing what's really involved.

I've heard the "not-enough time" thing before, but the problem is that you will have bugs. And someone will find them. Better the developer finding them sooner than a client finding them later. Also, in terms of time, on big projects, I think you actually save time.Having automated tests, helps you prevent regression. Think about all the stuff that breaks between a big ArcGIS releases - that's regression, and that's what good automated tests can catch.  

Difficulty. This is true. Writing good unit tests is hard. Using good design patterns help, and good tools can ease the pain, but even still it's not easy. Writing unit tests for ArcObjects code is very difficult, but not impossible. In these cases, I focus the tests on the most critical parts of a system - basically putting the effort where it will payoff the most. For these areas, I shoot for 100% code coverage - if they are the most complex, I want to make sure that my tests cover all possibilities. Again, difficult, but if you are writing a complex spatial rule engine, that works with relationships between multiple layers, business workflows, and user permissions, there is no realistic way to manually test it on any sort of a regular basis.

The next question was "If tests were easier to write, would you write more of them?"

So, a resounding YES on that. This is great, because as a community we can actually make this happen. 

A couple years back I threw some code out there under the umbrella of "ArcUnit" - the files referenced in those posts are now gone, but it was some demo code that showed how to unit test geometry operations, by serializing geometries and storing them in the unit test assembly. The code is now on Assembla in the ArcDeveloper project, under TestingUtilities. Seeing as there is interest in this, I'll likely write some more articles on this.

Unit Testing Frameworks

Ok - the Java people really ripped on this question. After adding an "Other", I did tabulate the results for all that as well.

This gets somewhat interesting - 60% of people said they are not using any tools, but back in the "What percent of your projects use unit testing" only 38% said "None". I guess some "homegrown" unit testing could explain a few percent, but... anyhow. Interesting that MBUnit and MSTest are so low. MSTest is baked into Visual Studio 2008 (Professional and above), and MBUnit is both free and awesome.

As for the "other", here's how that stacked up.

Apparently I could have saved myself a heap of greif if I'd just added jUnit to the list!

The final Unit Testing question went out to the edge - "What do you think of Test Driven Development"

So at least one zealot in the crowd aims pretty high! For the "No opinion" crowd, TDD is the practice of writing your unit test before the implementation. The intent of this is to essentially define the desired behavior in the test, then make the software behave in that way. No doubt this is difficult, and requires you to be a total unit testing & pattern guru. I *think* this is possible, even on complex projects like GIS, but you'd need to be working with a test friendly GIS framework (as in don't come asking me to build you an ArcGIS Server .NET ADF site using TDD!)

Code Refactoring

As you write code, there are times when you need to change it's structure - usually to conform to a pattern, to facilitate extensibility, or just because your function got long and messy (i.e. you're making maintenance easier!). This is called refactoring. The first question was related to how often you refactor your code.

The second question related to the use of .NET Refactoring tools. I appologize again to the non-.NET people, but I don't know of any Java Refactoring tools.

What's interesting here is that the "Not Refactoring" people are not even using the tools in Visual Studio. When we were doing a lot of desktop development, we used RefactorPro - mainly because they had good Visual Basic.NET support. Now that we're using C# and doing 99% web development, we are finding that the IDE tools / manual refactoring is sufficient.

Code Documentation Generation

This was a quick question on the use of automatic code documentation generators. They are pretty common in the larger developer community, and relatively easy to bring into the mix, and spit out some good API documentation. Worth the effort in my opinion.

Comments

Fifty-Two respondents left comments at the end of the survey. Most were constructive, and others... well... lets look:

WTF, no C++ on the list of languages? What language do you think the bulk of geospatial software (from GDAL to ArcGIS) is written in? C# is just a evil marketing ploy from MS to try to deflate Java's market; nobody is expected to actually _use_ C#.

Reply: Not having C++ was an oversight. As for your issues with C#, can't help you there.

Summary:

Overall, this was an interesting experience. Clearly I could do a much better job on the questions, and have a much wider range of options on the answers. I think it does show that geospatial developers are adopting main stream techniques and tools, just at a somewhat slower pace. Thoughts?

Download the results (Excel 2007 format)