Embrace Fear

I used to be scared of databases.

They’re the closest thing to a black box that I deal with on a daily basis.

Cryptic messags point to mal-formed queries; Debugging consists of <pre>PRINT</pre> statements; and learning the inner workings is akin to learning another computer architecture.

Databases were foreign animals to me. I open up a box to another world; another construct; and quite like the Matrix: I have no idea how it works.

There was my problem. Right there. In bold, even.

I wasn’t particularly proud of this fact.

If you’re a professional software developr, you’re probably on the wrong end of the database-skill curve; I know I [still] am.

For developers, SQL and Databases are a tool. We’d use XML and XSLT if it were more performant.  There’s an entire industry that uses Object Relational Mapping to get around SQL and Databases. But the problem isn’t with ORMs, it’s when we use them because we fear the unknown.

Verily I say unto you:

Embrace this fear. Let it work for you.

Without it, we’d blindly write queries; we may not parameterize variable input; and we might do something stupid, like mis-sizing a database field.

When you aren’t afraid of the unknown anymore, it’s time to question why. That fear is healthy; ignoring it isn’t.

Configuration Pain – Creating your own Custom Configuration Section

 

Recently I was asked to implement a ‘smarter’ application for managing temporary files on our company’s webfarm. We use a number of third-party tools that don’t clean up after themselves  really well (or, we may just be using them incorrectly); and as such we frequently run into low diskspace issues due to viewstate and other third party utilies not being cleaned up.

Goal: Build an application that can be configured by the end user to delete directories and files as needed (like viewstate, activePDF temp files) and run as a scheduled task. Any logging should be done to the Windows event log.

There are a number of methods that could be used to enable the user to set up their configuration options, but in keeping with the .NET model for configuration, I picked using XML and the app.config to store the settings using a custom configuration section.

I ran into an issue  during the course of development because I had the wrong XML layout. I used the following method:

<folder>
     <path>D:MyPathmyFolder</path>
     <description>MyDescriptionhere</description>
     <fileType>*.txt</fileType>
</folder>

instead of:

<folders>
     <folder id=”1″ path=”D:MyPathmyFolder” description=”MyDescriptionhere” fileType=”*.txt” />
</folders>

This creates a problem because of how .NET handles custom sections. It apparently doesn’t like the syntax of the former, and instead of implementing code to serialize it and de-serialize it myself, I chose to stick with implementing the configuration API as written.  I had that choice, since I was implementing a new ‘feature’; and if you’re maintaining a legacy project, you may not have that luxury. 

Once you know the format your XML will take, it’s a simple matter of creating the custom configuration section C# classes. The first class that is going to be created is a class that is the actual Custom Configuration section.  Classes also need to be created for each collection of XML items (the list of folders in the <folders>, and a class needs to be made for each element and its properties (the folder element and the path, description, and fileType properties.

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Configuration;

namespace DelViewState_CS
{
    public class DelViewStateConfigSettings : ConfigurationSection
    {
        public DelViewStateConfigSettings()
        {
            
        }
                       
        [ConfigurationProperty(“folders”, IsDefaultCollection = true)]
        public FoldersCollection Folders
        {
            get { return (FoldersCollection)base[“folders”]; }
        }
        
        [ConfigurationProperty(“timeout”, IsRequired = true)]
        public int Timeout
        {
            get { return (int)base[“timeout”]; }
            set { base[“timeout”] = value; }
        }
       
    }

}

 

The configuration section has two properties, the timeout property (a poorly named legacy property that indicates how long it’s been since the file was accessed), and a folderscollection property that will contain the individual folders and their properties.

Here is the C# code for the folderscollection class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Configuration;
namespace DelViewState_CS
{
    public sealed class FoldersCollection : ConfigurationElementCollection
    {
        protected override ConfigurationElement CreateNewElement()
        {
            return new FoldersElement();
        }
        protected override object GetElementKey(ConfigurationElement element) 
        {
            return ((FoldersElement)element).Id;
        }
        public override ConfigurationElementCollectionType CollectionType
        {
            get
            { return ConfigurationElementCollectionType.BasicMap;  }
        }
        protected override string ElementName
        {
            get
            { return “folder”;  }
        }

        public FoldersElement this[int index]
        {
            get { return (FoldersElement)BaseGet(index); }
            set
            {
                if (BaseGet(index) != null)
                {
                    BaseRemoveAt(index);
                }
                BaseAdd(index, value);
            }

        }

        new public FoldersElement this[string Path]
        {
            get { return (FoldersElement)BaseGet(Path); }
        }

        public bool ContainsKey(string key)
        {
            bool result = false;
            object[] keys = BaseGetAllKeys();
            foreach (object obj in keys)
            {
                if ((string)obj == key)
                {
                    result = true;
                    break;
                }
            }
            return result;
        }
    }
}

The final class we have to write is the folder element itself.  This contains the necessary properties of the folder element:

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Configuration;
namespace DelViewState_CS
{
    public sealed class FoldersElement : ConfigurationElement
    {
        [ConfigurationProperty(“id”, IsRequired=true, IsKey=true)]
        public int Id
        {
            get {return (int)base[“id”]; }
            set { base[“id”] = value; }
        }
        [ConfigurationProperty(“path”, IsRequired = true)]
        public string Path
        {
            get { return (string)base[“path”]; }
            set { base[“path”] = value; }
        }

        [ConfigurationProperty(“description”, IsRequired = false)]
        public string Description
        {
            get { return (string)base[“description”]; }
            set { base[“description”] = value; }
        }

        [ConfigurationProperty(“fileType”, IsRequired = false)]
        public string FileType
        {
            get { return (string)base[“fileType”]; }
            set { base[“fileType”] = value; }
        }
        
    }
}

Once all of that is written, it’s a simple matter of accessing the custom section and reading these properties (and in my case, deleting the files associated with them. Accessing the custom configuration section is as simple as creating a static factory method in the customconfigurationsection.cs file:

public static DelViewStateConfigSettings GetDelViewStateConfigSettingsSection()
        {
            DelViewStateConfigSettings cs;
            System.Configuration.Configuration config = System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.None) as System.Configuration.Configuration;
            cs = config.GetSection(“delViewStateConfigSettingsGroup/delViewStateConfigSettings”as DelViewStateConfigSettings;
            return cs;
        }

 

There are plenty of methods for writing to the event log, but I followed the guidelines laid out here.

In the end, it took a little over a week from the time that I first learned about the task to the time it was completed (testing, checkin, cleanup).  There are a number of ways it could be made better:

  • Using delegates and anonymous methods to shorten the written code that deletes the files and writes to the event log
  • Pull the custom section into its own XML file that is referenced int he app.config; to allow for drag and drop placement.
  • Checking the files for being ‘locked’ (which happens sometimes) and working around that.  For the time being, I’m logging those happenings to the event log so I can find out why they’re happening and fix the actual problem

There are more improvements to come, in the next blog post on this topic, I’ll talk about enhancing this utility by getting it to scope out IIS Virtual directories and auto-filling that information in.

Who let the Comments out?

There are a multitude of blog posts out there that detail when you should and should not comment, but Jeff Atwood of Coding Horror puts it best:

Code can only tell you how the program works; comments can tell you why it works. Try not to shortchange your fellow developers in either area.

We’ve all heard of tales of college students whose professors required that they extensively document their code; sometimes at risk of a letter grade.

Once upon a time, in a land not so far away, a diligent young computer science student sat eagerly attentive in her C++ programming class. Her formidable instructor was droning on and on about how Programming Comments were the basis of all that is good in the world of software design. Then at last, those famous words, “If you do not comment your code, you will automatically drop one (1) letter grade.”

Academia is one thing, but what about programming texts? Shouldn’t they advocate the sane way of commenting code?

I wish.

I pulled open my old C++ book today, just to get a refresher on function pointers and things I’d forgotten (since C# makes use of function pointers in anonymous methods and lambda expressions), and happened to open up to the page on comments.

There were no less than eight bullet points on commenting code.  From Structured & Object-Oriented Problem Solving using C++, Third Edition by Andrew C. Staugaard:

 

Debugging Tip

Programming Comments are an important part of the program documentation and should be used liberally (emphasis mine).  […] At a minimum, the program should include the following comments:

  • The beginning of the program should be commented with the programmer’s name, date the program was written, date the program was last revised, and the name of the person doing the revision.
  • The beginning of the program should be commented to explain the purpose of the program, which includes the problem definition and program algorithms.  This provides an overall perspective by which anyone, including you, can begin debugging or maintaining the program.
  • Preprocessor directives should be commented as to their purpose.
  • Constant and variable definitions should be commented as to their purpose.
  • Major sections of the program should be commented to explin the overall purpose of the respective section.
  • Individual program lines should be commented when the purpose of the code is not obvious relative to the application.
  • All major subprograms (functions in C++) should be commented just like the main program function.
  • The end of each program block (right curly brace) should be commented to indicate what the brace is ending.

Well, at least he’s thorough.  Some of the advice is sage; and other parts of the advice are just downright redundant in the real world, if you’re using source control and an anything but notepad.

So here’s my revised list — directed at that very same college student who is stuck reading that text.

 

Debugging Tip

Program Comments are an important part of the program documentation and should be used to help any programmer understand what is happening.   […] Use the following guidelines for guidance:

  • The beginning of the program should be commented with the programmer’s name, date the program was written, date the program was last revised, and the name of the person doing the revision.
  • The beginning of the program should be commented to explain the purpose of the program, which includes the problem definition and program algorithms.  This provides an overall perspective by which anyone, including you, can begin debugging or maintaining the program.
  • Preprocessor directives should be commented as to their purpose, and directives should not change the meaning of reserved words.
  • Constant and Variable definitions should have a clear name that explains their purpose, so comments aren’t necessary.
  • Major sections of the program should be commented to explain the overall purpose of the respective section when its purpose isn’t reasonbly clear.
  • All major subprograms (functions in C++) should be commented just like the main program function.
  • The end of each program block (right curly brace) should be commented to indicate what the brace is ending.
  • Write code that explains itself. Comments should only be used to tell someone WHY you did something, not what you did. That’s what code is for.

Instead of using the beginning of the textbook to discuss basics that any CS101 book should cover, I’d use it to cover source control, and the integral part it plays in keeping track of code changes — something that the author wanted the bullet points to do, but which don’t make sense in modern source control systems.

If you have new developers on your team, do them (and yourself) a favor and point them to one of the references I mentioned. Friends don’t let friends comment liberally!

NB: These ideas aren’t original to me; I got them from reading Coding Horror and reading Code Complete.

 

The Cost of OpenID

I was chatting with a friend today about implementing OpenID for a possible startup idea, and we talked about the cost of OpenID vs its benefits.

The conclusion of the chat was that if you’re a bootstrapped startup, it almost never makes sense to spend the time and money implementing an authentication system.

Don’t take my word for it, look at the numbers.

Let’s say the average Software developer in your area makes just $65,000 a year (or $34 per hour)*. If they build their own authenication system from the ground up, you could look at between 80 and 120 hours worth of time spent on it (given a 60% productivity rate, that comes out to 72 hours spent on the project, or $4080 spent on programming this one part of the system.  That’s a conservative estimate.  There are many ways to do authentication; and everyone gets it wrong sometimes.

What’s the cost of implementing OpenID? 5 hours worth of initial work and $500 at most? If you went with the ‘Plus’ option, it’s only $100 per year — that’s a savings of almost $3800!

That’s $3800 that could be used for far more important things than building an authentication system, and it’s one less part of the system you have to maintain in the future — which represents an immeasurable cost savings towards other projects.

In most cases, the cost doesn’t justify the benefit of rolling your own system. Let someone else take care of it.

No Aliases in Where Clauses

I was bit by the ‘No Aliases allowed in Where Clauses’.  It also explained Linq-to-SQL’s seemingly strange syntax at the same time.

The SQL Order of Operations isn’t as its written by developers, but the other way around.

  1. FROM clause
  2. WHERE clause
  3. GROUP BY clause
  4. HAVING clause
  5. SELECT clause
  6. ORDER BY clause

 

So, when you have an aliased column, it can’t use that in the WHERE Clause because it hasn’t been told what that means yet.  So what happens when you want to use the Aliased column in the Where Clause?

There’s a Hack you can use:

Wrap the entire statement (or that line, as applicable) with a SELECT statement that contains the WHERE Clause you want to alias.

For instance:

select * from ( select a + b as aliased_column from table ) dt where dt.aliased_column = whateveryouputhere.

It does it rather nicely. You can find the question and answer (not mine) on Stack Overflow.