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.

As a reference application for SignalR, David Fowler from the ASP.NET team built JabbR, an open source group chat application similar to HipChat or Campfire. It's a complete chat solution with rooms, private messaging, emoji, embeddable content, desktop alerts, audio notifications and more. You can even write Hubot-like bots using Jabbot. A public version is hosted at jabbr.net and has become a popular gathering place for members of the ASP.NET community.

You can quickly get up and running with your own private JabbR instance on AppHarbor using a free web worker in combination with (also free) Shared SQL Server Yacto add-on. Here are the steps to follow to get it up and running for your team:

• Create an AppHarbor application with the SQL Server add-on
  • NEW: Enable file system write access in application settings (Jabbr caches optimized javascript and stylesheets)
• Create a Janrain Engage account for authentication
• Clone the code from GitHub
• Update configuration settings
• Deploy to AppHarbor

Create an AppHarbor application with the SQL Server add-on

Sign into your account, select 'Your Applications', enter the name of your application and click 'Create New'. After the application is created, select 'Add-ons' from the left and from the add-on screen install the Yacto SQL Server plan.

When the add-on installation completes, click on 'SQL Server' in the installed add-ons list.

From there, click on 'Go to SQL Server' which will bring you to the configuration screen for your database. On the configuration screen, click 'Edit alias', enter 'Jabbr' (exactly as shown below) in the Alias field and click 'Update'.

When you deploy your app to AppHarbor later on, JabbR's connection string will be replaced with the connection string for your live database. This allows you to use the SQL Express instance locally for testing and the live database for production without having to manage the connection strings yourself.

Create a JanRain Engage account for authentication

JabbR uses Janrain's Engage (formerly RPX Now) service for authentication. You can sign up for a free account here. During the sign up process you'll be asked for an application name. Enter something memorable as you'll be using this value later to connect your Janrain account to the JabbR application.

After you've completed the account set up, configure which sign on providers you'd like to support (https://rpxnow.com/relying_parties/<your_app_name_here>/setup_widget). Note that currently JabbR only supports authentication via Janrain and since your site will be on a public URL anyone could log into it. We recommend you pick a URL that would be difficult to guess and only enable the sign on provider most relevant to your users. JabbR may add more authentication options in the future or you could customize the source to integration more closely with your environment.

With your Janrain Engage account created and your providers configured, head back to your dashboard and click '(manage)' next to 'Your Domains' on the bottom right of the screen. From there, add the domain(s) you'll be using for your JabbR site (e.g. myjabbr.apphb.com).

Clone the JabbR code from GitHub

Next we'll download the code from GitHub. Using your Git tool of choice, clone https://github.com/davidfowl/JabbR.git From Git Bash, it would look like this:

$ git clone https://github.com/davidfowl/JabbR.git

That will create a JabbR folder under the current folder.

Update configuration settings

Open JabbR.sln in Visual Studio and open the Web.config file. Update the appSettings values to match those from your Janrain Engage account. Note that the appName is the one you picked during sign up, and not the AppId shown in the dashboard.

<appSettings>
    <add key="auth.apiKey" value="janrain_engage_api_key_here" />
    <add key="auth.appName" value="janrain_engage_app_name_here" />
</appSettings>

Deploy to AppHarbor

From your AppHarbor application detail page, click 'Repository URL' to copy it to the clipboard. Back in Git Bash, add that URL as a remote so you can push your code to it:

$ git remote add appharbor https://[email protected]/your_app_name.git

Next, commit your changes to your local repository and push them to AppHarbor:

$ git commit -am "updated web.config"
$ git push appharbor master

That's it, you're done! Load your app in your browser and chat away.

Give back to JabbR

Because JabbR is open source, if there's a feature you want or a bug you need fixed you can contribute it back to the project. There's no better way to express your appreciation for high-quality free open source software than to give back to the project you're using. If you have any idea for something you'd like to add, join the public JabbR meta room to discuss it.

How often does your payroll software ship new features? Once a year? Never?

KeyPay is an Australian startup that wants to change the slow pace that traditional payroll sofware moves at and they're using AppHarbor to make that possible for their customers. The company shipped new features four times last week and has done 20 new releases since launching six weeks ago.

We had a chance to talk to Phil Bernie about what KeyPay is and how they're using AppHarbor.

What is KeyPay?

PB: KeyPay is a cloud based payroll application for small to medium Australian businesses. The cool thing about it being hosted in the cloud is that you can access it anywhere, anytime from just about any internet enabled device. We love the fact that we can have accountants processing payrolls for clients from their iPads at a coffee shop, or that employees can login and check their payslips from their iPhone and it all happens without having to install a single thing.

KeyPay was founded by myself (@lomaxx), Paul Duran (@fatal2), Kristian Reynolds (@kristian) and Richard McLean (@richwebscale).

Why did you decide to start KeyPay?

PB: The inspiration for KeyPay came from not being satisfied with the payroll options for small to medium businesses. Rich has worked with many clients for a number of years and he saw time and again the frustration of small businesses having to choose between clunky desktop software with specific OS requirements, backup routines etc and enterprise level systems like SAP which are so expensive and complicated to setup that it's just not viable for a small business to use.

After thinking long and hard about it, we felt we could design a fully featured payroll system that was simple and affordable for smaller businesses and allowed them to use KeyPay when and where it suited them.

What technologies are you using?

PB: We use ASP.NET MVC 3 (but hoping to move to 4 soon) with MSSQL (via the SQL Server add-on) for the database. For data access we use NHibernate (with FluentNHibernate). We use Spark as our view engine and on the client side we use jQuery and Knockout.js a lot. Our HTML is also heavily reliant on the awesome Twitter Bootstrap framework. For our blog we also use the FunnelWeb blog engine. For sending emails we use the SendGrid add-on. Our code is hosted on BitBucket using Mercurial.

We love ASP.NET MVC and have found it really enjoyable to work with, particularly when coupled with Knockout.js. Using them together has really helped us keep our UI simple yet responsive which makes it a very for us.

We didn't fully appreciate the power of using a DVCS like Mercurial was because it was the first project everyone in our team had used it for so we've really enjoyed that. What we didn't expect was how well AppHarboor supports working with DVCS. We can have multiple branches of development that we can push to our central repo and AppHarbor will build all the branches, which is extremely useful. The icing on the cake is that you can pick any one of the branches that have successfully built and deploy them with the click of a button. We weren't quite expecting AppHarbor to be so well integrated with DVCS.

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

PB: Completely Embrace AppHarbor. If you're going to use AppHarbor, don't have half your services hosted on AppHarbor and half on an EC2 instance somewhere or on a desktop server under your desk.

Our general principle is that if it doesn't run on AppHarbor we aren't interested in using it, because it just ends up costing too much time and/or money for it to be worth it.

We also really enjoy using the addons and if there's an addon that does the job for you, we'd strongly recommend using it because the deployment / integration story is awesome.

What's in store for the future?

PB: We're really excited about establishing KeyPay in Australia so that's our focus at the moment but we're keen to expand into international markets in the future and we see AppHarbor as a key part of that plan. We're also working hard on integrating with other 3rd-party services to help ensure a smoother overall cloud experience.

Any final thoughts?

PB: The only other thing I'd like to mention is that AppHarbor is extremely cost effective, but the quality is amazing. We're self-funded so we don't have piles of VC money to throw around, so doing the math, AppHarbor is the most cost effective solution for us. We run two instances with a few addons, SSL and custom domains and our bill last month was < AU$50 which is amazing given what we get for that price. When we're ready to scale we can pay more for web workers and even then, it's still an extremely cost effective option.

---

Using AppHarbor to continuously deploy your application can give you significant speed advantages over entrenched competition that can't move nearly as fast. If you want to ship more features faster, sign up for a free AppHarbor account.

We're happy to announce the release of the AppHarbor CLI. This utility gives you complete control over your applications using simple commands. After logging in, you can create new applications, retrieve build history, and manage configuration variables and host names.

Get started by downloading and installing the utility. The installer will add it to your system path.

Download AppHarbor CLI

In the first version, the following commands are supported. The commands at the end in parentheses are shortcuts that you can use directly. This will be demonstrated in the examples below.

app                         #  List your applications
app create [name]           #  Create an application ("create")
app delete                  #  Delete application
app info                    #  Get application details
app link [slug]             #  Link directory to an application ("link")
app unlink                  #  Unlink application from directory ("unlink")
build                       #  List latest builds
config add [key=value]      #  Add configuration variable to application
config                      #  List all configuration variables
config remove [key1 key2..] #  Remove configuration variable
help                        #  Display help summary
hostname add [hostname]     #  Add a hostname
hostname                    #  List all associated hostnames
hostname remove [hostname]  #  Remove hostname from application
user login                  #  Login to AppHarbor ("login")
user logout                 #  Logout of AppHarbor ("logout")
user                        #  Show currently logged in user

Example: Create a new application

Begin by opening a command prompt and logging with your AppHarbor user information.

c:\dev>appharbor user login
Username: js
Password: **********************
Successfully logged in as js

Create a new directory for your app and use the create shortcut to create the app with AppHarbor and initialize the directory with the Git settings your application needs to push and deploy your code to AppHarbor's servers.

c:\dev>mkdir MyFancyApp
c:\dev>cd MyFancyApp

c:\dev\MyFancyApp>appharbor create MyFancyApp
Created application "myfancyapp" | URL: https://myfancyapp.apphb.com

Git repository is not initialized in this folder. 
Do you want to initialize it (type "y")? y

Git repository was initialized with default .gitignore file.
Added "appharbor" as a remote repository. 
Push to AppHarbor with git push appharbor master.

Example: Link an existing application

If you already have an app in a folder configured for use with AppHarbor, you can link it to the existing application so that you can use the CLI commands to manage configuration variables and hostnames.

Navigate to the folder that contains your application and use the link command to tie it to the specified AppHarbor application slug. If the appharbor remote doesn't exist, it will be created for you.

c:\dev>mkdir MyExistingApp

c:\dev>cd MyExistingApp

c:\dev\MyExistingApp>appharbor link myexistingapp
Added "appharbor" as a remote repository. 
Push to AppHarbor with git push appharbor master.

More To Come

In this first version we wanted to make sure we supported the core interactions developers have with AppHarbor on a daily basis. We'll be adding more commands and features in the future so keep an eye on the GitHub project for changes. And since it's open source, if there's a command you'd like to add, feel free to fork the project and send a pull request.

Have questions or need help with AppHarbor CLI? We're standing by.

This blog post is a tutorial on configuring automatic schema-migrations using Entity Framework 4.3 in an ASP.NET MVC application (we'll do a post on doing the same with NHibernate soon). Having your application automatically update its database schema greatly eases development and makes frequent deployments to platforms like AppHarbor a cinch.

Why you want automatic migrations

At AppHarbor, we try to make deploying new versions of your code as fast and safe as possible. An important part of dependable application deployment procedures are safe and correct schema-migrations of any underlying datastore. If you are using a schema-less NoSQL datastore like RavenDB, CouchDB or MongoDB, this is probably not a big problem. If you're using a traditional SQL-based datastore like Microsoft SQL Server or MySQL, migrations are an important concern.

Because AppHarbor makes deployment relatively painless, you'll likely end up deploying more frequently than you're used to. Frequent deploys makes automated schema-management important. If it's a manual and error-prone chore, it will make pushing new versions of your code less attractive and this negates some of the advantages you get from running on AppHarbor. With dependable, automatic migrations in place, you can fearlessly push new versions of your code without worrying whether the underlying data-schema is in sync with your code.

When schema-updates should be triggered

We often get questions from users asking how they can incorporate schema-updates as part of AppHarbor building their code. Schema-migrations during builds is a bad idea, however. This is because your schema and code can get out of sync in a number of ways:

• AppHarbor runs unit tests after the build and if any of the unit tests fail, the code is not deployed. You will then have an old version of your code running on the new database schema

• Schema updates are not run if you roll back your application to a previous version of your code. If you roll back and the migration is not run, old code will be running with the newest version of the database schema

• On AppHarbor there's is a lag between the build completing and the code getting deployed during which time running code and schema will be out of sync

A much better approach is to place the code someplace where you know it'll get called at least once before any other code in your app is executed when it's deployed anew. For ASP.NET MVC applications, Application_Start() is a good bet. Alternatively, if the check to see if the schema is up-to-date is fast or can be cached, running the update whenever you instantiate your repositories also works. In the tutorial below, we will use Entity Framework's OnModelCreating(DbModelBuilder modelBuilder) method to configure migrations.

Note that Application_Start() and any repository initilization might get called many times for any one deployed version of your app. On AppHarbor, for example, Application_Start() might get called multiple times if your application pool is recycled and started again or if your application is scaled to multiple web workers each starting up their own instance of your code. This makes it very important that your schema-updates are idempotent, i.e. implemented in such a way that running them multiple times won't cause trouble.

Entity Framework Code First

As mentioned in the introduction, the example we're building is an Entity Framework-backed ASP.NET MVC app. The application will be split into two projects, "Web", an ASP.NET MVC web site, and "Core", a class library. "Core" has all the interesting bits, the website is only included to demonstrate that the migrations are actually working. Here's a screenshot showing the finished solution in all it's simplicity.

The finished "Core" contains the following classes:

• Entity.cs - base class for all model classes, has Id property (required by Entity Framework)
• User.cs - lone model class (you can add more)
• Configuration.cs - where migration behaviour is configured
• Context.cs - the context used to manipulate entities and where migrations are enabled

To start out, let's set up a standard Entity Framework Code First data store. First create the Core class library project and install Entity Framework from the NuGet package manager console:

install-package EntityFramework -ProjectName Core

Then add these classes:

Entity.cs:

namespace Core.Model
{
    public abstract class Entity
    {
        public int Id { get; set; }
    }
}

User.cs:

namespace Core.Model
{
    public class User : Entity
    {
        public string Name { get; set; }
    }
}

Context.cs:

using System.Data.Entity;
using Core.Model;

namespace Core.Persistence
{
    public class Context : DbContext
    {
        public DbSet<User> Users { get; set; }
    }
}

...and that's it for Core project for now. Go ahead and create the Web project (this tutorial uses Haack's Really Empty MVC 3 project template). For development storage, we'll be using SQL Server Compact and installing EntityFramework.SqlServerCompact gets us the necessary packages:

install-package EntityFramework.SqlServerCompact -ProjectName Web

Add a project reference to the Core project and add HomeController.cs:

using System.Web.Mvc;
using Core.Model;
using Core.Persistence;

namespace Web.Controllers
{
    public class HomeController : Controller
    {
        private readonly Context _context = new Context();

        public ActionResult Index()
        {
            return View(_context.Users);
        }

        public ActionResult Create(User user)
        {
            _context.Users.Add(user);
            _context.SaveChanges();

            return RedirectToAction("Index");
        }
    }
}

Add a Home directory in Views and an Index.cshtml view:

@model IEnumerable<Core.Model.User>

<h2>Index</h2>

<ul>
    @foreach (var user in Model)
    {
        <li>@user.Name</li>
    }
</ul>

@using(Html.BeginForm("Create", "Home", FormMethod.Post))
{
    <input type="text" name="Name" />
    <input type="submit" value="Submit" />
}

Now create an App_Data directory in the Web project for SQL Server CE to store its files and then configure the connection in Web.config:

<connectionStrings>
    <add name="context" connectionString="Data Source=|DataDirectory|data.sdf" 
            providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>

Hitting F5 should result in a web form that you can use to add users to the database.

Automatic migrations

First, try changing the User model class by adding an additional property

namespace Core.Model
{
    public class User : Entity
    {
        public string Name { get; set; }
        public string EmailAddress { get; set; }
    }
}

And update the view accordingly:

@model IEnumerable<Core.Model.User>

<h2>Index</h2>

<ul>
    @foreach (var user in Model)
    {
        <li>@user.Name (@user.EmailAddress)</li>
    }
</ul>

@using(Html.BeginForm("Create", "Home", FormMethod.Post))
{
    <input type="text" name="Name" />
    <input type="text" name="EmailAddress" />
    <input type="submit" value="Submit" />
}

If you try to run the app now, Entity Framework will throw an exception stating that the model has changed and that you should be using migrations. In this tutorial we will use automatic migrations (if your application requires very elaborate migrations then Entity Framework also does code-based migrations). Configuring automatic migrations is extremly simple, just add a configuration class to the Core project:

using System.Data.Entity.Migrations;

namespace Core.Persistence
{
    public class Configuration : DbMigrationsConfiguration<Context>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
        }
    }
}

(AutomaticMigrationDataLossAllowed is optional. Without it, Entity Framework will throw an exception if it's about to do a migration that involves dropping columns or tables).

Finally add this OnModelCreating method to the Context class:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    Database.SetInitializer(new MigrateDatabaseToLatestVersion<Context, Configuration>());
}

That's it! Hit F5 and your app is in business with any previous data intact (less any dropped entities or columns) and the database schema automatically updated to reflect the new model.

Deploying to AppHarbor

The best thing is that all this deploys and works seamlessly on AppHarbor. The only thing lacking in the code is a Web.Release.config transform that changes the providerName attribute in the connectionstring from System.Data.SqlServerCe.4.0 to System.Data.SqlClient:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings>
    <add xdt:Locator="Condition([@name='context'])" providerName="System.Data.SqlClient" 
        xdt:Transform="SetAttributes" />
  </connectionStrings>
</configuration>

You also need add the SQL Server add-on to your application and set the alias to "context" (see screenshot below). This will make AppHarbor overwrite your SQL Server Compact Edition connectionstring with one that will work on AppHarbor.

Wrap up

So there you have it. Entity Framework Code First is delightfully simple to configure and use and with the migrations features released in 4.3, managing schemas while developing and deploying fast-changing apps is no longer a chore.

Full source code for this blog post is available here: https://github.com/friism/CodeFirstMigrations

Redis is all the rage lately. If isn't helping your company get bought for a billion dollars, it's helping run your favorite sites like Stack Overflow, GitHub and craigslist.

Redis is a key/value data store focused on performance. At a glance, it's deceptively simple with only five primitive data types and a set of simple commands. But with simplicity comes great flexibility and Redis shines in use cases from tiny to enormous and everything in between. Redis most likely won't replace your traditional relational database, but it's many uses (like caching, queues, pub/sub) can augment any application.

If you'd like to learn more about Redis, we recommend the following resources. Go ahead and read through them. We'll wait here until you're ready.

• Karl Seguin's Little Redis Book (highly recommended for getting started)
• Interactive tutorial
• Redis official web site
• What are the underlying data structures used for Redis?
• Redis at Stack Exchange
• Redis persistence demystified (advanced)
• Fast, easy, realtime metrics using Redis bitmaps (advanced)

Redis in .NET

While there has been some effort to run Redis on Windows, it's not officially supported. AppHarbor has your back though with our Redis To Go add-on. After installing the add-on you can access your Redis To Go instance from your local machine but just be aware that there may be a little bit more latency between your local machine and Redis To Go than there will be between our servers and theirs. This is nothing to worry about though, Redis is so fast you probably won't notice.

To interact with the server you'll want to use either ServiceStack.Redis from Demis Bellot or Booksleeve from Marc Gravell. Both make all the Redis commands available to you in a .NET friendly way. For this post our examples will use ServiceStack.Redis, but Booksleeve will work just as well if it's more your style.

Hello World

Create a new AppHarbor application and add the Redis To Go add-on. The free 5MB plan will suffice for this example. Once you've set up your application, create a new project in Visual Studio. The easiest way to get ServiceStack.Redis is via NuGet so add that to your project as well.

To access your Redis To Go instance we need to grab the server URL. From your application's page click on the Redis To Go entry under 'Installed Add-ons' and then click 'Go to Redis To Go'. You should see a screen that looks like this:

Copy the URL at the top of the screen that starts with redis://. We'll use this URL in our local environment by creating an application setting in our app.config (or web.config in a web project) like this:

<?xml version="1.0"?>
<configuration>
    <appSettings>
        <add key="REDISTOGO_URL" value="redis://redistogo-appharbor:[email protected]:9081/"/>
    </appSettings>
</configuration>

Be sure to add a reference to System.Configuration so that we can access the app setting from our code. If you're using a console app, make sure you are not using the client profile.

Now we're ready to write some code! Let's write a simple string value to the 'hello' key and then write it back out to the console:

using System;
using ServiceStack.Redis;
using System.Configuration;

namespace RedisIntro
{
    class Program
    {
        static void Main(string[] args)
        {
            var url = new Uri(ConfigurationManager.AppSettings["REDISTOGO_URL"]);
            using (var redis = new RedisClient(url))
            {
                redis.Set("hello", "world");
                Console.WriteLine(redis.Get<string>("hello"));
            }

            Console.ReadLine();
        }
    }
}

If everything checks out when you run the program 'world!' will be displayed.

Turning it up to 11

We were recently very impressed with Compilify, a web site that allows you to compile and run .NET code from your web browser. Compilify works by taking the code entered in the browser and putting into a Redis-based queue to be processed by a background worker. The background worker listens for new jobs in the queue, executes the code contained in the queue items and uses Redis' publish/subscribe facilities to send a message with the outcome back to the browser. Check out the source code of the worker to get a sense for how Redis makes some traditionally complicated tasks very simple and straightforward. Learn more about Compilify from our interview with Justin Rusbatch.

Web or Worker

Redis isn't just for worker processes. Your web applications can take full advantage of it as well. One of the strongest use cases for Redis is caching. If you're starting to see performance issues in your site, adding Redis as a caching layer can provide significant performance boosts with minimal code. Read Kevin Montrose's answer about how Stack Exchange uses Redis for caching to learn more.

Your Turn

Have you deployed an AppHarbor app that uses Redis? If so, we want to hear about it! Drop us a note describing how you used it and if we feature it on the blog, we'll send you some AppHarbor swag. If you have any questions about using AppHarbor and Redis, we're always standing by to help.

CouchDB is an advanced and mature NoSQL database that has been around since 2005. CouchDB stores data in a JSON format and uses Javascript for queries and to define views. It also has great HTTP-based REST API. These features makes CouchDB extremely accessible and easy to use by web developers.

On AppHarbor you can get fast, hosted CouchDB by using the add-on provided by our friends at Cloudant (Cloudant was in the illustrious first batch of AppHarbor add-ons).

The Cloudant guys have great resources to get .NET developers started with CouchDB. If you don’t want to use the raw REST API, there are a bunch of solid libraries that make using CouchDB from .NET very simple. These include:

• Divan
• Relax
• relax-net
• EasyCouchDB
• WDK.API.CouchDB

Sample application

To make getting started with CouchDB on AppHarbor even faster, we have developed a simple ASP.NET MVC application that uses CouchDB as its backing store. The sample uses relax-net to talk to CouchDB. relax-net handles interaction with CouchDB service and abstracts away all JSON serialization and deserialization of .NET objects.

relax-net also comes with a strongly-typed, fluent query-syntax for fetching documents out of CouchDB. The neat thing is that these relax-net queries are automatically converted to Javascript-defined CouchDB views. This means that queries, after the first, one are going to be super fast, even if query parameters change. Below is a screenshot of the Cloudant administration interface showing a view automatically generated by the query on age found in the sample code.

var repository = new Repository<T>("connectionString")
var peopleAgeFiftyOrOlder = repository.Where(x => x.Age).Ge(50)

Don’t miss out on this great piece of technology and go provision the Cloudant add-on right now!

*

In our last post about background workers we talked about simple one-time background task execution and how to handle errors and capture output from them. This post will build on the concepts introduced in that post and introduce how to use Quartz to run tasks on a schedule.

Quartz: "Enterprise" Job Scheduler for .NET

Quartz is a job scheduling framework that is a port from the popular Java version of the same name. While the syntax can feel a little Java-ish, the just-released version 2.0 has made many improvements. The code is available on GitHub and documentation can be found on the project site. Note that at the time of publishing this post the Quartz tutorial has not yet been updated to use the new version of the library.

Here are some example use cases that are supported:

• Run a job one time at a specified time
• Run a job every 10 seconds
• Run a job every day at a specified time of day
• Run a job using a cron-compatible schedule

For more examples, head over to the project site.

There are three pieces involved in scheduling a task to run. The first part is the job itself. Jobs are simple classes that implement the one required method of IJob called Execute. The next piece is called a trigger. Triggers are containers for scheduling logic that allow you to specify when the job should be run. Triggers can be configured with a variety of different schedules and intervals.

After you create a job and a trigger you pass a pair of them to a scheduler which takes care of running them at the appointed times.

Your First Scheduled Task

For our first example we'll create a worker that outputs the current time to the console every 15 seconds. Start by creating a new console app in Visual Studio and installing the Quartz package via NuGet.

The logic for our task is a simple implementation of IJob:

using System;
using Quartz;

namespace QuartzIntro
{
    public class SampleJob : IJob
    {
        public void Execute(IJobExecutionContext context)
        {
            Console.WriteLine(DateTimeOffset.Now);
        }
    }
}

In a more practical use case you can replace our useless implementation with any code that you'd like. With the job logic done, we can create a trigger and schedule the job:

using Quartz;
using Quartz.Impl;

namespace QuartzIntro
{
    class Program
    {
        static void Main(string[] args)
        {
            // construct a scheduler
            var schedulerFactory = new StdSchedulerFactory();
            var scheduler = schedulerFactory.GetScheduler();
            scheduler.Start();

            var job = JobBuilder.Create<SampleJob>().Build();

            var trigger = TriggerBuilder.Create()
                            .WithSimpleSchedule(x => x.WithIntervalInSeconds(15).RepeatForever())
                            .Build();

            scheduler.ScheduleJob(job, trigger);
        }
    }
}

There are a few interesting things worth pointing out here. First, a scheduler can handle any number of jobs and triggers. Second, as long as the scheduler has jobs scheduled the application will continue to run. That means you don't have to put in any while (true) blocks to keep it alive. If the app exits with a non-zero code (which most likely means it encountered an unhandled exception), AppHarbor will restart it and the scheduler will resume. If the scheduler doesn't have any outstanding tasks the application will exit and restart on the next deploy.

Complex Schedules

Quartz supports cron-style scheduling as well to suit your most intricate scheduling needs. For instance, if we have a task that needs to be run at 10:30, 11:30, 12:30, and 13:30 on every Wednesday and Friday we can create a trigger with that schedule using the cron syntax. We'll also tell it to start an hour after the worker is launched and to end in seven days.

using System;
using Quartz;
using Quartz.Impl;

namespace QuartzIntro
{
    class Program
    {
        static void Main(string[] args)
        {
            var schedulerFactory = new StdSchedulerFactory();
            var scheduler = schedulerFactory.GetScheduler();
            scheduler.Start();

            var job = JobBuilder.Create<SampleJob>().Build();

            var cron = TriggerBuilder.Create()
                            .WithCronSchedule("0 30 10-13 ? * WED,FRI")
                            .StartAt(DateBuilder.FutureDate(1, IntervalUnit.Hour))
                            .EndAt(DateTimeOffset.Now.AddDays(7))
                            .Build();

            scheduler.ScheduleJob(job, cron);
        }
    }
}

Just Scratching the Surface

We've only just touched on a small amount of the functionality Quartz offers. Try it out in your next AppHarbor background worker to see if it will work for your scheduling needs.

We have just added Blitline to the add-on catalog. Blitline is a great way to offload image processing from your AppHarbor application to a dedicated, high-performance cloud service.

Blitline supports most image processing functions relevant for web applications such as generating thumbnails, applying filters, adding watermarks, rotating images and many more. Jobs are scheduled using a convenient REST API and Blitline will notify your application via a callback-url once your processed image is ready.

Add Blitline to your AppHarbor application right now, get rid of your crufty image processing code and start getting beautifully processed images from Blitline, fast.