Silverlight 3.0 and Why Flash Still (unfortunately) Won

Last week Silverlight 3.0 was released.  In Toronto, ObjectSharp put on a very cool launch event, with lots of great demos and compelling reasons to start using Silverlight immediately.  I was impressed, but I’m a Microsoft fan-boy (fan-boi?), so that doesn’t count.  It was certainly fitting that ObjectSharp propose using Silverlight for some parts of our new website, seeing as they won the bid to build the new site.  I saw the potential; as did a few others on the team.  However, some executives did not see the benefit.  I respect their opinion, somewhat because I have to – they can fire me after all, and mostly because they have business sense on their side.

The company is very much on the cutting edge of technology in a few respects, but very conservative in the way we choose technology.  For instance, our new site will be built on Microsoft Office SharePoint Server 2007.  I’d wager there are less than a hundred publically facing websites on the internet that use MOSS (probably due to complexity and cost), yet we chose to use it because of the potential in further developing it in future iterations.

Silverlight on the other hand is a different story.  Recent reports peg Silverlight penetration at around 25-30% of all browsers.  Whether or not this is accurate, who knows.  It’s the only data available.  Flash penetration is at 96%.  Now, in my opinion 25% growth in 2 years on Silverlight’s part is impressive.  Flash has been around for nearly 2 decades.  There is definitely a correlation to be made in there somewhere.

At this point, I was sold on using Silverlight.  The exec’s still weren’t.  Seeing as Silverlight is a browser plug-in, it must be installed in some way, shape, or form.  At 25%, that means our customer demographic would have around 10% penetration.  That is terrible.  Getting them to install a plug-in to view site content is a tough sell.  The executives didn’t want to scare away customers by making them install the plug-in.  SharePoint doesn’t need a browser plug-in.

And here in lies the Catch-22

To expand our marketed audience, we build on Silverlight to give them more content that is better authored to their needs.  In doing so, we lose customers because they need to install the plug-in.  There is no metric at this point in time to help us extrapolate the difference.  There is a reasonable risk involved with using such cutting-edge technology.  We will use it when browser penetration is high enough, yet browser penetration won’t grow if sites like ours don’t use Silverlight.

Ah Well

I’m a technology risk taker.  I live on the bleeding edge.  I run Exchange 2010 beta, on Server 2008 virtualized on Hyper-V, with IIS7 running this site, browsed by IE8 on Windows 7 RC, and authored in Office 2007 (2010 if Microsoft would give me the flippin bits!).  The company, not so much.  Risk is good – as long as you can mitigate it properly.  I can manage my risk, as it’s not the end of the world is something here crashes.  I don’t lose an audience.  If the company can’t market to it’s customers because the tools in use are too new, it will lose audience.  Period.  And that means lost revenue.

Maybe we can convince the exec’s in Phase II.

Techdays 2009 – VIP Pricing

As budgets get tighter, Tech·Days is the perfect way to get the Tech·Ed experience without the travel expense, with two days of skill-strengthening education to help you position yourself for success by:

  • Learning the technology—with a customizable agenda from over forty sessions across five technical tracks on both current technologies and new products, like Windows® 7 and Microsoft® Exchange 2010;
  • Connecting with Experts and Peers—with Birds-of-a-Feather lunches and the new Windows 7 Zone, you'll have lots of opportunities to share your ideas with those who know the products best; and
  • Apply what you learn—with a Learning Kit packed with products and resources so you can continue to grow your skills long after the event has finished.

Technologies discussed: Windows 7 Operating System, Windows Server® 2008 R2 operating system, Visual Studio® 2008 development system, Silverlight™ browser plug-in, Exchange 2010, Security/Management, and more.

If you want the VIP Discount use the promo code TD09Partner.

City Date Venue
SEPTEMBER 14-15 Vancouver Convention Centre
SEPTEMBER 29-30 Metro Toronto Convention Centre
NOVEMBER 2-3 World Trade & Convention Centre
NOVEMBER 17-18 Calgary Stampede
DECEMBER 2-3 Mont-Royal Centre
DECEMBER 9-10 Hampton Inn & Convention Centre
DECEMBER 15-16 Winnipeg Convention Centre

Early Bird: $299, Regular Price: $599

There is a good chance I will be presenting at one (or more) of these locations, so keep an eye out.  In the event that I don’t, I will definitely be enjoying the Toronto stop of the tour.  In either case, I will be there ready to learn, with a pocket-full of business cards.

Oh, and I’ll be leaving with a box/bag/shopping cart* of swag.

*Metaphorical shopping cart.  They are going to give away lots of awesome stuff.

Security, Architecture, and Common Sense

Good enough is sometimes not good enough.  I’ve been doing a lot of thinking lately (well, I’m always thinking), and security has been an issue that has come up a lot.  Frankly, I’m a two-bit software developer.  I know my code isn’t the best, nor the most secure.  I use strong passwords, encrypt my sensitive data, and try to limit access to the applications for those who need to use it.

In theory this works.  Problem is, it’s a lame theory.  There are so many unknown factors that have to be taken into account.  Often times they aren’t.

When I go to build an application I spend time designing it and architecting it.  This is usually the case for most developers.  What I’ve noticed though, is that I don’t spend time securing it.  I can’t.

Imagine building a house.  You put locks on the doors, bars on the windows, and someone breaks in.  Why?  Because someone left the key in the door.  You can’t build against that.  You just can’t.

You can follow the Security Development Lifecycle, which I recommend to each every single developer I meet.  There are tons of resources available.  But it can only go so far.  It’s designed more for being part of the iterative processes, not the architecture.  Or at least, that’s how most people interpret it.


My last post talked about Single Sign-On (SSO).  It’s a great sellable feature for any product.  What most people don’t realize though is the inherent security benefit to it.  With it, that means one less password to remember, one less password that could get intercepted, one less password to change every month.  This is a fundamental architectural issue.  But at the same time, it’s common sense.

What is sometimes the simplest idea, is usually the correct solution

What the hell does that mean?  It means keep it simple.  Security is simple.  Keep data from prying eyes, and keep it from getting lost.  This is common sense.

Security is not difficult to comprehend.  It becomes difficult when academics get involved.  Spouting theories and methodologies scares people into thinking security is extremely difficult to implement.  It’s not!

Follow the Data

Understanding the flow of data is crucial in properly architecting an application.  It’s crucial in properly securing an application as well.  SSO is a perfect example of this.

The SSO feature in Office SharePoint Server 2007 maps user credentials to back-end data systems. Using SSO, you can access data from server computers and services that are external to Office SharePoint Server 2007. From within Office SharePoint Server 2007 Web Parts, you can view, create, and change this data. The SSO feature ensures that:

  • User credentials are managed securely.

  • User permission levels that are configured on the external data source are enforced.

It makes perfect sense.  It’s simple when you think about, and it affects every subsystem of SharePoint.  Make security a feature.

The Fine Line Between Insanity and Clarity

The BBSM (Building Broadband Service Manager) is a Windows 2000 box that acts as a gateway to the internet for customer access.  It handles that login page when you connect to the open WiFi network.  It is the most convoluted piece of [insert noun here].  The guy who signs my paycheck had asked me a few weeks back to redesign said login page in keeping with corporate designs.  It was also requested that it be mobile browser friendly.  Classic ASP, running JScript (yes, JScript), in IIS 5 on Windows 2000 behind ISA Server 2000.  The new layout was done in about an hour, and it looks pretty good.  It has been 3 weeks and I still can't get the freakin mobile code working.

In a moment of insanity (clarity?) I got the bright idea to install .NET on the box and rewrite all the pages from scratch.  Rewriting took a couple hours, and the mobile support works.  Go to set it up on the box (which must be done via USB key, via Ops guy, via physically walking to box in DataCentre {which I don't have access to}) and come to find permission errors for the ASPNET account doing COM stuff.  Needless to say I hate COM Interop with a passion.  I even sunk to the level of giving the ASPNET account full admin privileges.  Turns out Windows 2000 does not like COM Interop either.

"It looks nice if you use a laptop" was my statement to the boss.  His response was "everyone is using PDA's and their iPhones.  Maybe 10 customers use laptops."

Moral of the story: If the original code was written in the same year you turned 11, run.  Quickly.

This is interesting…


I’m fairly certain there’s a good reason for this, but I just thought it was interesting because these are not hashes.  They are actual encrypted passwords.  Statistically improbable to get something like this in production systems.  Completely understandable in development.  Just thought it was interesting to see.