Kudos to Microsoft

Ars Technica reports that Microsoft donated almost $500 million to charity this year.  Now, I’m no Microsoft fanboy (although I warm up to them the more I mature), but I do believe in giving credit where credit is due.  So kudos to you, MS!  If more big corporations were like you, the world would be a better place.

With that said, I know that MS isn’t the only company that gives a lot of money away.  If you know of any other companies that are good about giving, feel free to post in the comments!

It works, why fix it?

It’s such an easy thing to get in the habit of thinking.  My code may be written using a platform that’s long outdated, but it works.  Why change it?  Here’s the problem:  your code probably doesn’t work.  You just don’t know it yet.  Ok, so maybe if you’re working on a 20 year old system using Fortran, you’re close to the point of being bug-free (if that is even possible).

Traversing the slippery slope

But the allure of a software system that works and never has to be touched again seems to draw so many people in.  Michael Feathers characterizes these people as Gammas.  These are the people that tell you that the website you maintain has gotten along well enough running Classic ASP up until this point.  Why consider something else?  Besides that, you’ve just got to implement this one feature.  After that, the system will work and you’ll never have to mess with it again.

If only it worked that way in practice.  The problem is that these kinds of prophecies wind up being self-fulfilling.  After all, why should you be very concerned with that one bug report?  They told you that you don’t have to worry about the system anymore, right?

Eventually, you wind up with a system that doesn’t work.  All those ignored bug reports, those last minute hacks to get it working now, and the general lack of attention paid to the software tend to add up (see Technical Debt).  At this point, you’re stuck between a rock and a hard place.  Do you take the time to rewrite it from scratch or do you convince your developers to fix a piece of software they didn’t want to be working on in the first place?

Unfortunately, the answer is all too often neither.  We’ll just fix it when we get a chance.  And that chance never comes.

But my code is perfect!  I tested the bejeesus out of it!

Nobody ever says it, but they think it:  I’ll do it right the first time.  And if anybody does say it, they’re going to be hit with a hard dose of reality soon.

But I’ll humor you.  Let’s say that your program is absolutely flawless.  Dijkstra himself would be in awe of your programming prowess.  And that may even be true for a time.  But there’s a thing about business requirements:  they have a way of changing in unforseen ways.  End users demand more features.  Managers change.  Laws get passed.

You’d better hope that these things happen sooner than later.  Otherwise, the poor soul that gets stuck maintaining your heap of code will hate you and everything that you stand for.  And sometimes that poor soul happens to be you.

But technology changes so quickly!

Keeping up with the times is tough.  Look, nobody’s saying that you have to be running the latest beta version of .Net version 9.3.  But bear in mind that you’re going to have to pay the cost of not keeping up with the pace of technology sometime.  And it’s usually better to do it sooner rather than later.

Ubuntu rethinks desktop notifications

Mark Shuttleworth talks about desktop notifications in Jaunty.  I find this to be an interesting subject, despite my hatred of notifications.  Why?  Well, it seems as though I’m not the only one who dislikes notifications.  Microsoft is also trying to change things in Windows 7.  To quote Ars Technica:

The taskbar’s system tray has also been improved. A common complaint about the tray is that it fills with useless icons and annoying notifications. With 7, the tray is now owned entirely by the user. By default, new tray icons are hidden and invisible; the icons are only displayed if explicitly enabled. The icons themselves have also been streamlined to make common tasks (such as switching wireless networks) easier and faster.

Well, maybe they haven’t quite come over to my side just yet.  But it sounds to me like they’re starting to rethink the notifications area some.

Anyway, back onto the subject of Ubuntu.  If the video Mark posts is what the end product will look like, I think this will be a step forward.  The notifications are simple and unobtrusive.  There’s one thing that’s sure to be controversial though:  the new notification system is set up specifically not to allow for user input in notification windows.

At first, this does sound like a somewhat limiting idea.  But Mark brings up a good argument against allowing notifications:

Our hypothesis is that the existence of ANY action creates a weighty obligation to act, or to THINK ABOUT ACTING. That make [sic] notifications turn from play into work. That makes them heavy responsibilities. That makes them an interruption, not a notification. And interruptions are a bag of hurt when you have things to do.

I couldn’t agree more.  One somewhat more useful thing that this causes is the fact that notifications don’t eat up any of your desktop.  How many times have you seen a notification, but had to either close it or wait for it to get out of the way because it was in the way of what you were wanting to do?  It happens to me on occassion, and it’s annoying.

At any rate, it looks like Mark is attempting to make good on his promise to make Linux look more beautiful than OS X.  After all, love Apple or hate them, they’re the guys to beat when it comes to UI prettiness.  I’ll save the subject of whether or not that means a better user experience for another blog post.

Ways to annoy me, a public service announcement

I seem to be noticing a lot of very good pieces of software doing a lot of needlessly stupid (and more to the point annoying) things.  So I figure that these companies must have good people working for them.  They just may not know that some of the stuff they do is annoying.  Thus, I’m posting this in hopes that someone will learn something new and never commit these travesties again.

Most of these boil down to one rule:  make your app a good and courteous citizen of my computer. So without further ado, here are my current top annoyances:

1. INSIST on installing shortcuts to my desktop, quicklaunch bar or dock, and start menu.  Sure, I can just delete them once the installer’s done.  But is it really that difficult to add an option to not have these shortcuts installed?  Of course, I’m sure that a lot of this is done to get some marketing exposure (this means you, Adobe).  But just about the only people that leave these icons are the ones that have hundreds of icons scattered across their desktop anyway.
2. Install an unnecessary background service to my computer. Really, this one isn’t that big a deal as long as that service doesn’t eat up too much of my system resources and doesn’t make itself blatantly apparent.  The bad ones are the ones that remind me of their presence constantly.  Hardware manufacturers seem to be the worst about this.  I don’t need a “control center” that’s accessible from my taskbar at all times just to install a device driver for my video card.
3. Make your application blissfully unaware that there may be other programs running at the time. Symantec Endpoint Protection’s LiveUpdate is terrible about stealing focus from whatever program I’m using every 5 seconds.  It’s enough to make my computer temorarily unaccessible.
4. Use “hidden” windows.  This is by far my biggest gripe with Windows (especially XP).  How many times have you been configuring something in the control center, switched to another application, and then had to go through and minimize each window untill you found the one you were looking for because it wasn’t in the taskbar?
5. Use Growl/Windows Notification area. I don’t have Growl installed on my MacBook, and I’d uninstall the notification area in Windows if I could.  Seriously, there are 3 reasons to distract me like this:  1)  I explicitly told you to. 2) You have good news (Oh, hey!  File X is finished downloading!) 3) I need to run for my life because my computer is about to explode.  Beyond that, there’s not much reason to pester me with pointless notifications.

So those are the main things that you can do to annoy me as an end user.  However, if you value a good end user experience, you would probably avoid these things!

ETL in Subsonic

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.

The best tool for the job: Duck typing vs Interfaces

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.

Securing VisualSVN Server

Apparently, VisualSVN has a bit of a security vulnerability:  it uses Apache’s default settings for mod_ssl.  This means that it uses the insecure SSL v2.  Not that SSL v3 is perfectly secure by any stretch of the imagination, but the fix for switching over to SSL v3 is just so simple.

All you have to do is add the following lines to your VisualSVN Server\conf\httpd-custom.conf file (or change the lines to this if they’re different):

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

I’d recommend doing this as the SSLv3 protocol has been well supported for a long time (Netscape released it around ’96 because of the vulnerabilities in SSLv2).

UPDATE:  I’m told that this will be fixed in a future version of VisualSVN.    Also, you should make the changes in httpd-custom.conf rather than httpd.conf.

UPDATE 2:  As of VisualSVN 1.6.4 (and possibly older releases), this seems to have been fixed.

From Testophobe to Testaholic

I know what you’re saying.  “TDD – that’s one of those newfangled programming fads.  Who cares?”  The answer’s simple:  I do and you should.

But you’ve been told that before.  Many times.  I know this because I was like you once.  So I’ll spare you the lectureon why you should become a TDD fanatic and sacrafice three lambs a week to the gods of XP.  I can do this because if you give me an hour’s worth of your time, that will happen on its own.

So rather than extol the wonders of TDD, I’m going to teach you how to test testing.  Humor me on this.  If I’m wrong, I won’t bother you again.

You ever have one of those days that go something like this:  *Program crash* “Whoops!  Field x is now a member of object y!  Let me change that.”  *Program crash* “Oh darn, forgot to check for null.  Silly me.” *Program crash* “<insert other stupid bug>” ?

Well, here’s what you should try.  Make a unit test for that one piece of code that you seem to have so many problems with.  You don’t have to spend any time learning any mocking frameworks or unit test suites.  Just write a mini-program that will make sure it works.  Assuming that you’re into the whole modularity thing, it probably won’t take long (but it may involve some thought).

Now that you have that out of the way, run that test every time you compile your code.  I guarantee you you’re not going to have problems with it much longer.

And that’s all you have to do to start your journey to being “test infected.”  Easy eh?  But I already know what’s on your mind now.  TDD is more involved than just writing a unit test.  And what about this xUnit contraption you keep reading about?  All that will fall into place in time.

Eventually, you’ll feel that writing these tests will result in a lot of code duplication.  That’s when it’s time for you to learn an xUnit framework.  After that, you’ll find that you’re asking yourself “Do I have enough tests?”  and “How the heck do I test this?”  And that’s when you’ll adopt TDD.

You see, the idea behind TDD is that you write your tests before you write the code.  The main benefit isn’t that you get to make sure that your tests aren’t slanted towards working (although that helps).  The main advantage is that you will know that you have enough tests because you’ve already planned that up front.  And you know your classes will be testable for the same reason.

So, now it’s just up for you to try it out.  Don’t say I didn’t warn you though.  Chances are, you’ll become test infected just like I did!