The Clouds

I am walking in the air, and speculating about the sun.
-- Socrates, in Aristophanes' The Clouds

Self-explanatory.

What's wrong with having your head in the clouds?  For starters, you might fall into a well.  That's what happened to the ancient Greek philosopher Thales while he was gazing at the heavens.  Aristophanes ridiculed Socrates in a satire called The Clouds for speculating about abstract nonsense without understanding anything about the here-and-now.

Slightly more recently, 'The Cloud' has arrived to save us from all earthly ills.  Got a problem scaling?  Move to the cloud.  Want to reduce cost?  Go to the cloud.  Disaster recovery?  Cloud.  High availability?  Cloud.  Yet, the cloud can't really be a cure-all.  It may be appropriate for your needs, but this has to be evaluated given an understanding of how your cloud implementation will work.  If your number one problem is performance or security, the cloud is probably not going to help.

There are many 'clouds' or high-level cure-alls available to developers today.  For example, I've been learning the Spring Framework, which is a Dependency Injection (DI) framework.  DI is a form of Inversion of Control (IoC), in which object coupling is not known at compile-time but rather is determined at compile-time.  Using a DI framework, you can build interfaces, inherit classes from them, and control application flow using configuration files and annotations (like @inject).  During development, you can stick to the pure work of thought--programming, that is--without having to worry so much about the nuts-and-bolts of connecting classes.

DI frameworks like Spring are just one more layer of abstraction (or one more cloud) that let us focus on business logic rather than implementation details.  And, just like other layers of abstraction, they're a double-edged sword.  Dependency injection isn't always a great idea, such as if your interfaces are likely to change often.  Dependency information has to be stored somewhere, after all.  Enterprise frameworks tend to give you flexibility for the price of code bloat and complexity.  In my time, I've seen programming become ever more complex, but, at the same time, ever more like plumbing.  Frameworks like Spring, Rails, and .Net's Entity Framework let you quickly build applications.  But they don't prevent you from doing very stupid things if you don't know how they really work.  ORM libraries are great, for example, until you have to scale.

For this reason, I've been brushing up on my data structures and algorithms.  It's easy to think such things don't matter.  Plenty of people get by without earning computer science degrees.  And who cares if a client-side algorithm is O(N^2) when the database is orders of magnitude slower?  You might concede that algorithmic theory is worth studying only to develop certain intuitions about processing time, memory size, problem size, and algorithmic complexity, which is certainly true.  But I think it's useful to revisit data structures and algorithms once in a while to stay grounded in reality.  If you're only doing high-level plumbing, you have your head in the clouds. 

Silverlight, Security, and Sandboxing

I'm taking ownership of an application that uses Silverlight for a front end. I had never programmed in Silverlight before and only really knew of it from Netflix's Instant Streaming. I've come to really appreciate Silverlight, since it provides a rich user interface while leveraging the resources of powerful platform like .Net.

It's easiest to think of Silverlight as an alternative to Adobe Flash, which does not easily integrate with other code. The recent Internet-based UI revolution has taken two paths: Flash-like applications (called Rich Internet Applications (RIA)) and AJAX-powered pages like GMail. It's hard to remember the days when you had to refresh an entire page to gain new content, since AJAX and Flash provide such a seamless experience.

Developing in Silverlight is just like developing Web Forms, Sharepoint controls, or User Controls. It just uses XAML instead of ASPX. See the snippet below:

<stackpanel name="LayoutRoot" background="White">
<textblock text="Hello, World!" horizontalalignment="Center">
<ellipse name="FirstEllipse" height="100" width="200" fill="SlateBlue">
<button name="FirstButton" width="100" content="Click" click="FirstButton_Click">

private void FirstButton_Click(object sender, RoutedEventArgs e)
{
FirstButton.Content = "Click Again!";
}

(taken from this example)

As a long-time ASP.NET Web Forms developer, I was surprised that I couldn't just make a DataGrid object and connect it to a DataSource object. To connect to any data, you have to create a Windows Communication Foundation (WCF) web service. This entails learning yet another technology (more on that in a later post), and all the difficulties entailed in creating, deploying, and debugging web services.

I had a hard time finding anything explaining why all this was necessary, until I found this article by Josh Twist. Since a user downloads a Silverlight application that runs in their browser, it cannot be trusted by a server. You need a boundary of abstraction and authentication in order to ensure that the integrity of your data (and your servers) is maintained.


When you have a standard Web Forms application, all of the code is executed on the server. Even though Silverlight code looks like server-side code, it's really executing on the client's machine. For this reason, it faces all of the same limitations as client-side code you might be more familiar with, such as JavaScript and Java applets. A Silverlight application can't be trusted, since its code is non-deterministic and might become corrupted at any time. For this reason, it is sandboxed by your browser. It can't take up all your memory. It can't access the file system. And it certainly can't access your database.

This secure sandbox model is going to become more and more prevalent. The 2000's saw a resurgence of the client-server model in which thin clients (like web pages) did little processing but produced a lot of network traffic with servers. But with the rise of mobile phones, tablets, and other cheap devices, there is no reason to continue to put such a strain on servers and networks. RIA's also provide a great user experience--so great that Windows 8 is going to make it a major part of its architecture. The Windows Metro platform is meant to emulate the touch-driven interface of mobile apps while maintaining the tools many developers have continued to use.

If you want to port an application to desktop, tablet, and mobile devices, you'll have to make this architecture your friend.

Links:
-MSDN article on Silverlight sandboxing
-Windows Metro preview at Engadget