The job descriptions are boring as hell though ;-)

It’s us, the developers, who have to figure out where and on which layout/browser/os these bugs manifest themselves. This can be a very frustrating & time-consuming task, so that’s why we made ourselves a little helper.

Meet: SUD. It’s a smart little bookmark widget. Some javascript code that creates a small overlayer head-up display (HUD) with a bunch of info.

It gives you:
- A number representing the current “layout” in your responsive site (we like to number our different layouts)
- The current active media query
- All necessary browser info
- All OS info needed

Here is a little screenshot:

SUD is still in BETA, it’s a work in progress. You can find it on github if you want to see how it works.
Or simply start using it now by dragging this link to your bookmarks bar or by creating a new bookmark with this in the link field:

javascript:(function(){s=document.createElement('script');s.type='text/javascript';s.src='https://thesedays.blob.core.windows.net/labs-thesedays-com/sud/td.plugin.sud.min.js?v='+parseInt(Math.random()*99999999);document.body.appendChild(s);})();

If you want the widget to run at page load, just include this script tag:

<script type="text/javascript" src="https://thesedays.blob.core.windows.net/labs-thesedays-com/sud/td.plugin.sud.min.js"></script>

Feel free to check it out and give it a go. And make sure to let us know what you think of it!

Whenever you need to create an interactive widget on a website you often end up writing a lot of code in having the widget updated through asynchronous calls between client and server. Moreover in most cases the widget will pull for updates while it would be much more efficient in having the server push updates to its clients. This is where SignalR comes in: a signaling library for ASP.NET which does all the heavy lifting for you, making it dead easy to push data from server to client(s).

The best way to get started with SignalR is by looking at Hubs which are a higher level implementation of a persisted connection. Check out the quick start example and see how easy it is. Note that in order to support certain browsers you will need to include json2.js in your application.

Why create a progress bar using SignalR?

In our production department we have several (web based) collaboration tools amongst which a deployment tool for .NET based websites. The tool allows front-end developers to work against a shared development environment (not having to run websites on their local machines) and deploy websites to a staging environment which is accessible to our clients for previewing and acceptance testing.

Since deploying larger websites can take up to several minutes we needed to provide the user with feedback, preferably by means of a progress bar. We also needed to make sure that during website deployment the deployment could not be reinitiated and finally we thought it would be really cool if we could prompt the progress bar to other (concurrent) users as well.

And although this could also be accomplished with Ajax/JSON, it is just so much easier using SignalR!

Let’s see this in action: the screenshots below represent 3 different browser windows showing 2 simultaneous deployments. When a user visits the deployment page of a website a progress bar is prompted if the website is currently being deployed. The overview page which lists all the websites is updated as well (a rotating progress loader is shown instead of the deploy button)

Deploying a first website

Deploying a second website

Overview which lists all websites and their deployment status

A look at the source code

The deployment tool is an ASP.NET MVC 3 web application so installing SignalR is a breeze with NuGet and the first thing I did after installing the package was adding the progress bar to the view which initiates the deployment.

Client-side code in the Deployment view

In the head section I added references to the scripts required for SignalR and the JQuery UI progress bar as well as some JS code which initializes the Hub and handles the progress updates. Instead of having the form post back to the server, the submit button triggers a client side click event which will call a method on the hub (in this case run). Note that Jquery itself also needs referenced (in a shared layout).

That’s pretty much it when it comes to client side code and as you can see below the actual implementation of the hub is written in plain old C#

DeployManager: server-side implementation of the hub

All it takes is creating a class which derives from SignalR.Hubs.Hub and by doing so the run method that is executed in the client-side script will trigger the run method on this class, which is all handled by SignalR.

The actual deployment logic is implemented in the WebAppManager class, so the run method just creates a new worker thread and passes in the deployment info. The worker thread instantiates a WebAppManager and subscribes to the progress event which will bubble progress events back to the DeployManager. Finally, the DeployManager will update the progress to all its clients (also handled by SignalR) which causes the updateProgress method on all clients to fire. Isn’t that just awesome?

Finally, the view which lists all websites can be easily updated by adding some familiar client-side script.

Client-side code in the App Management view

Whenever a progress update is received the script will check to see whether a website’s deploy icon (and alt/title text) needs to be switched back and forth.

And apart from the actual progress calculation, basically that is all there is to it!

Related files: download the source code – download the web application

Jupiter is just around the corner

With its first beta release on November 11^th the road to Umbraco 5 (aka Jupiter) has brought us very close to its destination. The members of the Umbraco core team have been working really hard on stabilizing the API and many of our beloved (and improved) CMS features are well taking shape.

As Umbraco 5 remains open source all current and future releases are made available through Codeplex which allows developers of the Umbraco community to explore and work with the source code, to contribute and to provide the core team with valuable feedback.

After having attended the awesome Umbraco v5 hackathon organized by BUUG and hosted at our offices in Amsterdam – and also very much inspired by Alex Norcliffe’s talk at the Microsoft offices in Brussels – we really wanted to get our hands dirty and – deep dive into hive!

Umbraco Hive

Many of the recent Umbraco 5 talks and presentations involve Hive, a completely new and extremely powerful concept in the upcoming version. Much unlike a traditional data layer in most n-tier or n-layer (web) applications Hive represents an abstraction layer for developers to plug in multiple, stackable data providers. These Hive providers can pull data (read and/or write) from nearly any data source and allow for smooth integration within the Umbraco back office as well as a transparent way of querying the data in the front-end.

The first beta release comes with three Hive providers, created by the core team:

• A persistence provider that already supports SQL server and SQL CE (which uses NHibernate as ORM)
• An Examine provider for data indexation (which uses the Lucene.NET indexer)
• An IO provider which stores data on the local file system

Basically this means Hive already supports the vast majority of (.NET) based websites.

By the way, didn’t I mention these providers are stackable? In a recent demo (video currently not available yet) Alex quickly swapped the Examine provider with the persistence provider, having Umbraco run entirely on a file index without using a database at all. Although that’s a neat trick by itself, the true power of Hive is the ability to query multiple, stacked providers: imagine having data stored in both a database and a file index while data is always retrieved from the file index in order to gain a performance boost… Hive will make it work.

Community hackathons

In many countries the ongoing v5 hackathons allow Umbraco developers to come together, share experiences, learn and contribute. These sessions are the perfect opportunity to experiment with the various new concepts in v5 such as hive, hive providers, property editors, surface controllers, tree controllers and much more.

During the BUUG hackathon we were able to play around with the WordPress Hive provider created by the Karminator. Basically the provider connects to a WordPress blog and fetches categories and posts which are then loaded into the Umbraco back office. And even though our efforts of making the provider writeable were somewhat fruitless (#h5is) it did allow us to get familiar with Hive and understand how to create and configure a custom Hive provider.

The source code of the WordPress hive provider can be found on bitbucket and has also been added to the Umbraco 5 Contrib project on Codeplex which was introduced during the recent UK hackathon.

Since we weren’t able to attend the Umbraco UK festival and we didn’t want to wait until the next hackathon to further explore v5, we started a somewhat experimental side project: whether or not the websites we create are hosted on Windows Azure we often want to store resources on Windows Azure CDN or blob storage. In Umbraco v5 style sheets, scripts, templates and media uploads are stored on the local file system. All of this is handled by the IO Hive provider, so we decided to create a Hive provider which is to save these files on blob storage, and it works!

As for the more technical part of this post, let’s have a closer look at the setup.

Configuring the Blob Storage Hive provider

When you have a closer look at the Hive configuration file you will notice that a Hive provider can be configured separately for each of the storage types known by Umbraco.

The hive configuration file, located in App_Data\Umbraco\Config

The configuration file allows you to configure the type of the Factory class that is used by Hive to instantiate the provider’s entity repository (more on this later) as well as a reference to the provider configuration section which is located in the web.config. As shown below this configuration section allows users to further configure the Hive provider.

The umbraco configuration section in web.config

As for the blob storage provider we allow users to configure the name of the connection string of the blob storage account (which is to be added to the connection strings section) as well as the name of the blob container.

Creating a custom configuration section is fully supported by the Umbraco v5 Framework and is just a matter of creating/inheriting some classes that will allow the settings to be injected into the Entity repository (handled by IOC, very sweet). Make sure to have a look at the source code to find out exactly how easy it is ;-)

The provider dependency helper is a property of the abstract entity repository

Creating the Blob Storage Hive provider

Although we haven’t gotten around testing the provider for all storage types just yet, obviously the first thing we had in mind was having the provider handle media file uploads. The one thing which distinguishes media from other storage types is is that it uses both a persistence provider and a storage provider. This approach provides a (much needed) separation of the concept of media on the one hand and the actual physical storage on the other hand (I will come back to this in a moment).

As we won’t be replacing the persistence provider we were able to reuse plenty of the code written for the IO provider. So instead of walking through all the code, let’s just have a look at the key differences (and imperfections).

When you create a custom Hive provider you start out with creating an Entity model and a schema, allowing you to convert an arbitrary data model into a model which can be interpreted by Hive. Hive provides base entity classes for both model and schema (currently TypedEntity and EntitySchema) and base repository classes (currently AbstractEntityRepository and AbstractSchemaRepository) which allow Hive to query against model, schema and relations.

The main problem we faced when creating a model and schema for blob storage is that we noticed the core property editor used for uploading files in the back office creates a File model (IO provider). Since we did not want to create a custom upload property editor just yet, we decided to have our Blob model derive from the File model instead.

The Blob typed entity which derives from Umbraco.Persistence.Model.IO.File

Definitely something we will need to reconsider in the future, but for the sake of getting the project of the ground quickly it seems like a fair solution. This is also the reason why we didn’t put too much effort in tailoring the Blob schema just yet (a simple schema with a node name attribute seems to work just fine).

Next we copy/pasted the entity repository used by the IO provider and implemented most of the key logic in having data stored on blob storage. This actually all went pretty smooth and the one thing worth mentioning here is probably the use of Hive ID’s. The IO provider assembles Hive ID’s by normalizing the file path and although I’m sure it makes perfect sense we didn’t get it straight away and decided to implement our own strategy which basically comes down to: blob – container – blob name (which includes the GUID of the persisted media).

Although we haven’t yet fully implemented all of the entity/relation operations (and revision support for that matter) we did implement some of the relation operations which basically allow for the creation of thumbnails (AddRelation and PerformGetChildRelations). Having these implemented was amazingly straightforward by the way, so a big thumbs up to the core team! And again, you should really check out the source code to find out just how easy it was ;-)

The AddRelation method of the Entity Repository

That’s basically it, and now we seriously wanted to test-drive this baby! Unfortunately the upload property editor did require a small fix in order to make it work with our blob storage provider: the code used to create a thumbnail creates a bitmap by passing in a file path. To fix this we just had to replace 1 line of code (maybe 20 characters?) which I think still is impressive considering we are reusing the existing property editor ;-)

A small fix in the core Upload property editor

And it just works!

Media section in a local Umbraco v5 beta installation

Cloudberry explorer showing the media files on blob storage

We were actually somewhat surprised to see it work immediately as we first figured we would still have to make some changes in having the editor display the thumbnails (they’re on blob storage, so what about the URL?) and this is when we found out Umbraco 5 uses a custom mechanism for rendering media, i.e. the following URL will display an image uploaded as media:

http://umb5beta.local/Umbraco/Media/Proxy/media%24empty_root%24%24_p__nhibernate%24_

v__guid%24_28a171dda97048f98e6b9fa501792a5b?propertyAlias=uploadedFile

Remember the separation of the concept of media and the actual physical storage I mentioned earlier? Right!

What’s next?

Although we realize this is just a very basic implementation we would certainly love to see it being further developed into a solid Jupiter hive provider, and of course we love to hear your feedback and suggestions.

The source code is available on the Umbraco 5 contrib project (forked) or  you can just download it here or download a full web application which has the provider already configured (it uses SQL CE so no need to setup a database).

At These Days we are already looking forward to the next release of Jupiter!

That’s why it’s time for responsive awareness. The presentation included in this blogpost exists out of three parts and is intended for everybody with an interest in responsive web design and development, designers and front-end developers. Are you ready to make the switch? Do you want to deliver optimal user experience at all times? Get responsive already.

Demo

check it out

Look ma, no javascript. Without scripting however IE6, IE7 & IE8 won’t display properly. If you would like to see this work in every browser known to mankind simply include respond.js. While viewing the demo, screen resolutions are displayed in the upper left corner. Depending on your screen size you can see up to seven different layouts.  The css is dynamic thanks to less.

Presentation

This presentation aims to shed light on do’s and don’ts for both designers and front-end developers. You can expect some tips on how to approach a responsive project, how to optimize the website for speed and plenty more.

Geolocation is used to center the map and show the user’s exact position in Antwerp. As you ride around the city your new location is automatically represented on the map.

The serverside part of the application is built with NodeJS to be blazing fast. It constantly scrapes data from the official velo-antwerpen.be website and stores it as a JSON file. NodeJS is fast because it is an event driven server. After the server sends out a scraping request it will rest, and CPU usage will go down to zero, until it receives a response. This allows it to manage many simultaneous tasks.

On the client side, scripts and stylesheets are included as inline code to reduce the number of HTTP requests made and improve the performance of the app.

All code for the project is open source and available on GitHub, so if you’d like to improve something about the website, feel free to make your own changes and submit a pull request.

There are a number of reasons we built this as an HTML5 web app rather than a native app.

The most important reason is cross-device support. The Google Maps SDK we use already supports iPhone, Android, BlackBerry 6 and Dolfin 2 (Samsung Beda). As other manufacturers improve their mobile web browsers, Dude Where’s My Velo will automatically support those devices. We are expecting good support for Windows Mobile and Nokia devices later this year.

The second reason for web over native is bug fixes and feature updates. Web apps can be updated as quickly and easily as normal websites. Changes don’t have to be approved or reviewed by third parties.

So check it out now. Visit dudewheresmyvelo.be on your phone or computer. We would also like to give a shout out to DotCloud who are hosting the app for free. Happy cycling!

The FB.login() method of the JavaScript SDK won’t help us because Safari does not allow cookies to be set from iframes, which Page Tabs are loaded in. There are some nasty hacks that claim to get around this but I wouldn’t go there. Anyway, its actually really easy to implement the server-side auth flow in a Page Tab.

Here’s the flow we’ll need to implement:

1. Use the getLoginUrl() function of the PHP SDK to generate a login URL.
2. The redirect_uri parameter should point to a page on our server — let’s call it facebook-callback.php for the example.
3. After the user allows (or denies) our permission request, Facebook will forward them on to facebook-callback.php.
4. That page will initialise the Facebook SDK so that a cookie is set. If you’re asking for offline access, this is when you should save the access token.
5. That page will then redirect the user back to our Page Tab, and voila, they are logged in.

If you implement this flow you will be able to reliably access the Graph API from your client-side and server-side code.

If you read my previous post, Query Strings for Facebook Page Tabs, you might be wondering how to use the server-side authentication flow in a multi-page, deep-linked Page Tab. Its actually really easy because you can add query string parameters to the redirect_uri. When you generate your login URL, you can append your app_data parameters like this:

$callbackUrl = 'https://playground.thesedays.com/facebook-serverside-login/facebook-callback.php';
$encodedParams = urlencode(json_encode($params));
$loginUrl = $facebook->getLoginUrl(array(
	'redirect_uri' => $callbackUrl . '?app_data=' . $encodedParams
));

Then in your facebook-callback.php page, you just need to forward those parameters on to the Page Tab:

$tabUrl = 'https://www.facebook.com/mypage?sk=app_128534967229326';
if (!empty($_GET['app_data'])) {
	$redirectUrl = $tabUrl . '&app_data='.urlencode(stripslashes($_GET['app_data']));
}
header('Location: '.$redirectUrl);

Now you can have login links which go to different states in the same Page Tab. I’ve put up an example of using server-side authentication on Page Tabs. The source is on GitHub.

Note: Using the server-side auto flow with Page Tabs will result in 3 HTTP redirects — first to Facebook, then to facebook-callback.php, then to the Page Tab, which finally loads your content in an iframe. Therefore you should only use this flow when you need to authenticate a user. If a user is already logged in, you should load new pages directly. Ajax is your friend!

Facebook Page Tabs are loaded in an frame, which means they don’t have access to the query string. But Facebook have provided a way around this by passing on one particular parameter. Any value in the app_data GET parameter is made available to your application as a string in the signed_request object. You can use JSON encoding to make that parameter store any number of objects.

Enough talk — time for some code. I’m going to walk through a really basic demo of how to make this work. First, let’s initialise the Facebook SDK.

$facebook = new Facebook(array(
  'appId'  => 'YOUR_APP_ID',
  'secret' => 'YOUR_APP_SECRET',
));

Now we’ll ask for the signed_request object.

$signedRequest = $facebook->getSignedRequest();

Now let’s take the app_data string parameter and decode it into an array.

$appData = array();
if (!empty($signedRequest) && !empty($signedRequest['app_data'])) {
  $appData = json_decode($signedRequest['app_data'], true);
}

For testing purposes, we’ll print out the results.

echo 'appData contains: ' .
  '<pre>' . print_r($appData, 1) . '</pre>';

Now that we’ve set up a way to retrieve and display the app_data parameters, let’s create a link which actually passes some parameters in. The first step is to define our parameters in an array.

$params = array(
  'page' => 'home',
  'id'   => '99'
);

Next we’ll encode that array into a JSON string, and then URL encode it so it can be used in a query string.

$encodedParams = urlencode(json_encode($params));

Finally, we’ll concatenate the string onto our Page Tab’s base URL and print it as a link.

$tabUrl = 'http://www.facebook.com/mypage?sk=app_142464959162218';
$linkUrl = $tabUrl . '&app_data=' . $encodedParams;
echo '<a href="' . $linkUrl . '">My link</a>';

The value of $linkUrl would be:

http://www.facebook.com/mypage?sk=app_142464959162218&app_data={%22page%22%3A%22home%22%2C%22id%22%3A%2299%22}

As you can see, having multiple query string parameters in a Page Tab is a really simple process. If you want to you can use this functionality to build multi-page Tabs with deep-linking. I have made a working example of a multi-page Tab for you to check out. You can follow the links below to see the demo, and the source code is up on GitHub of course.

Deep link red
Deep link green
Deep link blue
Source on GitHub

A common problem we have as Facebook application developers is the need to provide users with a way to select one or more of their friends and then capture that selection. The Graph API can provide us with an array of the user’s friends but there’s no official way to convert that array into an interactive interface component. The These Days Facebook Friend Selector aims to fill that requirement.

Here’s what it looks like:

You can view an example in the These Days Playground or check out the source code on GitHub.

We had a number of priorities when designing this plugin:

• User experience — The plugin should look and feel like an official interface component on facebook.com.
• Ease of implementation — You can get the example up and running on your own server simply by adding your application’s API key to example.js. The plugin loads the user’s friends automatically via the Facebook JavaScript SDK.
• Flexibility — You can customise the number of friends to select, the number of friends to display per page, toggle auto-deselection if the maximum number of friends is reached and have multiple instances of the plugin on the same page, each with separate settings. The CSS classnames are all editable, as is the CSS itself, which is provided in SCSS syntax for ease of authoring.

The plugin is tested (IE7+) and production ready. We’re using it in a couple of upcoming projects to allow users to select friends who they would like to invite to play a game. But of course a plugin like this is never finished. We will continue to work on it, and you’re also welcome to fork it and submit pull requests on GitHub. Some of our ideas are:

• Adding unit tests — we know we can’t realistically expect the community to contribute patches if there are no tests.
• Adding a button to toggle between ‘All Friends’ and ‘Selected Friends’.
• Adding alternate UI modes — such as a tile view as well as the list view, and an embedded display mode as well as the popup/overlay display mode.
• Adding support for other JavaScript libraries — currently we rely on jQuery for selectors, event binding and style changes. It might be nice if the core of the plugin was library independent and there were different adapters for jQuery, MooTools, YUI, etc.

To get started with the These Days Facebook Friend Selector, check out the readme and download the source on GitHub.

• Project manager: Why does it take an extra development effort?
• Developers: Why should we write platform-specific code?

In my opinion the cloud is about leveraging web applications and enhancing scalability & content delivery. In order to fully take advantage of Windows Azure applications need to be scalable as well, and they should definitely use the features provided by the underlying platform.

A first step in the migration process had us identify the parts of the application that needed to be redesigned, either to support scalability, to apply best practices or simply to work around some of the platform’s limitations. At this stage we needed to be familiar with the concepts introduced by Windows Azure, such as web & worker roles, blob and table storage, queues and distributed cache.

By looking at these concepts we decided action was needed in handling:

• ASP.NET Session state
• Static content
• Event logging (log4net)
• E-mail notification (SMTP)
• Scheduled tasks
• Data exchange (FTP)

Using distributed cache to store ASP.NET sessions

The application had already implemented ASP.NET membership and it was also using in-process ASP.NET session state to maintain state between pages. As by default, session information is stored in-memory of the application, but since we wanted to run at least two instances to ensure high availability, we figured we needed a different session store.

In Windows Azure common alternatives are storing session information in a database or table storage. A new service however is the AppFabric Cache which provides a global distributed caching mechanism that can also be used to store session information. For this type of storage a custom session state provider exists out of the box so basically we just had to configure it.

Note that in order to use this service we also needed to install the AppFabric SDK (currently v1.0, a newer version is already available in CTP and expected to be released soonish).

Using blob storage for content delivery

For smaller and local web applications we normally don’t consider a CDN and have the content stored directly within the web application itself. Having static content deployed to multiple web role instances however is not ideal, and it would also require us to redeploy the application even when minor changes occur, for example to images, style sheets or scripts.

A good practice therefore is to store this type of content outside of the application, and for this we decided to use blob storage. Blob storage is easy to setup and there are several tools that allow you to upload files, configure cache control, manage header information, etc.

• Cloudberry Explorer
• Cloud Storage Studio (Cerebrata)

I would like to add that blob storage is also a great solution for storing dynamic content such as file uploads and image galleries. Some working examples can be found in the Azure training kit.

Configuring log4net and transferring logs to table storage

We often use log4net as our logging framework and this web application was no exception. The events we log are usually either informative (i.e. a worker process that started) or exceptional (both managed and unhandled exceptions). The application was already configured to write these log entries to a file using a RollingFileAppender, a setup we needed to reconsider because:

• A web role instance runs in a virtual machine with a (somewhat limited) IIS installation and local storage is to be considered temporary (if the VM dies or gets upgraded local storage is lost)
• Log entries will be written by multiple web role instances so we needed to combine these events and also keep track of their source

Fortunately the Windows Azure SDK provides a diagnostics configuration and management API which allows you to collect diagnostics in different roles and transfer this information to table storage at regular intervals.

We also found a helpful blog post describing how to create a custom log4net appender that utilizes the diagnostics API and provides a means of configuration through the service configuration file allowing us to change the logging configuration without having to redeploy.

Using queue storage in processing e-mail notification

The web application needed to send e-mail notifications during user registration or whenever a contact form had been submitted. The original implementation relied on the existence of an SMTP e-mail service on the hosting environment and here’s the catch: Windows Azure does not provide an SMTP service. The Azure adoption team recommends using either:

• A custom on-premise e-mail forwarder service
• E-mail server’s web service API’s
• A third party SMTP service

We were actually pretty fortunate in having other e-mail notifications that would run within a scheduled task already configured to use an on-premise e-mail service using a web service API.

So we needed to make that work for all notifications and while at it, we also decided to completely move the notification process out of the web role and to take advantage of the Azure Queue service to forward messages to a worker role for background processing. Let’s look at the benefits:

• Notification logic is abstracted from the web role
• The web role becomes more responsive
• Messages are kept in store in case the e-mail service goes down
• Monitoring the queue allows us to scale up or down by adding/removing worker roles as needed

Configuring jobs to run within a worker role

For the application to synchronize its data with external systems at regular intervals the original idea was to configure scheduled tasks on the hosting platform. And although Windows Azure does provide a VM role that allows you to create a virtual machine and setup the scheduled tasks, we figured this approach to be rather inconvenient.

That is why we decided to use the Quartz.net scheduling framework and had the tasks converted into jobs. We used cron expressions to schedule the jobs in the worker role and configured these in the service configuration file. Of course we did need to consider the time zone the worker role would be running in.

Since we were using third party assemblies, we also needed to ensure that:

• The assemblies are included in the package (by setting the copy local property to true when referencing the assembly)
• The assemblies are compiled to run on a 64-bit platform (in our case the Quartz.dll was compiled to run on any CPU, but we did have to recompile the Common.Logging.dll)

Having your local development machine run on a 64-bit platform does make deployment easier.

Setting up data exchange via FTP

During a synchronization process the application needed to import files that were uploaded to a local FTP server by an external system and export files that were to be picked up by that system later. And although it’s not the most flexible way of exchanging data it’s still a common practice and nonetheless a requirement for our application.

The problem we faced here is that Windows Azure does not provide an FTP service so we had to come up with a work-around. The options we considered were to create:

• An FTP client in the worker role which connects to an on-premise FTP server
• An FTP server in the worker role that accepts FTP connections and uses blob storage for storing files (for example by using FTP2Azure, a project on codeplex)
• A small application that would run on the on-premise FTP server and synchronizes files with blob storage

Considering time and resources we decided to go with the first option which did require us to set up an on-premise FTP server, although the development effort would somewhat be reduced. Eventually it turned out that implementing a simple FTP client is well supported by the .NET framework.

Conclusion

Much of the work involved in migrating the application to Windows Azure was due to fact that the application was not very scalable to begin with and it pretty much relied on the infrastructure of the hosting environment (local SMTP, FTP and file storage) although I must say that SMTP is a pretty common requirement for many applications and it surprises me it’s not provided out of the box.

Windows Azure offers plenty of new features that improve overall scalability and content delivery. Automated scaling, online storage, diagnostics and performance monitoring have been made easy and the Windows Azure SDK provides developers with the necessary tools and API’s to quickly start using these features.

Although we did have our fair share in refactoring our application, I am convinced that applications designed to run on the platform can also drastically improve by sharing common services including e-mail notification and data exchange and by fully taking advantage of the services already offered by Windows Azure.