Thursday, 28 September, 2006

Jim, where is your shirt?

When I was seven years old, my dad moved us to a house that had a swimming pool. We five children, ages four to ten when we moved in, spent the next five or six summers in the back yard, swimming in the pool, jumping on the trampoline, sunning ourselves, or running around like a pack of yard apes as kids are wont to do.  It was a wonderful way to grow up.

The back yard also contained a very large covered patio with two huge (hey, I was a little kid) picnic tables, some lounge chairs, and an outdoor fireplace where we'd sometimes roast marshmallows at night. Every afternoon, Mom would make a plate of sandwiches and bring them out to the patio, setting them on the picnic table and calling us and whatever friends were there to sit down and eat.

I'd sit down prepared to dig in and Mom would say, "Jim, where is your shirt? You know you can't eat lunch without your shirt on." Whenever we sat at that picnic table, we wore shirts. Even my sisters had to put on shirts to cover their bathing suits before they were allowed to sit and eat.

Almost 40 years later, at my own house now and making lunch to eat out by the pool, I sit down at the table and hear my mother's voice in my ear: "Jim, where is your shirt?" Honestly, I get up to find a shirt, even if that entails walking back into the house and digging one out of the dresser drawer. I think I just might experience a mental break were I forced to eat lunch without my shirt on.

I think others have similar tales: times when they hear a parent's voice in their heads, or rituals that they engage in due to upbringing.  We all have them: the way we tie our shoes, the food we call "comfort food," the way we brush our teeth or groom ourselves. The shirt at the dinner table thing is one of my favorites to relate because it shows how seemingly insignificant things from our upbringing affect our lives in so many ways.

Anybody else have random things like that? Things that you don't even think about, but strike other people as odd?

Wednesday, 27 September, 2006

Insulted for the crime of being courteous

Part of my daily bicycle commute has me riding about a half mile on a sidewalk through a neighborhood association's greenbelt.  The sidewalk is meant for bicycles as well as pedestrians and it shaves about a mile off my ride.  More importantly, it keeps me off a busy two-lane road that has no shoulder.

Most days I encounter people walking on the trail.  If I approach from the front, of course, it's rare that I need to attract anybody's attention.  I slow down and make eye contact, though, to be sure that people really do see me coming by.  I smile and say hello, and then continue on my way.  But when I approach from behind I have to warn people that I'm coming by.  Not only as common courtesy, but also as a safety measure.  Many people are walking dogs or walking with children, neither of which I'm particularly interested in colliding with.

As I approach from behind, I get within range where I can say "bicycle behind you" loud enough to be heard, but not so loudly that I'm screaming.  I always slow down, of course, and if the person does not acknowledge, I will repeat it, "bicycle behind you", in a louder voice and much closer.  Most people hear the first time.  Almost all hear the second.  Without fail, they thank me for making my presence known and they ensure that there's room for me to pass.

Periodically I come upon somebody who's listening to music or somehow otherwise so preoccupied that he (or she) doesn't hear my warning.  Since I don't feel like screaming to scare anybody, I just ride slowly by and hope that he doesn't take that moment to start his Fred Astaire routine.  All good, right?  Except that almost every time I do this, the person with the music blaring in his ear will yell obscenities about rude bicyclists.  It's absurd.  I'm in too much of a hurry and too non-confrontational in any case to turn around and explain that I made my presence known but he was too involved in his music to hear it.  Probably best in any case, as it's doubtful that such actions would have a positive effect.

There's a hike and bike trail near the house where I ride my mountain bike from time to time.  I perform the same ritual there and experience the same results.  Conversations with other bicyclists have confirmed that this is a common problem.  We do what courtesy requires and yet we're verbally abused because some people don't have the common sense to turn down their music so that they can hear what's going on around them.  What, exactly, are these people thinking?

Monday, 25 September, 2006

Odds 'n Ends

Yes, I've been a little busy and haven't taken the time to keep up here.  Perhaps later in the week I can spend some time on it.

Wednesday, 20 September, 2006

The Endurance 50

Dean Karnazes is attempting to run 50 marations in 50 consecutive days, in 50 states.  He started on Sunday the 17th.  Today he's in Little Rock, Arkansas.  He calls the event The North Face Endurance 50.  He also maintains a blog, Endurance Is.  This is some seriously impressive craziness.  I've run marathons, and I can tell you first hand that the last thing most runners want to do the day after a marathon is get up and run another one.

In the world of ultramarathoners, Dean Karnazes stands out.  Men's Fitness said he "might just be the fittest man in the world."  He regularly does 100 mile ultramarathons, and once ran 350 miles non-stop:  foregoing sleep for three consecutive days.  He's a mountain biker, surfer, triathlete, and I don't know what all else.  His book Ultramarathon Man is an international best seller.  Most people look at what this guy does and just shake their heads over the insanity of it all.  Not me.  I know what kind of dedication it takes to do what he does.  I'm impressed by anybody who sets a goal and continually works toward it.

I'm also quite impressed by the Endurance 50 web site.  This an an excellent use of Flash, and the site is very well designed, pleasing to the eye, and easy to navigate.  It displays the necessary information in an attractive design, without any extraneous bells and whistles.  It's a pleasant departure from all too many sites that look as if they were designed by people who think, "more is better."

Monday, 18 September, 2006

Blog Changes

I spent some time over the weekend adding a Title Index to the blog here, and also rearranging the monthly archive pages.  In the past, the monthly archives had URLs of the form /diary/year/year_month.htm.  That is, the archive for October 2005 was http://www.mischel.com/diary/2005/2005_10.htm.  I don't remember how I came up with that convention, but it's kind of wonky.  I've changed things now so that the URLs are of the form /diary/year/month/index.htm, so that if you want to see entries for October 2005, you can go to http://www.mischel.com/diary/2005/10.  I've created redirect commands so that the existing old-format URLs will work, but there won't be any old format URLs for new months.

I suspect that the Title Index will be useful mostly to me.  In almost six years of blogging I've covered a lot of different topics, and I find myself referring back to them quite often.  I've been using Google to search the site, but I think the Title Index will be much easier and it will prevent me having to filter the Google search results when I know that what I'm searching for is in the entry's title.

I've said before that I'd like to move to a different blogging program.  The problem is finding the time to convert everything, and I dislike the idea of trying to keep two blogs in sync for even a short period.  I'm pretty sure now that I won't be installing WordPress or any other blogging sofware on my server.  I am, however, considering either moving the blog to one of the blogging sites, or switching to a provider who includes blogging software as part of the hosting package.

Wednesday, 13 September, 2006

Finding new music in unusual places

I was sitting in the conference hall this afternoon, working on an article and listening to the music they were playing while waiting for the next session to start.  I can block out most music if it's not too loud or incredibly offensive, but when something out of the ordinary comes on I get shocked out of my zone.  Such a shock came when what sounded like Mariachi music started coming from the speakers along with lyrics in Spanish.

Then I laughed out loud when the language changed to English, singing one of my favorite wacky songs.  This rendition is different, though:  Flaco Jimenez singing En El Ceilo No Hay Cerveza (In Heaven There Is No Beer) in Spanish, English, and Dutch.  Definitely laugh-worthy to me, and enough to get me to buy his latest CD.

Tuesday, 12 September, 2006

Flashforward2006

I'm at the Flashforward2006 conference in Austin today, tomorrow, and Thursday.  I honestly don't know how many people are here, but it's a lot.  I heard somebody say 300, but I think there were at least 500 in the audience at the keynote.

It's impossible to get an unbiased view of a product or technology when you're at a conference that's specifically about that product or technology.  Almost everybody here has a vested interest in the success of Flash and wouldn't be here if they didn't think there was a very bright future for it.  Still, there are many things to indicate that Flash will only grow in popularity.

At the keynote, Kevin Lynch, Chief Software Architect at Adobe and formerly a major player in the development of Flash for Macromedia, gave us some interesting statistics on the adoption of Flash.  Version 7, according to Lynch's numbers, was adopted at the 70% level in about 12 months.  Flash 8 reached 80% adoption within 9 months of its release.  For Flash 9, which was released less than two months ago, Adobe is projecting a 50% adoption rate in three months, with 80% adoption in six months or less.  With major sites like MySpace and YouTube already including Flash 9 content (YouTube has standardized on Flash 9), those projections are probably realistic.

From my perspective, the key new features in Flash 9 are the new runtime and the JIT compiler that converts Flash bytecode to native code.  The result is that Flash 9 applications have much better performance than previous versions.  During the keynote today they demonstrated a particle animation effect in Flash 8 that was trying to run at 33 frames per second.  Computing the particle effect took a little more than 100 milliseconds per frame, so their real frame rate was something less than 10 fps.  The same application compiled for Flash 9 takes about 15 ms per frame, giving them plenty of time for other things while still maintaining 33 fps.  Flash 9 doesn't have the performance of .NET, but it probably could.  Right now, there's probably a 10x performace hit running Flash (that is, for CPU-intensive applications, a native application will run 10 times as fast as a Flash application), but that's still plenty fast.  Flash 9 applications run faster today than native applications ran in 2000.  One can only assume that Adobe is working to improve the ActionScript compiler and Flash player's performance.

With Flash 9 we have a cross-platform (they demonstrated the Linux version at the keynote) virtual machine that can play video and audio, and perform animations.  With the new Flex 2 framework, it's possible to create real interactive user interface applications that are richer and perform better than equivalent Ajax applications.  And the best thing is that, for all practical purposes, every Internet user has the Flash player or can get it painlessly with a simple download.  Microsoft even ships an early version of Flash with Windows XP, and the Express Install feature will upgrade the Flash player seamlessly.

About the business of Flash, I'm less sure.  The people here do seem to be excited about the future, and almost all of the presenters have mentioned that their companies are hiring Flash developers (artists as well as ActionScript programmers).  It's possible that this is all a lot of hype reminiscent of the late '90s Internet boom, but it doesn't feel like that.  I honestly believe that there is a lot of room for innovation in Flash and a lot of opportunity for small developers.  It will be interesting to see, three or four years from now, whether I'm right.

Thursday, 07 September, 2006

When modal isn't really modal

The Flash application framework, MX, provides a powerful and easy to use platform for creating user interface applications.  In many ways it's similar to the .NET Framework, and similar packages that I've used in the past.  However, there are key differences that will surprise a newcomer.  I ran into one this morning when I wanted to create a modal dialog box that would gather information and return it to the caller.

When you create a modal dialog box in Windows, execution of your main program is halted until the dialog box is closed.  The simplest way to illustrate this is with a message box:

public int SomeFunction()
{
    MessageBox.Show("Hello, world");
    // next statement will not be executed
    // until the messagebox is dismissed.
    return 1;
}

When the message box is displayed, execution is transferred to the code that handles the message box and the user cannot interact with the main program.  The same holds true for modal dialog boxes.  In Windows.

Under Flash, things are a bit different.  As with Windows, a modal dialog box in Flash prevents the user from interacting with the window or form that spawned the dialog box and execution of the main program is suspended until the user dismisses the dialog box.  The difference is when that suspension takes place.  Under Windows, it's immediate.  In Flash, program execution continues until your program returns control to the Flash virtual machine.  Consider this method that is executed when the user presses the "New Game" button:

    private function startNewGame() : void
    {

        var dlg : NewGameDialog;
        dlg = NewGameDialog(PopUpManager.createPopUp(this, NewGameDialog, true));
        // do some stuff
        return 1;
    }

In this function, execution continues in the function after the popup is created.  Flash displays the dialog and disables the caller's user interface until after the dialog box is dismissed.

What does it mean?  A program can't just display a dialog box and in the next line of code get the results from that dialog box.  Instead, the program has to display the dialog box, return, and then wait for a message or event to indicate that the dialog box has been dismissed so that the program can harvest the results.  It's a much different programming model than Windows.

I'm not saying that either way is better than the other--just that Flash is different from other systems and it's going to take some time getting used to the new model.

Wednesday, 06 September, 2006

Bicycle commuting: lessons learned

Over the past two months of almost daily bicycle commuting I've made a few observations about the reactions of drivers to bicyclists, and also learned a few things to watch out for.  Fortunately, none of those lessons have involved me hitting the pavement.

  • Most drivers are friendly enough and will go out of their way to make room for me:  letting me pass in front of a turn lane, and moving far to the left side of the lane when they pass.  I don't let that lull me into a false sense of security, though.  I'm careful to make eye contact and telegraph my intentions before putting myself in front of a moving car.  It only takes one mistake to become road pizza.
  • In general, drivers are much more courteous during the morning commute than they are in the evenings.  The worst time to be cycling on the road is between about 4:30 pm and 6:00 pm.  Drivers seem to be in a very big hurry to get home, and they'll do stupid things like cut me off in a turn lane just to save a second or two.  Friday evenings are especially bad.
  • There's one exception to the above rule.  Drivers get more anxious and much less indulgent as they get closer to their destinations.  My route to work takes me by a large office complex into which many cars turn each morning.  Because it's near the bottom of a pretty good hill, I'm usually moving at a pretty good clip--30 MPH or so--when I go through that intersection.  I position myself at the left edge of the right turn lane rather than on the shoulder so that I don't get hit with a right hook (scroll down to tip #4) by somebody making a right turn.  That's all well and good until some idiot whips past me at 40 MPH, swerves into the turn lane, and then slams on his brakes to slow down for the right turn.  I pass by on the left two seconds later, thinking not-nice thoughts about the driver.  Next time I'm going to rap on the window of the car as I go whizzing by.
  • Although it's fun to zip along on the shoulder at 20 MPH, passing a miles-long line of cars stuck in traffic, it can be dangerous.  Not having to worry about an inattentive driver plowing into me from behind, it's tempting to let my guard down and crank away unaware.  This morning that almost cost me.  I looked up and saw a car making a right turn into traffic--right in front of me.  Traffic on the road had stopped to let this guy in, but he hadn't seen me barreling toward him.  I'm glad I have good brakes.
  • Briefly stated, The Law of Gross Tonnage says, "thou shalt not argue with anybody whose vehicle outmasses your own."  In nautical circles it's a matter of physics: a larger craft is much less maneuverable than a smaller craft.  When applied to the world of cars and bicycles, it's more a matter of common sense.  I'm not about to try to insist that a driver yield to me.  Although many would yield, it only takes one inattentive or malicious driver to ruin my day.

We can complain all we want about drivers being clueless or even discourteous, but that's not going to change.  As much as I wish that drivers would pay closer attention and look out for bicycles, it just doesn't happen.  If you're on your bicycle sharing the road with cars, it's in your best interest to assume that the drivers don't see you, to always make eye contact before putting yourself in harm's way, and always leave yourself an out.

Sunday, 03 September, 2006

Tales from the Trenches: The Forth Incident

In my first games programming job, I took over development of a game that the original designer had started.  He had written a "first playable" version that included basic game play and graphics.  My task was to work with the publisher to complete the design, and then implement that design.  The contract called for a Windows version and a version for the Macintosh.  Since we didn't have any in-house Macintosh experience, we contracted with another development firm to complete the Mac version.

The entire project was written in C.  We wrote all of the internal game logic to be platform independent so that it could compile without change on either platform.  I put all of the Windows-specific user interface code in separate modules, and had a very strict separation between platform-specific and platform-independent code.  Such was common practice, and it had worked well for us in other projects that we had developed for multiple platforms.  All the other programmer had to do was develop the Mac-specific user interface and attach it to the base game logic.  Simple, right?

The first few milestones in the Mac port came and went, with the programmer showing good progress on the port.  One day, however, we got a call from the owner of the other development house.  He had to fire the programmer who had been working on the game.  Why?  Because the programmer--a very junior developer who was working at his first job--had decided that it would be easier to throw out the 20,000 lines of fully-tested platform-independent C code and replace it with entirely new code written in Forth.  Let's just say that none of us involved in the project were very happy about that.

I don't have anything against Forth as a programming language, and I'll be the first to admit that my C code didn't present the best possible interface, but discarding a large body of existing and proven code in favor of something new is almost always a bad idea.

This "throw it away and start over" mentality is very common among junior developers who don't understand that things are usually much more difficult than they appear.  They think that it's easier and faster to rewrite code from scratch than to take the time to study and understand the existing interfaces.  Besides, implementing user interface code isn't nearly as cool or interesting as developing core game logic.  And we all know how programmers will favor cool and interesting over tedious UI hacking.

Ultimately, of course, the blame lies squarely on the project manager who let several milestones go by before performing even a cursory inspection of the code.  Had he examined the programmer's work at the first milestone, it would have saved him a whole lot of time, money, and heartache.  He had to pull a programmer from another project so that they could finish our contract in time.

The moral of the story is twofold.  First, a complete rewrite takes longer than you think, especially if you don't fully understand what you're rewriting.  Not only that, the new code probably has a large number of non-obvious bugs that probably existed in the old code, but were fixed over time.  The old code, as clunky as it might appear, contains a whole bunch of hard-won knowledge that will almost certainly be lost in a rewrite.

Secondly, programmers need supervision, especially junior programmers at the beginning of a product development cycle.  You have to live with your early decisions throughout the product cycle, and any mistake you make early on will be very expensive to fix as time goes by.  It's imperative that managers keep an eye on the development team's early decisions.

Saturday, 02 September, 2006

Odds 'n Ends

I guess it's a good thing that I've been too busy lately to find little filler snippets for my Odds 'n Ends box.  Just a couple of notes today.

  • As an exercise in learning more about the new Flash 9, David and I have built an anagram/crossword finder.  It's been an interesting experience, and has required us to learning a surprising amount about ActionScript and the internal workings of the Flash runtime system.  If you play with it, I'd appreciate any feedback.
  • The annual Women's Adventure Race will be held in the Austin area next Sunday the 10th.  We can always use volunteers to help out with many aspects of the event.  The Williamson County Amateur Radio Club will be providing communications again.  If you're interested in volunteering to help at the event, contact volunteer@womensrace.com.  If you want to help with communications, contact me by clicking the "contact" link on the left.

Friday, 01 September, 2006

Working with Console Screen Buffers in .NET

The second article in my series about making the full Windows Console API available to .NET programs has just been posted to DevSource.  This article, Working with Console Screen Buffers in .NET, describes screen buffers and their use.  Screen buffers allow you to pre-compose console output in an offscreen buffer and then make that buffer active--effectively redrawing an entire screen in a single operation.  The ConsoleScreenBuffer class that I developed also provides some much more flexible output methods that aren't available in the standard System.Console class.

Full source code for both articles, including many examples in C#, is available here.