NewItUp()

I started re-reading The Pragmatic Programmer over the weekend and one of the early chapters mentioned the broken window theory.

Google search the term, but the quick version is basically that studies were done by experts in crime and urban decay that something as small as one broken window in a building, left unfixed, will make people occupying a neighborhood feel as though no one cares about the neighborhood and things will go downhill from there.  One study was done where a car was left in the same spot for weeks and nothing happpened to it.  Then one day, the person conducting the study smashed the window and by the next day, the entire car had been stripped.

Ok, so how does this apply to software?  Well - when a codebase contains a lot of un-clean code and generally looks as though it's been abandoned, the developers working on it are often more likely to use it as an excuse to do things the quick and dirty way.  Why should I worry about making my code maintainable, when this codebase has duplication all over the place and functions/pages that haven't worked correctly in months.

On the flipside, if a codebase is nice, clean and easy to work with... developers will be LESS likely to go for the quick and dirty change because they won't want to be responsible for being the one to start the downfall.

The reason this hit me so hard this weekend while reading was on account of something that occurred during work on Friday.  I came across an old file in my application that had a few validation functions in it.  The only problem was, the entire body of the functions were commented out and all that was left was a "return true".

Now, this is hardly the biggest problem I've come across in this codebase since I started my job, but it was just another case where I could've seen it, felt hopeless and moved on.  But what I decided to go was... fix them.  Remove the functions that have been commented out for years and then clean up the code was calling on them only to set their values to true.

And that's basically what the chapter in The Pragmatic Programmer suggests.  Fix Broken Windows.  Because just like seeing decay will sway a fellow developer to continue the decay, seeing repair will push fellow developers to continue that effort towards a cleaner codebase.

This is a very important book on a topic that hasn't been covered thoroughly prior to its release.  For all the text out there about Agile software development, XP programming practices, unit testing, etc., there seems to be an unwritten understanding that you're dealing with a fresh, new project space.  And for me, specifically, that was the case for the past few years.  As a independent contractor, I was often brought in to projects at their beginning to see them through to completion.  But having recently re-joined the full-time employee ranks to maintain and improve an existing product, I now understand how overwhelming it can be to look at a giant codebase and think to yourself "ok, where do I even start?"

That's where this book comes in.

First, it's definition of legacy code is simple.  Any piece of code that is not under test.  I think that's a good starting point.  Too many people think of legacy code as having to have been written years ago and allowed to degrade.  Not true.  By the author's definition, legacy code is still being written by developers every single day.

So obviously, the point of the book is refactoring existing code to make it testable.  And what's provided are chapters describing different situations, such as "I'm Changing The Same Code All Over The Place" and "I Can't Run This Method In A Test Harness".  In that way, the book can act like a reference material for programmers working in legacy code.  If you see yourself running up against one of these problems, simply flip to the chapter list, find your problem and read the chapter about it.  Most chapters are pretty short and get right to the point.

After the situational chapters, the book ends with a list of refactoring techniques, written step-by-step, that you can apply to get pieces of your code under test.  It's very much like Fowler's Refactoring book, except with some new techniques explicitly for getting your code into a test harness.

I had heard that this book was useful for years now, but never bothered to pick it up.  But now facing a codebase that seems unwieldy, I think this may be one of the most important books I've ever read.  We don't all code in green pastures, but this book certainly helps you not lose focus of the techniques you hold dear (unit testing, separation of concerns, D-R-Y, single responsibility, etc.) when you encounter a situation that seems overwhelming.

http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

Well - I just watched this screencast which served as my intro to Code Contracts and now I'm not quite as siked on them:

http://www.dimecasts.net/Casts/CastFeedDetails/118

They're still pretty useful and I think the syntax beats having all the IF statements checking for null and other expectations as far as readability goes, but I really thought they would throw a full fledged compiler error in the case that a contract was violated, rather than just a warning.  I mean, it's better than nothing, but a lot of programmers ignore warnings (unless you've subscribed to the pragmatic programmers philosophy of treating warnings as errors).

I also don't particularly like the code you have to write to handle the contract check (it's in the SetUp of the test harness in the video).  It just seems like an added step, where you could just assert that the exception was thrown in the old piece of code, without having to write in that extra stuff in SetUp.

I'm still looking forward to hearing more about this as VS2010 and .NET 4.0 come closer to being released.  For me, the jury is still out on this one.

But the video did show me one cool thing, completely unrelated to code contracts.  In his test, he used NUnit syntax helpers which I thought made the test code more readable.  I'm going to have to look into those and once again renew my ongoing battle between MbUnit and NUnit.

I just read about this new feature coming with .NET 4.0 this morning at work, linked from some blog in my reader.  After following a few links, I came to this one:

http://codebetter.com/blogs/matthew.podwysocki/archive/2008/11/08/code-contracts-and-net-4-0-spec-comes-alive.aspx
http://research.microsoft.com/en-us/projects/contracts/

In a nutshell, Code Contracts is Microsoft's Design By Contract (DbC) implementation. And it looks pretty cool.

Admittedly having only looked at it for about 20 minutes this morning, my initial thoughts are:

+ It's AWESOME that this library supports runtime checking.  That means if you have a piece of code like:

if (someObject == null) throw someException else { // do stuff};

you can replace it with:

CodeContract.RequiresAlways(someObject != null);

// do stuff

And if during compilation, the compiler notices a spot where null is being passed into the function, it will notify you with an error at compile time, rather than throwing an error when you run your code.  That's ESPECIALLY cool if you build them into a library that you release and let others use.  If they try to pass invalid objects into your library, they'll be notified when they compile.

+ The syntax is certainly cleaner than wrapping things in IF statements to check their state.  The code also communicates more clearly, in that regard.  It's easy to read what is expected in a function the way these contracts are written.

Now, the negatives:

- I still wish there was a better way to add these conditions to your code.  It's better than IF statements, but I still wish I could just write a clean function without having that in there so that ONLY the actions performed within the functon stood out.  Oh well, it's a step in the right direction.

- I think it could lull people into a false sense of security and away from unit testing, which is a slippery slope.  But a few articles I read made the case for using both complementary, as opposed to trying to tout the benefits of one over the other.

I'm going to look into it a bit more in my free time (I'm posting on my company's dime right now), but if anyone even knows my blog exists, I'd like your thoughts on this.  Is it worth using or not?

I bought a MacBook Pro a few months ago because I needed a new laptop for work and was intrigued by the Apple line, after reading a bunch of great reviews from .NET developers who had made the jump.  After a few months of use, I really began to the love thing and considering it has more computing power than my current home desktop setup, I decided I wanted to shift my use to the MacBook Pro completely and ditch the desktop altogether.

So I've been spending the past few weeks making sure any program I use regularly on Windows has a Mac counterpart and I've managed to get pretty much everything I needed.  However, one little Windows application that I use all the time, Active Desktop Calendar, did not have any Mac equivalent that I could find.

It's such a simple application - you put events in a calendar that sits in your system tray and it displays them down the right side of your screen.  But it became so indispensible to me - I entered all the Flyers games in there (I'm an avid fan), all the upcoming concerts in the area I wanted to go, birthdays, parties, family events, etc.  It got to the point where I had to look at the thing before giving someone a "yes" or "no" about whether I could make an event to see what else was scheduled.  And I loved that I could just see it - I didn't have to open a program or anything.  It was just always floating there.

I wanted similar functionality on my Mac.  And I couldn't find anything out of the box that took care of it.  Until one day, I saw this post about this post on Lifehacker.  Now the ball was rolling.  I liked that it displayed freely on your desktop, but wasn't a fan of the calendar-like format.  It seemed a bit excessive and took up a little too much screen real estate for my liking.  So I downloaded the script and decided to take a look.

I had never worked with AppleScript before, but I figured now was a good time to dive in.  The syntax is pretty easy to pick up, especially if you have some programming background.  And I spent some time cleaning up the code to do what I wanted it to do - instead of creating files to be read into the Remind program, I just created text files formatted the way I wanted to display on desktop using GeekTool alone.  I also found a few ways to speed up the script - it grabbed all the events in a calendar, whereas I made it grab only events with a date that was either today or in the future.  And I made a few other tweaks to my liking.  My script can be downloaded here.  WARNING:  It's a work in progress and I actually have a bunch of additions/changes planned for it now.

The one major problem with this script is that it doesn't run automatically.  Every time you updated your iCal, you'd have to go run this script to get the changes to show up.  Not my idea of user-friendly.  So I set about trying to figure out get this thing to run on a schedule and came across launchd.  You use configurable plist files to schedule pretty much anything on our Mac.  It took me a bit to figure out how to get this thing working (where do I put the plist files? can I use relative pathing or must it be absolute) but I finally did and now I have it running where the script runs once every hour.  There are some advanced features where you can set WatchPaths and have launchd run your commands based on whether or not a folder, or any files in that folder, have changed.  I'm putting that on my TODO list for this application - I'd love to have it run after I enter a new item into iCal, instead of on a timed basis.  That would be beautiful.

Anyway, here is the plist file I created (turns out - absolute paths are necessary):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>Debug</key>
    <false/>
    <key>Label</key>
     <string>com.apple.iCalToDesktop</string>
     <key>OnDemand</key>
     <true/>
     <key>ProgramArguments</key>
     <array>
          <string>osascript</string>
          <string>/Users/*myusername*/Documents/Calendars/iCalToDesktop.scpt</string>
     </array>
     <key>StartInterval</key>
     <integer>3600</integer>
</dict>
</plist>

I think it's pretty self-explanatory (now that I have it working - I was ready to pull my hair out for a day or two haha), but if you have any questions, please don't hesitate to get in touch.

You put that file in your User/*username*/Library/LaunchAgents folder. Then open a terminal and run:

launchctl load *path to that plist file*

You have to log out of your account and log back on before the schedule starts running though.

So once you have that going and you want to display your text files on your desktop using GeekTool, it's pretty elementary. Just open GeekTool, create a new entry of type "Shell" and enter this:
cat *path to text file you want to display*

If it worked, you should see the contents of the file display on the desktop with a rectangle around them. You can position this rectangle by dragging it to wherever you want on the screen, and make it whatever size you want.

So now I have my precious events showing up on the desktop like I had with Active Desktop Calendar and it's even more of a benefit because it uses iCal which will also sync with my iPhone and whatnot. Pretty sweet.

I know this post lacks a lot of detail about the code itself, but if you open it, you'll see that the syntax is pretty easy to follow. Of course, if you have questions/comments/suggestions/improvements, please don't hesitate to get in touch. And I want to stress that the base of my code was taken from this blog post so this guy deserves a bulk of the credit. I sorta just took his framework and updated it for my own personal needs.

A few improvements I'm planning for when I get some more time:

• Adding the TODO list items from iCal
• Further formatting of each individual calendar (I have different calendars for concerts, Flyers games, birthdays, etc.)
• Adding the ability to read the repeat type of an event (daily, weekly, monthly) and displaying them accordingly

I'm sure more stuff will come to mind once I start seeing what I like and don't like about my current setup.

A post earlier tonight by Max Pool over at codesqueeze.com caught my eye moreso than the average post on a programming blog.  It asked What Music Do You Code To?  Great question.

Music is the most important thing in my life - yes, even moreso than programming.  We all need passions other than what we do for a living (right, RIGHT?) and since all I knew of computers was King's Quest and AOL, I've been going to concerts, buying CDs (or cassettes... and yes, I still buy them as showcased by the picture in this post - each of those racks behind me holds 1000 CDs and that's not even all of them - yikes!) and generally pouring a vast majority of my attention into the music scene.  Heck - my first foray into database-driven web development came in the form of an online music magazine that I ran for quite a few years.  It was a way for me to both indulge my constant craving for new music, while also having a sandbox to try out new things I learned about programming.  Sorry kiddies - no links... the site is still in classic ASP as it died a slow, painful death when I got to college and started doing internships and homework.

Anyway, back to the point, the music that comes out of my laptop at work is truly off-the-wall.  Just ask my brother who sits about 10ft away from me in our office - I can easily go from death metal to gangster rap without a second thought.  I blame that on being a Gemini.  But if I had to peg myself into a musical role, I'd say I was a hardcore/punk/indie kid and recovering metalhead.

Lately, the bands that have been getting the most spins (do mp3s spin?) include:

• Joy Division / New Order
• Alkaline Trio
• The Loved Ones
• Nirvana
• David Bowie
• The Cars
• The Clash
• Cursive / The Good Life
• Social Distortion
• Minor Threat
• Ink & Dagger
• The Misfits
• Wolf Parade / Sunset Rubdown

(I've also placed a link to my Last.fm profile on the side of my blog - so if anyone has any interest in what I'm listening to, or is just really bored, you can check that out)

I've noticed that the best stuff to listen to while working is something you're very familiar with.  When I listen to new albums, I like to immerse myself in them to truly hear and enjoy them.  However, when I can sing the lyrics of a song without a second thought, it just seems like everything is in order and my code seems to flow as smoothly as the music.

Well, in order to keep this thread running through the developer community, I guess it's time to tag a few more people to fill this out.  So I'm going to throw the onus on the few bloggers I deal with on a somewhat regular basis:

• Brian Donahue
• David Laribee
• Steve Eichert

This post began as a discussion between my brother and I after the preview release of the new MS MVC Framework. Both of us were chomping at the bit to get our hands dirty with this new piece of Microsft technology. One of us suggested using it for a new project that we were about to start for a client. The other one had his reservations with such a forward-thinking and proactive approach, suggesting rather that use on an internal application would be a better idea. Which one of us felt which way? Well - unless you were at Philly Alt.Net's December meeting you'll never know - better to leave sibling rivalry remain between siblings ;)

Getting into the nitty gritty of a new piece of software is a noble trait. You can't fault someone for being proactive. And in this particular case, the MS MVC isn't all that different from previous work we've done with Castle MonoRail. And obviously, the sooner you start working with something, the faster you'll learn how to leverage the tool to your needs. It may even give us the ability to provide feedback to the MS MVC team for bug fixes and enhancements to the RTM (Released To Manufacture) version.

But sometimes, when you play on the bleeding edge, you run out of band-aids. The risk involved in building software on top of a framework that hasn't been RTM seems pretty straightforward. There may be bugs. Features may be incomplete, missing or cleaned up before RTM. This isn't such a big deal when you have the time and resources to roll with these punches, but when you're under the pressure of a deadline and a budget, the amount of refactoring might be too great.  Not to mention, client buy-in could be tough on a product they can't rely on and a lack of support from the manufacturer as part of the license.

Again - there is no question that getting the jump on a new technology has its benefits. But there are also some pain points when being the first one on the bandwagon - those horses may be too much for you to control. The question is whether or not the benefit of the new framework outweighs the possible problems.

What does everyone else think? Not just about MS MVC, but about EAP/CTP software in general? Would you take the plunge or play it safe?

5 months to make my first post?  Yikes!  I need to get on the ball.

But now seems like the perfect time to jump into things with the release of the ASP.NET 3.5 Extensions Preview coming soon (supposedly this week, but I haven't been able to find it yet) which features the MS MVC Framework that the Alt.Net community has been so excited for.

WIth the release imminent, I've been thinking about a few things.  Not things like predicting syntax, interoperability or how MS MVC will ease TDD.

I'm wondering how this release will affect the community.  Not just the Alt.Net community - those whom have already bought into the idea of reaching outside of the mainstream.  I'm wondering if the backing of Microsoft will lead those developers whom are perfectly content with doing things the "Microsoft way" with giving MVC a shot, now that it, in a way, is the Microsoft way.  Or at least it could be.

Furthermore, will Microsoft promote their MVC architecture as the new way to do things?  With Ruby On Rails getting a lot of attention lately, Microsoft may make a big deal about their implementation of a similar framework.  Can we expect to see code samples and tutorials in MSDN, featured prominently?

As someone who has taken a strong interest in MVC through working with MonoRail, I'd be overjoyed if Microsoft would push this framework as the new standard.  Imagine removing the pressure points of trying to sell this technique to management and other team members?  No more fighting the uphill battle trying to explain that this separation of concerns simplifies code, makes things more testable, maintainable, etc.  No more hitting walls of resistance because developers would rather not leave their comfort zone.  Instead of trying to sell MVC as a better way, we'll be able to say "this is the Microsoft way!"

I obviously don't have the answers, only the questions.  So what does everyone else think?  Will MS make a big deal out of this release?  And what would you LIKE to see them do, and why?  (I bet you didn't expect a pop quiz from my first blog post!)

I've been programming for a few years now and decided it was time to join the gang and start up a blog.  I've spent more than my fair share of time getting tips from others' blogs, so hopefully this one will effectively share a few of things I've picked up, as well as create an environment for me to continue learning.  It'll focus on .NET and web development for now.  Hope you enjoy!