I ran into this problem last week, and it had me stumped for quite a while.

Problem:
I’d start Visual Studio 2005, and try to connect to our Team Foundation Server, but all I would get is a pop-up box stating “Team Foundation Error – object reference not set to an instance of an object”. Boom. All of the sudden I could not connect. Things had been working smoothly the day before, and I could connect on other systems so it was not my credentials.

Non-Fixes:
I tried repairing Visual Studio Team Edition, and the Team Foundation Explorer – neither made any difference, but it did eat 2 hours of time.

What Worked:
As usual Google came through – Dave Donaldson had experienced the same problem, and had written up the solution on his blog.

Turns out the culprit was un-installing the Source Gear Vault client software. We are in the (slow) process of migrating all our source code into SubVersion. At this point we have moved all our code out of our (very) old vault instance. Once that was done, I figured I’d un-install the client as well.

Seems that the uninstall unregisters / changes the registration of a number of IE dlls. Read Dave’s post for more background, but the solution was to re-register the following dlls:

regsvr32 /s urlmon.dll
regsvr32 /s actxprxy.dllregsvr32 /s shdocvw.dllregsvr32 /s mshtml.dllregsvr32 /s browseui.dllregsvr32 /s jscript.dllregsvr32 /s vbscript.dllregsvr32 /s oleaut32.dll

After doing that, things were back to normal. Now I just need to migrate our Team System projects into SubVersion!

Over the weekend I was talking with a friend who’s company had recently been invited to a finalist interview for a large state contract. As a company, they have been adopting agile with good results, despite the fact that most of their current contracts are fixed price – fixed deliverable.

For a while now they have been looking for agile contracts, but none have come up. So they decided to change the game. They went into the finalist interview, and in addition to presenting their qualifications, experience, and proposed solution, they also did a quick presentation on their project management methodology (Scrum + Selective XP Techniques). No discussion of why it’s better than waterfall – just “this is how we do things”.

Given that state agencies are not known for embracing change, it was a gutsy move, but it paid off and they won the contract. Now they have a great contract, and can run it in a sensible way.

I love this story - it’s very “Seth Godin” - do things differently to get the results you want! They were sick of fixed price projects but were not seeing many requests for agile, so they changed the rules. Instead of trying to “win” a client over to using agile, they just stated “we use agile”. Period. They made it the default position.

In addition to winning, it also sets them up for more success. By writing up a case-study about how the project worked, they can show both their success in the vertical market and how agile can be successful in one of the most challenging environments – state government. And that can be used to win over other, possibly skeptical clients.

I’m trying to get some maps published in ArcGIS Server, and I’ve run into some weird problems. When I try to publish a map, I get an error stating that the Server Object Creation failed, and that the map file can not be opened.

My first thought was security, and there were some issues there, but that did not solve everything – I still got the errors. So, as I posted the other day, I started up ArcMap as the ArcGISSOC user. The thing is that even though I can browse to the map as that user, it fails to load the map under most conditions.

I can load the mxd file into ArcMap if I first preview it in ArcCatalog (also running as ArcGISSOC). If I just try to open the mxd with ArcMap, the app just disappears. So now I’m thinking it’s something with the file being corrupted (works fine as a normal user, but who knows). So I try to create a fresh new map - I fire up ArcMap as ArcGISSOC, connect to a layer, and save the file. When the save finishes, I get this helpful message

Apparently no error occurred. Thanks ArcMap, but I’m still somewhat suspicious about that.

Turns out that the error is related to security. I’m working on a client’s system, that’s really locked down, and instead of trying a 1000 little things to see if it was security related, I took out the big hammer – I added ArcGISSOC to the local admin group. Shazam – we got maps! Now that I know it’s permission based, I need to dig out the Admin guide again and review exactly what’s needed

This morning Vish sent me a link to a video of the Microsoft Patterns & Practices team space at Microsoft. I checked it out over lunch, and besides showing off some really sweet developer digs, Peter Provost & Ed Jezieski talk about how the whole Patterns & Practices team uses agile methodologies. They also mention that the Team System Database Professional team is using Scrum to build their project, and that more and more product teams are “dropping by” to see how agile is working for them. Given that this video is over a year old (posted on Oct 5th 2006), it would seem that Agile has been making serious inroads at Microsoft.

Organizations the size of Microsoft have a lot of inertia, and things don’t change easily. But if Microsoft can see the value and adapt, what can possibly be holding other groups back? If you are not using Agile – why not?

Getting started is pretty simple – the hardest thing is deciding to start. As for what you need – lots of teams run almost entirely on 3 by 5 index cards, with a little Excel used to make burn-down charts. Of course once you get rolling, using some software to track everything simplifies things (in my opinion), but it’s certainly not needed to get started. Once you show the benefit to the organization, I think you’ll find that funding for Agile tools is pretty easy to come by.

Today I had to try and figure out why I could not publish a map file to ArcGIS Server. The message I got was

“Server Object instance creation failed on machine foomachine. Document D:\arcgisserver\maps\mymap.mxd can not be opened.”

When I checked the permissions on the file all looked good – the ArcGISSOC user had access to the file. So where’s the beef?

Instead of messing around in the security settings for hours on end, I simply fired up ArcMap as the ArcGISSOC user. It’s easy to do – just drop this into a batch file, and you’re off and running…

runas /user:youdomain\arcgissoc /profile /savecred “C:\Program Files\ArcGIS\Bin\ArcMap.exe”

Then, try to browse to the file in question and open it. In my case, the problem was ArcGISSOC could not access the D: drive, which seemed to override the explicit permission I granted on that file.

I wanted to raise the coverage numbers noted in my last posting, so I jumped onto the code, looked at the coverage, and realized that I needed another test. I added this is, and my coverage jumped from 35% to ~70%. Good I thought – and went to look at the coverage output to see what other corner case I had not covered.

What I saw was very interesting. All the code was highlighted  as being run. Wha?

The SecurityManager.CanUserEditObject method basically does 3 levels of security checks - it checks the layer’s “default policy”, a layer-wide editor role, and finally a per-user, per-feature policy. Thus, the code is structured around 3 nested select blocks… (simplified example below)

What was interesting was that by directly returning from inside the case statements was causing the code coverage numbers to be lower than you would expect. Since this is a bit of a code-smell, I refactored the code to only have one return statement at the end. That alone got me 10% more coverage – no more actual code was run, but the coverage algorithm liked it better. Below is an image of the code-coverage highlighting.

Even at this point, the Visual Studio code coverage tool is reporting only 87.5% coverage for this block.

Anyhow – the take home here is that the code coverage algorithms are fickle, and even though you tests hit all the code, you may not get 100%.

In response to my last post on Refactoring and Unit Testing, Morten posted a comment with some very good questions…

1. Should you really have multiple test assertions in the same test? (I know is convenient to do, but also very messy from a test driven development perspective).
2. What is the code coverage of the unit tests.

Instead of just answering in comments, I thought I’d provide some more information as a separate post.

Multiple Assertions in a Test

It’s true that this is a bit of a code-smell, but I view this as an acceptable trade-off between making tests easy to author (ergo you actually write and maintain them), and “best practices”. As long as the asserts have good messages, what you get back is informative. Given that the class I’m focusing most of this testing on is a singleton, running multiple tests in a row is  realistic in terms of run-time usage.

Code Coverage

I had not setup code coverage when I wrote the original post. After setting that up, here’s what I found:

At first glance, 73% is not bad coverage. But let’s look at the class model for the SecurityManager class.

Looking at the ISecurityManager interface, we can see that the most critical method is CanUserEditObject, and it’s only at 35% coverage! It’s good to know that the private methods have high coverage numbers – 100%, 94% and 72%, but the actual method that is used by the client objects still has a ways to go in terms of good coverage.

When authoring the tests, my gut feel was that I had pretty good coverage – certainly shows the value of running coverage! I’m going to add more tests to up the coverage on this method, and I’ll be posting more about how I created the tests later this week.

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 have to admit that when I first saw twitter, I had a few thoughts, more or less in this order:

1. This is stupid and a waste of time
2. This is IRC “2.0″ with mobile support
3. The txtmsg kids are gonna love this
4. I wish I had thought of it

Given that I had not thought of it, I’ve never been into IRC, and I’m not a txtr, I pretty much ignored it. Until this week… 

Background

Over the last week, I read Ship It! A Practical Guide to Successful Software Projects. I highly recommend this book to anyone who is involved with software development, as it is a quick read and hits on a number of great Agile ideas without espousing any formal methodology (i.e. Scrum). One practice that was new to me is sending out “Code Change Notifications” – simple summaries of what changes have been checked into the source control.

My initial gut feel was that it would be a waste of time, but their anecdote made me re-consider. In this anecdote, a couple developers on a distributed team have spent a day or so working on improving the performance of some section of code. When they have tweaked the code as much as they can, they check in their code, and send out a notification to the entire team. Another developer on the team, in another location, reads the notification. It turns out that this person has a background in high-performance algorithms, and is able to quickly review the code change, and re-work it for a 10 fold increase in performance.

Setting aside the fact that there is some misapplication of resources on this team, if the notification had not been sent out, the opportunity for this substantial improvement would not have occurred. Sending out the notifications basically pings the collective experience of the team. Most times little will come of it, and as long as the opportunity cost for sending out the notification is low (i.e. automated as part of the code check-in process), and it’s quick to read, this still nets out positive if there is some occasional input.

Twitter in the Mix

Taken in this light, I now see twitter as a platform for real-time pinging the collective experience of a community. If someone fires out a “tech tweet” about what they are working on, maybe one person who just worked on something similar sees it and fires back an idea that changes your entire outlook on the problem. At the very least it’s worth a try.

Since someone has to start this off, so as of Monday, I started simply sending out quick tweets relating to what I’m working on at any given time. This will be only technical stuff – no off-topic minutiae. If you want to follow along, you can view the feed here http://twitter.com/dbouwman, or sign up with Twitter, and have tweets sent to your IM or Phone.

Obviously there are scalability issues here – I don’t want to get 1000 tweets a day, nor would anyone else, but that problem is quite a ways into the future. For now, let’s see if this is useful

We put a lot of business logic into Class Extensions tied in on the OnCreate, OnChange, and OnDelete Object Class Extension events. If an edit violates business logic, it is rolled back and the user is informed about what was wrong. This has been working quite smoothly until today when we started creating our Object Inspectors (see previous post).

What we found was that attribute edits done through our Object Inspector (and consequently ArcDAL) were not respecting the business logic. I dropped some breakpoints into the OnChange event in one of the class extensions, and found that it was not hit when we saved changes in the Object Inspector. Yet, when I opened the table editor I would see the changes, so I knew something was happening. Here’s the series of events graphically…

1) Original values in Object Inspector…

2) District Name updated and saved

3) Table editor shows the updated name, but OnChange event never fired!

4) When I try to edit the District Name via the table editor…

the OnChange event does fire, and the edit is rolled back because I do not have edit rights to that feature.

We traced it back to using update cursors. Turns out that updating features via FeatureClass.Update in an edit session does not store changes to the base table until the edit session is saved. Thus, the ObjectClassExtension events do not fire until you “save” the edits and end the session. We need these events to fire as the edits occur so the user is informed when business rules are broken.

The solution was to just change back to using IFeature.Store – which correctly raises the events. This was just 4 simple edits, but we have 25 feature classes in our geodatabase model. Thanks to code-generation, we just made the edits in the templates, and re-generated all the classes.