Corruption and Salvation · 8 June, 06:09 AM

Phil Windley related today some lessons learned the hard way. I’ve been a big believer in his first point for a long time. There was marketing slogan for MFC back in the mid 90’s: “You are not a machine, so stop repeating yourself”. I used to keep that hung up on my wall. This was before I read the Gang of Four, before I read Refactoring, and I’ve learned that it carries over into all kinds of activities. With respect to operations, an absolute minimum is to write down everything you need to bring a new server online, starting from a clean disk. Once you’ve done that, automating the process is the next logical step, and then Phil’s other points are logical extensions of that. Maintaining a server image and managing your servers through virtual slices is just another automation step, and once you have more than one server, you have to think about load balancing.

There’s an interesting comment on Phil’s post though:

..on systems that were manned-flight rated, they always worked in pairs with one person proofing what the other admin was doing before pressing the “enter” key.

That’s kind of an interesting concept: pair administration. Funny how these Agile principles keep showing up.

— Gordon Weakliem

Comment

---

Process, In Context · 2 June, 08:15 AM

Is all this Success Actually Failure? Ron Jeffries observes (or rather, concurs with the observation) that “75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.” This is the Eighty-Twenty Solution, where we (in the “royal We” sense) live and die by the Pareto Principle, so I’ll offer the observation that whatever it is you’re doing, chances are that you’re failing at it. It’s just the nature of things.

What’s apparent is that succeeding isn’t nearly so important as learning how to succeed. Success is a function of at least three variables: a good idea, good execution, and a considerable amount of luck. It’s unclear and will likely always be unclear how to optimize this function. We create processes as an attempt to formulate a function for success, but I can easily identify several companies that no doubt use excellent processes yet produce products that are positively awful; and conversely, I can identify companies that should be worst case stories in terms of process, yet are stupefyingly successful.

The conclusion of this is that, in terms of success, rules are worthless without goals. Nobody sets out to create a terrible product, yet it happens all too frequently. The problem is that we want to formalize the process of creation while ignoring the greater precondition of inspiration. It reminds me of a lesson from a guitar teacher a long time ago. To paraphrase: “technique is like manure… it helps to spread it around, as opposed to putting it on display”.

— Gordon Weakliem

Comment

---

XSD Validation in .NET · 1 June, 12:30 PM

It seems like there’s more than one way to do XSD validation in .NET, but only one correct way. Here’s two versions of a chunk of code that does XSD validation on a sitemap file; #define DOCVALIDATE to switch:


#define DOCVALIDATE

using System;

using System.Xml;

using System.IO;

using System.Xml.Schema;


	
namespace XSDValidator

{
   class Program
   {
      static void Main(string[] args)
      {
         Stream xsdStream = File.OpenRead(args1);
         XmlDocument sitemapDoc = new XmlDocument();
         Stream ms = File.OpenRead(args0);
#if DOCVALIDATE
         XmlSchema xsd = XmlSchema.Read(xsdStream, new System.Xml.Schema.ValidationEventHandler(OnValidate));
         sitemapDoc.Schemas.Add(xsd);
         sitemapDoc.Load(ms);
         sitemapDoc.Validate(OnValidate);
#else
         XmlReaderSettings settings = new XmlReaderSettings();
         settings.ValidationType = ValidationType.Schema;
         settings.Schemas.Add(“http://www.google.com/schemas/sitemap/0.84”,
            XmlReader.Create(xsdStream)
         );
         XmlReader reader = XmlReader.Create(ms, settings);
         sitemapDoc.Load(reader);
#endif
      }


      private static void OnValidate(object sender, ValidationEventArgs args)
      {
         Console.WriteLine(args.Message);
      }
   }
}

Going just on the available documents I initially thought it was a simple matter of loading the schema, adding it to the XmlDocument.Schemas collection, and then loading the document, thinking that the ValidationEventHandler handed to XmlSchema.Read would report the errors. It turns out that that particular event handler will only report parse errors on the Schema document itself; you need to call XmlDocument.Validate to actually perform the validation on the document. The second method is a bit less flexible since it requires you to know the targetNamespace a priori, but that specificity could be a good thing; it’s probably better to restrict your options if you’re doing validation as a critical function, as opposed to a generic service.

— Gordon Weakliem

---

If You're Lost, Don't Take Me With You · 30 May, 03:06 PM

I logged into Rally today and was greeted with a popup that informed me of a seemingly trivial update to the application:

Essentially, the change is that they renamed some tabs. What’s wrong with that?

Two things:

  1. It’s confusing to the existing users. I’ve used Rally for about 3 years now and I’ve gotten used to the terms they use – confusing or not, I know where to go look for “defects”. Fortunately, they didn’t move the tabs, so I don’t actually read the tabs anymore.
  1. Rally is supposed to be for managing Scrum. Scrum literature employs terms like “Backlog” and “Tests”, so someone who’s trained in Scrum sees those terms and they have meaning. Now, maybe the new terms have more meaning to someone who doesn’t know Scrum, but is that the point? To reach untrained users? One of the key points you hear from people like Ron Jeffries is that Agile requires you to change – if you feel like your existing process doesn’t work, you need to learn something new.

At the bottom of it all, it’s not really about a few words. It’s about the thinking behind the words. Why the change? Were that many people confused by the use of standard terminology that Rally felt compelled to change; yet Rally felt that the change itself was confusing enough to merit calling attention to it? Or was this just a judgment call by some Customer Representative at Rally? Either way, it’s not good.

— Gordon Weakliem

Comment [1]

---

Setting up IIS in PowerShell · 23 April, 01:56 PM

I work on multiple branches of the same code base, which is simple enough to handle, except for handling websites in IIS. I could run separate copies of the code on different ports, but that makes me have to remember what port corresponds to what branch, and the procedure to re-root IIS is simple enough -it’s just tedious. A bit of searching revealed that Power Shell is capable of modifying the IIS metabase via ADSI or WMI. The only difficult thing is getting the new config to stick – for some odd reason, I have to make the change twice to make it stick. Anyway, here’s the code that I use to change the path for an IIS VDir – in principle, it’d be easy to extend this to do things like create an application or set security on the site.

function moveIISRoot([string] $site_name, [string]$topath)
{
        # look for a site with display name = $site_name
	write-host "Re-rooting $site_name at $topath"
	$siteroot  = get-wmiobject IIsWebServerSetting -namespace "root\MicrosoftIISv2"  | Where-Object {$_.ServerComment -eq $site_name} | Select-Object Name
	$objIIS = new-object System.DirectoryServices.DirectoryEntry("IIS://localhost/" + $siteroot.Name + "/Root")

# I don’t know why, but you have to do this twice to get it to stick $objIIS.Put(“Path”,$topath) $objIIS.PSBase.CommitChanges() #write-host “Done once: “, $objIIS.Path

$objIIS.Put(“Path”,$topath) $objIIS.PSBase.CommitChanges() #write-host “Done twice “, $objIIS.Path
}

— Gordon Weakliem

Comment

---

Older