Tag Archives: Sinatra

A simple website on Cloud Foundry

I’ve been remiss in blogging since switching job roles, so it’s about time to change that!

One of the goals of a Platform as a Service (PaaS) – like Cloud Foundry – is to enable developers to be more productive, more quickly. It’s about getting out of the way, removing the barriers and setup steps, and enabling developers to write and deploy great code as quickly as possible.

Something I’ve needed to do fairly often since starting work with Cloud Foundry is to quickly put up a “static” web site. The platform supports a number of runtimes and frameworks (Java, Ruby, node.js etc) but it doesn’t currently[1] have an runtime type of “website”. So, I can’t simply put together a bunch of HTML, CSS, images and client-side Javascript files, run vmc push, and have my site online on cloudfoundry.com – I need an “application” to serve the web content.

That’s exactly what my sinatra-static-web project does for me. I’ve found that it’s a very handy and quick template application which enables me to get simple static sites up on Cloud Foundry, and a good starting point to build out from if I want to stretch my Ruby skills 🙂

To use it, simply fork or clone the project using Git; replace the entire contents of the public directory with your HTML, CSS and JS files (with an index.html file as the main page); potentially adjust a couple of settings in the web.rb file; and vmc push the app. You can take a look at the sample site I’ve added to the app, of course… it’s just a load of junk content based on Twitter Bootstrap and with some random Lorem Ipsum-style text to fill it out.

There’s no real need to go near the code, and it is trivial at any rate – but let’s take a quick look.

# a super-trivial Sinatra-based webserver
# for static content
require 'sinatra'

# set all the settings!

configure do
  # this is arguably not necessary... 'public'
  # folder is the static content location by default
  set :public_folder, 'public'

  # optionally configure Cache-Control headers on responses
  # set :static_cache_control, [:public, :max_age => 300]

  # if using mime types not known to Sinatra, uncomment and
  # configure here (by file extension)
  # mime_type :foo, 'text/foo'

# serve the files!

# route to starting page (index.html)
get "/" do
  redirect '/index.html'

# route to custom error page (404.html)
not_found do
  redirect '/404.html'

The code uses the super-handy Sinatra framework for Ruby, which allows an application with multiple URLs to be defined very quickly. In this case, we simply declare a dependency on Sinatra; set the public folder as the one where the static content resides; and then create a default route, so that when a user hits our root URL / they are redirected to the index.html file. We also create an error route so that if the user hits a URL that doesn’t exist, they receive a customised but simple 404 error page (assuming that such a file exists in the public folder!).

As you can see, there’s really only a few lines of code here, and the rest is handled by the framework. I’ve commented out a couple of optional parameters that can be used if desired, but without any changes this will serve the contents of the public folder perfectly happily.

I’ve used this a few times now, for sites of varying levels of complexity – in particular the resources site I created for Cloud Foundry’s sponsorship of Young Rewired State was based on this (the source code is on Github if you want to take a look at that, too – it’s understandably extremely similar!). I was also able to use it to help a number of students who I worked with at YRS 2012 to get their sites online. More on YRS, shortly…

Just a simple little resource that you might find handy for prototyping your next web UI – you don’t even need to know Ruby, Java, or node.js to get going!

[1] … note that I’m not saying that Cloud Foundry should have or will have such a type of container in the future – but the code base is Open Source, so there’s every chance that someone will come along and add this kind of thing one day!

Update 05 March 2013: I just pushed a few changes to the app to reflect a slight change in the way Sinatra apps work on Cloud Foundry now. Use the source!

Unshaved yaks with MonoDevelop (and some pre-shaved ones, too)

This yak is ready to go!There’s a cool Cloud Foundry fan site called preshavedyak.com – and last week at SourceDevCon London, we challenged a bunch of developers to earn themselves a nice new preshavedyak hoodie by registering for a Cloud Foundry beta account and seeing how quickly they could get a “hello world” app up-and-running in the cloud. The event saw a bunch of new signups and some great discussions.

The “pre-shaved yak”, of course, is one aspect of what a polyglot open source PaaS is all about – delivering a ready-made, ready-to-host, application runtime environment. We shaved the yak, so you can just go ahead and get productive with your development tool of choice, be that vi or emacs, Notepad or TextMate, or Eclipse / a.n.other IDE. Grab a micro Cloud Foundry VM image and take your pre-shaved yak with you when you’re not connected! 🙂

I actually started to write this post in order to comment on something that’s a bit more hairy that, though! I’ve been playing around a little bit with MonoDevelop and ASP.NET (for reasons that will become apparent during this week, I suspect). I’m using the current stable Mono (2.10) and MonoDevelop (2.8) packages on Lion, and they seem to work well. I’ve also recently been learning about Sinatra, the lightweight web framework for Ruby, and one of the node.js equivalents called Express. It turns out that the .NET world has a bunch of Sinatra-wannabes, the most popular of which appears to be Nancy (see what they did there…? dive into the world of Sinatra-themed name-related web frameworks…!).

Nancy’s site recommends installation via NuGet, which is evidently really well integrated into Visual Studio (NuGet is the equivalent of gem in Ruby, or npm in node.js). Unfortunately there’s no MonoDevelop equivalent. Here’s where the yak shaving started! The NuGet FAQ claims that the command line NuGet.exe will run and can be compiled under Mono, but in my experience, that’s not quite true – I could not get the source to compile in MonoDevelop on OS X. I grabbed the pre-compiled version and followed the instruction to get it to update itself (basically you just run it, and it bootstraps and downloads the latest available)… that went fine, but after that, it would no longer work and produced a huge stack trace.

So here, after getting most of a yak’s fleece all over me, is the secret. The prebuilt NuGet.exe will work under Mono on OS X, but it does require a Windows .NET 4.0 DLL (Microsoft.Build.dll) to be in the same directory / locatable in the path – I grabbed mine from my Windows VM install. It also requires that you tell Mono to present a v4.0 runtime. So I whipped up a tiny script to avoid having to type a bunch of paths and switches each time.

# add a simple 'nuget' command to Mac OS X under Mono
# get NuGet.exe binary from http://nuget.codeplex.com/releases/view/58939
# get Microsoft.Build.dll from a Windows .NET 4.0 installation
# copy to /usr/local/bin and Robert is your father's brother….
mono –runtime=v4.0 /usr/local/bin/NuGet.exe $*

view raw


hosted with ❤ by GitHub

Further results of this recent dalliance in .NET land will be coming soon…