On The Other Hand

I was debugging a customer issue in QGPM today and came across the strangest problem. Part of the issue involved using a service account with minimum permissions, so I duly followed the steps to set this up.  This is something I should do more of, as you will soon see.

Once I finished setting up the service account, I tried to reproduce the customer issue, but kept getting an error from the GPMC API’s that we use internally to back up GPO’s.  Something about a null reference exception.  I started up GPMC using the runas command to run it under my service account credentials.  Sure enough, I was unable to back up the working copy GPO that I had just created.  I kept getting an "invalid pointer" error from GPMC.  However, other GPO’s backed up just fine.

Certain I had made some kind of permissioning error, I carefully retraced my steps.  Nothing I tried helped.  Finally I turned to Google and all my questions were answered.  I never would have figured it out on my own in a million years.

I like to use short account names in my testing domain.  For my service account, I had used the name "sa".  Seemed perfectly logical at the time.

When the QGPM service created the working copy GPO, the service account was naturally added to the access control list (ACL) for this GPO.  When GPMC backs up the GPO, it backs up the ACL in a format called SDDL, which is essentially a string representation of the ACL.

It turns out, there is a list of two letter abbreviations that are used in SDDL to represent the well known groups in any Windows domain.  You guessed it.  "SA" is the abbreviation for the Schema Admins group.  Any software that uses SDDL internally can potentially break if you have a two letter account name on that list.

Like I said, I never would have figured it out on my own.  Thanks, Google!

Back in the old days, it was extremely common to buy software that just had a plain old version number.  You know, "Windows 3.1", "WordPerfect 5", etc.  If you got your hands on a beta copy of a piece of software it meant you were usually a highly-valued customer, a paid tester, or your brother-in-law worked for the company.

These days, regular version numbers are a rarity.  Everything’s beta this and beta that.  Seems nobody really knows what those designations mean anymore.  If they do know what they mean, the formal definitions are thrown out in favour of the perceived marketing advantages of seeming more "Web 2.0."  Sometimes I wish we could go back to the old days, when these things still meant something.

Alpha

Alpha used to mean the first draft.  An alpha release usually had big swaths of functionality missing.  Placeholders instead of features.  It might crash your machine.  It might not do anything useful.  It might steal your cows and your daughters.  It was meant largely as a proof of concept, to get feedback on the general direction on the features for the next release of the software.  This is a great time to let the programmers know when they have completely missed the boat, because there’s still plenty of time to make substantial changes.

Beta

Beta, to me, means feature complete.  A beta doesn’t indicate any particular level of quality.  It does mean that the placeholders have been replaced with features and, assuming it doesn’t crash, you can do everything with the beta that you will be able to do in the final release.  It’s missing help files and polish.  You’d be silly to run it in production because it may very well destroy your data.  But it is feature complete.  If the feature is not in the beta, it won’t be in the production system.

Release Candidate (RC)

This designation ought to be the easiest to understand, as it’s the first one that’s not a Greek letter.  The release candidate should be just that.  Except for the version number and the license agreement, this is finished software.  It has passed all of the internal quality bars and the development team considers it ready for production use.  This stage is a final check to see if anything has been missed, quality-wise.  If nothing is found, you change the license agreement and version number and ship the product.

I haven’t written here and months and months. I don’t have an excuse for most of it, but at the beginning of this month, I finally broke down and bought my first home — a small condo in the south end of Halifax.

There’s plenty of work left to do — furniture, baseboards, art, the kitchen (!!!).  Nonetheless, today was move-in day and, I thought I’d post some before and after shots.  The before shots were taken on the first day I came to view the place.  The after shots were taken tonight.  It’s been a long road.

Living Room - Before

Living Room - After

Bathroom - Before

Bathroom - After

I just bought a new Canon Powershot A570IS.  One of the great things about it is that it has full manual control.  I was walking home tonight and took a couple of shots that, I think, show just how valuable that is - even to a photo newbie like me.  Both photos have been resized for your downloading pleasure but are otherwise straight out of the camera.

Here it is with full automatic point and shoot mode…

And here it is with some manual adjustments…

Well, it may as well have been.

Just got back from Steve’s birthday party.  Time to have a quick beer and venture out to see if there are any good bands playing in this town tonight.

On my product team we have been using the SCRUM methodology of software development for a while.  For those of you not familiar with it, here is the oversimplified version…

• Get a big list of all the things you want to do, prioritized by our customers (in our case by proxy via our product manager)
• Estimate how many things you can get done in your team’s sprint interval (usually anywhere from two to four weeks, a team’s interval length never changes)
• Do them
• Show them to the customer
• Lather, rinse, repeat

Of course it’s a little more complex than that, but you get the idea.  From a developer’s point of view, this is fantastic and predictable way of developing software.  It’s easy to release working software on a regular basis.  There is very little risk you will end up developing something the customer doesn’t want, and if they do change their minds (and they will) you don’t waste very much time.

One of the great things about working at Quest is that we develop software and sell it to customers - and that’s pretty much all we do.  We’re reasonably good at it and our management team has a realistic understanding of how it works. Within reason, trading a feature for a release date is always an option. So long as we continue to satisfy our customers we will always have another version coming along soon.

On the other hand, many (most?) developers do not have this sort of luxury.  Whether working for internal customers in an organization’s IT department or external customers on contract, traditional project management requires prediction of the costs and efforts involved in an entire project, usually before the scope of the project is fully known. Getting non-software project managers to buy into a process like SCRUM is incredibly difficult. With government or defence contracts it may be impossible or illegal. This is probably the single biggest disconnect in the business of developing software. During my years as a contract developer I spent many sleepless nights worrying about it.  Talking to folks at CanHEIT this week it seems it’s still just as much a problem as ever.

I count myself very lucky.

One of the other tracks I have been following at CanHEIT is on identity management.  At Quest we care about this quite a bit.  Our customers have obvious concerns about security and compliance, as well as significant costs associated with customer, employee, and partner identity.

It probably shouldn’t have surprised me that our institutions of higher learning have significant challenges in this area as well. Each year a large proportion of their student body turns over. Some of them may come back later for more courses.  Some may transition to alumni or faculty. Many students take courses at partner institutions, for which credit is granted at their home institution.  Finally, universities tend to have extremely heterogeneous computing environments, even more so than industry.

All in all, a fascinating look at a diverse set of challenges I wouldn’t normally see in my day-to-day routine.  They will call for a robust set of tools and standards to meet the needs of federation and user-centric identity in a platform-agnostic world.  Despite years of work on directory services and single-sign-on, there are still many questions to answer. It’s a very exciting and rapidly evolving problem space.

Many thanks to Jens Haeusser from the University of British Columbia for an informative and enjoyable presentation.

I went to see Tim Bray talk at CanHEIT this morning.  I really enjoyed the talk, though I missed the first two or three minutes as he seems to have started fifteen minutes before his scheduled time.  I’ve never had a chance to see him speak before and I was not disappointed.  I’ll try to hit the high points, though I’m sure I’ll miss some stuff.

The talk was, more or less, a survey of the state of web application development from his point of view.  He talked about the rise of Ruby/Rails and how Java/C#/etc., seem to have levelled off in terms of growth.  He spent quite a bit of time talking about the aspects of web app development that he considers to be most important in terms of being able to successfully scale up and out.  From his point of view, some of the high points are…

• Time to market - doesn’t matter if your app is slightly better if I already have all the users by the time you ship. This, of course, is why Rails is so hugely popular.
• Observability - if you are successful, you will inevitably run into scaling issues at some point and you’re going to need to peer in and see what’s going on.  Sun has been doing a lot of work on this front in Solaris with their dTrace stuff.
• Shared-nothing-architecture - Tim said PHP really pushed this as it was the first framework that, by default, was shared nothing.  I can’t comment as my PHP experience came long after my experience in the Microsoft web app world in the late ’90s and, by that time, I’d learned this lesson the hard way.  Speaking of which, the next iteration of my product’s service is nearly shared-nothing (save the database) and the thing just screams in comparison to the previous stateful design.

One side point that he made was that testing is still an unsolved problem.  In his opinion, we are headed in the right direction but we still have a long way to go in terms of this aspect of software development in comparison to other aspects.  As someone who struggles with this on a regular basis I couldn’t agree more.  I wish there had been more time to discuss this.

During a break and also during lunch I had some opportunities to speak to other conference attendees about the talk and reactions were mixed.  A large proportion of the folks in attendance are not software developers and the general consensus is that they just didn’t get it.  One of the problems with being a big shot like Tim is that you get the big timeslot in the morning where they don’t schedule anything else and everyone goes to the same talk.  I think it might have been more effective if there had been a competing talk for the IT management types to go to.  Or maybe they just didn’t try hard enough to understand what they were seeing.  Or something.

The other feedback I got was that people were a little afraid that Tim’s worldview is a little biased.  Surely he pushed Java/Ruby (Sun, after all, was sponsoring the talk), but I think it is ironic that folks thought of him as a mouthpiece for a vendor.  This guy has done more for cross-platform interop than almost anyone out there (hellooo, XML anyone???).  Some of this was also coming from his strong belief in REST, which I completely agree with.  Unfortunately, I think the rank and file are a bit behind the curve on this one.  In fact, I don’t personally know that many folks that have spent any time thinking about scaling in the same way as Tim et al., let alone REST.  The official-speak coming out from the vendors has been WS-* for a long time and many folks still believe it.

After the talk I had a quick chat with Tim where we talked about Atom and blogging clients.  I mentioned that I use Windows Live Writer which (soon, hopefully) will be a proper APP client.  He mentioned that at the recent Atompub Interop event at Google, the scripting guys would break, change a bit of code, and try again, while the Microsoft guys would break, change a bit of code, recompile the world, and try again.  I often wonder how much this compilation tax slows us down.