Categories: Delphi Posted by Shawn Oster on 8/16/2007 12:15 PM | Comments

Building projects has always been a pain in the arse.  You want it to be simple, fast and easily reproducible, all of which are tenets of good continuous integration.  When it comes to building a Delphi project I've tried a whole slew of things from batch files to the Ant-based Want to very slick IDE's like Automated Build Studio and FinalBuilder.  I keep coming back to simple DOS-based apps though because in my ideal world a user should be able to do a clean checkout of your code and then be able to build.

Currently I use Want, which is a Delphi port of Java's Ant, .NET users will probably think of NAnt which was also a port and then heavily extended.  Ant, or it's derivatives, is great until you need to manage a large build file and have to wade though all that xml to figure out what's going on.  Xml is just not the best format for humans to muck about in so lately I've been looking at Rake, basically Ruby's version of make.  Maybe I'll whip this up into an tutorial or something more informative but for now here is a *very* basic build script using rake, in fact it's the one I use to build my ZuneKeys application:

(I'll sex up the code formatting later once I find a good online code formatter)

def compile_project(project_file)   
    args = "-B -Q #{project_file}";
    result = %x[dcc32 #{args}]
    if result =~ /Error/
        puts result   
        project_name = project_file.gsub(/\..*/, "")
        puts "built #{project_name}"

file 'ZuneKeys.exe' => ['ZuneKeys.dpr', FileList['*.pas']] do
    compile_project "ZuneKeys.dpr"

task :default => ['ZuneKeys.exe'] do       

desc "Remove temporary files created during compile"
task :clean do   
    if File.exists?('ZuneKeys.exe')
        rm "ZuneKeys.exe"
    rm FileList['*.dcu']
    puts "clean"

task :release => [:clean, :default] do
    puts "release project"

Posted by Shawn Oster on 7/27/2007 9:36 AM | Comments

A quick guide to setting up Subversion in Windows and making sure it works from remote locations as well.  There are a few other guides out there but they're all out-dated from what I can tell or they're missing the few things that have bit me in the past.  There is also a great little project called Svn1Click that will get you setup with Subversion, only problem is that it seems to also be out of date, it installs Subversion 1.4.2 and the current is 1.4.5.  So, roll up your sleeves.  I guarantee you'll be able to setup svn faster than it took me to write this thing.

Install Subversion

1. Download latest version of Subversion.  Right now that's version 1.4.5.  You'll want the Windows installer which is svn-1.4.5-setup.exe.

2. Install using defaults.

3. Open a command prompt (Win+R, Cmd, Enter)

4. Check to make sure that Subversion's bin directory was added to your path.  Type "svnadmin help", you should see a list of available svnadmin command.  If not you'll need to add it manually (Right-click My Computer, Properties, Advanced Tab, Environment Variables, System variables,  double-click Path, add ;c:\program files\subversion\bin to end, OK out of all dialogs).

Install TortiseSVN

While not needed to get a svn repository working it's such a rocking way to access your repository you should be using it.

1. Download TortiseSVN (1.4.5 as of this writing) and install it.  Yup, that easy.

Create Repository

1. At a command prompt...

2. Decide where you want your software repository.  Personally I picked the highly imaginative "d:\repository".

3. From the command-line type "svnadmin create d:\repository".  Don't worry if the folder doesn't already exist, the create command will automatically create the folder for you. 

Lock It Down

You'll probably want some security.  Determine who should be able to view it vs. who can commit back to it.

1. Browse to "d:\repository\conf\" and open svnserve.conf.

2. If you're going open-source and anyone can do a checkout but only the chosen can do commits then leave it like it is.  If you're a little more picky over who can see your source then uncomment the "anon-access = read" line and change it to "anon-access = none".

3. Uncomment the "password-db = passwd" line.

3. Save & Close.

4. Open passwd in same folder.

5. Under the users section add your username + password in the form of "username = password".

6. Save & Close.

Running Subversion As a Service

1. Subversion is most useful when you're running it as a service and the nice svn devs have provided a windows service that'll run happily in the background serving up your code.  Type the following into the command-line:

sc create svn binpath= "\"C:\Program Files\Subversion\bin\svnserve.exe\" --service -r D:\repository" displayname= "Subversion Server" depend= Tcpip start= auto

This command line is tricky, two things to remember:

  • Resist your natural urge to clean up the command line, you need exactly one space after the equals of each key pair and no space before it.
  • Since the default install of Subversion installs it in C:\Program Files you need those escaping backslashes in the command-line.  Forget those at your peril.

2. You've created the service, now start it, "net start svn"

3. To access a repository being served by svnserve the url is "svn://<machine name, ip or url here>".  So, to access a repository running locally you can simply do "svn://localhost" (but don't, read the tips below for why).

Is This Thing On?

1. Type "svn info svn://localhost"

2. If you went open-source you'll see some info, otherwise you'll be prompted for your login/password.  Enter it.

3. You'll get back a bit of info on the repository you're now serving.  Sweet.

Accessing SVN from the Road

You probably want to access your repository from more than just your home network so here are a few things you may or may not need to do.

1. If you're like 90% of people you don't have a static IP address to serve your svn repository from.  No problem, go to a service like DynDNS or and get yourself a free dynamic IP domain.  You'll end up with something "" or "".  Doesn't matter, get creative, express yourself.  I've used both, no problems with either so it really comes down to which "vanity" domain you like, both have a large selection of domain names you can pick and then you tack your sub-domain onto the front of it.

2. Your repository url is now: svn://

3. Now that you have an actual address to use you need to make sure svn traffic actually gets to your computer.  If you have a router you probably need to forward port 3690 to the machine hosting the svn service.  Check your router's manual on how to do this but here is what I do on my NetGear router:

  1. In a browser go to, enter login/password if needed
  2. Look for a section "Attached Devices" or "LAN IP", basically you're trying to figure out the local IP address of the machine running svnserve.
  3. Look for a "Port Forwarding/Port Triggering" section
  4. Add a new Port Forwarding
  5. Name it SVN, select TCP if offered a choice between UDP or TCP.  Selecting both won't hurt anything either.
  6. Port is 3690
  7. Forward to IP is the local IP address of the machine running the svn service.  You should have found this in step 2.  If not you can type "ipconfig" from the command-line and it should show you your current IP address.
  8. OK, Enter, all that stuff, you're good to go.

4. Lastly if you have a firewall it may decide to mess up your day.  There are many firewalls out there but the jist is that you need to allow inbound and outbound traffic on port 3690.  Some programs let you browse to the EXE and allow it, others do it strictly by port.  Some don't block it at all so this step may not be needed.

Advice & Troubleshooting

  • Always use your dynamic address, even at home, even when working on the same machine hosting the repository.  This will save you from having to run the relocate command on your working copies.  First time you go to a coffee shop on your laptop and attempt to connect to your home repository and don't get the "unable to connect to repository svn://home-pc" you'll thank me.
  • If a working svn url suddenly craps the bed and stops working there are usually two reasons, either a) your public IP address has changed and you need to go to your dynamic IP provider and update your IP or b) your machine grabbed a different IP address from your router so now your port forwarding is going to the wrong machine.  Either update your port forwarding or setup a static route in your router to always give your svn machine the same IP.  98% of the time though your svn machine will get the same IP so it's not too much to worry about but it's happened.
  • Add your repository folder to your backup if you're not doing a full system backup.
Categories: Zune Posted by Shawn Oster on 7/15/2007 2:32 AM | Comments

Before the Zune software I used Winamp and one of the things I really liked was it's Global Hotkey support, the ability to control the player using just hotkeys.  Ever since using the Zune I've found myself hitting Ctrl + Alt + Home to pause the player about a 100 times so instead of whining about it in yet another blog post I thought I'd actually do something.  It was a slow afternoon at work on a Friday so I whipped up this, ZuneKeys, global hotkey support for the Zune software.


  1. Download ZuneKeys
  2. Unzip and copy somewhere, personally I use c:\program files\zunekeys
  3. Run ZuneKeys.exe...
  4. ...and Bob's yer uncle!  Now you have global hotkey support for your Zune software.

I'd suggest adding ZuneKeys to your startup menu so it's always available.

The Keys

Play Ctrl + Alt + Insert
Pause Ctrl + Alt + Home
Stop Ctrl + Alt + End
Previous Track Ctrl + Alt + Page Up
Next Track Ctrl + Alt + Page Down
Volume Up Ctrl + Alt + Up
Volume Down Ctrl + Alt + Down
Fast Forward Ctrl + Alt + Right
Rewind Ctrl + Alt + Left


How it Works

I'm basically sending the same commands that your fancy media keyboards send, except I don't use media keyboards as they take up entirely too much space on my already cramped desk.  Nothing too magically here.  I'm pretty sure the Winamp one actually sends Winamp messages that it knows how to respond to but since the Zune software doesn't *have* anything like that I'm sorta faking it.

There is no customization of hotkeys and it could probably do a lot more but I wanted to keep it as tiny as possible since I already seem to have a 100 other things running in the background trying to compete for my system's resources.  If someone besides me actually uses this puppy I'm sure I could accommodate customized keys or other small enhancements.

This works with the Zune right now because that's where I needed it but it could easily be adapted to work for Windows Media Player, iTunes, Winamp, etc.

Oh, it seems to work just fine under Vista and XP.

The (Open) Source

It's written in Delphi as a standard Win32 application.  Since it's Delphi that means the only thing you need is the EXE, no .NET or Java Virtual Machine needed here.  Since I avoided using the VCL and went old-school Windows app it's only 30.5kb instead of the more usual 300kb Delphi app.  If you'd like the source just ask, I'll put it some place public or give you access to my subversion repository.  A special thanks to IconBuffet as the icon I'm using is from one of their "Free Delivery" icon sets, Dresden Symphony.

ZuneKeys Source

UPDATED: Some people noticed that the source zip was missing  Sorry for not having it there the first time.  I’ve updated the download with all the files I have in my source folder.  I’ll probably be moving this to Github or CodePlex so it’s more formally hosted and people can share their work.

Posted by Shawn Oster on 7/14/2007 12:32 PM | Comments

I've had my Zune for about 6 months now and wanted to revisit my thoughts on it since I first got it.

First, the hardware is great, there is only one issue I have with it (bookmarking) and I consider that more of a software/firmware issue than a problem with the actual device.  The interface is great, navigation is fast and easy, the screen is great looking, the matte finish has prevented any scratches and I find I like it's over-all look more each day. 

The software, ahh, the software.  Ever had an itchy shirt tag or a pebble in your shoe that at first you thought you could live with but after a few hours you feel like you're being tortured and you'll tell all secrets just to get rid of the agonizing pain?  Yeah, that's been my experience with the Zune's software.  Here are the "pebbles" that have grown into throbbing pains in my arse:

Metadata and Tagging 

Almost everything about the tagging support bothers me and I have a whole list of items.

  • Copying songs from Zune to PC results in any songs that don't have their "Album Artist" field set ending up in "Unknown Artist" folder.  Extra annoying because both the Zune and the software itself understand that you should fall back to Artist, a standard ID3 tag, when Album Artist, a non-standard tag, is used.  Why couldn't they extend the same logic to file copying?
  • Unable to set metadata for pictures or video.  So while Vista supports tagging of photos forget being able to access that in the Zune software.
  • "Find Album Info" is painfully slow when trying to find missing album information.  It's also not very robust and it's tied into a cumbersome wizard, song-by-song approach.  It should be tied directly to the Marketplace so you can find the album or song and say, "see these songs I've selected? map their info onto these other songs I have in my library, including album art."

This is the only the tip, I could fill three blogs worth of posts with my issues with the tagging support.

Large Library Support

My 80GB networked library seems to almost choke the software.  When I plug in my Zune it seems to take 5 minutes for it just to re-read everything that's on the device.  There really is nothing snappy feeling about the software when it's loaded up with 80GB of music.  Free software like Winamp does a much better job with large libraries.

No Bookmarking Support

This is an issue if you listen to long podcasts or books.  I'll often want to mark an interesting place in a podcast or remember my position in an audio book.  I should be able to set a bookmark, go play a few songs and then return to my prior bookmark in my audio book.  I can think of a few ways this could be implemented, such as "turning on" bookmarking support for a track so anytime you navigate away it's position is auto-saved and if you press play again it auto-resumes.  Another less fancy but still usable process would be bringing up a song's menu and selecting bookmark.  Either way it's a sorely lacking feature and I curse the lack of it almost every day when I lose my place in my daily BBC podcast.  Seriously, this should probably be my #1 annoyance.

Unable to Play Directly

If you want to play any music that's on your Zune via your PC you have to first copy it off the device.  Obviously it's annoying because you have to take the time to copy it off, then it's doubly annoying if the Album Artist isn't set (see metadata and tagging above) because your songs end up in the great Unknown Artist folder.  A subtle yet more insidiously annoying issue is that a lot of my songs go unrated because of this.  Since I copy the music off in 'Guest' mode there is no syncing, because there is no syncing anything I rate in the Zune software on the Guest machine is worthless.  If I want the rating to "stick" I have to manually copy it *back* to the Zune and that's a crapshoot, as sometimes it over-rights correctly while other times it just creates a copy.  If I could just play the music directly I could avoid all of this.


The more iTunes widgets I see the more I realize that the Zune community is missing out.  There is a huge database of information and I should be able to easily write plug-ins that both interact with the UI as well as mine the data for great Sidebar gadgets.  Great community driven widgets and plug-ins can really add to a product.  For example CoverFlow, the lovely ability to flip through album art in iTunes and the iPhone, started out as a plug-in created by a third-party, not as some great Apple genius.


The little bits that annoy:

  • Unable to see album art in the software for songs on your Zune.
  • No global hotkeys.
  • When using a media keyboard to control volume the volume slider doesn't adjust up or down in the software.
  • Recalculates remaining Zune space when you're copying music *off* the Zune.  How is that going to affect the available remaining?
  • Marketplace landing page takes too long to load.
  • Limited file renaming choices.
  • No way to tag a song or album as "download for later" or "interesting" in the Marketplace.
  • Zero community or "social" aspect built into the software.  Where is the playlist sharing?  The user reviews? 

The Rest

It's worth mentioning that I'm *not* annoyed by the lack of people to "squirt" songs to or lack of greater wifi abilities.  All the little feature some people want, like a calendar, alarm and clock don't phase me.  Podcasts?  I use FeedDemon to download them.  My first desire is a robust music player and music *manager*.  It used to be you could have an amazing hardware device and the software could suck since you could manage the device in a number of ways.  Take a Creative Zen, you can either copy files directly, use their software, use Media Player, Winamp or a handful of other utilities.  Create's music management software could suck all day and it wouldn't really matter.  Now, with the software/hardware lock-model of the iPod and Zune the software has to be *at least* as good as the device.  Currently the Zune hardware gets a "B+" while the software gets a "D-".  I'm really hoping a new version comes along soon that fixes some of these issues.

With all of that being said though don't confuse constructive criticism for dismissal, I still really like the Zune and it's still a joy when it comes to doing the one thing it was really meant for, playing music.

Posted by Shawn Oster on 7/7/2007 9:23 AM | Comments

Just ran into an issue trying to run a simple .NET 2.0 file writing command-line app across a network share.  No matter how much beating we couldn't get it to run until we ran across this little batch file in the comments on the .NET Security Blog post, Using CasPol to Fully Trust a Share:

call %windir%\Microsoft.NET\Framework\v2.0.50727\caspol -q -m -ag 1.2 -url %1\* FullTrust -n %1 -d "FullTrust granted to:  %1"

I dropped the code into a batch file called trustshare.bat and ran it like this:

trustshare.bat //machine/sharename

Suddenly the three hours of hair pulling finally ended.  The batch file needs to be run on each machine that's attempting to run the application, not on the machine that's actually sharing the application. 

While I really enjoy .NET for web applications I go crazy trying to use them as stand-alone desktop apps.  I much prefer CodeGear's Delphi when creating standard Win32 apps, you get a single EXE and don't have to worry about a secondary layer of security permissions beyond the file system during deployment.

Posted by Shawn Oster on 6/29/2007 7:14 PM | Comments

I just got done playing the Project Sylpheed demo on my XBox 360 and if you were ever a Robotech and Starblazers watching young teen then this is the game for you.  No, nothing transforms and it's nothing more in-depth than flying through space blowing up fighters and ships but something about the fast-paced action and constant steam of little anime characters yelling at you makes you feel like you're smack dab in the middle of one of those huge space battles you used to watch as a kid.

The control scheme takes a little getting used to (and six separate tutorials) and you get the feeling that it was actually a meth head that created the fast-paced combat because they needed something "faster" but if  you can come to grips with all of that you end up with a pretty enjoyable experience.  Very pretty graphics, responsive controls (when you remember to actually pretty the right combo), an AI that is just the right difficulty for my skill level and there's even a stock anime story wrapped around the action which is always fun to give your wrists a break.

Best yet I believe the game is only going to be $40 at launch, unlike the usual $60, which means it just might end up as a purchase.  Since it doesn't have multiplayer or any online component I'm guessing the replay won't be high but given everything else coming out soon that'll work ok for me.  This is one of the few times a demo is actually pushing me towards purchase, because I probably would have skipped this otherwise.

Posted by Shawn Oster on 6/29/2007 8:10 AM | Comments

One annoyance when I installed Vista on my development machine at home was that I could no longer debug my ASP.NET apps, due in large part to this error:

"An authentication error occurred while communicating with the web server."

Lots of searching got me to an article by Mike Volodarsky on using various workarounds but I just saw on Scott Guthrie's blog that there is now there is a better solution out there, a patch for Visual Studio 2005.

The patch can be downloaded here.

Posted by Shawn Oster on 5/11/2007 7:39 AM | Comments

There are some pretty great looking icons out there, with lovely drop shadows and alpha-blending, problem is they look pretty bad in Delphi since it doesn't fully support them. Below is how I use XP-style, 32-bit png images as icons inside my Delphi applications.

Create a resource file

  1. Get your image into an .ico format.  I use icon sushi to convert png images into icos.
  2. Create a new text file, save it as icons.rc (you can call it whatever you want).
  3. Edit the file and for each icon create an icon resource entry, like this:
    icon_edit    ICON    "edit.ico"

    icon_edit is the name of the resource, this is how you'll refer to it in code when you load it.

    ICON is the type of resource, in this case... well, you get it.

    "edit.ico" is the name of the icon file and it can include a path. A common pattern I use is to put all my icons in a folder, imaginatively named "icons" and then I include them like this:

    icon_edit ICON ".\icons\edit.ico"
    icon_copy ICON ".\icons\editcopy.ico"
    icon_paste ICON ".\icons\editpaste.ico"

  4. Compile the resource script into a resource file. I use Borland's Resource Compiler, brcc32. To make it so I don't have to drop down to DOS all the time I create a little batch file that I can double-click. It looks like this:
    brcc32 icons.rc

  5. Include the resource file in your project. You can include a resource in any of your unit files but I prefer to include it in the unit from where I'll be using it, such as the main form or a datamodule. Include it like this:
    {$R icons.res}
Prepare your Form

  1. Add a TImageList to your form. Change the Width & Height properties to match the size of the icons you want to load (32x32 for example).

  2. Download this file: It has routines that will enable your TImageList to support 32-bit XP style icons. I can't take any credit for these routines. I found them on someone else's site describing the exact same thing I am but I can't find it anymore.

  3. Unzip and add the uXPIcons.pas unit to your project.

  4. Create a new procedure called "InitializeImageList()" or some other fun name.

  5. Add the following code to your new procedure:
    AddIconResourceToImageList('icon_edit', ImageList1);
    AddIconResourceToImageList('icon_copy', ImageList1);

  6. AddIconResourceToImageList returns an integer which is the index of the icon just added, which can be used to set the GlyphIndex for any control that takes both an ImageList and a GlyphIndex.

  7. Call "InitializeImageList()" from your FormCreate().

  8. Run it and rock.

Update: One thing you'll notice is that now your main application icon has been replaced by the first icon in your resource file.  My suggestion is to just make sure your application icon is first in your resource file.  It actually works better for me since I often have to create versions of my applications with different main icons and being able to swap them out via different resource files using a build script is much easier. tags: , , , ,
Posted by Shawn Oster on 5/3/2007 6:49 PM | Comments

There are lessons you learn in school and there are the things you learn along the way.  I've been developing software for 25 years, since I was 8, starting with a book called "Your First BASIC Program" that my dad bought me because we had a PC while all my friends were playing StarBlazers on their Apple IIs.  He said if I wanted to play games then I could write one myself.   At the time I was a bit disappointed (OK, crushed) but now... well, Dad, thank you.

These are some of the things I didn't learn in school, but wish I had:

1. Use Version Control

Even if you're a solo developer get into the habit of using a version control system. For one it gets you used to the concepts of version control which you'll definitely need if you work with a larger team and secondly it offers another level of protection.  My current favorite is subversion, it's easy to install, has a great command-line and GUI client and it's free.

One more bit, commit often.  Think of commits as "undo checkpoints".  You thought replacing every instance of the base class across 50 project files was a great idea but then realized your idea sorta sucks?  No problem, you can restore all 50 of those files back to their pristine state.  No undo buffer will help you the way a good VCS will.

2. Use the Native Naming, Coding and Formatting Style or "When In Rome"

Before you decide to reinvent the wheel look to the native language for hints on code formatting, variable naming, indenting and method naming.  Fight the urge to use your own style or to use your favorite formatting from another language. There are a few reasons:

  • Maintenance. Some poor schmuck down the line will probably have to look at your code and they will probably disagree with your highly stylized use of brackets.  At least the native style of formatting will be familiar to them as a common baseline.
  • Fighting the IDE. If you're using an IDE it'll probably have some form of code completion, with some built-in templates for basic things like loops, classes, closures, etc.  Those templates will more than likely be in the "native style" and you'll either spend all your time fixing the formatting or worse you'll create a mishmash of your style plus the IDEs, which creates confusion.
  • Avoids Fights. Everyone loves to fight about how to format code, picking the native coding style means you're the only one with an actual real argument, everything else is just opinion.
  • Sharing Code. Sometimes you'll have bits of code that don't work and you'll post a snippet on a forum or newsgroup.  It's much easier for everyone to help out if the code looks familiar.  Anytime I see some really crazy formatted code from someone asking for help I skip right over it.  I don't have time to puzzle over their code AND their strange formatting.

3. Catalog your Knowledge

Whether it's a blog, a wiki, or just a big fat txt file you'll want a way to collect the bits.  As a developer you absorb an amazing amount of information each day and you're bound to forget that exact command-line parameter you need to get something working.  Trust me, it's easier to spend 5 minutes writing a blog post or tagging it in than to have to spend another 30 minutes later hunting it back down.

4. Don't Be a Bigot

Don't attack someone just because they don't code in your language or tool of choice.  I see so much energy wasted by people putting down one language or another.  Ruby on Rails developers bashing ASP.NET coders, ASP.NET users coming down on Flash programmers, Delphi developers ripping apart .NET.  Every language and framework has strengths and weaknesses and given the huge number of tools there will be many ways to accomplish the same goals, none of them more correct than the other.

5. Don't become a Framework Programmer

I've sat through some pretty painful interviews when I asked basic programming questions only to answered with, "well, first I'd download this library and then..." or "I'd use this helper method...".  Then when I asked how they'd do it without that library or method I either got blank looks, or my favorite answer, "well, then it couldn't be done".  Knowing that there are great frameworks out there, whether they be .NET, the VCL or Rails, is great, and knowing how to squeeze all the performance out of them is a worthy skill but you will always hit points where you have to go outside the framework.  If you understand programming concepts you can always learn new languages pretty quickly but if all your knowledge is sunk into a single framework it's going to make the transition rough.

Understanding programming as a concept vs. a set of syntax and framework calls also opens up a huge number of resources for you.  Not every article will be written in your language and there is no reason to ignore a great idea just because it's not tailored for your framework/language of choice.

6. Don't just Copy And Paste Code

I have a phrase I use at work that I'm pretty sure annoys the hell out of co-workers, it goes like this, "Don't just copy and paste code, instead copy, understand and THEN paste".  There is a wealth of code samples out there but if you don't really understand what it is you are using then it's going to be a pain in the arse later to debug.  We all have times we just want to get something working but if you don't really understand the code you're using then you're always going to be dependent upon someone else.  It's also important to remember that just because it turned up on the internet doesn't mean it's actually good code.

7. Understand the Sugar

Lately I've seen a few examples in Ruby, JavaScript and C# showing off some great syntactical sugar, shortcuts that make it easy to do things in one line that used to take five or six.  They are impressive and definitely time saving but they come with a cost, usually in terms of performance. 

One example is working with collections in Ruby.  Someone posted a snippet showing how you could replace a "bulky, ugly for-loop" that gathered objects that met a certain criteria and then did "something" to them with a single line of Ruby code.  The Ruby looked sexy, it was small, it was readable, it got ohhs and ahhs.  The for-loop was the underdog at 9 lines, it used nothing but the most basic language constructs.  The problem was the fact that the single-line of code actually went through the collection 4 separate times while the old-school for-loop did it in a single pass.

There are quite a few times where the sugar outweighs the performance hit but it's important to understand what that sugar is really doing.

8. Code for Maintenance

Pretend you're in that movie "Memento" and that you forget everything about your project every night.  You should be able to figure out what's going on the next day fairly quickly just from how the project is structured, it's class names and coding style.  Your variable names should make sense, methods should be tidy, there shouldn't be 15 layers you have to drill through just to do something that should be simple.

Here is a dirty little secret, the easier it is for someone else to understand your code the easier it is for you to hand it off.  If you're the only one that can make sense of your code you are going to tied to that project forever.  Forget getting first pick of new projects, you're now kept in reserve incase you have to do maintenance on your project.

9. Code for Now

As developers we love to code for that future when we may need to add another database back-end or swap out a different rendering engine or port to a different platform.  Guess what, unless those things are actually on some roadmap or written on a stone tablet they will either never happen or will happen in such a way that you'll end up rewriting your code anyway.  I have a ton of old projects littered with extra layers of abstraction that I've never needed and they've gotten under foot more times than they've been helpful.

Dirty Secret: It's always been easier to add in a new abstraction layer than it has been to work with an existing one that was never used.  If you don't need it right now then don't code for it.

10. Stay Abreast of the Landscape

You'll never know everything about programming, it's a constantly expanding landscape but it is a good idea to keep abreast of what's going on around you.  One of the things that has served me best is knowing just enough about other programming areas that I usually have pretty good idea to know where to look for things. 

There is no excuse to not know a little bit about what it is going on these days.  It used to be I got most of my information from magazines and newsgroups, now there are also blogs and wikis, community forums and podcasts.

Dirty Secret #1: Subscribe to at least two different sources that have different views.  Everyone is biased and again, not everyone knows everything.  Usually between an evangelist and a detractor you'll come close to knowing the "real" story about something.

Dirty Secret #2: Read even the boring things.  We used to get a Delphi magazine at work and at first I'd only read the articles that applied to me.  I'd ignore the database and security articles because that's not what I was working on at the time.  Then I got bored and started reading the entire thing each month.  Later, when I started working on a project that was heavy on DB and security I found I already knew a little something about both.

Posted by Shawn Oster on 5/1/2007 2:49 AM | Comments

OK, disclaimer, I actually have no idea if it will or not but in the tradition of bloggers everywhere I thought I'd do a bit of overstatement to grab some eyeballs.  Plus if it turns out to be true I can claim psychic powers.

After looking at a lot of WPF and Silverlight demos it seems that something like the Zune software would be a perfect fit.  It allows for a much greater degree of UI customization and "prettification" while still integrating naturally into the OS.  Looking at apps like Vertigo's Family.Show or thirteen23's Harmony you see the richness of UI that can be achieved while maintaining a functional application.  With the Zune trying to position itself as a social, interactive device you need a software interface that mimics that immersive, social, networked experience and currently the Zune software feels about as social as watching a midnight matinee alone in an empty theatre eating stale popcorn.

Another reason is that many gripe about the Zune software being written on top of Windows Media Player 11 and while the concept doesn't bother me the fact that the Zune team is tied to the WMP team for software improvements does. 

The last big reason I see the Zune software being written in Silverlight is to solve the cross-platform issue.  A lot of criticism is heaped on the Zune simply because it doesn't have Mac or Linux software and while it did take a year for iTunes to come to Windows after the iPod came out newer portable media players don't quite have that luxury.  I haven't done enough research to know how deeply you can hook into the OS, as I imagine you'd have to do to enable some things like the Marketplace DRM and USB device syncing, yet if it is possible you'd have a very strong poster-child for the power of developing in Silverlight.

Of course I can also see the obstacles.  WPF isn't proven yet, in fact I don't believe it's even hit 1.0 status and it requires .NET 3.0, which in turn makes for a larger install with more pre-requisites.  When you're talking about a consumer level device you want the software to be as easy to install on as many computers as possible and using fresh, out of the oven technology isn't always the best way to ensure a 100% trouble-free experience.  Plus the developers now have twice the work-load as they not only need to push the full power of the Zune but they also need to to wrestle with learning the ins and outs of a new tech.

Given all the obstacles though I think there would be a huge benefit in writing the next Zune software version in WPF or Silverlight, both at the Zune level for the degree of interactivity to be gained and for Microsoft as a way to showcase just what WPF can do.

Technorati tags: , ,