# Monday, October 10, 2005

After seeing Serenity, I was really jonesing to watch the Firefly series again, but alas, my copy was lent to a friend and thence disappeared into oblivion.  So…

I ordered a new copy, and it showed up on Friday.  Pure goodness.  I’ve gotten through the first 4–5 episodes already.  What’s not to like?  The dialog is fantastic, the future both well crafted and highly plausible, and the acting was quite good for what it was.

It’s always a joy to watch Joss Whedon’s shows.  It’s nice to know that there’s someone out there who doesn’t assume their audience is composed entirely of knuckle draggers.

Monday, October 10, 2005 2:54:14 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

I upgraded both this blog and my food blog to the tip of the dasBlog CE 1.8 source, and had no problems at all.  I love how smoothly the content upgrader from 1.6 works.  I’m digging some of the new features too, including built-in support for FeedBurner

Kudos yet again to Scott and Omar et. al.

Monday, October 10, 2005 10:28:53 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, October 03, 2005

Kudos to Joss for making such a good transition to the big screen.  Vikki and I went to Serenity yesterday, and we were both impressed.  I thought they did a great job of preserving the best parts of the show, while coming up with a story that could be self-contained in two hours. 

Several reviews I saw complained about the lackluster special effects.  To them I say:  that’s not the point.  The effects were comparable to what was in the show, and that’s all that was required.  If you spend all your time on effects, you end up with something as crappy as Episode II.  The whole point to Firefly/Serenity is the character development. 

I do think that if you haven’t watched the show you won’t quite grasp some of the subtler bits of the film, but probably not so you’d notice. 

Overall, well worth seeing whether you’ve seen the show or not.  If only they’d stuck with more of the banjo music…

Monday, October 03, 2005 9:42:06 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, September 30, 2005
How cools is this?  The first ever pictures of a live Giant Squid.  My son has been completely fascinated by these things for years, so he’ll freak when he sees these shots.  Getting pictures of a live Giant Squid has long been the holy grail of marine biology, which makes these images that much cooler.
Friday, September 30, 2005 9:44:15 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, September 29, 2005

The long awaited movie version of Joss Whedon’s brilliant TV series Firefly opens tomorrow.  I’m all aquiver with anticipation.  The show was fantastic, and the previews of the movie look pretty darn good too. 

Joss, man, everything you do is art!

Thursday, September 29, 2005 1:11:11 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

September and October are the very best months here in Oregon.  Yesterday was truly spectacular.  Bright sunshine, clear blue skies, 45° in the morning, 75° by lunch.  The leaves are just starting to turn, and it looks like they are going to be something else this year. 

I also love that when I walk to work from the bus stop in the morning I often see Killdeer and a Great Blue Heron hanging out in the field across the street. 

Thursday, September 29, 2005 1:05:33 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 

Scott turned me on to TiddlyWiki a while back, and I’m totally diggin’ it.  I decided to use it for my latest Web Services class at OIT, and so far I think it will work out well. 

For those who haven’t seen it, TiddlyWikki is a self-contained, all DHTML wiki.  Just one HTML file filled with JavaScripty goodness.  It has very nice editing features built in, so all you have to do is keep slinging the one file around, and it’s all there.  I don’t have to worry about installing any server side code on my hosted site, and can edit the file basically anywhere FTP works. 

There isn’t much there yet, but if you want to take a look at an example, my class site is here.

Thursday, September 29, 2005 1:02:22 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, September 27, 2005

Since our beloved husky-German Shephard Saffy passed away in July we’ve been casually shopping for a new dog.  Vikki and I both decided we wanted something smaller, and mellower.  In short, something that will be content to just hang out, and doesn’t take up too much room. 

Last week we found what we were looking for in the form of Carter.  He’s a Chihuahua/terrier mix that we got from the animal shelter.  About a year and a half old, had his shots, neutered, some puppy school.  All is good.  He’s a bit of an escape artist, but when he’s not escaping, he pretty much just wants to hang out with us, and he’s about the same size as our cat.  Perfect. :-)

Pictures to follow.

Tuesday, September 27, 2005 4:08:42 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 

I’ll be starting the class I’m teaching this term at OIT tomorrow night.  Introduction to Web Services.  There’s still time to get in on it.  CST 407.

Tuesday, September 27, 2005 4:04:41 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, August 23, 2005

I’m not actually dead.  Here I am posting.  I’ve been doing a lot of design work lately, and have reached a generally introspective period, so not posting much lately. 

That said…

I was trying to come up with a way to make asynchronous requests from a web server to a back end system.  Like really asynchronous.  Fire and forget, no socket open on the network, etc.  Maybe implemented as two one-way web services, whatever.  The glaringly obvious fact is that given the nature of HTTP, the web client has to block, since an HTTP request/response is by its very nature synchronous and blocking.

So, the solution I came up with was to do the blocking in the one place where it matters, which is in the web client.  It depends on sending some kind of correlation ID between client and server, and back.  So sending the message from ASP.NET might look like this:

    public WaitHandle Send(Envelope env)

    {

      WaitHandle h = new AutoResetEvent(false);

      string correlation = Guid.NewGuid().ToString();

      env.CorrelationID = correlation;

      lock(correlationToWaitHandle.SyncRoot)

      {

        correlationToWaitHandle.Add(correlation, h);

      }

 

      ThreadPool.QueueUserWorkItem(new WaitCallback(DoSending), env);

 

      return h;

    }

 

This will do an async send to your back end, keeping track of a WaitHandle by the correlation ID.  That way, you hand the WaitHandle back to the client, who can wait on it as required by HTTP.

In the mean time, the DoSending method has gone and sent the Envelope to your back end.  When it’s done, it sends the response back to the client machine by whatever means (I’m using ASMX web services) and calls the PostResult method with the response…

    public static void PostResult(Envelope env)

    {

      if(correlationToWaitHandle.Contains(env.CorrelationID))

      {

        AutoResetEvent are = null;

        lock(correlationToWaitHandle.SyncRoot)

        {

          are = (AutoResetEvent)correlationToWaitHandle[env.CorrelationID];

          if(are == null)//this shouldn't happen, but would be bad.  Other option is to check Contains again after lock.

            throw new InvalidOperationException("Threading problem!  CorellationID got removed before lock!");

        }

        lock(waitHandleToResult.SyncRoot)

        {

          waitHandleToResult[are] = env;

        }

        are.Set();

      }

      else

      {

        throw new ArgumentException("unknown corellationID","env");

      }

    }

Look up the wait handle associated with the correlation ID, since we need it, and it’s all the client has at this point, then take the response we got back from the server and store it against the wait handle.  Finally, signal the wait handle, so the client will no we’re done.  When that happens, the client will stop waiting, and call the Receive method to get the results.

    public Envelope Receive(WaitHandle wh)

    {

      Envelope result = null;

 

 

      if(waitHandleToResult.Contains(wh))

      {

        lock(waitHandleToResult.SyncRoot)

        {

          if(waitHandleToResult.Contains(wh))

          {

            result = (Envelope)waitHandleToResult[wh];

            wh.Close();

            waitHandleToResult.Remove(wh);

          }

        }

        lock(correlationToWaitHandle.SyncRoot)

        {

          correlationToWaitHandle.Remove(result.CorrelationID);

        }

      }

      else

      {

        throw new InvalidOperationException("No response received.");

      }

     

      return result;

 

    }

We look up the stored result by the wait handle, clean up our hashtables, and return the result to the client.

For the sake of simplicity, we can go ahead and wrap this in a synchronous method for the client to call.

    public void SendAndWait(ref Envelope env)

    {

 

      WaitHandle h = Send(env);

      if(h.WaitOne(TimeSpan.FromSeconds(90.0),true))

      {

        env = Receive(h);

      }

      else

      {

        throw new RequestTimeoutException("Timed out waiting for server");

      }

 

    }

That way all the wait handle stuff is hidden, and the client just sees their response come back in the [ref] Envelope in a synchronous fashion. 

By decoupling the client from the server this way, we not only get better control over how many threads are running in our server side implementation (although there are other ways to do that) but we also aren’t dependent on the ability to hold open a network socket from client to server during the time it takes to process the request.  Normally that’s not an issue, but it can be a problem in certain circumstances. 

Tuesday, August 23, 2005 2:39:05 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |