A Quantum Immortal

I had to setup a wiki for some project, and thought of using Heroku for this purpose.

Heroku doesn’t cost anything for 1 dyno, and comes with a bundled 5MB database that might just suffice for this project’s need. To my surprise, I didn’t find any guide on how to do it … but the task didn’t prove to be difficult at all:

1. Create a new git repository
2. Populate it with the latest MediaWiki installation
3. heroku create <app_name>
4. git push heroku master
5. Setup a CNAME record pointing wiki.yourproject.org to your-project.herokuapp.com
6. git config | grep DATABASE
7. Go to http://wiki.yourproject.org/, follow the wizard and configure your database
8. This creates a LocalSettings.php file – download it but DO NOT COMMIT IT yet.
9. Edit it, and replace all the local database settings with this:


## Database settings
$_wgDBConnectionString = getenv('DATABASE_URL');
if (preg_match('%(.*?)://([^:]+):([^@]+)@([^:]+):(\d+)/(.*)%', $_wgDBConnectionString, $regs, PREG_OFFSET_CAPTURE)) {
$wgDBtype = $regs[1][0];
$wgDBuser = $regs[2][0];
$wgDBpassword = $regs[3][0];
$wgDBserver = $regs[4][0];
$wgDBport = $regs[5][0];
$wgDBname = $regs[6][0];
} else {
die("Failed to parse DB connection string");
}


(Obviously, it’s important not to commit your user/pass to a public git repository. If you accidentally did, just remove all reference to it from source control, parse the connection string as above, and then reset your db password).

For your convenience/reference, here is the github repository, although I recommend to just follow the procedure above in order to get the latest MediaWiki and setup wizard.

A little while ago, while coding Bitcoin Pie, I found the need to overcome the notorious Same Origin Policy that limits the domains javascript running on a client’s browser can access. Via Stack Overflow I found a site called Any Origin, that’s basically the easiest way to defeat Same Origin Policy without setting up a dedicated server.

All was well, until about a week ago,  Any Origin stopped working for some (but not all) https requests. It just so happened that in that time I had gained some experience with Play! and Heroku, which enabled me to quickly build an open source clone of Any Origin called Whatever Origin (.org!) (on github). For those unfamiliar with Play! and Heroku, let me give a short introduction:

Heroku is one of the leading PaaS providers. PaaS is just a fancy way of saying “Let us manage your servers, scalability, and security … you just focus on writing the appliaction.” Heroku started as a Ruby shop, but they now support a variety of programming languages and platforms including python, java, scala, javascript/Node.Js. What’s extra cool about them is that they offer a huge set of addons ranging from simple stuff like Custom Domains and Logging through scheduling, email, SMS, and up to more powerful addons like Redis, Neo4j and Memcached.

Now for the application part, I had recently found Play! Framework. Play is a Java/Scala framework for writing web applications that borrows from the Ruby on Rails / Django ideas of providing you with a complete pre-built solution, letting you focus on writing your actual business logic, while allowing you to customize everything later if needed. I encourage you to watch the 12 minute video on Play!’s homepage, it shows how to achieve powerful capabilities from literally scratch. Play! is natively supported at Heroku, so really all you need to do to get a production app running is:

• play new
• Write some business logic (Controllers/Views/whatnot)
• git init … git commit
• “heroku apps add” to create a new app (don’t forget to add “–stack cedar” to use the latest generation Cedar stack)
• “git push heroku master” to upload a new version of your app … it’s automatically built and deployed.

Armed with these tools (which really took me only a few days to learn), I set out to build Whatever Origin. Handling JSONP requests is an IO-bound task – your server basically does an HTTP request, and when it completes, it sends the response to your client wrapped in some javascript/JSON magic. Luckily Play!’s support for Async IO is really sweet and simple. Just look at my single get method:

public static void get(final String url, final String callback) {
    F.Promise<WS.HttpResponse> remoteCall = WS.url(url).getAsync();
 
    await(remoteCall, new F.Action<WS.HttpResponse>() {
        public void invoke(WS.HttpResponse result) {
            String responseStr = getResponseStr(result, url);   // code for getResponseStr() not included in this snippet to hide some ugly irrelevant details
 
            // http://blog.altosresearch.com/supporting-the-jsonp-callback-protocol-with-jquery-and-java/
            if ( callback != null ) {
                response.contentType = "application/x-javascript";
                responseStr = callback + "(" + responseStr + ")";
            } else {
                response.contentType = "application/json";
            }
 
            renderJSON(responseStr);
        }
    });
}

The first line initiates an async fetch of the requested URL, followed by registration to the completion event, and releasing the thread. You could almost think this is Node.Js!

What actually took me the longest time to develop and debug was JSONP itself. The information I found about it, and jQuery’s client-side support was a little tricky to find, and I spent a few hours struggling with overly escaped JSON and other fun stuff. After that was done, I simply pushed it to github, registered the whateverorigin.org domain for a measly $7 a year, and replaced anyorigin.com with whateverorigin.org in Bitcoin Pie’s code, and voila – the site was back online.

I really like developing websites in 2011 – there are entire industries out there that have set out to make it easy for individuals / small startups to build amazing products.