Jodie and I went furniture shopping this weekend.  Our basement furniture is really starting to show its age (10 years) and it is time for a replacement set.  We found a really nice oversized couch and chair + 1/2 set at a local furniture store (BTW – I did not know that there was such a thing as a chair + 1/2).  The furniture seemed very well made, the style was nice and it was available at a very reasonable price.  We were concerned about the size of the pieces in the set; we have a nice finished area in our basement, but way the floor plan is laid out limits the area in front of the television where you would put a couch and a chair.

We could have bought the furniture and had it delivered and then started trying to figure out where to place the pieces, but I thought I would do some paper prototyping instead.  Using the measurements of the pieces that I got at the furniture store I used newspaper and tape to lay out the dimensions of the furniture.  It was then very quick and easy to figure out that the space was too small for the oversized furniture.  About $2.00 worth of supplies and 30 minutes of time avoided a potential fiasco with figuring out that we had bought the wrong furniture.

In software development we get really hung up on prototyping.  How many times have you been in a conversation about how all the work done up to this point was a “prototype” and should be considered “throw away” code?  I personally have seen prototypes carry on for months, which is not a good use of time or effort. 

I blame a lot of the problems we have with prototyping on the tools that we chose to prototype with.  Quite often we use a high fidelity tool like Photoshop, Visio or PowerPoint (and I am sure you can add to the list).  The rest of the time we use the actual development tools that we would use to build the finished solution like Visual Studio, Flex Builder, Expression Blend, etc.  It is no wonder that our non-technical partners are confused at why this is a prototype when it looks like a real application.

There are technology solutions that allow you to have electronic low fidelity prototypes; Expression Blend’s sketchflow and balsamiq are two that come to mind.  Those tools are fantastic, but you should try just using simple paper prototypes as well.  There is no more rapid prototyping than laying out screens and workflows using a few sheets of paper and a sharpie.

Note: My story about the furniture would not be complete unless I told you that Jodie and I disagreed on our concern about the size of the furniture.  We were both concerned that it was too big, but I was concerned about how it would fit in the room, Jodie was concerned that the couch would not be able to even get down the stairs.  It turns out that we were both right, but I got a blog post out of my paper prototyping.

Last night I was hanging a cabinet at home and I wanted to make sure that it was centered on the wall.  I took measurements of the wall size, the cabinet size and where the anchors would have to be on the back of the cabinet.  Then I did some addition and subtraction to figure out where I would have to drill the anchors and marked the holes on the wall; this is the point where you are really committing to the process – making holes in your wall.

Right before I started to drill the holes I remembered a piece of advice that my father gave me when I would help him with home improvement project:  “Measure twice, cut once”.  Now my father did not invent this concept, but I think he did a great service in teaching me the concept.  So before I drilled the holes in the wall, I grabbed my yard stick and measured their location again.  Turns out the first time that I measured, I marked the right hole at 11 1/4 inches from the wall and not the desired 11 3/4 of an inch from the wall (I was holding the yard stick upside down to measure and it is easy to make the mistake in that case).  Since I measured the 2 holes separately, I would have wound up not being able to hang the cabinet at all and would wind up patching one of the holes (which would turn a 15 minute project into a 2 day project).  Taking the extra 2 minutes to measure twice saved me from a lot of effort.

As with many things, I tried to relate the situation to technology, and in particular software development.  The easiest analogy to make is to software deployment and testing.  Deploying code is like putting the holes in your wall, you are really committing.  Testing is expensive, but not as expensive as having to patch software after the fact.  I am not advocating just running the same tests twice; normally you get the same results each time that you run a test (data differences aside, that is how software usually works).  I think I am advocating running two totally different types of tests in order to double check your work.  Maybe the best practice is to run a battery of tests and then to create a new set of tests independent of the battery that you ran before looking for edge or failure tests that you did not anticipate.  Then the next time that you run those test you can fold those into the core test suite.  Just thinking out loud….

Regardless of how you “test twice, deploy once”, you should be approaching your project with that mindset.  It might make you father proud.

My oldest son started college a few weeks ago.  It was a real generational shift for me in a number of ways because some part of me still thought that I could fit in on a college campus. As Zachary and I went through the application process, orientation this summer and finally move in day at his dorm this summer I quickly realized that the only time that I would fit in on campus is parent’s weekend and I am not 100% sure that Zachary would even want to hang out with us then. 

I don’t appear to be the only one to have gone through a generational shift in the last ~20 years.    The dorm rooms themselves don’t seem to have changed much since I lived in one, the size, furniture and even the smell is exactly as I remember them.  The changes that I noticed involved the technology that was installed and what the kids brought with them.  I thought it might be interesting to chronicle them.

Telephone
By Esparta Palma
Used Under Creative Commons

The telephone was a critical part of my dorm room experience.  Each room had one and they were a part of the campus PBX (Private Branch Exchange), so you could dial anywhere on campus just using the 4 digit extension.  While the phone was useful for calling other dorm rooms and around campus, it’s most important feature was the critical lifeline back to your home, where you could reach your parents and more importantly, their wallet.  You did have to jump through several hoops in order to reach the outside world, by getting a calling card or a long distance plan hooked up to your phone.

I got a bit of a shock when the residence life director at Zachary’s school told us that the dorms did not have any phones.  He said that the building where still wired for them and you could get a phone hooked up if you jumped through several hoops, but they were no longer standard issue.  It is easy to see why, all of the kids carry cell phones, although none of them actually talk on the phone, they just text message back and forth.

A word processing typewriter was something that I bought just before I showed up on campus.  Mine was not a just an average type writer; mine had memory, a spell checker and a display screen that showed you the better part of a sentence and a half of what you had just typed.  Mine was so advanced that you did not even have to physically be typing in order to work on your document; you could type the whole document and then print it out.  Word processors and there old fashioned cousins the typewriters were still common when I showed up to college, but they did not last long.  In the 4 years I was an undergraduate and 2 years I spent in graduate school the typewriter became an antique.  However the changes kept on coming, when I left college laser printers were a luxury (still running at $.10 a page to print) and you could count on one hand the number of color printers on campus.

A small TV with Rabbit Ear Antennas was standard issue when I went to school.  I remember how much time my roommate and I invested in finding the optimal location for the antenna for each of the 5 broadcast stations in the area and how one of the stations had a different position during the day than at night.  It was a lot of work, but all worth it so that we could catch that hot new show “Star Trek the Next Generation”.  During summer vacation I was able to save enough money to buy a 4 head VCR, so that we could set about achieving our goal of watching “Blade Runner” 100 times.

Now days all the dorms have cable television and most rooms sport a flat panel TV set.  Many of the TVs have gaming consoles attached to them.  But the kids these days are just as likely to watch TV on their computer as they are on the television.

We had a very efficient computer network when I was on campus, if you needed to copy a file you put on your shoes and walked over to the computer lab.  Now you had to go to the right computer lab the first couple of years that I was in college, because not all of the labs were networked together.  If the file was bigger that the disc size you had you jumped through a bunch of hoops with various zip or packing utilities to get it moved over.

Zachary has the choice of using the wireless networks in the dorm room, or if he needs a better connection, he can plug into one of the 2 wired connections in the room (they had to put something in where the phone jacks were).

I love it when I experience great customer service, when people go above and beyond to make your experience just that much better.  Maybe I am lucky, but it seems like about once a week I have an above average experience.  It has happened to me a couple times already this week; the customer service rep on the phone who reversed a fee even though they did not have to and the waitress who brought my son a cupcake because they were out of the dish that he ordered and he had to “settle” for another one.  I normally would not write about fantastic customer service here, but I got an interesting e-mail about an outage that Netflix experienced that is an example of great customer service (I got the e-mail on Tuesday, September 1, 2009):

The most interesting thing about this is that I did not try and watch any Netflix Movies or TV shows on my XBOX on Monday night (ironically I was watching an old school Netflix DVD: Slumdog Millionaire).  For the record I did not request the 3% credit on my billing statement, I would feel too guilty if I did.

I am not sure the criteria that they used to send this out to their customers, but I can tell you that I do watch movies and TV shows on my xbox quite regularly so I am clearly a customer who might have been affected by this outage.  They could not have sent it out to only those people who were affected because it was an outage, they don’t know who might have been affected.  Netflix was proactive in acknowledging the fact that they had a technical issue and proactively “making it right for their customers”.  They did not wait for the customers to call and complain to get a credit, because they know that many people would not and just think the service was unreliable.    Other companies could learn a lot about dealing with outages by following the Netflix example..

So I posted a quick blurb on my Facebook wall yesterday that I had taken a new job within Microsoft:

I got a lot of well wishes.  And I want to thank everyone who did either post on my wall or sent me an e-mail with the congratulations.  I also should have predicted a few questions and I figure rather than try to answer them all in those tiny comment boxes, that I would put up a post here and fill everyone in with more details.  But first a bit about my old job.

Most people know that I am currently an evangelist for Microsoft, a position that I have held since January of 2007.  I won’t bore you with the details that there are different flavors of evangelist and evangelist will focus on different segments of the technical community, but I will just say that I am an audience architect evangelist.  An evangelist is an interesting position, because we are the face or Microsoft to people who write code on our platforms.  It is a fun job because the people who do it are paid to do what they naturally love: technology.  But enough of my old job, on to the new job, and to answer some of the questions I got about it.

I am going to be an Account Technology Strategist working with some customer accounts in Wisconsin.  I joked with one of my teammates that I had to take a job with a title that was as “interesting” as evangelist and I think strategist is pretty close (although I will not get jokes about wearing a white suit and preaching the gospel of .NET).  Some of the ways that the job is different are:

Smaller geography.  In my old role I was responsible for Microsoft events and community outreach in 3 states: Wisconsin, Illinois and Indiana.  I went from Green Bay, WI to Decatur, IL to Bloomington, IN (fortunately not all the in the same day).  My new job keeps me much closer to home, which fits nicely with some changes in my personal life.

More Technology.  In my old role I focused primarily on Visual Studio, the .NET Framework, Silverlight and Internet Information Server (I would touch on other technologies on occasion, but most of the time it was .NET and the related technology).  In my new job I am the primary technical contact for all Microsoft technologies.  Not sure if you looked lately, but we have a lot of those.  Fortunately, I get to bring in specialist for specific questions on some technologies (I personally know a lot about the platform, but come on, that is a lot to learn).

Fewer Customers.  As an evangelist, my customer base was anybody writing code (not just Microsoft code – because we did more than preach to the choir).  Depending on how you counted it, that was close to 200,000 people in the three states.  In my new job I will have just a handful of customers to work with.

Deeper Engagement.  As part of working with just a few accounts, I will have the opportunity to spend more time with each customer.  Evangelism is about scale and reaching a larger number of people, being an ATS is about having a close partnership with a few customers.

I think Scott is asking if I am still going to be active in the local technology community.  I am personally very passionate about the community. I did not go to user groups, code camps, conferences and barcamps because it was part of my job, it was something that I liked to do (It was a bonus that I could also call it “work”).  So you will still see me around.  I no longer work for the part of Microsoft that is helping to foster and build communities, so it is something that I will have to juggle with my job, but that makes me like everyone else that goes to user groups after a hard day at work. 

In my previous job, I helped to secure Microsoft sponsorship of a lot of cool local events (RIAPalooza, MOSSCamp, IndyTechfest, Barcamp Milwaukee, Drupalcamp Wisconsin and the list goes on).  I don’t have the direct connections to do that anymore, but never fear I am still good friends with someone who does have those connections.

Yes, Rob, I will have to “dress up” for my new job.  This is a long running joke with Rob Nottoli and I.  Rob thinks that evangelist show up to meetings in jeans, shorts, pajamas or whatever else they find lying around on the floor.  I will really miss that part of the job.  :-)

For the last 2 1/2 years Microsoft DPE has been putting on a series of events called ArcReady (short for architecture readiness).  We have run the events in the area that Microsoft calls its Central Region (which is the 18 states in the middle of the United States between Canada and Mexico and Nebraska and Tennessee).  The events have been interesting and well attended and I thank each and every person who took the time to attend one of the 35 events on 10 different topics that I personally helped to deliver in Wisconsin, Illinois and Indiana.  But ArcReady as an event series has come to an end. 

We started the ArcReady series because our customers were telling us that Microsoft had a lot of great developer tools and technologies, but we did not talk enough about architecture; that we focused on products and not solutions.  You talked and we listened and created ArcReady and (we think) delivered that architecture message very successfully.

After a year we launched another series of events called MSDN Unleashed, which was the developer oriented companion to the ArcReady series and we ran that from September to this last may in the afternoon (right after the ArcReady events).  We heard from our customers that many of you did both development work and architecture work (you wore both hats).  You did not want separate topics between the architecture and development sessions.  You also did not want to have to take a whole day off work in order to hear our architecture and developer discussions.  You also wanted us to continue to talk about solutions and not just products.  You talked and we listened.

So we made the following changes:

• We eliminated ArcReady as a separate event and as a separate name
• We will have architecture conversations during our developer events
• We will focus on solutions and include Real World applications and case studies in all events
• Our events will be 1/2 day, so as to have less impact on your work schedule
• We have gone back to the MSDN Events name for developer events (no more Unleashed)
• We will also added a 1/2 day event for IT Professionals under the name TechNet Events if you prefer to talk about servers and networks instead of code – these TechNet Events will also include an architecture discussion

We hope that you like the changes to the event format.  We know that your time is valuable and we want to make your investment of that time in one of our events as rewarding as possible.  If it is not, please talk to us and we will listen.

Announcing Real World Azure with Microsoft IT

Our first event under the new format will be on cloud computing and specifically the Windows Azure Platform.  Cloud computing is a big topic in the industry these days, Microsoft is not the only player in the space, but we are pretty proud of our Windows Azure Platform.  This topic will talk about the nuts and bolts of the platform, but will also showcase an application built on the platform, “Project Austin”.  Here is information on the TechNet Events and MSDN Events.

TechNet Events Presents – Azure for the IT Professional

In this event, we will discuss:

• Azure architecture from the IT professional’s point of view
• Why an IT operations team would want to pursue Azure as an extension to the data center
• Configuration, deployment and scaling Azure-based applications
• The Azure roles (web, web service and worker)
• Azure storage options
• Azure security and identity options
• How Azure-based applications can be integrated with on-premises applications
• How operations teams can manage and monitor Azure-based applications

Dates & Location (click on city name to register)

8/18/09 - Columbus, OH
8/19/09 - Mason, OH
8/19/09 - Downers Grove, IL
8/20/09 - Indianapolis, IN
8/20/09 - Dallas, TX
9/16/09 - Grand Rapids, MI
9/17/09 - Southfield, MI
9/17/09 - Overland Park, KS
9/17/09 - Houston, TX
9/22/09 - Cleveland, OH
9/24/09 - Waukesha, WI
9/24/09 - Austin, TX
9/29/09 - St. Louis, MO
9/29/09 - Nashville, TN
9/30/09 - Knoxville, TN
10/1/09 - Chicago, IL
10/27/09 - Bloomington, MN

(All TechNet events are from 8:30am to noon)

MSDN Events Presents – Azure for the Developer & Architect

• Cloud computing architectures in general and the Azure architecture in particular
• Several aspects of Azure from the developer’s and architect’s perspective
• Azure roles (web, web service and worker)
• Azure storage options
• Azure security and identity options
• How Azure-based applications can be integrated with on-premise applications
• Configuration, deployment and scaling Azure-based applications
• How development teams can optimize their applications for better management and monitoring

Dates & Location (click on city name to register)

8/18/09 - Columbus, OH
8/19/09 - Mason, OH
8/19/09 - Downers Grove, IL
8/20/09 - Indianapolis, IN
8/20/09 - Dallas, TX
9/16/09 - Grand Rapids, M
9/17/09 - Southfield, MI
9/17/09 - Overland Park, KS
9/17/09 - Houston, TX
9/22/09 - Cleveland, OH
9/24/09  - Waukesha, WI
9/24/09 - Austin, TX
9/29/09 - St. Louis, MO
9/29/09 - Nashville, TN
9/30/09 - Knoxville, TN
10/1/09 - Chicago, IL
10/27/09 - Bloomington, MN

(All MSDN Events are from 1:00pm to 5:00pm)

Update on 6/28 – I did a Thirsty Developer interview with Doc List, about Open Spaces and the unmeeting that we held.  Check out the Episode Page or Listen to the show.  I also made a minor change to the text below (moved one of the titles down a paragraph).

I think pretty much everyone has heard of the concept of the Open Spaces (or its close cousin the unconference) Open Spaces are:

A facilitated participant-driven face-to-face conference around a theme or purpose. (according to the unconference blog) 

Recently some of my teammates gathered together to talk about planning our direction for the next year (the Microsoft fiscal year runs from July to June).  We had a day together and a lot of items to cover, as you can imagine planning the direction for a large team for a full year will give you a lot to talk about. 

I got the task of putting together the agenda, which is a tough when you have limited time and lots of material.  Brian Prince, my friend and colleague from Ohio, put out the suggestion that we should try to apply the Open Spaces Technology to our planning meeting.  Our boss, Brian Moore, is always willing to let us try things that are unconventional (with a few caveats that I will mention later).  So eight of us set about having a meeting that used some of the Open Spaces principals or what I am dubbing an unmeeting.

Applying the Open Spaces Principles

With open spaces, there are 4 principles that guide the event.  They are very Zen like, which is why you generally have a professional facilitator to help guide you through the application of the principles.  The principles are:

1. Whoever comes is the right people
2. Whatever happens is the only thing that could have
3. Whenever it starts is the right time
4. When it's over, it's over

I got to serve in the role of facilitator for our “unmeeting”.  We did a number of things to apply the Zen like principles.  Our plan was to have 6 attendees at the event, but we discovered that we needed more “right people” there.  So we recruited a couple more people (including one that we picked up at a happy hour the night before).

The majority of our agenda was driven by a combination voting / consensus process (we used post in notes on the whiteboard with tick marks).  We also modified the conversation throughout the day, which was important because there were a couple of topics that did not fit into nice hour long segments.  And of course was not problem with everyone knowing that the meeting was over, after a long day of planning, it was obvious it was over. 

In addition to the 4 principles of Open Spaces, there is one law…..

Another key difference between the unmeeting that we held and the traditional Open Spaces is that the “Law of two feet” was somewhat modified for our purposes.  The law of two feet can be summed up as:

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute.

No voting with your feet at our unmeeting

The law of two feet is great when you have choices of the activities to participate in; many Open Spaces events will have multiple sessions going on at the same time.  If you are not getting something out of your current session, it is great to be able to leave without you or the other people feeling awkward.

Our unmeeting did not have breakouts, so the only option was to leave the room for a while (which we encouraged if you needed a mental or physical break) or to lose focus on the proceedings by getting lost in your e-mail.  We tried to discourage non-topical use of your laptop during our proceedings (I as the facilitator used some creative techniques as you can see from the photo).  This was somewhat a violation of the law of two feet, but part of this was driven by our culture as a company. 

Most of you have probably never been to an internal Microsoft meeting (unless you work there).  The great majority of the meeting has the Microsoft folks all affixed to their laptop screens dealing with the avalanche of e-mail we get on a daily basis (we try to behave ourselves better when we are at a meeting with customers and partners).

The boss is still the boss

One of the things that was different about our unmeeting was that it was commissioned by our boss and he did have a specific set of outcomes that he needed to accomplish at the conclusion of the meeting.  As a result, he did dictate that we cover a few agenda items. 

If it was a true Open Spaces, the participants could have chosen to ignore topics that they did not want to cover, but this was an unmeeting.  We accommodated the “mandatory” sessions by putting them on a different colored sticky from the other topics during the voting/consensus process.  The participants still got to choose when in the agenda that we covered the mandatory sessions, but we had to work them into the day.  Other than that, our boss did not really rule the meeting with an iron fist (despite the picture).  He did serve in the role of the “expert” as we would have questions about the outcomes that we were trying to accomplish.

Overall I think we had a positive experience applying the Open Spaces Technology to an internal meeting.  I would encourage considering how you could apply the principles and law at your work.

At the Chicago Code Camp this last month (May 30th) I got to see a great presentation by Micah Martin (@slagyr) entitled “Ruby Kata and Sparring”.  Micah’s presentation was in a very “Zen” style and the majority of his talk was about the importance of practicing your coding skills.  He talked about how we can learn from two common types of training that are used in the various martial arts:

Kata - detailed choreographed patterns of movements practiced either solo or in pairs…most commonly known for the presence in the martial arts

Sparring - relatively 'free-form' fighting, with enough rules, customs, or agreements to make injuries unlikely

After he introduced the concept of Kata, he showed us a demonstration using a well known exercise called Langston’s Ant.  Micah bowed to the audience (as is typical in Kata) and proceeded to  “live code” his implementation from scratch and ended with another bow to the audience (also typical).  The Langston’s Ant has no perfect solution, so he then asked the audience to rate his code and to give him feedback on how to improve his implementation.

One of the things that struck me was how Micah answered the question “It seems like you are very practiced in writing this solution, how many times have you done this?”.  Micah told us that he had done the solution more than 50 times.  He did point out that he had not done the same implementation 50 times (as if he were practicing giving a Langston’s Ant demonstration), but had evolved his implementation over the course of his Kata sessions.  His 50th solution was “better” than the first solution as he had refined it; just like your technique should get better as you practice your martial arts.

I personally need to get a coding workout.  I am an evangelist for Microsoft, but that actually involves a lot less coding time than most people would think (the amount of time varies from individual to individual, some of my colleagues code a lot more than others).  A field evangelist for Microsoft is typically a technology generalist, having to cover a real breadth of technologies.  As you may know, Microsoft has a lot of technologies, so we spend a fair amount of time immersed in learning new things and not necessarily practicing our coding skills.

Over the course of the summer, I intend to get a coding workout; knock the rust off or sharpen the saw as it were.  I am going to practice a coding exercise every week (unless I take a week off for vacation; which I would totally unplug for).  To keep myself honest, I am going to post something about each workout up on the blog, even if it is to admit a FAIL.  Look for the first post next week: Coding Workout: A twitter badge using jQuery.

Note: I have been on an un-planned blogging hiatus for the last 2+ months.  It is not that I have not had things I have wanted to say, but have just been short of time to say them.  For those of you who have stuck around (kept me in your RSS reader or checked the site for updates), I thank you for your patience. I did want to write a “Sorry for not blogging” post (I hate those – just start blogging!).

This past weekend I took a flight and I did something that I normally do not do, which is pay attention to the flight crew as they give their safety briefing.  Years of air travel have given me the ability to recite the standard briefing in my sleep, so normally I read a book.  One of the first things they tell you in their safety briefing is to get out the briefing card and follow along, since I was paying attention this time, I decided to play along.  As I looked at the briefing card, I was struck by how much information that they could fit into such a compact space and with so few words, because they leveraged the pictorial so well.  Here is a quick glimpse of one of the pictures that gives the complete procedure for opening up the emergency exits and getting out of the plane:

Image from Aero Safety Graphics

I have been really interested in the concept of pictures as better documentation than words for a while.  I think my fascination was first spurred on by Mike Rhode’s sketchnotes.  I even asked Mike about it in the Thirsty Developer Podcast Dave and I did with him last fall.  I was specifically asking about pictures, graphics and typography in the design stage at the time, but I think the concept applies equally well (if not better) to the finished product.  It is a great way to show the business process that a software application can support.

Furniture Instructions

Multi-lingual by default?

In addition to capturing lots of information in a small space, pictures done in a certain style have the advantage of being multi-lingual by default.  Take the instructions that I got with the some assembly required furniture pictured here.  The instructions are able to tell me a lot without using any words, and thus does not need to go through the long, tedious and expensive process of being translated to multiple languages.  A real cost saving move if the product is being sold in different countries.  This particular instruction manual only had one page with writing on it that needed to be translated.  That one page was translated into 8 different languages, so clearly that was the intent of the designers to go global with the single document.

Not for every situation

Clearly there are times when pictorial based instructions could be overkill for a situation.  I can think that the contrast to “A picture is worth a thousand word” could be “Eight words is quick than a 1/2 dozen pictures”.  I do think there are situations were pictures could really enhance documentation, so maybe we can learn a thing or two by paying attention to airline safety briefings.

As I mentioned previously, I spoke to the Architecture Special Interest Group (SIG) of the Indianapolis .NET Developer Association (IndyNDA).  Steve Porter, who is in charge of the group, asked me to present when they founded the group last September and it took a few months for our schedules to align and I am glad that they did.  Steve asked me to do the “in person” version of my Architecture by Baseball series of articles.

I have to admit at first I did not see the value in standing up in front of a group and covering things that I had already written.  As I was putting the presentation together, however, I realized that there are a lot of things that I had not covered in the articles themselves add a lot of color to the topics presented in the written form.  I had a lot of fun putting the talk together (which I did at the last minute, the night before) and had even more fun delivering the talk to the group (about 35 people or so).    Thanks to Steve and to all those who attended the talk.

I promised I would make the deck available to the people there and thought I would share it here as well.  It is up on My Slideshare Account: