Ran into some odd behavior today – I had installed MbUnit and TestDriven.net a while back after re-paving my workstaion with Vista64, but had not used either since then (writing more proposals than code lately). I went to add some new tests to the ArcDeveloper Tile Server code-base and found that when I ran the test from the Solution Explorer context menu, they would not run.

In fact I got this message in the output window:

—— Test started: Assembly: TileServer.Core.Tests.dll ——

The target type doesn’t contain tests from a known test framework or a ‘Main’ method.

Nice. So something it likely messed up in the install. But for grins I tried running a test from the code window context menu – and it worked.

So clearly something is way jacked up. I un-installed TestDriven.net and MbUnit, and re-installed. No dice. Un-installed ReSharper, re-installed TestDriven.net and MbUnit. Nada. Repeat with various other options. Zilch. Googling turned up nothing. Yeech – not good.

Then I recalled getting an email from Greg Littlehales when I posted about switching to Vista 64… something about TestDriven.net. A quick search in Gmail pulled up the answer – there is a bug in the TestDriven.Net installer which causes it to put some registry entries in the wrong spot. Here’s the url of the issue over in Google Code: http://code.google.com/p/mb-unit/issues/detail?id=270 

The response from Jeff Brown is…

The installer doesn't know how to create the right entries on x64 machines.
We'll be fixing this in the new WiX-based installer as part of an upcoming release.

In the interim, you can export the
HKLM/Software/Wow6432Node/MutantDesign/TestDriven.Net/TestRunners key and import its
contents back into HKLM/Software/MutantDesign/TestDriven.Net/TestRunners.

I fired up RegEdit, did the export, deleted all occurances of “Wow6432Node/” in the file and imported it back in. Once I did this, all was well in the world and I could go home (and hit Publish on this post!) So far this is the only issue I’ve run into with Vista (other than a client who’s VPN does not support Vista, so I run an XP VM to connect)

For others who may run into this, here’s the what I used – this assumes that everything was installed in default locations.

[HKEY_LOCAL_MACHINE\SOFTWARE\MutantDesign\TestDriven.NET\TestRunners\xunit]
@="4"
"AssemblyPath"="F:\\ArcDeveloper\\tileserver\\trunk\\Third Party\\XUnit\\xunitext.runner.tdnet.dll"
"TypeName"="XunitExt.Runner.TdNet.TdNetRunner"


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?

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, t
here 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)

I just finished off some burly refactoring of our security management code base so that it could be better unit tested. This subsystem essentially controls what tools a user has access to, as well as what layers / features a user can edit, so it’s a pretty critical part of the infrastructure.

I’m working on some posts about how I did this, and should get them out next week, but for now, I’ll just show this…

Although there are only 16 tests listed, many of these methods actually contain a number of individual test assertions, and there are more than 80 tests that are actually run.

I’m in the process of creating a set of Visual Studio templates to share with the community – pretty simple stuff, but can be quite a time saver. In the past I’ve posted about how to streamline coding using templates, and while the process for packaging templates outlined in that post works, it’s pretty manual, and that’s not going to work if I’m going to maintain and grow these things. Enter MSBuild. But before I go into that, lets review how I’ve organized the solution.

The solution is called “ArcDevelper.Templates” – and it simply contains a bunch of other projects that contain the template files, as shown in the following graphic.

Each project simply has the template file (class.cs for example), an associated icon, and the vstemplate file that tells Visual Studio how to transform the file. It’s important to note that I’m are just using Visual Studio as an editing environment, and the solution as an organizational scheme – we do not actually “build” anything in the traditional sense.

First off the projects would not compile because the still have string parameters in them that get replaced when the templates are run (see my previous post on templates for more). What we want to do is package the files so they can be used as “templates” – this is where MSBuild comes in.

The MSBuild Script

The other thing I have in the solution is a build.xml file that actually extracts out the files, puts them into zip files and moves them to my “ItemTemplates” folder. With this in place, I can easily make changes to my templates, re-run the build script, and have the updated templates immediately available.

In order to make this work, I had to use MSBuild “batching”, which is not exactly intuitive. Without getting into too much about MSBuild (Google it – there’s ton’s of info around), when creating the itemgroup that will be fed into the target (the actual zip & copy), you need to create some metadata for the items, and then use the Outputs attribute of the Target to subset the items by some of the metadata. As an old client of mine used to say - clear as mud. Maybe this will help…

This is the Item Group that lists the templates (projects) that we will be working with. The path, zipname and itemname sub-elements are the metadata I was talking about. This is then used by the target…

The target specifically notes the inputs and the outputs. Apparently by specifying a metadata item in the outputs forces MSBuild to group / subset the items (depending on how you want to think about it) by that item. In my case, the item is unique – so I get the effect of simply looping over the list.

Anyhow – now I’ve got this all working smoothly, so I’ll add some more stuff into the templates, and then load it up into the ArcDeveloper.net Subversion repository over at SourceForge. I’ll post about the actual templates when they are up there.

This week I will be transitioning from Microsoft Team System to Subversion for our source control system. There are two main reasons for this change - cost and ease of use.

Cost

The cost issue is two fold – first there is the internal cost of using the Team Editions of Visual Studio. For the MSDN subscription, Team Edition (not Team Suite) runs $1000 more per develper, per year than Visual Studio Professional. While this is not bad for a small team, it’s prohibitive if you are looking at growing significantly, or standardizing across large group. I can think of many useful ways to spend $7,000 per year besides sending it to Microsoft. Not that Team System is not cool and useful, but in the end, I just don’t see it being $7,000 per year cooler than Subversion + TRAC (open source issue/bug tracking system) and that’s the real bottom line – value. 

The second cost aspect is somewhat inverse – if we are using Subversion and an open source build/unit testing/coverage/installer stack, then we can ship this to our clients. Since we build state level enterprise systems, and most of our clients expect to take on the longer term support and maintenance of the system, there is some serious value in being able to turn it all over to them as a comprehensive development platform. If we are on Team System, then it would be doubtful if we could ship the whole stack.

Ease of Use

Since Team System is fully integrated into Visual Studio Team Edition, the user experience for most things is pretty good. Actually I really like the check-in rules you can implement. However, we have had many issues working with web projects, as well as dealing with “other” files such as CodeSmith templates. Of course CodeSmith does not “know” about Team System, so it can’t automatically “check out” the files prior to editing them. Since Team System sets your working copy to read-only when you check in (there may be a way to change this – not sure), in order to make a change to my template, I need to open Visual Studio (slow), connect to Team Server (slow), navigate to the templates in source control, check out the file, make the change, go back to Visual Studio and check in the file again. Compared to working with  Subversion, this is a major pain.

The Transition

At this point we have our Subversion server setup, and our domain accounts are authenticating through Apache. All is well. The next step is at the end of our current Sprint, get the latest code from Team System, do a build, run all the tests, clean the solutions (using Omar Shahine / Jeff Atwood’s Clean Sources) and then load the files into Subversion. I did some Googling for tools which would take the history etc. along for the ride, but I did not find anything. At this point we are early enough in the project where losing history would not be too much of a problem, and we’ll be able to have the Team Server running for at least 6 months incase we really need to get some old version.

Tools

At this point we are planning on using the very well regarded TortoiseSVN as the main client for Subversion, but we’ll also be trying AnkhSVN and VisualSVN to handle the Visual Studio integration. I’ll let you know how those tools pan out.

One way to increase developer efficiency is to leverage automation where
possible, including in your Visual Studio item templates. In this post I will
review how to create some simple Visual Studio templates, and how to share them
with a team of people. 

About Item Templates

For every type of item you can create in Visual Studio, there exists a
template, and when you select the item to add to your project, the template gets
executed, the new item is produced and the file(s) are added to your solution.
Sounds simple, and for the most part it is. Of course there are some
wrinkes.

Before we get into that, you can find your existing templates at:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ItemTemplates. There
is also a ProjectTemplates folder at the same level. Templates for each language
(Visual Basic, C# etc) are located below these folders.

Zip Files and the Template Cache

The first wrinkle is that templates are stored in zip files. The second
wrinkle is that the actual templates that are used by visual studio are stored
in a cache folder. This is located in the same folder, and not suprisingly named
ItemTemplatesCache.

This is all well and good, but it can make debugging your templates a little
bit of a pain.

Editing Templates

The first thing to do is decide where you want to actually edit your
templates – I would not edit them in the ItemTemplates folder. Since these end
up being part of your codebase, create a source controlled location just like
you would for any other code. 

Custom Class Template

In this example I’m going to show how to add some useflu extras to all your
classes. We’ll add a header that will have a copyright statement, the
developer’s name and the date it was created, as well as a default namespace. To
do this, in Visual Studio, we just create a new class library project, and add a
class. We then edit the class so that it has the header we want, and the
regions.

We also need to add some parameters into the class that Visual Studio will
replace when the item is added into the solution. These are of the form
$parameter$, and there are 13 that are automatically present. You can also
create custom parameters if you need more control. See the MSDN page on Template
Parameters for more information.

Icons

If you want your new class to have a saucy new icon, then you’ll need to
create or locate a suitable icon and have it handy when we export the class from
the project.

Exporting to a Template

Once yoiu have the file the way you like it in Visual Studio, simply use File
–> Export to Template to start the export Wizard. The wizard is very simple
and easy to follow. What’s really nice is that you can have the template
automatically include references into the target project for you. This is very
convenient when working with ArcObjects.

The final step of the wizard is shown below – essentially it will export the
template, create the vstemplate metadata file, store the output and import it
into Visual Studio all at once.

Using the Template

Once the template has been imported into Visual Studio, it’s ready to be
user. Just add an item to a project, and scroll down in the “Add New Item”
dialog to the My Templates section. There you will see your shiny new tempalte.

Select it, give it a name, and Visual Studio will do the replacement, and
open it in the editor.

That’s it. You now have a way to easily create classes that have consistent
headers and organzaiton. This is a very simple example, but you can look at the
ArcGIS templates provided by ESRI and see some examples doing more complex
things.

Sharing Templates

It’s  one thing to write your own templates, but the real benefit shows up
when you have a whole team using the same templates – this ensures that the code
is more consistent, and thus it’s easier for other team members to work on.
Sharing templates  is a two step process. First, put your shared templates on
the network, and use the Tools –> Options, Projects and Solutions and set
the location of your User Item templates. Next, open the Visual Studio Command
Prompt (not a normal command prompt!) and run devenv
-installvstemplates. This copies all the templates from the User Item
Templates location into the ItemTemplate cache. Whenever the templates are
changed, this step must be re-run to load the items into the local cache.

In a following post I’ll show some more complex templates
that simplify the Supervising
Controller pattern I talked about a few posts back.

Download the example Template Visual Studio Project You’ll have to export the template after editing the custom class – i.e. adding your copyright and default namespace!

Resources

Template
Parameters (MSDN)

Visual
Studio Templates Overview (MSDN)

A while back I posted about setting up my home source control server using Subversion. The original post basically listed the steps to getting it installed.

I was just reading Omar Shahine’s blog, and he noted that there is now a 1-Click Subversion setup package for Windows users. I had not heard about this, and thought I’d point this out to others. Installing subversion was pretty simple before, and now it’s virtually painless.

So – if you still have a list of reasons why you were not using source control, you can strike out “difficult to install” and “cost”.

Since we are hiring, we need to get some more workstations – thus it is time
once again to see how much power a couple of grand will buy. If you have recently bought a kickin workstation for ArcGIS Development – I’d love to hear about your experiences…

Instead of simply specing out a top end box without much idea as to how it
would perform, I decided to try and figure our what ESRI would recommend. I started by cracking open the 2006 System Design
Strategies white paper from ESRI. I say cracking, but really it was quite a bit of waiting as Acrobat loaded the 289 page document.

Here’s the important bit – on page 7-17, the document states that ESRI uses
the “SPECInt Rate 2000″ as their system comparison benchmark. Conveniently the
rates for all kinds of systems are published so you
can check things out.

After further digging in the system design document, it turns out there was little in there that I could directly apply to the developer experience i.e.
they have not done benchmarking for how fast ArcMap starts, or how fast visual studio is while debugging. So, I decided to check the rating on
our current systems, so I’d at least have a
relative ranking.

Current Workstations:

Dell Precision 370, 3.8Ghz P4 w/ hyper threading, 3GB RAM, 256Mb dual head video card, ~100GB
disk

While not specifically listed, a similarly equipped Acer system with this
chip rates
a 23.5

While not bad, these workstations certainly could be faster – particularly
when starting ArcMap, and running Visual Studio 2005 with large solutions. Thus,
I started looking at systems which had a higher Spec rating, and more
specifically at the CPU’s which had the high ratings.

AMD Athlon vs Intel Core Duo

Obviously there are other factors which make a PC fast, but at the heart of
it all is the CPU, so may as well start there.

The top rated AMD chip is the Athlon
64 FX-62, with a 43.7

The top of the heap from Intel is the Core
2 Extreme X6800 at 63.5 with other Core 2 Duo’s coming in at 58.7 (E6700)
and 53.7 (E6600). Based on this, I figured that we should be able to at least double our workstation performance. The next step was figuring out what is was going to cost.

Looking for Systems

Traditionally we’ve been a Dell shop, so I started there.

The Dell
Precision 390  can be configured with each of the Core 2 Duo chips. For the pricing below, all
have 4GB of DDR2 RAM, and 2 80GB harddrives, 128Mb dual head video card, CD/DVD
burner WinXp. (For those scratching their heads on the 80GB drives – we really don’t need a lot of disk space, as 90% of our projects use ArcSDE as the data store.)

Here are the prices (as of 10/27/06)

1. Core 2 Extreme X6800: ~$2800 (Spec 63.5)
2. Core 2 Duo E6700: ~$2350 (Spec 58.7)
3. Core 2 Duo E6600: ~$2150 (Spec 53.9)

Not bad, but last winter I built a box for home and I’ve been really happy
with it, so I thought I’d check out what I can get from there -
GlobalComputer.com.

They have a Systemax
system that’s build to order – same basic config – 4GB DDR2 RAM, 2 80GB hard
drives, 256Mb dual head video card, CD/DVD burner, Win Xp.

1. Systemax Core 2 Duo E6700: ~$1950 (Spec 58.7)
2. Systemax Core 2 Duo E6600: ~$1650 (Spec 53.9)

Verdict?

It’s hard to say – Dell does have great support, and it’s the exact system
noted in the Spec ratings, so that’s a bonus. That said, is the support really
worth the $400-$500 difference? An even better question relates to the cost
difference vs. performance difference between the top $2800 system (63.5)
and the much cheaper $2150 system (53.9). Is that 10 spec points really worth
$650? Or is there just a premium on the fastest chips?

We’ll have to make the call next week, but right now, I’m leaning towards the
Systemax boxes. We’ve had great luck with other off-brand boxes (1/2 our servers
are SuperMicros) and I’m sure that I can find some other cool stuff to get with
the remaining cash.

After last nights ArcDeveloper talk on code generation with the Geodatabase (link to powerpoint slides ~5Mb), I ran into a blog entry on Microsofts “Data Access Guidance Package” by David Hayden over at CodeBetter.com

From my quick read, the “Guidance Automation Toolkit” contains a set of tools for creating data access layers via code generation, automation tools  and templates for use in Visual Studio, as well as recipes (the “guidance” part) for how to apply all this. Sounds nice.

But, being Microsoft Labs, they take it a step further – there is also a “Web Service Software Factory”, which is designed to work with the output of the Data Access Guidance Package.

Armed with these tools a developer should be able to go from a data model to full set of business objects to an operational web service in an afternoon. That’s power.

If this sounds good to you, check out these articles… (also David Hayden)

• Code Generation and Automation in Visual Studio
• 
  Web Service Software Factory – Guidance Automation Extensions on Steroids
  

Get the bits here…

• Data Access Guidance Automation Toolkit
• Web Service Software Factory