In case I haven't made it clear I'm a pretty big fan of being involved in the community.  I don't just mean sending in a check to the Red Cross or other charity, who would be happy to take your money and from which would you get zero feedback - and in a way that's the point.  In most cases just writing a check while valuable gives you the least return on your money.  I mean actually going out there, being involved in a fund-raiser as either a participant or volunteer, donate blood, work at a shelter (human or animal) there are plenty of opportunities to volunteer and instead of it being just a 'bill' you get feedback, feedback that is worth just as much to you as the time you spend is worth to those who benefit.  Even better is when you combine donating money with actual involvement and involvement may be as simple as being a voice to help get an important message out.

I bring this up because with the recent events surrounding hurricane Katrina everyone has been looking at how they can help.    In the case of InterKnowlogy we were lucky enough to have someone in Emilie Hersh who was involved with pastor Bill Jenkins church group in Normal Heights that actually had a point of contact (POC) out in Mississippi.   Given that they had an actual POC (related churches) on the other end it became possible for them to put together a drive to send materials directly to those in need.  Let me pull a little from a recent article from the San Diegoe Union tribune available here: http://www.signonsandiego.com/uniontrib/20050922/news_lz1c22relief.html

"they formed Operation Baby Buggy to collect children's items to take to Hancock County, a rural area in southern Mississippi that got slammed by Hurricane Katrina. She found a truck and a driver. He tapped his contacts back home to clear the way for the delivery.

... The Operation Baby Buggy truck trailer, all 53 feet of it, pulled into a distribution center in Kiln, Ms., Sept. 14.

...Truck driver David Linture said that when he got to the distribution center at the VFW club, members of the Ohio National Guard immediately unloaded the goods. In another part of the center, a line of cars was coming in for care packages."

The nice thing here is that while we could have just written a check, the goods were in some ways more valuable because unless for example people wanted to start using wads of $1 bills to make diapers, the actual diapers were of more value then what they cost because there wasn't anywhere left to buy them.  That's the reason that not just InterKnowlogy but several companies teamed up with organizations that had contacts local to Mississippi and Louisianna to send aid directly where it was needed.

I haven't posted on my road riding of late.  I'm still trying to get out every Saturday (and in fact succeeded on the past two consecutive Saturdays) with the North County Cycle Club.  Including today's ride my current mileage is 5525 which puts me at just under 1,700 for the year and which means I'm only about 325 short of my goal for the year.  The current plan is to make my next ride the new Tour de Poway century ride.  Last year I did the metric century which was 63 miles, so this year they've introduced a new century route that I'm going to take.  Of course my longest rate thus far this year has been like 60 miles so going for a full 100 is a challenge.   On the good side the worst of the elevation is at the start of the ride, on the bad side my mapping software doesn't include one of the new road extensions nor the bike path so there is no way to tell how accurate the elevation profile between mile 80 and the 3rd stop are in the image below.

At any rate my bigger concern is distance since I haven't really got the miles, and I'll be out of town most of the coming week with my plane not landing till close to midnight the night before the ride.  But sometimes you just have to go for it... Of course if this goes well I think I may have to try for one more century before year end - probably a Tour de Cure ride up in Riverside but we'll see how this goes first.

One of the more annoying trends in technology and business is the buzzword.  Often times ideas which are years old are wrapped with a new buzzword and the result is a 'new' technology.  Lets take the current a current example, the XMLHTTPRequest object in Java Script.  Originally introduced with like IE5 this control allows you to make a callback from within a page, retrieve updated content for a portion of your page and then redisplay that portion of your page in the browser.  This is to say the least technology that's been around for quite a while and importantly the market has spoken.  This object although originally used for things like the Outlook Web Access client is now supported across several browsers and is used by thousands of web sites.

In today's example of buzzwords gone wild we have the new term "AJAX" or "Asynchronous Javascript And XML" implemented with... the XMLHTTPRequest object.  That's it, AJAX  means you know how to use this Javascript object to update a portion of your page after the page loads.  Yeah that's a new technology - it's revolutionizing the web if you read the blogs.  It's also be added to toolkit after toolkit, in fact even Microsoftt is in on the act with the Atlas toolkit as blogged by Scott Gu.  This kit like the others goes beyond the 'basics' of using XMLHTTPRequest and allows you to better debug some of your logic since script is notoriously difficult to debug.  On the down side it makes it easier to carry out some 'tricks' as also illustrated by Scott Gu on this other link.

The nice thing about the XMLHTTPRequest object is that it does allow for a richer user experience heck, it's almost half as good as a Windows Form... The key is as you hear about AJAX just keep in mind its not a new technology its an understanding by the IT industry that a technology introduced by Microsoft, adopted by it's competitors, still not standardized by the W3C and already in use on hundreds of web sites can provide a richer web experience.  You'll want to diig up the latest XMLHTTPRequest pages, and if you are using ASP.NET look for the initial release of the Atlas toolkit.

For the future though I'd just like to appeal to the technology world to ease up on the unnecessary buzzwords.  I could post a dozen or more links to AJAX related sites and blogs most of which aren't clear on just what AJAX is. Can't we just say what we mean without trying to apply some marketing term to cloud the issue and hide the what's really going on.  After all don't even get me started on the Web 2.0, which apparently is a term created to justify a conference to web technologies other then HTML... http://en.wikipedia.org/wiki/Web_2.0

So I was up in Big Bear again this past weekend, and it's 'Old Miner Days' right now.  Thus the town of Fawnskin was having a Doo Dah parade so when I went for my ride I headed out through town initially so I wouldn't be trying to return in the midst of the parade.  So after I headed up 3N14 to 3N12 I got a real treat there crossing the fire road was a beautiful coyote.  It was definitely an adult and looked healthy, he calmly finished crossing the road and when I got up to where he crossed I could see him over in the trees looking back at me.  He then headed off before it dawned on me to take his picture (sometimes I'm pretty clueless...).  That in and of itself meant I was having a good ride.

I then headed up 3N12 and down to 3N16, across 3N16 and ran into 3N10.   3N10 is a trail I haven't ridden before so I decided to head off on that trail.  It starts a a pretty straight forward ride for about the first mile or so.  A little uphill but nothing major.  Then it intersects 3N43, this is where there is a sign I've never seen before. 

As you can see the Jim Bull trail has a sign that indicates that it is triple black diamond.  Now to be honest I didn't even realize that the US Forrest Service rated trails.  But since I was out exploring I figured what the heck let's go for it.  Wow.  This is a challenging trail.  There are some areas that are quite passable, and there is alot of climbing (since the elevation peaks a little over 8,000 feet).  However, the real challenge are the rocks which in some places overcome the entire road.  Below is a camera phone picture of a jeep coming down one of these truly nasty sections.

On the plus side though you get some great views as you head up.  Note, when coming from 3N16 the best views are on the way up shortly after the flats, here is one shot out onto the high desert.

However, on this day my adventure wasn't quite done... As I crested this trail I found myself facing an afternoon thunderstorm.  The clouds in the picture below tell part of the story.  Yes for my trip back down the rains began.  I would like to point out that although it was a good 80 degrees fahrenheit when I set out on my ride, the rain was very cold.  It could easily have been hail, although I'm thankful it wasn't. 

So I headed downhill post haste eventually intersecting with 3N32 which took me back down to 3N07 using some trails that aren't on my map (as long as I was headed down I was headed the right way).  This of course brought me back to 3N16 which took me to Polique Canyon Road (2N09) that I could use to head back.  The good news was that by the time I got back to 3N16 the rain had stopped.  The Jim Bull trail is very difficult, and while th view is impressive I can get much the same view off 3N16 which runs up above Baldwin lake.  So I'll probably not be riding this trail again for now - I have other challenges, but if someone wants a challenge, I'm up for most any trail.

As you can tell I'm using this morning to really catch up on my blog posts.  I've been meaning to update them but things were busy and then I was sent on this assignment called 'vacation'.   Turns out I really enjoyed that assignment... I need to post a couple picks of my wonderful neice and nephew, but I'm all ready for a repeat. 

But for now I just wanted to send out a quick reference to a new technical book regarding Visual Studio Tools for Office(VSTO).  The book is being published in September, but I was fortunate enough to get an early look because InterKnowlogy has been doing alot of VSTO work lately and Tim Huckaby (our CEO) spoke at Tech Ed on this topic.  So after Tim took a look at the book so he could say what he thought of it he passed it to me and I put it to use.  The book covers not only VSTO but integration with Microsoft Office 2003 from .NET 2.0.  It talks about how to call office from your application and just as importantly how too build really powerfull VSTO apps.  More importantly it doesn't draw a line in the sand with Word and Excel, this book goes into customizing Outlook and Infopath.  This book covers stuff that some of our IK developers have had to learn the hard way.

The book will be released mid september but there is Addison-Wesley and a portion of Chapter 1 is posted here: http://www.awprofessional.com/title/0321334884

The version of Chapter One I previewed is noticably longer and the book comes with plenty of code samples.  Although it's written in C# instead of my preffered language of Visual Basic I definitely recommend it for anyone who is looking to leverage the power of Office 2003 in their custom application.  Converting samples from C# to VB just helps you really understand the code.

So I started documenting my observations on GUIDs and how they are used in databases in a previous entry and it’s time to get back to this topic.  The original entry which discusses what GUIDs are and the model they typically follow can be found here: http://nerdnotes.net/blog/PermaLink,guid,0ab98866-4d22-4874-bd1d-10ab6fa483b6.aspx

 

This entry is going to focus on why it’s bad to use a GUID as the primary key on a SQL Table.  As I noted in my previous entry, one of the characteristics of GUIDs that make them unique is that they are generated randomly.  On the other hand a primary key in SQL Server uses a clustered index.  A clustered index describes an index where each of the entries in the index is kept in sorted order.   Specifically the idea is that since entries are inserted into the index in sorted order, it is possible to very quickly find an entry without needing to scan the entire index.

 

Key to this discussion is an understanding of the implications of a clustered index.  As with any index in a database, it takes extra time to add an entry into an index.  The advantage of an index is that they speed up lookup on a table.  Sometimes, indexes are unique (such as the one for the primary key) and in some cases they are clustered.  Each of these requirements can slow the amount of time needed to add the latest entry to that index.  The result is that when we work with a table and we start making decisions on what should and shouldn’t be indexed we are looking to balance the cost of doing an insertion or update vs. the speed of doing a lookup.

 

Of the indices you place on your table, the one with the most direct impact on the speed of your database's query is the clustered index which is by default on the primary key.  It is possible to create a  primary key that doesn’t use a clustered index, but this is a rare event and not even considered by most DBAs and developers.  What's important however is the unique characteristic of a clustered index.  Clustered indices are sorted, that is each entry is physically ordered based on it’s sort order.  This is where the difference between an identity/integer based primary key and a GUID based key becomes vital.

 

The way that GUIDs are generated randomly means that unlike an identity column where the next value always sorts after the preceding value, GUIDs are random.  Thus when you need to add this new entry to your clustered index, instead of SQL Server appending the latest entry to the bottom of the index which is a quick and relatively painless operation, it is constantly attempting to insert your new entry into the middle of the index.  Doesn’t sound like a big deal, well it is because it triggers block splits and a lot of additional information.  Not only that but a 4 or 8 byte integer value takes up a lot less space then does a 64 byte GUID.

 

Yes, space, not something we normally worry about anymore, and from the standpoint of your database as a whole it’s not an issue.  It's an issue because of the fact that you are putting this value in an index.  The whole point of an index is that multiple entries can be quickly accessed because each entry in the index is small, but with GUID values aren't small.

 

So this accounts for two easy to verify technical reasons why GUIDs are a poor choice for use as the primary key on your table.  Other reasons include the fact that since SQL Server and .NET v1.1 have slightly different physical representations for GUIDs you are constantly converting between the formats, and the fact that identity values are much more human readable in a test environment as opposed to GUIDs.

 

But aside from the arguments against GUIDs what are the arguments for GUIDs.  Well the first is that since behind the scenes SQL Server applies a row identifier in the form of a GUID you are actually saving space by re-using that row GUID for your primary key.  Of course the fallacy here is that just because SQL Server has assigned a value behind the scenes to the row doesn’t mean you are using that value in your index.  As a result your indexing is still more expensive.

 

More importantly is a common security issue in web based applications.  HTML/CGI developers and their future counterparts in ASP and ASP.NET need a way to identify the user between HTTP requests.  The challenge here is that each HTTP request needs to carry an identifier for the current record in the database, so there is a huge temptation to use the primary key for that record.  The problem is that if you are using identity columns and are passing those integer values, it is very easy for a hacker to manipulate that integer value by adding or subtracting 1 and getting someone else’s record.  This is VERY bad.

 

So one way to resolve this was to use GUID values as the primary key.  This way a hacker couldn’t just shift a digit and get another record, of course they could start guessing at the correct ID for another user or record, but the odds of guessing correctly are incredibly small.  Unfortunately this solution still has a flaw, which is that once a hacker has that identity value even though it’s a GUID security is still compromised.  Fortunately there is a simple and much better solution for .NET developers.  The Session ID allows you to associate each request with data maintained on the server.

 

Session values are temporary and as a result resolve the security issues seen with passing identity columns across the web.  The only remaining reason (that I know of off the top of my head) for using GUIDs has to do with resolving differences across multiple independent databases.  This is another large topic, and so I’m going to put off that discussion until a future post, but suffice it to say for the current discussion that this remaining reason has nothing to do with transaction databases.   Unlike a database which is being used to hold records from multiple different unique sources your transaction database doesn’t need to be concerned with integrating entries from another source… but as I said that’s a topic for another post.

Those that know me are aware that while I ride my road bike near my home on the coast I regularly get up to the Fawnskin/Big Bear area to ride my Mountain bike.  For those who aren’t familiar with the area Fawnskin lies on the North Shore of Big Bear Lake. Unlike my roadie which I ride for miles, my Mtn bike is a pure adventure tool.  So I don’t count the miles I ride on it toward my roadie goals whether I’m doing about an hour with my coworkers in the Flightline area or out for an adventure up in the San Bernardino National Forest.

 

Note with my coworkers the normal ride is about 5 miles and we do it in around 50-75 minutes.  It’s a loop with some steep but by definition relatively short climbs.  The ride is all single track and rather technical.  On the other hand up in Big Bear the rides tend to be long climbs (1-3 miles generally ascending) for literally a thousand or more feet and then the accompanying downhill.  A good example is my original ride up Polique Canyon Rd. to 2N71 across to 3N12 down to 3N14 and into Fawnskin.  The ride is about 10 miles and the first 5 miles climb from the lake elevation of 6900 feet to an elevation of ~8000 feet, followed by an equal down hill back to town.

 

This past 4th of July holiday weekend I decided to explore a new route.  I’ve been taking a more challenging route that takes me up Polique Canyon (2N09) and then across Holcomb Valley (3N16) to 3N12 which brings me back to 3N14 just south of the YMCA camp so I descend down into Fawnskin.  This has a massive 2.5 mile climb up 2N09 followed by a very tough climb up 3N12 (before it descends).  Overall the goal, since these roads aren’t very technical (rocks and difficult handling) is to ‘keep it on the middle ring’ and when I’m fresh I can do just that.  So this weekend it was time for a new challenge.

 

I had already gone to the east on 3N16 out toward Baldwin Lake, so I wanted to go west.  What I saw on my map indicated that I could continue a short distance past 3N12 and hit 3N08 and that it would take me around to 3N14 down below the Hanna Flat campground area.  So this was my new route.  The first 4 miles took me to the top of 2N09.  The next 4 miles took me down into Holcomb Valley, across to 3N08 and started me along 3N08.  These 4 miles were mostly rolling hills and some sand, nothing too difficult.  Then I got into 3N08.

 

3N08 is the first fire road that I would classify as 'difficult'.  Now over the course of 3N08 (heading West) you are loosing elevation, but it isn't a downhill ride.  In fact there is a lot of climbing and a lot of it up steep inclines.  Areas that definitely call for the granny (little) front chain ring and your lowest gears.  The down hills are very steep and ugly with lots of rocks.  This is a tough downhill and I know I’m not ready to head up this road yet.  

 

A word of warning however, the first time I road this I started to doubt my map.  After all fire roads are exactly well documented and the map I use sometimes has minor errors.  As you ride along you have a beautiful view of a river valley and on the other side are the mountains between you and Fawnskin/Big Bear.  Now of course along the way my thought was "uh-oh I'm on the wrong mountains! When do I go across (there aren’t many suspension bridges in the forest)?  Where am I really going?".   My concern was if the map was wrong I was headed to Green Valley Lake and was going to be calling home for a ride back.   Of course, by the time it became an issue I was past what I considered to be the point of no return so I continued forward.  The net is the next 4 miles down 3N08 go on forever and you are literally out in the middle of nowhere, but you can’t miss 3N14, because this part of 3N08 dead-ends into this much larger fire road.  At the same time 3N08 is very technical to the point that there is one downhill section that I walk because of the jutting rocks that could cause major bodily injury.

 

Once to the 'bottom' of 3N08 you hit 3N14 right in the river valley.  This gives you a long 2 mile climb up 3N14 (a more well maintained/traveled fire road) past the Hanna Flat campgrounds and the YMCA Camp Whittle and down into Fawnskin.  The views off to the north-west while climbing 3N14 are great and I'm pretty certain that was Lake Arrowhead I could see off in the distance.  All told you are looking at about 17.5 miles depending on where you start.  It was a very challenging ride and one I repeated a second time so I could be more comfortable on it in the future, of course the future is tomorrow at this point... so I'll be out on the roads again on Saturday morning.

After logging in, be sure to visit all the options under Configuration in the Admin Menu Bar above. There are 26 themes to choose from, and you can also create your own.

 

One of those things that happens when you ride a consistent route is it's nice to get a feel for your best time.  Of course the trick is remembering your previous best time. Today Tim tracked our time out on the standard Flightline route that he, Adam and I have been riding since they started the environmental destruction to put in a couple new roads through our local mtn. bike area.  Today's time was 50 minutes 42 seconds.  So next time we need a reference we can get one.... we can do better... it's only 5 miles.

Time for a more technical entry here in my blog.  As you can probably tell, I have a pretty strong belief that my blog, should not be a flat one-dimensional product.  After all it's important that we maintain interests outside of our job, so as I sit here watching a bit of OLN's Cyclism Sunday I figure I'll put in a quick technical entry before I go for my own Sunday ride down the coast.

In this case I want to talk about the use of GUID's.  First I'm going to talk about the characteristics of what a GUID is...  Historically of course Microsoft introduced the GUID structure around the same time that UUID's were introduced.  SO let's start with what's a UUID.  Good definitions are available here: http://www.dsps.net/uuid.html and here: http://www.opengroup.org/onlinepubs/9629399/apdxa.htm.  As you can see the UUID is defined as a Universally Unique Identifier and it is a 128 bit or 16byte value.  A value of this size is represented bya seres of hexadecimal (base 16) pairs.  This format is the same one used by Microsoft in the implementation of the GUID.  One of my favorite lines which I remember hearing from a Microsoft employee was that Microsoft had named their implementation of UUID as GUID, because they didn't consider a value of this size to be unique across the universe but hopefully something which would be valid at the global level. 

in part I'm going to allow Microsoft to give us a complete defintion available from MSDN here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemguidclasstopic.asp  I happen to really like this definition from Microsoft because it clarifies something which people sometimes mistake: GUIDs are NOT guaranteed to be unique.  In fact let me quote the way that Microsoft phrases from this page: "Such an identifier has a very low probability of being duplicated."  This is an important statment because it recognizes the reality that GUIDs aren't guaranteed to be unique and shouldn't be treated as such in every instance.  The reason that a GUID can be treated as unique is that it uses a number range that is large enough to make random generation of the same values a low probability.  However, it is the use of random generation which also causes GUID's to repeat before the entire range of values can be used.

So what are the 'system' characteristics where a GUID makes sense?

Let me break the answer into a series of bulleted characteristics:

• A decentralized model where several disconnected or different systems need to generate identifiers.
• Identifiers will generally be unique. (meaning they might not always be unique, so uniqueness is not a true requirement)
• it should be possible to easily change the identifier assigned to any given system with little or no impact to account for those instances where a duplicate GUID is created.  
• the order that the identifiers are created and assigned should have no impact on behavior.

So what are some example systems where these characteristics fit well, well for starters the 'system' for which they were originally created, as identifiers for objects.  For developers using Microsoft technology GUIDs became famous during the progression of COM.  As an object is created a unique GUID is assigned to that object and when deployed those objects which may have been created by any software vendor should be unique.  Every now and then a collision does occur and sometimes those collisions even make it out into the world at large, but when that happens the next version of software can change out the GUIDs associated with that software with little or no system impact.  (Yes I've seen it in comercial products and I would prefer to not name the vendor involved, but in short they had an object which collided with a GUID used by a driver on certain PC's) Similarlly the value of the GUID that is assigned to an object does not change the performance of that object either during installation or at runtime.

Of course developers fell in love with this model and became focused on the word 'unique' in the title.  As a result, whenever a developer thinks they need a 'unique' value they immediately think of GUIDs.  However there are situations where a GUID is not a good solution, and in fact SQL Server presents a common one.  So in my next post I'm going to discuss why GUIDs should never be used as the unique identifier for rows in a transaction database.... I'll also discuss how a transaction database is different from a data warehouse and as a result why a GUID might work just fine for that solution.