Language Frontier: March 2010

Sunday, March 28, 2010

Combining and Testing a joint Ruby Rack and Sintra Application

Having explored basic Rack features in previous posts, I will today venture into using Rack with Sinatra and cover testing.

Sinatra: Rack Reloaded

Sinatra is light-weight web framework on top of Rack. It is easy to configure and supports a wide array of template languages. It also literally speaks to the developer - request handlers are defined in a very natural reading domain-specific language.

Suppose we want to design the 'Hello World!' application again, using Sinatra this time. The code is this:

[cc lang="ruby"] require 'sinatra' class HelloWorld < Sinatra::Base get '/' do content_type "text/plain" 'Hello World!' end end [/cc]

Line 4 shows how different URLs inside the application are declared. The [cci lang="ruby"]get[/cci] defines a HTTP get method handler which returns the result of the supplied block. Line 5 sets the content type for this request, and Line 6 returns the String 'Hello World!'

Now we want to use this application with the known [cci lang="ruby"]Rack::Builder[/cci]. We don’t want to use a browser manually, but automate the test. So let’s introduce Ruby web application testing

Saturday, March 13, 2010

Ruby Rack: Using Objects and defining Middleware

Rack is an interface to many Ruby web application. The last post showed how to use simple lambdas to define applications. Today, we explain how to use classes and what a Rack middleware is.

Rack Applications using Class Objects

Remember from the last post that any Ruby object can be used as a Rack application - as long as it answers to the call method. It’s perfectly valid to use a normal class object. Just take a look at the following code:


class HelloWorld
  def call(env)
    return [200, {"Content-Type" => "text/plain"}, body]
  end
end

status = lambda do |env| 
  [200, {"Content-Type" => "text/plain"}, ["Running | #{Time.now}"]]
end

map '/' do
  run status
end

map '/hello' do
  run HelloWorld.new
end

Now, whenever we hit the '/hello' URL, the HelloWorld instance's call method is executed. Every Ruby class object can be used in this way inside a Rack application. Just think about all those projects you have made and how easy you can bring them to the web.

Monday, March 8, 2010

Short Taxonomy of Domain-Specific Languages

This article introduces how Domain-Specific Language can be separated along their origin, appearance, and implementation.

Types of DSLs

DSLs are separated into the following dimensions origin, appearance, and implementation according to [MernikEtAl2005], [CzarneckiEisenecker2000].

Origin

Describes whether the DSL is based on a host language or uses a individual generator or compiler.

External DSL: If the language engineer wants to have maximum freedom with the available expression and statement -- from both a syntactic and a semantic perspective -- then external DSL are the right means. Once the initial design is determined, a model for parsing the syntax to an internal representation, and the semantics of the internal representation have to be defined. Doing this from scratch is a tremendous effort, but special tools can help, like the early Centaur [BorrasEtAl1989] and PAN [BallanceEtAl1990], or the modern xtext. The tools predefine the language used to express grammatical rules, transformations, and semantics.
Internal DSL: Instead of designing a complete free language, the language engineers can also use an existing programming language as the host. The complete language infrastructure, consisting of editors, tools and compilers, can be reused with the DSL. Also, reuse is strong because every DSL expression is an expression of the host language. which simplifies integrating the DSL with existing libraries, frameworks and other DSL written in the same language. Internal DSL sacrifice their syntactic and semantic freedom for this infrastructure, requiring less effort to get a first implementation. But they require extensive developer knowledge of the metaprogramming capabilities of the language in order to extend the available methods and symbols to suite the domain.

Read more about the appearance and implementation of a DSL at http://dsl-engineer.com/2010/03/08/short-taxono…ific-languages/

Wednesday, March 3, 2010

Introduction to Ruby Rack

Rack is a minimalistic web application interface sitting in the background of your favorite Ruby web framework. This post introduces Rack and shows how to implement a minimal stand-alone ‘Hello World’ application.

Introduction to Rack

Rack is a minimal framework for web applications. Build on top of libraries like Net::HTTP, it defines domain objects such as path, requests, params, responses, cookies and sessions. In short, it handles many low-level details and encapsulates them in easy-to-use objects. Rack has evolved from a standalone application to an interface for major Ruby web frameworks like Rails, Merb, Ramaze, Sinatra and Camping are supported. Once you understand the Rack interface, It allows you two distinct usages. First, any Rack compatible application can be combined with other applications through a central configuration file. Second, some applications can be used as middlewares - code pieces filtering request and applying specific modifications or messaging of these requests.

Language Frontier