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.

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.

We are sponsoring the upcoming Cloud Connect Conference in Santa Clara.

If you’re in the neighborhood, stop by our booth (#818) and grab yourself this cool T-shirt!

Visiting the Expo hall is FREE: Get a free pass here (Use code CPNACC138)

The expo at Cloud Connect is open Tuesday – Wednesday, February 14-15 – 11am to 6pm.

Hope to see you there!

You may also be interested in:

• Visit Xeround @ Cloud Connect Santa Clara – Get Your Free Expo Pass Today!


• Meet Xeround Team at the 2011 MySQL Conference & Expo


• Data Matters – OSCON and Beyond

If you have used Jelastic, chances are, you have also tried one of our competitors. There are a number of them out there. One of the biggest ones is Google App Engine.

One of the main reasons we developed Jelastic was due to the short comings and hurdles that the current solutions available for deploying Java apps to the Cloud had, either inherent or planned. One of the biggest issues is being locked-in to, and having to code for the platform that you wanted to use.  With Jelastic, you don’t have to worry about that. You are never locked-in; you don’t have to code for the platform (because we use standard software stacks); and deploying your app is easy.

One of our users, Richard Bremmer, wrote a short post on his blog (Codezuki) about moving from Google App Engine. Here it is in part:

Moving from Google App Engine to Jelastic

by Richard Bremmer

I have had some experience recently moving from GAE (Google App Engine) to Jelastic. One of the main reasons I fell out of love with GAE is because it required too many design compromises. I found myself designing my data model because GAE needed it to be that way and not because that’s how I wanted it to be. Such design restrictionsare in the name of extreme scalability – however I came to realise that I will probably never need such scalability and in the short term the compromises were hurting my effort. I started looking for alternatives…

After being burned by GAE (ok, it was a slow burn over a few years I decided I wanted full control and I eventually narrowed this down to two great options. Cloud Foundry is an excellent choice which I strongly suggest you should consider. Being a Mac user and not wanting to spend money on VMware Fusion I decided to look for something free and I eventually settled on Jelastic.

The great thing about Jelastic is that you don’t have to run any kind of special local environment. When you setup your Jelastic environment you have several database and application server options. I chose MySQL and Tomcat. Now I can build and run my .war against my local MySQL and Tomcat then simply deploy it to Jelastic and that’s it – ready for the great unwashed masses. The fact that there is nothing special about the Jelastic environment is its greatest attribute in my opinion, I can deploy my .war file just about anywhere. Yippe

….

Though he has run into a few problems (you can read more about those on his post), we are continuing to work through our beta and most of those issues should be resolved now.

We hope you have a great weekend. If you have any issues or need to reach out to us, you can always find us Facebook or Twitter.

Looking Back
In 2011 we added a total of seven edge locations to Amazon CloudFront and Route 53. We also added lots of new features, as I documented last year.

Looking Forward
Our newest edge locations are located in Milan, Italy and Osaka, Japan. This brings our total worldwide location count to 26 (see the CloudFront page for a complete list). Each new edge location helps lower latency and improves performance for your end users.

Making Plans
We have additional locations in the pipeline for 2012 and beyond. Our planning process takes a number of factors in to account including notes from our sales team and discussions on the Amazon CloudFront forum. We also collect latency measurements from a number of points around the globe to our current set of locations and correlate them with broadband Internet penetration and existing Amazon CloudFront usage in the area.

I would also like to invite you to participate in the Amazon CloudFront Edge Location Survey. We are very interested in your suggestions for additional locations. We'd also like to learn a bit more about the type of content that you deliver to your customers.

All Aboard
The CloudFront team is hiring. We need some Software Development Engineers, a Senior Systems Engineer,a Senior Software Development Manager,  a Product Manager, and a Business Development Representative.

-- Jeff;

 

CloudBees is proud to be sponsoring the 7th Annual Philly Emerging Tech Conference, April 10 & 11th in Philadelphia. If you're in the vicinity, check out this popular conference, hosted by our friends at Chariot Solutions. It sells out most years, so don't wait to sign up for this 2-day, 5-track technology extravaganza.

The Emerging Tech Conference (a.k.a. Emerging Technologies for the Enterprise) covers topics ranging from Java EE in the cloud to the Play Framework to cross-platform mobile development to NoSQL to HTML5 to functional programming patterns. Check out the full session list here and the list of expert presenters here.

The Early Bird rate of $375 per person is available through February 15. If you can take advantage of the group discount -- 4 colleagues or friends, not necessarily from the same company –- register at the same time and the price drops to $281.25 per person.

Sessions covering a wide array of technologies complement the Java and JVM-based focus. In addition to keynote speakers Chad Fowler (VP Engineering, LivingSocial) and Alex Payne (CTO, Simple Finance), the conference features Yukihiro Matsumoto (creator of the Ruby Programming Language); Douglas Crockford (Senior JavaScript Architect, Yahoo); Yehuda Katz (Ember.js and jQuery core developer); Elika Etemad (W3C CSS Working Group); James Shore (author of The Art of Agile Development); and many others. Keep an eye on the site, because more speakers and session abstracts will be added over the next few weeks.

Register and attend!

A little more than a year ago I presented a session on cloud computing at a CIO conference where I highlighted the three key issues prevent cloud computing adoption: security/privacy, availability and performance. However, in doing some research for a session I gave at CA World this past November, I realized that things have changed. Back in the mid-1990s companies were nervous about leveraging...