Don't Blame the Compiler

It's been a busy week without much time to blog.  In the mean time, here's a good reminder.  It's Always Your Fault.  Jeff Atwood explains why it's always the wrong idea to blame your tools.  New programmers especially see something they don't understand and assume that the tools (compiler, OS, libraries, etc.) are at fault.  While this is sometimes indeed the case, it is so rare that it's not worth considering.  Even if you do see an issue in the compiler or OS, you are unlikely to be able to get it fixed so you'll have to understand the issue and work around it anyway.

Which Language To Learn Next?

Once you have mastered one programming language, it is a good idea to branch out and learn some others.  Each language is optimized for different things.  Knowing multiple will give you a larger set of tools one of which which may solve the problem at hand better than others.  Additionally, and more importantly, different classes of languages approach problems very differently.  Learning languages from other groups will expand your thinking even if you stick to one language for most of your programming tasks.  C++, Java, and C# are all from a similar language class.  Languages like Lisp or Smalltalk are not.  Learning those requires learning new ways of thinking.  Christopher Diggins from Dobbs Code Talk presents a list of languages he recommends learning and what to get from them.  If you are looking to expand your horizons, check it out.

Your Hard Drive Probably Isn't Running At Full Speed

Here's a little known fact that could speed up your life.  Most SATA hard drives in the market today ship in 1.5 Gb/s mode instead of the 3.0 Gb/s mode they are capable of.  I know for sure that Seagate and Maxtor both ship retail drives with jumpers set to the slower mode.  I can only assume that this is for compatibility reasons.  Unless you need the compatibility though, you can get some extra speed out of your drive by changing the jumpers.  Look on the drive or in the manual for which jumpers to change.  It usually inolves merely removing the jumper but check to be sure.

Ten Years Later...

It was ten years ago today that I joined Microsoft as a full time employee.  When I started we were just finishing Windows 98.  Microsoft was around 25,000 employees.  My first job was testing DVD playback in the operating system.  Since then I've reported to 5 managers, resided in 5 buildings, occupied 8 different offices, and shipped 6 operating systems.  I also had a hand in shipping several versions each of IE, Windows Media Player, and Windows Media Center.  Ten years later, something like 17 products under my belt, and I'm still having fun.  I guess I chose the right profession.

Audio Not Keeping Up With HD Video?

Here is an interesting read about how the audio in HD TV is not keeping up with the video.  People are buying 1080p TV sets.  The networks are paying more attention to the quality of their video, but they are not yet doing much with the audio.  Many movies recording in 5.1 are broadcast in 2 channels. 

The article posits that this will change in 2009 when everything goes digital.  I'm not sure I agree.  Most everything is practically digital today.  There are people watching SD with rabbit ears, but they're in the minority.  Most people get their TV via cable or satellite.  Even so, there's still a whole lot of SD content out there.  Will turning off the analog broadcast airwaves make the need for that SD content over cable go away?  Probably not.

This article also highlights the tension between audio engineers and those holding the purse strings.  How much do people actually care about better quality audio?  The failure of SACD and DVD-Audio along with the heavy adoption of MP3 even in its overcompressed form would seem to indicate not nearly as much as we audio types would hope.

http://production.broadcastnewsroom.com/articles/viewarticle.jsp?id=329804

 

Update on Windows Home Server Corruption Issue

The WHS team has an update on their blog regarding the corruption issue.  In short, they fully understand the issue and are working on a fix.  The issue is at a low level of the operating system and so requires a lot of testing to be sure that the fix works and that it doesn't break anything else.  The ETA for a fix is June 2008.

 

Update is here.

Four Years and 300 Posts Later

It was four years and approximately 300 posts ago that I began this blog with a simple hello world.  Thanks to everyone who has taken the time to followed me during that time.  It has been an honor to write for you and to receive feedback on my ideas.

Now back to our regularly scheduled programming...

Suggestions for Smoother Meetings

A few weeks ago I attended a training and had an opportunity to try out the ideas generated from my earlier training.  As part of this most recent training we had an exercise where we were divided into two groups.  One group represented the technical team for a company.  The other group represented the marketing team.  We were presented with a series of possibly projects for the company to work on and asked to come up with a unified, prioritized list. 

Time Boxing.  We began by working as separate teams.  I was on the technical team.  One of the things we did early was to turn our work into a time-boxed activity.  We would take 1 1/2 hours before meeting with the marketing team.  After that, we would take 1 hour to merge the lists and 1/2 hour to write up the results.  Within our 90 minute time block, we set aside 1 hour to brief each other on our respective projects and 1/2 hour to actually rank them.  Setting up time boxes before the meeting began helped us not just to stay on track, but kept us on topic.  If the conversation started wandering afield, someone would just note the time and we would quickly wrap up that part of the conversation and get back to the central task.

It can be tempting to just dive into a meeting, but if the topic is contentious or open-ended, setting up boundaries beforehand can be essential to a successful outcome.  Having time bounds forces people to prioritize their actions and items that are interesting but not terribly relevant will be reduced.  People will self-select the most important parts of the conversation.

Search for Consensus.  When we merged with the other team, our lists looked quite different.  Our #1 item was their #2 but their #2 was our #5 (out of 6).  Other items were a little jumbled up.  The teams immediately started hashing out which was the most important for #1.  This argumentation would then carry down the list as we discussed each relative position.  I took a moment to look at the lists.  Upon deeper investigation, the lists weren't too far apart.  After their #2, we were within 1 position of each other on most items.  Thinking back to our internal discussions, we had decided on a decision framework to pick 1 long-term and 1 short-term item to be at the top of the list.  They had 2 long-term items at the top.  I inserted myself into the conversation and explained our decision framework.  Could they agree to such a framework?  They could.  With that agreed upon, we could focus our efforts arguing which long-term project to go after, but the loser would then fall to the bottom of the list.  We would be spared bubbling it all the way down the list.  This helped us get to total consensus on the list in less than the allotted hour.  Looking for consensus points rather than disagreement helped frame the conversation differently and removed much of the contention.

I've seen a similar technique used in stack-rank meetings.  At Microsoft come review time, we put the whole team into a ranked top-to-bottom list.  Sometimes there are ties in the middle but most of the time it's a complete list of the team from most valuable to least valuable for whatever criteria we decide on (future value, current contributions, etc).  What I have found to be very successful is to ask each manager to come prepared with his/her list already in a stacked order.  Then the meeting can focus on merging the lists.  The pre-created lists reduce the contention considerably.  Rather than having to argue each person's merits individually, it is possible to argue only key points.  If we have two lists:

List 1	List 2
Person A	Person E
Person B	Person F
Person C	Person G
Person D	Person H

and we can agree that person B is better than person E, we don't have to discuss person A.  If we can then agree that G is better than C, we only have to decide on the C,D,H merge.  We don't need to argue that F is better than C because that comes by default when G is better than C.

The same techniques can be applied to many other areas.  Look for points of agreement and focus on those rather than on points of disagreement.  This will narrow down the places where disagreement exists and thus narrow the bounds for argument.  It will still be important to hammer out agreement on the contentious issues, but if the arguments can be focused on only a few points of contention, a better decision will be made and it will take less time to get there.

Hello World Podcast

MacBreak Tech has a recent podcast talking about learning to program.  They begin with the question "how do I start programming games" and break it down.

1. Pick a project.  Don't learn for learning's sake.  Learn to accomplish something.  It will give you a structure to hang your learning on.


2. Pick a language.  They suggest Python, Basic, and Flash.  Those aren't bad places to start.


3. Book or class?  Think about your learning style.  Classes force the pace.  Books are often better than reference material.  They make a cohesive whole out of all the parts.


4. Borrow code.  Think about starting by modifying something someone else has already done.

Of course, the podcast is a little Mac-centric.  They don't mention Visual Basic or C#, but most of the content is applicable to any language.  If you have an MP3 player and are wondering where to start, try this podcast.

 

What Tests Belong in the BVTs?

BVTs or Build Verification Tests are standard Microsoft parlance for the tests we run every day to ensure that we didn't break anything important with our checkins the day before.  I've previously written about the importance of keeping them clean.  Within the range of tests that consistently pass, which ones should be in the BVT?  BVT test failures should be something you're willing to act on immediately.  In other words, the failures must be important.  Based on that, here are some criteria:

• Test major scenarios not minor ones.  If major features are failing, they will be fixed right away.  If a minor feature is failing, it should be noted, but may have to wait until later to be fixed.
• Test majority use cases, not corner cases.  Tests for the interaction of 3 parts shouldn't be in the BVTs.  Tests outside most user scenarios shouldn't be in the BVTs.  While every book on testing says to test the boundary conditions, the BVTs may not be the place to do that.  Instead, pick the most likely to be used values and scenarios.
• Run "positive" not "negative" tests.  By that I mean, don't send out-of-bounds conditions or invalid values.  These are valid tests and should definitely be run, but not in the BVTs.  An API faulting when sent a null pointer should be fixed, but the fix can wait until next week.

BVTs should be a carefully guarded set of tests.  They need to run quickly, consistently, and their results should matter.  If these rules are followed, the BVTs will be effective because failures will be respected.  Restricting the BVTs to the most important scenarios will ensure that the results are given the appropriate respect.

Drobo + Windows Home Server = Goodness

I've been using Windows Home Server (WHS) for a little over a month now.  While there is still an issue with data corruption if you work on files directly on the server, as a backup tool, it is great.  The system is practically foolproof.  Install the server, install the connector software on each machine in the house, and let it go.  Every night it will back up each computer.  In addition, it makes a great location for centralized files.  The shares are readily available from each machine.  Additionally, it can stream media to devices around the home.  I've been using mine for backup and centralized storage but I haven't actually played with the media streaming yet.

For the backing store on my WHS, I have chosen to use a Drobo.  Drobo is essentially an easy-to-use, flexible RAID solution.  It's not really RAID, but it's similar enough that thinking of it as a RAID isn't going to cause problems.  The advantage of the Drobo is two-fold.  First, it duplicates everyone on the machine.  WHS shares can be marked for duplication.  In that case, each file on the share is stored on 2 drives in the server.  However, the backup files are not themselves backed up.  The Drobo mirrors or stripes each file so they are all backed up.  In this way, losing a single drive won't cause the loss of any data.  The second benefit is that it makes for a slightly cheaper storage solution.  Because WHS uses redundancy for its backup model, it can only effectively use 1/2 of the drive space.  Drobo uses striping so with 4 drives, it can effectively use 3/4 of the drive space.  This makes storage a little cheaper.  However, you have to add in the cost of the Drobo so it's not really significant.  Of course, you have a Drobo afterwards...

Setting up the Drobo with WHS was trivial.  Ars Technica indicated early on that the Drobo wouldn't work with WHS but I found that not to be the case.  I had the 1.1.0 firmware on my Drobo and WHS saw it as a 2TB USB drive.  I was able to just add it to my drive pool. 

A few pieces of advice:

First, WHS treats all non-primary drives the same.  If you have the Drobo plus another drive in your storage pool, you'll lose much of the benefit because any files placed on your non-Drobo will not be backed up.  If you use a Drobo, use only a Drobo.  The Drive Extender Migrator will migrate all files off the primary drive to one of the secondary drives.  Stick with only 2 drives in the machine (boot/primary + Drobo) and everything will land on the Drobo.

Second, turn off all duplication of folders.  The Drobo already does this for you.  It just wastes space to duplicate further.

Finally, WHS seems to set aside 10% of a drive for shadow copies.  Because the Drobo appears as a 2TB drive, this means it will take up to 200GB for shadow copies.  You can see how much is actually being used with the Drive Allocation add-in.  To lower the amount of space allocated to Shadow Copies:

1. Log into WHS via remote desktop


2. Open My Computer


3. Right-Click on the C: drive and select properties


4. Select the Shadow Copies tab


5. Click Settings


6. Select c:\fs\B (or similar) share


7. Now change the limit.  I'd recommend 10% of the space you actually have on the drive.

Note that this is totally unsupported.  I think it's safe but I can't promise.  Do so at your own risk and only if you are comfortable playing with this part of Windows.  If you don't understand the instructions, don't try to follow them.

Note:  I'm not on the Windows Home Server team.  Nothing said here is official.  In fact, using a RAID-type solution with Windows Home Server is unsupported.

Is That A Wiki In Your Pocket?

Here's a cool little tool I discovered recently.  It's called DokuWiki on a Stick.  DokuWiki is a PHP-based wiki that stores its data in text files instead of a database.  This makes configuration and backup a little simpler.  DokuWiki on a Stick takes MicroApache and marries it with PHP and DokuWiki in a small, 6MB package.  There is no install necessary.  Everything runs out of the install directory.  This makes it perfect to take with you.  Throw it on a thumb drive and you can carry a wiki in your pocket.  Why would you want to do that?  Wikis are great for documentation.  Whenever you have something you want to preserve, just open the wiki and add it.  Whenever you have something to look up, just open the wiki and take a peek.  Better still, because this wiki uses text files for storage, it should be pretty simple to merge it with a live web-based wiki running DokuWiki so you can keep a personal copy of your wiki with you at all times.

 

To simplify the execution of DokuWiki on a Stick, create wikistick.cmd in the same directory and put these commands in it:

start .\mapache
start http://localhost:8800/

Then you are a double-click away from running.  I suppose you could even set it up to autorun off of your thumb drive if you were so inclined.