Monday, May 24, 2010

TAP is a better ?Hello World? ? Or The Challenge of Web-Application Development

We all know the infamous 'Hello World' applications to learn a programming language. But really - are you satisfied with a self-declaring one-liner to see how a language works? I’m certainly not. TAP - Twitter Application - is my approach to understand a language in more detail. TAP is a web application which produces HTML and CSS, talks with the Twitter API, and stores users and their tweets in a local database. Much to cover and thus much to learn how things work. This article explains the common functionality of TAP, and future posts cover implementation with Ruby, Python and more languages.

TAP Defined

Many of you already know or use the micro-blogging platform Twitter. User exchange small posts, called tweets in the Twitter jargon, either public visible or private. Tweets have a maximum length of 140 characters, thus requiring concessions to put something meaningful online. But hey, constraints are the fuel of creativity. Twitter also has a good documented API which allows to fetch posts from different users or the public timeline (recent posts of all users).

So what is TAP about? TAP allows to configure a set of users and store their tweets in a local database. You can see it as a personal Twitter hub. There is a dialogue to configure the registered users, you can view tweets with different filters, and a update TAP to fetch the newest tweets for all users. And this small application requires many stuff making traditional 'Hello World' apps child’s play. We need to filter URLs and invoke handlers, read and pass form & request parameters, render dynamic HTML, read & write to database and communicate with the Twitter API. That TAP's ground. Although the use cases are simple ones, combining all the little pieces is great for learning a languages capability and to get a feeling how things work.

See and read about the interface and upcoming posts athttp://blog.sebastianguenther.org/2010/05/24/tap-is-a-better-hello-world-or-the-challenge-of-web-application-development

Friday, May 14, 2010

Understanding Metaprogramming as Scope Manipulation

The common understanding of metaprogramming is to use a programming language for the manipulation of a realized program. In this article, I elaborate the scope concept as the internal representation of a programs structure. Metaprogramming is then explained as manipulating a programs scope.

Programs as Multi-Dimensional Scopes

A scope is the set of modules, classes, functions, constants and variables (generally called entities) which have a well defined visibility. For example, the global scope usually contains the core classes of the used language (like strings, integers, arrays) and other well known entities. A program either extends the global scope with its entities, or provides additional scopes. The entities of one scope are usually private, but can be made accessible from other scopes too. How new scopes are defined is dependent on and special to the used programming language: Scopes are created inside modules, classes, function declarations, or further expressions like control structures, iterations, or anonymous code blocks. The visibility of these scopes depends on the language: Typically, the methods and modules of classes are visible, but narrower scopes are not. In summary, a program consists of a set of scopes, each declaring their own set of entities.

Scopes are initially created by defining new entities. A declaration uses several expressions and statements to define a new scope - for example the definition of inner classes or methods. Declarations either happen intentionally as execution of manually written statements, or automatically by importing packages or modules from another scope, mix-in entities from modules, or copy entities with expressions from one scope to the current. After execution of the expressions, the scope will be populated with a number of entities, and is ready to be used in the program.

Read more at http://dsl-engineer.com/2010/05/14/understanding-metaprogramming-as-scope-manipulation-2.

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

Read more at http://blog.sebastianguenther.org/2010/03/28/combining-and-testing-a-joint-ruby-rack-and-sintra-application/

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.

Read more at http://blog.sebastianguenther.org/2010/03/13/ruby-rack-using-objects-and-defining-middleware

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.

Read more at http://blog.sebastianguenther.org/2010/03/01/introduction-to-ruby-rack/

Sunday, February 28, 2010

Welcome

Welcome to my blog! Let me introduce myself. My name is Sebastian Günther. I'm a researcher with special interest into domain-specific languages (DSL), metaprogramming, and dynamic programming languages. I have much experience with writing Ruby application including web-frameworks like Ruby on Rails, Sinatra, and Rack. When you program in Ruby, you have a vast array of DSL to choose from: Rake for general application tasks, DataMapper to bridge the gap between databases and application entities, and RSpec for high-level tests. But how are those DSL actually designed? How are they implemented within Ruby? Such questions motivate me in my research. I want to answer the question how to design, implement, and use DSL in software development.

Around this motivation, I want to present small reports, essays and tutorial about DSL, libraries and frameworks. Although I'm coming from the Ruby world, I will also write about other dynamic languages, like Python and Scala.

This blogs is a mirror of may activities at blog.sebastianguenther.org and dsl-engineer.com. I wish to reach a wide audience, so you can comment and discuss my articles right here - your feedback is welcome. You can also check out my Twitter profile.

But what exactly will I read here? If you

  • want to understand how to apply recent libraries and frameworks
  • see various domain-specific languages in action
  • gain insight into practical metaprogramming

then subscribe to this blog - or check back later to see the evolved content.

Have a good reading experience!

Sebastian