Brian Hartsock's Blog

Joel recently posted The Duct Tape Programmer which has received an enormous amount of buzz, both positive and negative. At work, I received emails telling me that the article is a must read, while receiving different emails flaming Joel. If you haven’t read it, I highly encourage you to do so. In short, it is about shipping software above all else.

I have spent the evening catching up on blogs, many of which are just responses to Joel’s, so I felt I should jump on the bandwagon. Instead of writing only my own sentiments, I have included a couple other thoughts from different bloggers to help clarify everything.

Uncle Bob really helped clarify the sentiments of developers.

Now don’t get me wrong. I’m the “Clean Code” guy. I want your code clean. I don’t want you making a mess. On the other hand, I want you to ship. I don’t want you gilding the lilly. I don’t want you wrapped up in endless polishing.

I want you to ship, but I don’t want you to ship shit.

If you think I’m contradicting myself, you’re wrong. There is no contradiction in the notion that you must ship, and that you must be proud of what you ship.

The programmer who spends weeks building the perfect structure does just as much harm to the project as the programmer who hacks a bunch of crap together. Neither have struck the balance that’s required.

In short, it’s bad to use too much duct tape. But I’d be suspicious if I didn’t see some duct tape!

While Casey Charlton explains the disconnect between the business and the developer.

Developers and business owners are not aligned in their goals – we prioritise the three factors [time, scope, quality] very differently, and for different reasons.

Only two things can happen here, your developers need to align with their business objectives, or the business needs to align with the developers – or they can both compromise.

Agile is all about the compromise, making both sides aware of the issues involved, and then coming to an agreement, but fundamentally – it is STILL A BUSINESS DECISION.

While it is the responsibility of a professional developer to explain all the problems they see with low quality code, and to make their boss aware of all the potential future issues this may cause, it is also their professional responsibility to go with the decision their boss makes.

As for what I think, it is pretty simple. Shipping software and shipping quality software should be synonymous. It boils down to having great developers capable of great things. Writing tests that speed the team up, not down. Developing architectures that make sense now, not in 30 years. And finally, capable of releasing great software by the deadline.

I always have to Google how to add an XML schema to Visual Studio because I forget the directory (even though it is super easy). Never again will I forget.

function register-vsschemas()
{
	begin
	{
		$schema_folders = gci $env:ProgramFiles -Filter "Microsoft Visual Studio*" | 
							gci -Filter "Xml" | 
							gci -Filter "Schemas"
	}
 
	process
	{
		if(!$_ -or !(Test-Path $_))
		{
			Write-Error "File '$_' not found"
			break;
		}
		if((gi $_).Extension -ine ".xsd")
		{
			Write-Warning "File $_ does not end in an .xsd extension"
		}
 
		foreach($folder in $schema_folders){
			#It is very interesting I had to use .FullName...
			cp $_ $folder.FullName -Verbose
		}
	}
}

Call it as follows:

gi .\lib\NHibernate\*.xsd | register-vsschemas

public class PSDefaultVariablizer<T> where T: class
{
    string variableName;
    T innerValue;
    PSCmdlet cmdlet;
 
    public PSDefaultVariablizer(string _variableName, PSCmdlet _cmdlet)
        : this(_variableName, null, _cmdlet) { }
 
    public PSDefaultVariablizer(string _variableName, T _innerValue, PSCmdlet _cmdlet)
    {
        variableName = _variableName;
        innerValue = _innerValue;
        cmdlet = _cmdlet;
    }
 
    public T Value
    {
        get
        {
            if(innerValue != null)
            {
                return innerValue;
            }
            else
            {
                return (T)cmdlet.SessionState.PSVariable.GetValue(variableName, null);
            }
        }
        set
        {
            innerValue = value;
        }
    }
}

Here is the use case for the class. You have a parameter that a user can input, otherwise it attempts to use a value of a variable in the same scope (think how $ErrorActionPreference works). This class allows you to very simply reuse that functionality.

[Cmdlet("Some", "Command")]
public class SomeCommand : PSCmdlet
{
    private PSDefaultVariablizer<string> someParam;
 
    public SomeCommand ()
    {
        someParam = new PSDefaultVariablizer<string>("SomeParam", this);
    }
 
    [Parameter()]
    public string SomeParam
    {
        get
        {
            return someParam.Value;
        }
        set
        {
            someParam.Value = value;
        }
    }
}

And you would use it from Powershell with the following.

Some-Command -SomeParam 'hello'
#or
$SomeParam = 'hello'
Some-Command

Pretty simple really. I just posted it because I thought the name was hilarious, but I didn’t really know what else to call it.

Let me know if anyone knows of an easier way to this. Unfortunately, there aren’t too many people I can talk to about SnapIn development

Tonight, I installed Visual Studio 2010 beta 1 for the first time. I know I am late to the game, but I had to give it a whirl since I found some free time this afternoon. One feature of .NET 4.0 I wanted to try out was the dynamic keyword with Python scripting. So, here is my first hello world program using dynamic, with the help of this walk-through.

class HelloWorldDemo:
 
    def run(self):
        return "hello world"

Here is the C# code needed to run it. Yes, I used WPF as my driver, but don’t worry about that.

...
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
 
namespace WpfWithPython
{
    public partial class Window1 : Window
    {
        ScriptRuntime py;
        public Window1()
        {
            InitializeComponent();
            py = Python.CreateRuntime();
        }
 
        private void MyBtn_Click(object sender, RoutedEventArgs e)
        {
            //Instantiate an instance of this file?!  Yes, it is weird at first.  
            // All the methods and classes in the file will be members.
            dynamic demo = py.UseFile("HelloWorldDemo.py");
 
            //This is the tricky step.  To create a new object, call it like a member...
            // I think
            dynamic instance = demo.HelloWorldDemo();
            MyText.Text = instance.run();
        }
    }
}

It took me a while to get this little bit of code working unfortunately. If you read the comments, you can see where some of my confusion was found. Overall, it is pretty awesome. I loved LINQ and I am already loving dynamic. There is something new to learn everyday. Maybe F# next…

Unfortunately, I have to say that VS2010, while pretty, is slower than 2008. And, IronPython took nearly 2 or 3 minutes to run some sample code it provided, which is crazy. If the performance problems can be overcome, then I see myself learning more Python and Ruby.

I very rarely hear people talking about SQL injection anymore. Just a few years ago, it was a very common problem that all developers needed to understand, in and out. My guess is, the prevalence of database abstraction layers in all languages have helped remove this problem from most developers minds. Hibernate, ActiveRecord, Zend_DB, and all the other frameworks in nearly every language are used much more than hand-written queries.

The death of SQL injection.

But wait. The principles behind SQL injection are still valid for any and all applications. Yet, I worry many developers don’t understand them, since the grandfather, SQL injection isn’t as prevalent.

SQL injection exploits a core problem, components don’t sanitize their inputs. Components that use this data to communicate with some resource, like a SQL database, are more prone to bad inputs causing serious problems. But databases aren’t the only concern. REST API’s, file systems, and many more resources can have the same security vulnerabilities.

Imagine a REST API, with the following URL structure.

http://rest_service/<username>/<action>

Your application calls the following action from some web form where username is passed in by the user.

http://rest_service/<username>/get

If the username portion of the URL isn’t sanitized before getting passed to the API, your application now allows REST injection.

Some smart hacker then enters in the username:

brian.hartsock/delete?

Now, your application is going to call the following URL, effectively ursurping what your application is intending to do, just get data, and instead delete data.

http://rest_service/brian.hartsock/delete?/modify

The silver lining is REST isn’t standardized, unlike SQL, so it is much harder to reverse engineer a site and figure out what to inject. The premise is still important though, components should sanitize their inputs, especially before sending them to resources like databases, file systems, and APIs.

UPDATE – Even though REST isn’t standardized, this doesn’t mean it isn’t a security hole. Jay had a good point, and I have struck that line from the record.