As a sort of addendum to Jason Bennet's post about client expectations from cloud services, I wanted to mention the PlayStation Network. PSN has been down for six days now, the last update mentioning only that Sony doesn't "have an update or timeframe to share at this point in time."

There are differences between Amazon Web Services and PSN, of course, the primary being that AWS is a paid service. However, the initial MSRP of the PlayStation 3 was $600, an extremely high price for a console. One of the features on the box, and a feature that continues to be noted on the home page of the PlayStation, is access to the PlayStation Network. So regardless of the lack of subsciption fee for PlayStation Network, there is a client expectation that they have paid a premium for the physical product with the understanding of 24/7/365 access to the free service.

Unfortunately, Sony's handling of this disaster has only exacerbated the problem. On April 20th, Sony took down the PlayStation Network. Their initial statement said, in toto, "We’re aware certain functions of PlayStation Network are down. We will report back here as soon as we can with more information.  Thank you for your patience." The next day they said they were "investigating the cause of the Network outage." The day after that they mentioned an "external intrusion," and said they took down the network themselves, back on the 20th. Many of their customers and game journalists understood "external intrusion" to mean the hacker group "Anonymous" who had recently gone after Sony. After the hacker group vehemently denied responsibility, Sony didn't mention it again. Officials at Sony have said they don't know if customer account data, including credit card numbers, have been compromised. Their blog includes only 3-4 line updates once a day, where they mention things like "Our efforts to resolve this matter involve re-building our system" with no estimated date or time for when something that sounds so monumental might be finished. There has been no explanation as to why this is happening. Rumors have swirled, none of which Sony has directly addressed. Games that depend on PSN for full functionality aren't getting sold. Products available for sale ONLY through PSN are obviously not getting sold either. Many of these titles are the lifeblood of indie game companies.

Compare this to XBox Live troubles 2 years ago after Christmas - Microsoft's Major Nelson stated the exact nature of the cause (Christmas rush led to a huge usage spike), possible work-arounds, estimates, and at the end of it, customers got a free XBox Live Arcade game and 1 month of free service. The whole busines was soon forgotten.

It's highly unlikely that will be the case with Sony. In all, their network disaster has turned into a credibility disaster, and the repercussions are bound to affect not just Sony, but many companies in the PlayStation environment. Sony has blogs, twitter feeds, facebook pages, and none of those are being used to communicate anything meaningful to their customers. The lesson here is a simple one - don't just have a plan for disaster prevention, have a plan for disaster recovery that includes customer communication and marketing. Because day six of the outage of your 24/7/365 network is too late to come up with a plan.

Update: Since I posted this initially, Sony has admitted that user accounts were compromised. Again, this is six days after the initial breach. User IDs, passwords, and credit card information are all at risk.

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers

So, to sum up the six easy steps are:

1. Check to see if you've already got Visual Studio 2008 Team Explorer - if you do skip to step 4.
2. Install Visual Studio 2008 Team Explorer
3. Install/Reinstall Visual Studio 2008 SP1
4. Install VSTS2008SP1FCUTFS2010
5. Add servers via Registry
6. Say hello to the future - flying cars and TFS 2010.

So, how about that Silverlight?

After a rocky initial few years, Silverlight's become quite the tool for creating rich internet applications, not to mention Windows Phone 7 applications. It does this by bringing the power of .NET directly into the web browser, via a plug-in. This brings one huge advantage: Silverlight, at its core, is a client application. That's right, despite being delivered over the web, Silverlight apps are built very similarly to a client application. There's no special tricks keeping track of state, requests from the user can be handled by event handlers, and all that good stuff. It's much easier to make a well- designed application because you don't have to constantly worry about reinstantiating objects. This also means you are freed from the anti-pattern design of ASP.NET. So, what's the best way to make maintainable and reusable code in Silverlight? MVVM.

It works in WPF too, FYI, but I'm ignoring that for now.

The usual response to inquiries about MVVM is, "Yeah, I've heard about it," with the "What IS it?" being implied. This is partly because MVVM hasn't been well publicized, and that's partly because it hasn't really been standardized. So the simplest answer one can give to the question of "What is MVVM" is that it is a design pattern. I'm not going to diverge off onto what design patterns are, except to say that (as Captain Barbossa might say) it's more what you'd call "guidelines" than actual "rules." However, MVVM is more than a design pattern, it is really the design pattern to use in Silverlight. The reason for this is straightforward - it takes advantage of the unique relationship that Silverlight has between the Presentation Layer and the UI Layer. Silverlight may be a client app dev tool, but that doesn't make it a WinForms app dev tool. I learned this distinction. WinForms design patterns don't take advantage of that unique UI layer, but MVVM does.

It stands for Model-View-ViewModel, BTW

MVVM describes the relationship between the Model, View, and the ViewModel. The Model and the View are pretty easy to understand. The Model is your collection of domain objects, and your business logic. The View is where you display your Model, listing domain objects, and listing their attributes. The ViewModel is the real meat of the MVVM model, and is the reason that MVVM is so necessary to a Silverlight project of any complexity. Again, this isn't official, and it isn't standardized really (again, guidelines), but at its core the ViewModel is where you hold the databinding logic that connects your View to your Model's data. Now, this is relatively unique as far as Presentation layers go. Usually, if databinding is to happen, it can't happen in the Presentation layer because the Presentation layer is too far removed from the UI. So what ends up happening is either the Presentation layer and the UI are smashed together, or the databinding happens all in real time and debugging becomes a pain. However, Silverlight's UI has built in hooks to allow for databinding to another object. This entirely changes how the UI relates to the Presentation Layer, because now the Presentation Layer can basically be anything. In fact, if you wanted, you could connect the UI directly to the Model.

Wait, what? Why don't we just do that?

So why the ViewModel? Why MVVM and not just ... MV? Because, as you can imagine, the model is meant to contain ONLY business logic. And if all you were doing, ever, was displaying the attributes of your object, then that could work, as you'd have no presentation logic. For relatively simple Silverlight apps, that could work just fine, more than likely. That raises questions though - what happens when an artist wants to work on the view? What happens when you want to test the UI? What happens if you want one view to show data from multiple domain objects?

This is where the ViewModel comes in. It provides the databinding layer for your UI to connect to. And in this databinding layer you can pull from multiple domain objects, you can sort lists, page lists, split things up and combine things together for display on the view. And the best part? You can even display dummy data for design time. That's right! Now your designer won't have to just try to build something and wonder if that's going to look right. All he has to do is connect to the ViewModel, and dummy data shows up. Now the designer has something to design against, instead of just guessing. And he doesn't need to know any of the logic, because the ViewModel takes care of all that, and if something changes, he's not totally screwed because everything is loosely coupled. Trust me, on a project of any complexity (and even simple ones!) if you bind directly to the model you will eventually regret it. And then you'll have to make a ViewModel for just one View, and then your code is inconsistent and everything is ruined forever.

MVVM and Rapid Development

Like MVC and MVP, the slowest part of design patterns like MVVM is learning them. And like MVC and MVP, once you've learned MVVM, it is significantly faster than attempting to do it the anti-pattern way. Also, trust me on this one, it's signifcantly faster than pretending that Silverlight is old WinForms tech. (That gets you nowhere, slow.) Not only are these design patterns faster to develop against than just smashing code wherever you can, but they're more modular, they're more maintainable, they're easier (and quicker) to design against, and there's generally a lot less of going back and forth over the same code trying to figure out why it breaks every time you make a change. (Again, hard lesson on that one.) This means more time focused on adding new features, and less time trying to track down hard to fathom bugs. Also, there is a nice separation of interests in the code, which lets people figure out where things are faster. Combined with templating in Silverlight, this makes application development very quick.

So MVVM works well for rapid development - once you've learned it. But it's very much worth learning. On a side note, what about rapid development with RIA? Well, that's another post. But yes, it does work with RIA.

Man, so Microsoft must have totally built MVVM right into Silverlight! Err...Right?

So, hey, builtin stuff, yeah. That's most likely coming in Silverlight 5. There is a good reason that MVVM hasn't yet been built into Silverlight - it isn't that old, in all honesty, and it's still being developed, even in terms of theory. And more so, if Microsoft does include a solution, it has to be a solution that appeals to almost everyone. So it's taking a little bit to get to that point.

So in the meanwhile, there are various MVVM frameworks that have been built. The only one I've used so far is MVVM Light, developed primarily by Laurent Bugnion of Galasoft. Now he designed this framework with "Blendability" in mind. That is to say, working with designers who are using Blend is the foremost concern. He readily admits that if you are looking primarily for testability, or have other concerns, MVVM Light might not work out for you. There's also Caliburn and MVVM Foundation. Also, as mentioned earlier, MVVM isn't just Silverlight, it's also WPF. In fact, almost all the frameworks mentioned above support both Silverlight and WPF applications. So really, by learning MVVM you're getting a twofer on app skills. So hopefully, if someone out there is wondering why MVVM is useful, this has helped answer that question. Now you're wondering, hey, heavy on the "why", light on the "how", right? Well, that would quadruple this article, so I'll just post some links to others who have already written about it. Dan Wahlin, Shawn Wildermuth, and for WPF focused, Josh Smith.

Questions and comments welcome below.