Jason in a Nutshell

All about programming and whatever else comes to mind

Posts Tagged ‘.Net’

Programming and safe theater or Things you have to do but shouldn’t if you can avoid doing them at any cost

Posted by Jason Baker on May 14, 2009

Joel’s (in?)famous article saying never to rewrite your software seems to be circulating again on Hacker News.  Essentially, what Joel is getting at is that software companies must never, ever under any circumstances rewrite their own software.  I must say that I agree with Joel for the most part.  While I agree with most of  what Joel says, I disagree with the ultimate conclusion that Joel draws from it.

I’m reminded of a scene from Hamlet 2 (which I’m paraphrasing from memory here):

Student:  I was thinking:  what if we had lowriders come across the stage in the final scene?

Mr. Marschz:  That sounds dangerous.

Student:  Ok, nevermind.

Mr. Marschz:  No, I’m not doing safe theater.  Let’s do it!

Joel’s stance is “safe theater” for programmers.  

Risk

Still not convinced?  Does safe theater sound just fine with you?  Willing to quote Joel’s stance on this unwaveringly?  Well, I counter your Spolsky with a Kay!

I believe that the only kind of science computing can be is like the science of bridge building. Somebody has to build the bridges and other people have to tear them down and make better theories, and you have to keep on building bridges. –Alan Kay, quoted from  A Conversation with Alan Kay

Granted, I don’t necessarily agree with Alan 100% either.  I think there’s a happy medium here.  When you get down to it, the risks in rewriting your software that Joel mentions are very real risks.  And several companies have found this out the hard way.

The problem is that you can’t innovate without taking risks, and a software rewrite is the ultimate risk.  Unfortunately for us, we as programmers are in the business of innovation.  Unwillingness to take risks is a sure route to becoming a “greybeard” who only codes COBOL on mainframes because it’s what they know.  I don’t know about you, but that’s not the kind of career that I had envisioned.

So you’re saying I should rewrite, correct?

Remember, when I said that I agree with Joel for the most part, I meant it.  A complete software rewrite is a crazy and maybe even a stupid move.  If you really want to innovate, sometimes you have to do things that are crazy and stupid.  But remember that the decision to completely rewrite a piece of software can be a job-ending or even business-ending move.  So if a blog post by me is enough to convince you to do the rewrite by itself, don’t do it.

Credit where credit is due

In fairness, I don’t think even Joel 100% believes software should never be rewritten.  In a book, he praises Microsoft for writing .net even though it violates his “never rewrite” rule.  Granted, this is because Microsoft is “a center of gravity,” which is something that we can say about very few companies.  

But even though this is a very small exception to Joel’s rule, it’s still enough to say that Joel doesn’t believe his blog post 100%.  But even if he still believes it 99.9%, there’s still 0.1% of leeway.  And never underestimate what a really good programmer can do with that 0.1%.

Posted in Programming | Tagged: , , , , | Leave a Comment »

Java vs C# vs Python vs Ruby: an “objective” analysis

Posted by Jason Baker on April 21, 2009

At my place of employment, we’re looking to migrate some of our old Classic ASP applications to something newer (yes, we still have actively maintained Classic ASP code). So my boss asked me to write up an analysis of the different options we have available.

Now before I give you the link, I have a few disclaimers and other random thoughts:

  • I tried to avoid editorializing so that this can be objective as possible, but it’s impossible to discuss these kinds of issues without being subjective.  Thus, don’t take this as the gospel truth.
  • There may be errors here.  In fact, I can almost guarantee that there are errors with Java and Ruby because I’m not terribly familiar with them.  If there are errors, feel free to leave comments.
  • My boss is a Java guy, so I left some blanks that I’m pretty sure he can fill in.
  • Some of these are blatant oversimplifications.  There’s only so much data that you can squeeze into a spreadsheet.
  • I’ll try and keep up with this for a while, but chances are that I won’t for long.  These languages are all being changed.
  • I’m biased towards Python.

Ok, without further ado, here’s the link:

http://spreadsheets.google.com/pub?key=p7efJLoHuYE-iw6JxBmpSQg&hl=en

Posted in Programming | Tagged: , , , , , , , | 12 Comments »

Enemies of Test Driven Development part II: YAGNI

Posted by Jason Baker on January 11, 2009

Just like in this post’s predecessor, don’t take the title of this post to mean that YAGNI should be abandoned.  YAGNI is still a very good principle that has saved me from writing a lot of crap code.  But many of us are trained to apply it in such a manner that runs counter to Test Driven Development.

Let’s take the following scenario.  I have a wrapper around one of the components of my data model.  The idea is that you insert data into it and then flush it, like so:

wrapper.Insert(some_collection);
wrapper.Flush();

The idea being that as soon as this code is ran, the contents of some_collection will be inserted into a database.  Let’s look at how the Flush method works at the backend:

void Flush()
{
    using (var dc = new SomeDataContext())
    {
        Flush((ISomeDataContext)dc);
    }
}

void Flush(ISomeDataContext dc)
{
    //do stuff with dc
}

Just to clear up any doubts you may have, the latter overload of Flush is not used in the production code anywhere.  I added this in just to make the code more generic.

You are going to need it

For those of you properly trained in the arts of YAGNI, these last two sentances probably set off alarm bells.  But take a look at this code:

class MockDC : ISomeDataContext
{
    public bool MethodCalled {get; set;}
    public void MethodThatMustBeCalledByFlush () {MethodCalled = true;}
}

[TestMethod]
public void TestFlush()
{
    var wrapper = new SomeWrapper();
    wrapper.Insert(stuff);

    var dc = new MockDC();
    wrapper.Flush((ISomeDC)dc);
    Assert.IsTrue(wrapper.MethodCalled);
}

Newbies to Test Driven Development (myself included) tend to find it difficult to write code that serves no purpose other than to enhance testability.  The thing is: code that makes other code more testable is needed.  And the above tests either wouldn’t have been possible or would have been hideously complicated without overloading Flush to be more generic.

So what is YAGNI good for?

Some people feel that TDD has largely subsumed YAGNI.  I can definitely see where they’re coming from.  But I think that YAGNI is still a good basic principle.

YAGNI is much like optimization in that it’s very difficult to apply at a micro-level.  Thus, if you find that you’re not adding necessary methods because of YAGNI, you’re probably using it wrong.  YAGNI is best applied at a high level.

One of my first assignments at my current job was to write a program to transfer some stuff from one database to another.  I thought I would try to go a bit above and beyond the call of duty.  See, my job has a lot of programs like these.  Just think of how much duplicated code must be out there!  Why not write some kind of framework to make this kind of stuff easier and allow code reuse?

The sky was the limit from this point on.  Before too much longer, I had a model that included the pipeline and observer design patterns.  Along with a component model that allowed linking components in all sorts of need ways.  I got about halfway through it.  At a certain point, it just became too difficult to make the .Net type system work with what I was wanting to do.

I eventually just decided to code it the “regular” way without any of that cool stuff.  I finished it within a few days.  Now, a judicious use of YAGNI would have saved me a lot of time here.  So what’s the lesson?  With apologies to Albert Einstein, the lesson is to apply YAGNI as much as possible, but no more.  Once you get a sane approach going, I think you’ll find that YAGNI is a tool that will help your programming rather than hurt it.

Other Posts:

Posted in Programming | Tagged: , , , , , , | 1 Comment »

ETL in Subsonic

Posted by Jason Baker on December 12, 2008

Since my university has migrated to a new registration and enrollment system (based on Oracle), the department I work for has been scrambling to make all of our systems work with it.  So here’s the task:  pull data from the database, and put it in one of our legacy applications’ database (SQL Server).  Sounds simple right?  Well, actually it is.  But it may not be apparent at first glance how a person would go about doing this.

For inserting records into SQL Server, we’re using LINQ to SQL.  It’s just so easy to set up that there’s no reason not to.  Unfortunately, that isn’t the case for dealing with Banner since LINQ to SQL doesn’t natively support Oracle.  There are plugins for this, but I have yet to encounter any that are of high enough quality to be used in a production system.  So my choice for this is SubSonic.

It’s easy to see why at first glance some people feel they have to “drag it around.”  But you can actually do some pretty interesting things with SubSonic if you spend some time and go through their (sub-par IMO) documentation.

Here’s the basic situation.  We need to be able to pull every newly admitted student into our system.  This is broken up into two tables, a person table and an admissions application table.  These can be represented in C# (using SubSonic) somewhat like this:

class Person
{
    public string FirstName {get; set;}
    public string LastName {get; set;}
    public string Gender {get; set;}
    public int PersonId {get; set;}
} 
class AdmissionApplication
{
    public string AdmitCode {get; set;}
    public string AdmitPeriod {get; set;}
    public string SiteName {get; set;}
    public int PersonId {get; set;}
}

I’ll spare you the business logic behind this, but essentially we’re joining these two tables together by PersonId and determining if the student was admitted since the last time we checked.  The data that we get will get put into a profile record in our SQL Server database.  This data will look something like this:

class Profile
{
    public string fname {get; set;}
    public string lname {get; set;}
    public char? gender {get; set;}
    public int pidm {get; set;}
}

There are a couple things I’d like to draw your attention to.  First of all, the data from the two tables is mainly the same, but the names are just different enough to make a difference.  Secondly, in our Oracle database, the gender is stored as a varchar (for some strange reason: it’s only one character).  In SQL Server, it’s stored as a single (nullable) character.  The first problem is easy enough to solve, but it takes a little bit of digging around on the SubSonic website to find it (I found the answer here: http://subsonicproject.com/2-1-pakala/subsonic-version-2-1-pakala-preview-the-new-query-tool/).

Here’s what the query looks like:

var sel = new Select(
    "ADMISSION_APPLICATION.PERSON_ID as 'pidm'",
    "FIRST_NAME as 'fname'",
    "LAST_NAME as 'lname'",
    "GENDER as 'gender'",
); 
var results = sel
  .From<Person>()
  .InnerJoin(AdmissionApplication.Schema.Name, AdmissionsApplication.Columns.PersonId,
             Person.Name, Person.PersonId);
  .ExecuteTypedList<Profile>()

(yes, I have been accused of abusing the var keyword)

This will automatically translate all of the column names from the result set into column names in Profile so that we have a List of Profiles.  But wait!  Don’t compile just yet.  We still have to tackle the issue of how to translate the string into that pesky nullable char.  That’s fairly simple to do.  We just have to add something to our Profile class:

class Profile
{
    public string fname {get; set;}
    public string lname {get; set;}
    public char? gender {get; set;}
    public int pidm {get; set;}
    public string StrGender
    {
        set
        {
            if (value == null || value.Length < 1){
                gender = null;
            }
            else{
                gender = value[0];
            }
        }
        get
        {
            return gender.ToString();
        }
    }
}

Then we just have to change that first part of the query above to this:

var sel = new Select(
    "ADMISSION_APPLICATION.PERSON_ID as 'pidm'",
    "FIRST_NAME as 'fname'",
    "LAST_NAME as 'lname'",
    "GENDER as 'StrGender'",
);

And we’re done!  Obviously, there are a few places where this code is fairly naive, but this is just an example.

Posted in Programming | Tagged: , , , , , , , , | Leave a Comment »

The best tool for the job: Duck typing vs Interfaces

Posted by Jason Baker on December 11, 2008

A question on StackOverflow got me thinking today:  what are the advantages of duck typing in comparison to interface-based languages (like C# or Java) and vice versa?  Notice that I’m not talking about the differences between dynamic and static typing.  These two comparisons go hand-in-hand to be sure, but they are two different things in my opinion.

The basic idea behind duck typing is that “if it walks and talks like a duck, then it’s a duck.”  Thus, if you want to do an operation on a certain type of object, then you should do that operation on a certain type of object.  If the interpreter has a problem, then the interpreter/runtime will let you know (and hopefully you’ve got some error handling in place).

On the other hand, interface-based languages solve this problem by having a pre-established contract between objects and code.  Thus, an object will guarantee that it will implement certain methods if the client code will guarantee not to call anything else.  If that contract is broken, then the complier will likely let you know at compile time (though that isn’t always the case).

So what are the pros/cons of these two methods?

On first glance, it would seem that the benefits of type safety would make interface-based designs more worthwhile in almost all cases.  Indeed, interfaces have helped me prevent a lot of needless errors that I frequently encounter in using dynamic languages.  It does this by forcing you to think your class hierarchy a long way in advance.

This is where C# and Java get their enterprise-y reputations.  If you need to develop a complex hierarchy of classes, interface-based typing is the only way to go.

This is simultaneously interface-based typing’s greatest strength and greatest weakness.  Indeed, it’s also duck typing’s greatest strength and weakness.  As wrong as it feels, not every class hierarchy needs to be so well-planned.  Heck, sometimes you don’t need class hierarchies at all (there seem to be a lot of python programmers who are totally against inheritance altogether).  Of course this does require a lot more unit testing, but you’ve already signed onto the TDD bandwagon anyway, right?

This is where Python gets its famed extreme levels of productivity.  By having a good set of unit tests, a Python programmer can churn out good code at breakneck pace.

At any rate, both ways of programming have their strengths and weaknesses, and there’s not any good answer as to what way of thinking about it is the best way to go.  So go with your gut.  If your first reaction at tackling a task is to say “gee, it really would be nice to be able to write a lot of code fast without having to go through a lot of tedium” then go with Python or Ruby or most other dynamic languages.  If you find yourself saying “I need a very complex class hierarchy to do this” then chances are you should be using C# or Java.

Posted in Programming | Tagged: , , , , , , , , | 2 Comments »