We're looking to help developers like you to build the apps that will drive Windows 8. If you're already building Windows 8 applications, or want to get started, let me know. I'll help get you early access to the app store, and even get you a Microsoft engineer to help you build it!

As if you needed another reason... just build _anything_ and get yourself a chance to win cash.

The Imagine Cup - I wish this had existed when I was in school

So, you're an ASP.NET developer and you're moving your app to the cloud. Time to learn about some alternate forms of persistent data storage... Don't worry, it won't hurt.

I know, I know... you're swamped at work. How are you gonna get a full day off for Azure training?

What are you waiting for? Get started developing for the cloud, at no cost (and free lunch too)!

Ready for class? Check out these great learning tools for Azure!

Customers and partners often ask me what the benefits are to moving from on-premise or traditional hosting environments to a cloud based platform like Windows Azure or AWS. If you're an ASP.NET application developer, you'll typically find the answer in one or more of these three reasons - Cost, Focus and Capabilities.

Want to support my.fancy.app.can.serve.up.anything.mybrand.com in your Windows Azure application? Just use wildcard CNAMEs and a little code glue!

So, you've decided to configure your Azure diagnostics using the magic of the diagnostics.wadcfg file, but haven't yet committed the schema to memory?

Fresh off the back of a cocktail napkin, here's a couple of sketches that might help you understand the components of Microsoft's cloud platform.

Processing image files while the user waits = badness. Let's look at the path to goodness, using Queues.

So, a very good friend and super smart developer has published his second book...

Just a quick note, following a debug session tonight...

I'm collecting a bunch of new links for you, to get you started and keep you moving along the path to cloud goodness.

We know a lot of you have been waiting for this: You can now create AppHarbor applications in the EU! This new feature will make creating fast and responsive apps targeted at European end users a lot easier. EU applications will still run on Amazon's high performance infrastructure, only they'll be running out of the EU-West region (Dublin) instead of US-East, where all current applications are located.

We have spent a lot of time making sure the AppHarbor platform is modular and scalable and this paid dividends when time came to spin up our new EU location. New applications are created in either the US or EU and existing applications cannot be moved, but we're already thinking about how to turn this up another notch to make AppHarbor a zero-configuration, multi-region, geo-load-balanced application platform.

Add-ons in the the AppHarbor add-on catalog will work with EU-based applications. Some (such as SQL Server) will intelligently provision resources based on where your application is located. We're working with our other add-on providers so that latency-sensitive add-ons can be provisioned in locations close to the application that is going to consume the add-on. For add-ons that do not currently support the EU, a warning will be displayed when they're provisioned to an EU application.

We're incredibly excited about this feature and we can't to see all the great apps that will soon be running out of the new AppHarbor EU location.

Image credit: Håkan Dahlström

We're very excited to welcome Xeround into the AppHarbor add-on catalog. Xeround is a cloud database, engineered from the ground up to be elastic, scalable and resilient to hardware failures. Xeround is MySQL-compatible and this lets you take advantage of all the great MySQL drivers and other tooling out there and not worry about learning new APIs or tools. The Xeround homepage has more details on what makes the service tick.

Using Xeround from your AppHarbor-hosted application is as simple as adding the add-on and then using the injected connectionstring in your app. We've written a short guide on using Xeround and we also provide a complete ASP.NET MVC sample application that you can either use to get started or look at for inspiration. It uses NHibernate and SchemaUpdate for easy configuration and hands-free automatic migrations.

Don't miss out on a great service, add the Xeround add-on) to your AppHarbor app right now.

We’ve recently made two significant improvements to the AppHarbor build setup: ASP.NET view precompilation and more and bigger build servers. Read on for details on both.

ASP.NET view precompilation

We recently extended support for ASP.NET view precompilation. Previously, if an application project file specified view precompilation AppHarbor would build application views but view build-output was not included in the package that AppHarbor deploys. View compilation on AppHarbor gave the safety of knowing that views contain no syntax errors, but it did not improve application startup performance.

We have now changed our build handling to package the view build output with the rest of the app. For new apps, compiling views is on by default (you can toggle this in application settings). Properly precompiled views should make your app start much faster.

View precompilation on AppHarbor is a separate step from the rest of the build so if your project file specifies MvcBuildViews and view compilation is specified for the app, views will get built twice. For that reason, we recommend setting MvcBuildViews to false for apps you’re deploying to AppHarbor.

Faster build servers

AppHarbor has grown significantly over the past year. If you’ve noticed increased build times it’s because our build infrastructure has been increasingly strained. In fact, until a few weeks ago, all builds were processed by a single server processing builds in sequence and it was beginning to show.

We launched AppHarbor with the promise to "deploy in 15 seconds, not 15 minutes". To stay true to that promise, we've now improved our build setup so that it can handle multiple builds simultaneously. We have also added additional and bigger build-servers and the built-in Git service runs on its own instance. This has the following advantages:

• Builds will rarely be queued for more than 3-5 seconds.
• Compilation is much faster (up to 60-70%) than on the old server
• The complimentary Git service is more reliable

The old build- and git-server is the oldest EC2 instance in the AppHarbor lineup and it's been with us since the very beginning when we had no money to buy fast instances. It previously hosted Git-repositories, ran builds and unit tests and held all AppHarbor SQL Server databases. It’ll soldier on for a time, running the Git-repositories that come with each application. But rest assured that it’s no longer slowing down your AppHarbor deploys.

We'll continue to optimize build times and improve application startup performance. We are also looking forward to new features in .NET 4.5 that'll let us further improve these aspects of AppHarbor. Until then we hope you'll enjoy the improved build process and give us any feedback you may have about how we can make it even better.

Image credit: Ciprian Popescu

When Sierra Trading Post launched their new API late last year with a contest, Joel Martinez and Cary Torkelson jumped at the opportunity to build something. Joel is an Android, Windows Phone and iOS mobile developer from New Jersey and Cary is the founder of a game development company based in NYC.

Together they created a price drop notification app called Dapper Hawk which took home the contest's 'Most Creative & Fun' award. Dapper Hawk is hosted on AppHarbor so we asked Joel to tell us more about the app.

What is Dapper Hawk?

JM: Dapper Hawk lets you search for products from the Sierra Trading Post catalog, and be notified when the price drops via email. The consumer-facing portion of the app is a simple interface to STP's search API. Once you find a product that you are interested in, you can watch it (like a hawk ;-) ). Then we have a backend process that we initiate daily which goes out and checks the latest price of the watched items. If a price goes down, we send the user an email to let them know of the price drop.

Sierra Trading Post held a contest for their API late last year. We decided to enter the API contest and brainstormed different ideas for our entry on the train ride into the city. After we decided on what we were going to build, I suggested that we use AppHarbor to prototype the idea because it was so easy to get started. Cary worked on the back-end code ... designing both the database schema, and the data access layer. And I worked on the API integration with Sierra Trading Post, and the front-end.

What did you build it with?

JM: Both of us have C# backgrounds, so ASP.NET MVC 3 with the Razor view engine was a natural choice. For the backend, we experimented briefly with the MongoDB add-on available through AppHarbor, but we ultimately decided to go with the tried and true SQL Server. We also decided to use jQuery for the 'watcher' functionality of the app (behind the scenes) to avoid HTTP timeouts from trying to host a long running process in IIS. The watcher manages the process of going out to check for the latest price for each watched item on the client so if there are a large number of items, the process can continue processing without timing out.

This was the first time I had a chance to use Razor, as a previous project where I used ASP.NET MVC was started before it was released (MVC 1.0 days). This turned out to be my favorite part of development as Razor is a joy to use.

I also used Paint.NET for all graphics and logos on the site. It's such a great editor in the absence of Photoshop. More people should really know about it.

What was something unexpected you learned while building it?

JM: It's not really something new that we learned, more like a reinforcement of what probably everyone knows intuitively but doesn't think about. And that's just how much work goes into all of the other aspects of creating a new product aside from pure development. Even for a small product like this, there's all the accounts we had to open (AppHarbor, affiliate program, STP API, bank, Google Analytics, AdSense, etc.). Then there's all of the testing/tweaking that amounts to basically staring at the same thing for hours on end. And finally there's copy-writing. Although the site doesn't have much text, we had to write some stuff for the contest entry describing what it was, and we had to make sure that the copy we did have on the site was clear and concise enough to let the user know what was going on, while not overwhelming the page with unnecessary info.

What advice would you give to other developers running their apps on AppHarbor?

Make sure you don't forget that AppHarbor can easily load balance your apps across multiple instances should the need arise. This means to pay attention to things like avoiding server-side state if possible, or at least using some of the awesome add-ons such as memcache to store your session state. Also, remember that every time you push changes, it's automatically deployed (assuming all tests pass and it compiles). This is a very freeing concept as it lets you avoid worrying about deployment, and allows you to focus on writing new features and shipping them nearly immediately.

What are your plans for it in the future?

There's a few different directions we can take the product at this stage. A few ideas that we're considering:

• Incorporating APIs and affiliate systems from other retailers, such as Amazon.
• Tracking price drop data and building a predictive price model that can suggest when a good time to buy might be coming up for a given product.

We also probably need a good designer to help us out with our logo and general UI/UX.

Your account statements are now accessible through appharbor.com, where you can easily get an overview of all your applications and how much each will cost you.

You can view both settled account statements for previous months and also the current statement as shown in the screenshot. The current statement shows what we'll bill for at the end of this month. If a service is removed you'll notice that the end date is updated and that the amount is prorated for the period you've used it. Likewise, if new services are added or the subscription changes, it'll also be instantly reflected on the current account statement.

Remember that all services you buy from AppHarbor are prorated down to the millisecond, so you only pay for what you use. You can use the account statement along with the subscription page to make sure that you're on the subscription that makes the most sense for the services you've selected.

AppHarbor plans also includes all usage (within the limits of our program policy, which makes it very easy to know exactly how much your services costs. We hope that this new account-level overview will give you a better idea about what we're billing for and help avoid surprises when you receive your invoice.

Account statements can be accessed by clicking your username in the upper right corner (when logged in) and following the "Statements" link.