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 www.woodbineentertainment.com,
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.
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 |
VANCOUVER
TD09Partner |
SEPTEMBER 14-15
|
Vancouver Convention Centre |
TORONTO
TD09Partner |
SEPTEMBER 29-30
|
Metro Toronto Convention Centre
|
HALIFAX
TD09Partner |
NOVEMBER 2-3
|
World Trade & Convention Centre
|
CALGARY
TD09Partner |
NOVEMBER 17-18
|
Calgary Stampede
|
MONTREAL
TD09Partner |
DECEMBER 2-3
|
Mont-Royal Centre |
OTTAWA
TD09Partner |
DECEMBER 9-10
|
Hampton Inn & Convention Centre
|
WINNIPEG
TD09Partner |
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.
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.
So?
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:
It makes perfect sense. It’s simple when you think about, and it affects every
subsystem of SharePoint. Make security a feature.
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.
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.