As a tester I’m often in a position where I want to write web applications for a variety of purposes. Most recently I wanted to make a simple test application that could be used to prove out my Symbiont test framework. Then I realized I wanted to deploy this application so that it would be available for a variety of purposes. I started looking into the simplest solutions I could find. This series of posts will cover what I learned.

This first post in the series will be a necessary slog through describing what I needed in place before I could do the work I wanted to do. It’s easy to write this stuff up in a linear fashion now but a lot of this was material that I had to learn piece-meal. Hopefully someone reading this will find this helps them get started quicker. The level of knowledge I’m going to assume exists will vacillate. It’s hard to cover every aspect of what everyone needs to know.

The Language Platform

You have to install Ruby. I recommend 1.9.3 just because I don’t like lagging behind on versions unless there is a good reason to do so. You will also want to install Rubygems if it’s not installed automatically for you as part of installing Ruby. (The installer on Windows automatically installs Rubygems, for example, thus saving you a step.)

You’re going to be installing lots of gems. Gems are similar in concept to PHP’s PEAR packages or Java’s archive files (JAR, EAR, and WAR). Ruby gems are self contained libraries and Ruby programs; the fact that they are in a gem file makes them easy to install. Rubygems can be thought of as a package manager, similar to PyPi for Python, Cabal for Haskell, Ivy for Java, or NuGet for .NET.

The Distribution Platform

One of my goals was to deploy the app I created to Heroku. Heroku is an online Rack cloud computing Platform as a Service (PaaS). The idea is that it provides a computing platform and a solution stack as a service. A solution stack is a set of different programs or application software that are bundled together in order to produce a desired solution. In order to do this later, it’s going to help to get the foundation for this in place now so that we don’t have to stop what we’re doing just to get the necessary plumbing and electrical wires in place.

Before you deploy your application to Heroku, you will want to use Bundler to manage all of the dependencies that your application has. These include all of the gems that you use as well as the gems that they depend on. You can also manage the version number of any gems so that you can ensure that the versions used in production are the same as those used in your development environment. So Bundler is essentially a dependency management solution. Along with that, Bundler allows you to make sure that you can provide a consistent, versioned development and execution platform.

You will need to install the Bundler gem:

gem install bundler

As far as Heroku, it used to be the case that you would simply install a gem to connect to the Heroku servers. However, you will not want to use that gem since it has been deprecated. You now should install the Heroku Toolbelt for your system.

Note: At the time I write this, the process for installing this on Windows, while simple, is a bit muddled. The toolbelt will install a version of Ruby in your OS %Program Files% path — even if you have a Ruby installed already. The installer will then update your system path to this new Ruby. Likewise, even if you elect not to install the bundled Git, the installer will put path references to a non-existent Git installation in your system path.

The toolbelt contains the Heroku client. This client is basically what the previous heroku gem provided: a command-line tool for creating and managing Heroku apps. A tool called Foreman will also be installed. This allows you to run your apps locally in a way that makes sure all supporting processes are also running.

Note: If you already have a Ruby installation, you’ll probably want to delete the Ruby installation that the Heroku client provides. And if you do that, you will need to install Foreman:

gem install foreman

Once you have the toolbelt, create an account at the Heroku site.

If it’s your first time on Heroku you will need to add your SSH keys. If you don’t have SSH keys, there are plenty of resources on the web telling you how to create them. From the command line, do this:

heroku keys:add

You can then authenticate your heroku install by logging in with the information you used when you created an account. Again, from the command line:

heroku login

If you have not added SSH keys, you will be prompted during this process to do so. But if you have, then you will be told your authentication is successful.

You can check the version just to be sure:

heroku --version

Incidentally, if you find yourself wanting to update your Heroku client at any point, that’s simple enough:

heroku update

Okay, that takes care of that. We now have a place that we can distribute our web application to once we create it.

The Web Development Platform

Now we need to get the tool we’ll be using to create our web application, which is called Sinatra. Sinatra is a Ruby gem. So to install Sinatra:

gem install sinatra

Sinatra is a Rack application or, more specifically, Sinatra is a “lightweight” wrapper around Rack middleware that enecourages a close relationship between service endpoints and the HTTP verbs. What that means will become clear as we go on. First let’s make sure that “Rack” is understood. Rack is a middleware API that wraps HTTP requests to help standardize communication between Ruby web applications and web servers. Sinatra abstracts Rack, allowing you to focus solely on responding to HTTP requests without worrying about the underlying plumbing.

Sinatra has a syntax that maps closely to functions exposed by HTTP verbs. Sinatra deliberately takes a minimal approach to development in that it provides only the absolute essentials to deal with HTTP requests and deliver responses to clients, usually the web browser. Sinatra uses a domain specific language and this makes it ideal for creating web sites, web services, and web applications using the Ruby programming language.

A domain specific language is a language for solving a specific problem, or is dedicated to a particular problem type. For example, SQL (Structured Query Language) is designed to facilitate interaction with relational database systems.

Some people like to think of Sinatra as Rails-lite, but Sinatra, unlike Rails, is not a framework. To make this distinction clear, let’s consider the example of Ruby on Rails. Here’s a list of some fo the things you get from Rails: custom routing, controllers, an ORM (Object Relational Mapper), asset packaging, the ability to manage multiple environments, scaffolding, and custom generators.

Sinatra has no helper functions, generator scripts, no asset pipeline, no complex folder hierarchies. There is no built-in ORM nor are there sets of configuration files. Also unlike Rails, Sinatra is not based on the Model-View-Controller (MVC) concept. In fact, it’s not uncommon for an entire Sinatra application to be written in just one file. (Incidentally, the Padrino Framework is itself a wrapper around Sinatra which brings the Sinatra core into the MVC world. If anything Padrino could hold a claim to being a Rails-lite.) The point is that with Sinatra you don’t have to use the MVC paradigm. You’re not tied to any particular ORM (Active Record, Sequel, Mongoid, etc), JavaScript framework (JQuery, MooTools, YUI, etc) or templating system (Haml, ERB, Markaby, Slim, etc).

But let’s go back to that list of what Rails provides. Do you know what all these items are and why you need them? If you’re anything like me, probably not. If you get started with Rails you can fairly easily have a working database-backed website within a half hour or so. You will most likely have absolutely no clue how it works. You will likely be a bit hesitant to change anything just in case you break something that seems to work behind the scenes even though you have no idea how or why. Rails is an example of a framework: it’s something you can put to good use once you know why you want to use it in terms of its particular features.

Sinatra is a tool that does use many of the same conventions as Rails — but it’s much, much simpler. Frameworks like Rails allow you to get really far without really knowing what you’re doing. You will have much better results if you concentrate on making something you actually understand.

So in these posts I’ll focus on Sinatra. We’ll make a small website that you understand. We’ll keep adding to it. You will find yourself doing a lot of repetitive tasks. At some point, as you get better, you’ll probably wish you could automate them. Eventually you’ll start to realize that Rails does automate those things but now you’ll better understand why. And that can lead you into the how. There is less “magic” (read: convention) going on in the background with Sinatra. This means you often have to figure out how to implement certain types of functionality yourself but it also means you know exactly what your app is doing and when.

While we are at it, let’s also install a nice little web server that Sinatra will automatically use if it finds it:

gem install thin

Most Ruby web developers are familiar with WEBrick, a web server written entirely in Ruby. Mongrel was later introduced as a faster and more stable platform for Ruby web applications. Thin continues this evolution by using code from Mongrel to parse HTTP requests but improves network I/O performance via EventMachine, which manages event-based network communication. If Thin is not installed, Sinatra will first try to run with Mongrel, choosing WEBrick if Mongrel isn’t available either.

Let’s also get the Sinatra Reloader.

gem install sinatra-reloader

This extension is helpful for reloading modified files without you having to start and stop the web server. We’ll use this pretty quick once we get development going.

Finally, let’s also get Sinatra Flash.

gem install sinatra-flash

This is a mechanism to let you store messages that the server returns as part of a session and then display them at a later time. We’ll use this fairly quickly as well. Again, we’re grabbing all these tools now just so they are ready when we want to use them.

That’s a lot of info for one post but it was necessary set up to get things going. Following posts in this series will get into some actual details of creating the web application using Sinatra and then, eventually, deploying to Heroku. Stay tuned.