This post will demonstrate how to do rock-solid phone number validation using the .NET port of Google's libphonenumber. When validating phone numbers you tend to end up either frustrating users with strict input requirements or with complicated regexes to cover all the interesting ways that users input phone numbers. If you have to also check international numbers (as we do at AppHarbor) the task becomes almost impossible.

Enter libphonenumber, a library from Google containing years of accumulated wisdom on how to parse phone numbers from all over the world. Patrick Mézard has created a .NET port of the Java version and there is even a NuGet package.

This makes using libphonenumber for validation as easy as installing the NuGet package and wrapping it in a DataAnnotation attribute like the one below (or just use the library straight up). The Attribute below will parse US numbers with and without country code while international numbers require a country code. Example of use:

using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using MyNamespace.DataAnnotations;

public class Address
{
    [DisplayName("Phone number")]
    [Editable(allowEdit: true)]
    [PhoneNumberAttribute]
    [Required]
    public virtual string PhoneNumber
    {
        get;
        set;
    }
}

Attribute:

using System.ComponentModel.DataAnnotations;
using PhoneNumbers;

namespace MyNamespace.DataAnnotations
{
    public class PhoneNumberAttribute : ValidationAttribute
    {
        public override bool IsValid(object value)
        {
            var valueString = value as string;
            if (string.IsNullOrEmpty(valueString))
            {
                return true;
            }

            var util = PhoneNumberUtil.GetInstance();
            try
            {
                var number = util.Parse(valueString, "US");
                return util.IsValidNumber(number);
            }
            catch (NumberParseException)
            {
                return false;
            }
        }
    }
}

Unit tests for attribute:

using MyNamespace.DataAnnotations;
using Xunit;
using Xunit.Extensions;

namespace MyNamespace.UnitTest.DataAnnotations
{
    public class PhoneNumberAttributeTest
    {
        private readonly PhoneNumberAttribute _subjectUnderTest;

        public PhoneNumberAttributeTest()
        {
            _subjectUnderTest = new PhoneNumberAttribute();
        }

        [Fact]
        public void GivenNull_WhenValidate_ThenIsValid()
        {
            Assert.True(_subjectUnderTest.IsValid(null));
        }

        [Fact]
        public void GivenEmptyString_WhenValidate_ThenIsValid()
        {
            Assert.True(_subjectUnderTest.IsValid(string.Empty));
        }

        [InlineData("+4527122799")]
        [InlineData("6503181051")]
        [InlineData("+16503181051")]
        [InlineData("1-650-318-1051")]
        [InlineData("+1-650-318-1051")]
        [InlineData("+1650-318-1051")]
        [Theory]
        public void GivenValidPhoneNumber_WhenValidate_ThenIsValid(string phoneNumberString)
        {
            Assert.True(_subjectUnderTest.IsValid(phoneNumberString));
        }

        [InlineData("123")]
        [InlineData("foo")]
        [Theory]
        public void GivenInValidPhoneNumber_WhenValidate_ThenIsNotValid(string phoneNumberString)
        {
            Assert.False(_subjectUnderTest.IsValid(phoneNumberString));
        }
    }
}

AppHarbor has been available in public beta for one year and we wanted to share some incredible statistics. Our users clocked more than 26,871,840 hours of free hosting. AppHarbor received an amazing 117,587 builds. 18,291 builds did not compile or failed unit tests and AppHarbor stopped them from going live. We deployed and scaled 99,296 builds!

AppHarbor cares deeply about our community. We responded 4,201 times on our support forum, our median response time is 1h 34m. Our community is not only on AppHarbor and we go where they go, including a thriving community on Twitter and a fast growing group on one of our favorite sites, StackOverflow.

When we founded AppHarbor, we set out to give .NET developers everywhere an amazing platform to deploy and scale their applications in the cloud. A portable platform so that developers could move their application somewhere else without any hassle. A platform where developers could easily use 3rd party add-ons to enrich their applications. A platform where any developer can throw together an application and deploy it live for free. And a platform that our users could rely on.

We are committed to always have a free offering. Through the last 12 months one of the biggest concerns we have heard from customers, is that you haven't been able to pay us. We realise you want to know that we will be around for years to come. We always planned on offering premium plans, and today we are announcing two new premium plans.

Meet Catamaran and Yacht which will complement our newly branded Canoe free plan. Canoe comes with one worker, a complimentary yourapp.apphb.com subdomain and piggyback SSL using the apphb.com certificate.

Like all AppHarbor applications, apps on the Canoe plan have access to our build service and continuous integration infrastructure. This includes built-in source code repositories, integrations with external source code repository providers such as BitBucket and GitHub, source code compilation, unit test execution and notifications for completed builds. Canoe apps also have access to the full catalog of add-ons many of which have free plans. Canoe apps are load balanced from the start, so it's ready to scale out when you need it.

Catamaran, at $49/month, gives your application 2 workers along with custom hostnames and SNI SSL. Yacht comes with 4 workers, custom hostnames and IP SSL for $199/month. Multiple workers are recommended for production applications, they increase the number of requests your application can handle and ensure that your application runs with no downtime in case of a sudden server failure. That is why we built it in to our paid plans.

If you are happy with the Canoe plan and just need custom hostnames or SNI SSL, those can be added a la carte for $10/month. If your app needs IP SSL with either the Canoe or Catamaran plans, that can be had for $100/month. Additional workers are $49/month and can be added to any plan.

The workers in our plans can be used as either web or background workers. Background workers are not available yet, but we are working hard on the remaining pieces and will launch a beta shortly.

Applications that already have custom domains or are using SNI SSL can keep using those for free for another month, until March 1st. Once the grace period expires, we will either start charging (if a credit card is added to your account) or downgrade the app. Applications that are currently scaled to two or more instances will be placed on the Catamaran plan.

We want our prices to be as straightforward as the platform itself. You don't need to calculate how much I/O you're going to use, or what amount of bandwidth you require. We've set some soft and hard limits, but chances are that you'll never exceed those.

We chose to charge for custom domains because our free plan is meant to be a great developer sandbox. Custom domains are a sign that what is being built requires a certain branding, whether it is a business product or even a personal blog. We think it is fair that users who get value from using AppHarbor share the costs of running the platform. We kept the price of a custom domain low and we do not intend to make money from it. In fact we plan to donate any profits generated by custom domains to open-source projects and charity! In addition, we are looking at other ways to support applications that provide a valuable service to the .NET community, non-profits and education, for example by extending additional free resources to such apps. Please drop us a line if you think your application qualifies.

Charging for AppHarbor ensures you can keep using our service in the future. It also means that we can start to offer more advanced features - starting today scaling to more than two workers and IP SSL is generally available to all customers. As always, we value your comments and feedback and look forward to keep improving what we already think is the best .NET application platform.

At AppHarbor, there is nothing we like more than getting out and talking to developers that use our platform. Meeting our users is our best chance of understanding how you are using AppHarbor and what challenges you are face crafting great .NET applications.

Last year we talked at Øredev, GOTO Aarhus, Alt.NET Seattle and Community Day in Copenhagen. We also did a meetup at AppHarbor HQ in San Francisco, organised a Code Retreat in Copenhagen and generally tried as much as possible to be around when interesting .NET stuff was happening.

This year we are already booked to appear at DevSum in Stockholm, GOTO Copenhagen and at the Norwegian Developer Conference in Oslo and we're working on getting to a bunch more. If you're going to a conference that you'd like to see someone from AppHarbor give a talk at or if you're organizing a conference and you want someone from AppHarbor to come then please let us know. We love to talk about building great .NET applications, continious delivery, how to take advantage of cloud platforms, how we built AppHarbor and what we've learned from helping developers move their apps onto AppHarbor. We promise to always bring plenty of delicious AppHarbor schwag.

Don't forget that Lanyrd is a great resource when deciding what conferences to attend. Check out the .NET topic and the "Microsoft Guide" (curated by @shanselman).

Today we're happy to announce beta support for node.js, and you can now run your node.js applications on AppHarbor. In this blogpost we'll walk you through the things you should be aware of when deploying node.js apps to AppHarbor and some background on why we're adding support for it.

As you probably know by now we're committed to giving the .NET world the fastest and most convenient way to deploy, manage and scale applications on Windows-based servers in the cloud. As such we didn't immediately think of node.js as the most obvious second platform to support. With recent developments in the node.js community, in particular Microsoft's support of a native Windows implementation along with the performance and stability it brings, node.js on Windows has become viable.

A number of fiery talks by Glenn Block on why node.js has a place in the Windows world further pushed us to make this decision. Finally Tomasz Janczuk made it incredibly easy for us to support it with the iisnode project, which allows us to run node.js inside IIS.

Without further ado let's dive into preparing and deploying a node.js application on AppHarbor. As this is a node.js blogpost we'll of course deploy a chat application and will use Ryan Dahl's node chat demo application. Applications that use iisnode needs a web.config in order to configure the application in IIS. When developing the application you can easily test it by installing iisnode and it's dependencies on your local system which are listed on the Github page. Make sure to take a look at the samples included to get a better understanding of how you can use the web.config file to configure your application.

Start by cloning the application from GitHub:

git clone https://github.com/ry/node_chat.git

The node chat uses the server.js file as the starting point, so we'll make sure to register that in our new web.config

<configuration>
    <system.webServer>
        <handlers>
            <add name="iisnode" path="server.js" verb="*" modules="iisnode" />
        </handlers>
        <iisnode loggingEnabled="false" />

        <rewrite>
            <rules>
                <rule name="myapp">
                    <match url="/*" />
                    <action type="Rewrite" url="server.js" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Most of this is taken from the express sample web.config which show the iisnode module is configured to handle the server.js file and alse how URL rewrites are configured so we don't have to use the filenames directly. Two things are worth noting:

• Disable logging: The iisnode elements sets loggingEnabled="true" which is necessary to run your node.js application on AppHarbor. The iisnode module writes a log file to the directory where the application runs and writing to the filesystem is not supported by default on AppHarbor. Alternatively, you can enable instance file system writes in the application settings on AppHarbor.
• Environment variables: iisnode automatically configures the node.js application with environment variables read from appSettings. In the example above the `NODE_ENV` variable is set. This sets the current node environment and you could should add a configuration variable on AppHarbor with the value "production". That value will then be replaced when you deploy the application as [described here](http://support.appharbor.com/kb/getting-started/managing-environments). If you've provisioned [add-ons](https://appharbor.com/addons) to your application their configuration variables will also be automatically injected.

With this configuration we're good to go and the application can be deployed to AppHarbor:

git remote add appharbor https://appharbor.com/<foo>.git
git push appharbor master

That's it - AppHarbor will the detect the node.js application and deploy it to the the application server. Go to the application's URL (this example is deployed here if you want to take a look) and start chatting with all your friends.

A couple of final remarks:

• NPM: If you're using NPM you'll have to make sure that all dependencies are included in the repository. We may support automatic download of dependencies with NPM in the future, but are waiting until a stable Windows version is ready.
• Websockets are not currently supported
• Node.js support on AppHarbor should only be used for development and beta testing purposes. We wanted to give our users the opportunity to try node.js soon and iron out any kinks with us, but for now this feature should be considered early beta. Please don't put your "mission critical" node.js apps on AppHarbor just yet.

Unless you've been living under a rock for the past month, you've probably heard of the SOPA and PIPA laws that are making their way through the US Congress. If passed, the laws will require US companies to censor the Internet in an effort to prevent copyright infringement.

We built AppHarbor because we love the Internet. AppHarbor makes it easy for people like you to make the Internet even better by taking the pain out of deploying and scaling web-applications. We feel strongly that the SOPA and PIPA laws, if passed in their current form, pose a grave threat to the free and open Internet that we know and love. For that reason, we support the January 18th protests alongside Google, Wikipedia and many others.

If you want to participate in the protest by blacking out your AppHarbor-hosted application, we have created a Stop-SOPA utility that makes the process very simple. Go to https://stopsopa.apphb.com/ to get the details. The utility will cause a blackout-page build to be deployed for your application in the same way that MaintMan deploys a maintenance mode page. Once you're done protesting, you can push a new build to AppHarbor or go to the application dashboard to deploy a previous build.

The Stop-SOPA utitlity uses some clever new bits of AppHarbor API. We will publish the source code in another blog post in a day or two.

Note that appbarbor.com will be available in its usual form throughout Wednesday 18th, but we support and encourage blackout protests by our users.

The first featured app of 2012 is WorkFu. WorkFu is headquartered in London, but the founding team is spread all over the UK. We talked to Neil Kinnish about the project.

What is WorkFu?

WorkFu is a web application that uses your social networks to find work opportunities that are relevant to you.

You can read more about the project and how it works and follow our progress on Twitter

Why did you choose AppHarbor?

We chose AppHarbor because we needed a reliable, scalable cloud based hosting service. AppHarbor gives us freedom to pick and choose the correct tools for our requirements and budget without locking us down to technologies and without high upfront costs. We also like the fact that we can provision Amazon services in the same location that our application is running.

Which technologies is WorkFu built on?

WorkFu is built on MVC 3 and utilises: Redis, Memcached, Autofac, Lucene, Dapper.net, SignalR, jQuery, Booksleeve, Elmah, MS SQL Server 2008, S3 for file storage and Postmark for mail delivery

We have background services running on separate Amazon instances along with our Redis and Memcached implementations.

How has AppHarbor worked for you so far?

AppHarbor is Superb. There are obvious benefits, such as being able to scale on demand. And it’s a joy managing the work flow through Git, especially as we all work remotely.

I should also mention that the support so far has been excellent.

How often do you deploy new versions?

Continuously. The project is in a constant state of development and progress.

What did you like best? Where could we improve?

One of the most important elements to any service is the support and this should not be under estimated. I’m happy that along with a great service you have got this element right.

Anything else?

Yeah, keep on pushing forward and doing great things.

AppHarbor uses ASP.NET Health Monitoring to log and display exceptions thrown by applications running on the platform. Enterprising AppHarbor users have used this feature for debugging purposes by throwing exceptions from their their code. Throwing an exception is inconvenient however, since doing so interrupts normal program flow.

Below is a simple example demonstrating how to subvert ASP.NET Health Monitoring and make AppHarbor log messages. Logged messages are available for inspection in the application Error Display and logging messages like this does not involve throwing an exception.

Note that this is not anything like a replacement for application event tracking solutions such as Airbrake or Logentries, but it's pretty neat if you just need a simple way to output some debugging information while your application is running on AppHarbor.

using System;
using System.Web.Management;
using System.Web.Mvc;

namespace ErrorLoggingSample.Controllers
{
    public class ErrorController : Controller
    {
        public ActionResult Index()
        {
            new LogEvent("message to myself").Raise();
            return View();
        }
    }

    public class LogEvent : WebRequestErrorEvent
    {
        public LogEvent(string message)
            : base(null, null, 100001, new Exception(message))
        {
        }
    }
}

As of today, you can provision StillAlive as an add-on to AppHarbor applications. StillAlive is a great way make sure your application is functioning correctly beyond just checking that accessing front page gives a HTTP 200 response. With StillAlive you can write test recipes checking that your login flow works, for example. This is a great feature for frequently updated AppHarbor applications

The StillAlive guys have written guides on Installing StillAlive and Creating your first Test Recipe.

Today, we have added Cloudmailin and JustOneDB to the AppHarbor add-on catalog.

Cloudmailin is an incredibly simple way to let you AppHarbor-hosted application receive emails without having to mess with SMTP servers. Simply provision the Cloudmailin add-on, configure Cloudmailin to POST to an url in your app that can receive Cloudmailin posts and hand out the Cloudmailin-provided email address to people that should send emails to your app. There's additional documentation on how to get started with CloudMailin on the AppHarbor support site.

JustOneDB is a fast, no admin, no tuning general purpose database designed and built for the cloud. You can interact with JustOneDB using either a REST API or though a PostgreSQL-compatible interface. We have written a complete sample MVC app using NHibernate interacting with JustOneDB through the PostgreSQL interface. Additional JustOneDB documentation is available on the AppHarbor support site.

We hope you'll take advantage of Cloudmailin and JustOneDB and all the other add-ons in our catalog to quickly build great .NET apps running on AppHarbor. We're working hard on adding many more add-ons to the catalog.

When you visit appharbor.com you will now be browsing the new and redesigned AppHarbor website. We're really happy with the way the new site looks and feels and we hope you will have the same experience using it. A sea dragon called Frode was adopted as part of the redesign and we hope you'll give him a warm welcome too.

If you look under the covers of the new design, you will notice plenty of HTML5 goodness and there is plenty more coming as we build out the interactive features of the new design.

We're getting stickers, t-shirts, sea-dragon-shaped thumb-drives and all the other schwag-paraphernalia of a startup so that you can soon show-off that you use AppHarbor to build and host .NET applications.

We know there are some nooks and crannies that need a little more work (and we need to port the new design to the blog) and we'll be attending to that over the next few weeks. If you find anything that's broken or not looking right in your browser of choice then don't hesitate to report it to support@appharbor.com.

We're excited to announce that AirBrake is now in the AppHarbor add-on catalog. AirBrake is a great way to track errors and exceptions in your AppHarbor hosted application. We have written a short guide to get you started logging errors to AirBrake from your AppHarbor application.

Watch a live salesforce.com integration in this Dell Boomi webinar.

New webinar from CloudBees and Codesion - CollabNet Cloud Services:
Tuesday, March 6, 2012 10:00 AM - 11:00 AM PST

At this very moment, software development and deployment practices are shifting monumentally…to the cloud! The cloud provides significant advantages that allow organizations to substantially improve efficiencies and delivery times at a much lower cost, reducing the overall total cost of delivery of applications.

Exploit the cloud? Get even better at Agile? Save time and money?

If any of these concepts pique your interest, you’ll enjoy this new webinar from luminaries at CloudBees and Codesion, the Cloud Services arm of CollabNet.

CloudBees VP of Products Steve Harris, CollabNet VP of Products and Engineering Willie Wang, and CloudBees Solutions Architect Jim Leary will enlighten you on how to easily and cost-effectively…

• Get started developing and deploying applications in the cloud
• Improve and expand your Agile practices using the cloud
• Exploit the cloud to accelerate the development and delivery of quality applications
• Modernize your continuous integration and deployment process and methods

If you want to spend more time writing awesome code and less time managing your environment, register for this webinar.

Willie Wang
CollabNet VP of Products and Engineering
Jim Leary
CloudBees Solutions ArchitectSteve Harris
CloudBees Senior VP of Products

Watch a demonstration of a salesforce.com and SAP integration in this live Dell Boomi webinar.

Picture Credit: Picupper.com

For most of the pundits out there in valley, OpenSocial is dead and meaningless. However, at Lotusphere 2012 last month, IBM was highlighting how they have used OpenSocial in their image makeover towards Social Business. They have relied on OpenSocial for activity streams and gadgets. When I was speaking to Suzanne Livingston from IBM if she anticipates OpenSocial to be resurrected inside the enterprises (which I personally think is going to be the case), she sounded affirmative. I thought I will do a brief post highlighting this view and get the feedback from other pundits.

Remind me, what is OpenSocial?

Simply put, OpenSocial is a set of APIs (containers) that helps add social component to web services/applications (for example, activity streams are a good example of this) and also in integrating different web pages by using OpenSocial Gadgets. For “interactions” that are not done using the browser, it also offers a REST API. Google threw OpenSocial as an alternative to a walled garden like approach taken by Facebook few years ago. Then Google didn’t have a social DNA and this move was seen as a hail mary pass to stop Facebook from getting a run away lead in social. However, it didn’t get enough traction in the consumer side and Facebook did run away with the kind of lead which Google feared at that time.

However, as the so called consumerization of enterprise started to happen and enterprise applications started getting socially aware (a core attribute as I have pointed out in this position paper), OpenSocial looked like a great opportunity for enterprise software companies. From Atlassian to Jive to IBM to SAP, many companies were embracing OpenSocial for injecting social DNA into their software. OpenSocial did start to gain traction in the enterprise.

Even though Lotusphere was all about IBM’s Social agenda, I didn’t fail to notice how effectively they have used OpenSocial to make their applications socially aware. In short, IBM has bet heavily on OpenSocial and I don’t expect them to go back from this moment onwards. They have tied their social future so closely with the future of OpenSocial.

But will it accelerate?

However, things are changing on the consumer side. Facebook has a strong runaway lead and Google is trying to catch up with their own approach to Social, Google+. This time they are doing few things right and Google+ seems to be gaining traction. Google+, even though it doesn’t have a good set of APIs at this moment, is built on top of OpenSocial and the relative success of Google+ is going to keep them heavily engaged in the OpenSocial community even as Larry Page keeps pruning their own services. Also, Google wants to take Google+ to enterprises and their approach with Google Apps offers some insight into where they are heading. If they want to really get some traction for Google+ on the enterprise side, they have to make Google+ the “social messaging bus” for enterprise application. It implies that they need to invest more on OpenSocial efforts. When you have companies like IBM and Google focussing their energies on OpenSocial, there is a very high likelihood that it will gain further traction and get further adoption. I am always in favor of open standards and I am realistically optimistic about the chances for OpenSocial in the enterprise. What do you think?

disclosure: IBM took care of my travel and stay for Lotusphere

As the platform matures, we see many cool applications being built on top of Cloud Foundry. This is the first in a series of guest blog posts by application developers explaining what their application does, how it is architected, what they like in Cloud Foundry and what needs to be improved.

Guest blog post by Eric Bottard

ThemaTweets2012 allows you to visualize what people say about the french elections candidates on Twitter, how these candidates relate to key themes of this 2012 event and analyze information under several angles.

The Story

In late 2011, Google France launched a data visualization challenge about the upcoming 2012 presidential elections. The rules of the challenge were pretty straightforward : provide a web application that leverages data from Google and/or Twitter and shed a new light on the french elections. The winners would eventually win a trip to Mountain View, or a nice Android tablet.

My team and I started hacking pretty late and although we wanted to use that opportunity to experiment with new technologies and great ideas (after all, the main reason we engaged in the challenge was for the fun of it), we focused ourselves on one simple thing : detecting the topics that mattered the most to people, and how candidates to the elections related to those. Now, you’ll admit that 140 characters is not much to convey structured information. Add to this the fact that people don’t always put a lot of effort into writing elaborate sentences on Twitter, so we decided to keep things simple : we would only count occurrences of candidates and topics, without trying to analyze the tone of the tweet.

Being a dataviz oriented application, ThemaTweets allows the user to navigate between different views of the same raw data. The main screen shows an overall breakdown of candidates and then the topics mentioned in tweets (eg. Nicolas Sarkozy is found in 43% of the tweets we captured and amongst those, 28% cite the topic “Taxes”). Click on a button and you’ll invert the view (eg. 54% of tweets captured deal with “Ecology”, of which 33% are linked to François Hollande).

One can also view the evolution of these figures over time. This is already useful and interesting, but we wanted to go further than that and help some hidden information surface out of those simple datapoints. So the application also has two other views :

1. one allows us to see how topics “belong” to a political side. By assigning some kind of left-right alignment to each of the candidates, we can average the relative positions of topics relative to each other.
2. the other selects the topics that are the most often encountered for each candidate and then displays the “overlap” that one can find between two (or more) candidates. For example, if N. Sarkozy is linked to “Euro crisis” in 34% of the tweets and Dominique de Villepin is credited with 21% of tweets for the same topic, we’d link them together with an arc. The thickness of the arc at both ends reflects the percentages.

Lastly, we added a view that highlights the terms we captured in the tweets, so that people can witness were the data is coming from.

Of course, users can view the evolution of topics or candidates share over time

How the application actually works

Under the hood, ThemaTweets is a simple web application, built on top of Spring and Hibernate. The data model is rather simple, with an added twist whereby we aggregate data hourly to avoid recomputing means and sums every time a view is needed. It leverages the twitter4j library to connect to twitter, making use of the streaming API. There are fixed keyword terms made of the candidates names (and their political parties, collaborators and so on). This allows the twitter API to pre-filter results. Then, for each tweet that is received, the app tries to match it against keywords related to topics. Contrary to the candidate filter, there is an opportunity here to apply Lucene related technology where we tokenize and stem the words (so that we would match “écologie”, “écolo”, “écologiste” as well as variants without the accented “é”). While we originally went for a trained bayesian filter approach, the ratio of useful words to garbage was really huge. So we decided to keep the algorithm, but using only handcrafted positive weighs for the topic words. This worked really well.

Terms that are captured in tweets are highlighted and linked to views in the application, so that users understand where the data is coming from

Being proficient with the technologies used helped us prototype quickly, with an added productivity bonus coming from Spring Data JPA. The application UI is really client centric, with data coming in JSON from Spring MVC controllers.

Interacting with Cloud Foundry

We chose from the start to experiment with some cloud infrastructure, just for the fun of it. Moreover, we had no idea of the exposure the app would get once the challengers would be revealed. Sadly, we did not have time to lose trying to bend our minds around limitations in JPA queries that actually operate on a NoSQL backend, or trying to have maven and a cloud related eclipse plugin play nicely together. So we finally went for Cloud Foundry after one or two days.

The setup was the most impressive experience I guess. Imagine adding 3 lines of maven plugin configuration to your pom.xml and being able to push the application code directly to the cloud ! The interaction with the vmc command line tool was also very pleasant, and provisioning services by simply following a wizard felt refreshing.

I think the most astonishing feature was the fact that, ThemaTweets being a rather simple app with only one datasource, it got reconfigured automagically to use the cloud mysql instance, as detailed here. So the very same code that ran locally could be deployed in the cloud with no modification.

Also, having access to a genuine java virtual machine without restrictions also was decisive in our choice. Indeed, the Twitter streaming API requires a long lived thread to be connected to the twitter servers, which ruled out some of the alternatives.

Those three lines of XML configuration are all that is needed to deploy to the cloud with maven

Of course, there were some difficulties nevertheless. The biggest drawback comes from the fact that when you’re in the cloud, you’re pretty blind to what happens with your app. At first, there was no way to know what was getting stored in our database, so we had to roll out our own back office application. Luckily, the tunnel solution was discovered soon after, although we had a very hard time making it work on a mac (something that should go more smoothly in the future if I understand correctly).

A side effect of this blindness is that importing / exporting data is pretty complicated, even with the tunnel working. Because of timeouts that have to be enforced on the mysql services, exporting our data had to be done in chunks, which was a bit tedious. Nevertheless, I believe the tunneling approach is very smart and could allow other usages in the future.

We also witnessed some strange memory usage from time to time, whereas the app was behaving very nicely locally.

Some additions to the platform could also be considered as “nice to have”, even though we made it without them. For starters, code versionning was not really an issue for us, as the app was not live until the challenge was over. But because Cloud Foundry allows services to be bound to multiple applications, I guess you can get away with having another app alias running the new code and being bound to the same services.

We also needed our Twitter connector to be a singleton among the whole cluster. While we ended up starting it from an http thread, having a cloud-aware singleton spring scope supported by the platform would be nice (remember that you can’t know beforehand the IP addresses of the machines you’ll be running on, etc.)

I also recently realized that although Cloud Foundry almost gives access to a vanilla Tomcat server, there is no way to add custom jars to the lib/ folder (eg. to allow Spring load time weaving). The platform does add the mysql/postgresql jdbc connector jar for you though.

Finally, I guess what the platform today lacks compared to the competition is a nice looking web UI, although the vmc command line tool (and the REST API behind it) offer a lot information.

Happy End

As you can guess, we were really impressed by the technology. We did not win the first prize in the challenge, but made it to the finals nevertheless. For the purpose of being shown on this youtube channel, the app had to be moved and operated by Google. Because Cloud Foundry did not force us to modify our plain Spring MVC app, the very same war file is now hosted on another platform and it works like a charm.

Signup for Cloud Foundry today, and start building your own cool app!

Our crack Services team has written a new technical solution brief about the pitfalls of doing DR for multi-tier applications. Seeing as how most apps these days are multi-tier, and those apps are usually the most critical to a business, figuring out how to backup or failover is paramount. We’ll serialize the tech brief for a few days here, but you can always find the whole thing here.

Protecting Multi-tier Applications

Overview 

Many businesses rely on multi-tier applications in order to deliver highly available and scalable services to their enterprise. Multi-tier applications are network services that are delivered using multiple servers each running specific roles within the tiered application. Typical multi-tier applications consist of at least a database layer and an application layer. Depending upon the service, multi-tier applications can consist of many more layers and services. Enterprise class applications often have the option of running many roles on one server and subsequently scaling up to multiple tiers in order to grow with increasing use and demand within an organization.

Given the scalable nature of a typical multi-tier application, these same services tend to be critical to business continuity. Due to the inherent complexity of multi-tier applications, developing a disaster recovery strategy for these applications can seem overwhelming. Using the nScaled approach, we can deliver a solution that can be routinely tested, validated, and easy to use, making protecting these critical applications achievable.

Typical Multi-Tier Architectures 

Even with the wide array of applications that can be delivered using a multi-tier design, the overall architecture of all multi-tier applications tend to have many – if not all – of the same components in common. Applications such as document management, online learning, customer relationship management, accounting, human resource management, asset tracking, and many others use architecture similar to the one shown.

Multi-tier applications tend to take considerable time and expense to set up. The investment of time required to completely and effectively deploy this architecture is well worth the reward, however, given the inherent scalability and reliability associated with reducing single points of failure and distributing the computing workload across more than one server.

Basic Server Protection 

With the nScaled approach, servers are protected using block level mirroring technology. Each write operation on a protected server is mirrored to the nScaled Local Cloud Appliance on the customer’s network. Once the initial snapshot has been taken, subsequent changes (deltas) are captured in a consistent state called a “quiescent snapshot”. A quiescent snapshot is an exact representation of a server at a specific point in time where both the file system and underlying blocks are in a consistent state. This quiescent state allows a server to be booted from the snapshot as a virtual machine. This approach is independent of any underlying SAN technology and works with both physical and virtual machines. Once the snapshots are captured on the Local Cloud Appliance, the data is replicated to the customer’s environment in the nScaled Remote Cloud data center. Since the server snapshot is in a quiescent state, the server can then be booted in the nScaled Local Cloud Appliance or in the nScaled Remote Cloud whenever it is needed.

We’ll finish up next time.

Richard Wallis left Talis (my former employer) last month, and has set up as a consultant at DataLiberate. In this short podcast, Richard shares some of his thoughts on data, semantics, and ‘the power of the link.’

Our conversation is also an excuse for an experiment. I have been producing audio-only podcasts here and elsewhere for a number of years, but have always tended to avoid producing video. It’s more effort, it requires more bandwidth at both ends of the conversation, and I’ve never really been convinced that it adds very much to a conversation between two people. Anecdotal evidence would also suggest that my current podcasts are consumed in environments where video would not work; washing dishes, walking dogs, and sitting on buses.

However, rather than just continue to presume that my biases are correct, I’ve decided to give video a try. Richard kindly agreed to participate, and the result is available on YouTube and embedded here.

An audio-only version is also available for download if you prefer. The introductory remarks in this version are slightly different to those on the video, as they come straight from the original conversation.

It’s perhaps unfair to draw too many conclusions from this first attempt, but a few things are immediately apparent. The whole process takes an awful lot longer. The files are larger, so processing and uploading times increase 2-3 fold. Uploading a separate audio file also takes a bit of time. Simply dumping the Skype recording into iMovie worked just fine… but I’ve (so far) not managed to find any way to balance the audio levels. Garageband lets me do this with my audio-only podcasts, but iMovie doesn’t seem to, so Richard’s side of the conversation comes across as quite a bit louder than mine.

Having done one, I’m still not convinced that the video adds anything to the conversation. But what do you think? If you’ve listened to any of my podcasts, please take a moment to complete the short survey over at SurveyMonkey. Your responses will help me to decide where to go next.

Many thanks.

(Cross-posted @ Paul Miller - The Cloud of Data)

Piston Cloud Computing, Inc., the enterprise OpenStack company, today announced strategic partnerships with leading cloud infrastructure automation companies Opscode, Puppet Labs and RightScale. These partnerships enable Piston Cloud’s customers to easily automate the tasks necessary to manage applications within their private clouds, simplifying the adoption curve. “Today’s private cloud solutions are poised to transform IT economics for the enterprise,” said Joshua McKenty, CEO and co-founder of Piston Cloud Computing, Inc. “Automation and orchestration are key to realizing the operational efficiencies of private cloud. By supporting solutions like Opscode Chef, Puppet Enterprise ...

This video provides an overview describing what will be covered in this 8 part video tutorial on building a multi-tier cloud application.