<![CDATA[Language Engineer - sebastianguenther.org]]>

<![CDATA[Language Engineer - sebastianguenther.org]]> 2012-02-24T20:17:53+01:00 en <![CDATA[CIN: Cloud Infrastructure DSLs]]> 2012-02-23T00:00:00+01:00 http://www.sebastianguenther.org/blog/2012-02-23-cin-cloud-infrastructure-dsls.html Imagine you are a server admin and need to create a complete IT infrastructure consisting of an application server, a database server, and a backup server. First, you need to setup the servers, physically or virtually. Second, you need to install an operating system of your choice. Third, you select, configure, and install the needed applications.
No doubt, these steps are easy manageable for experienced admins. Yet, they are time consuming. And if you need to prepare the larger infrastructures over and over again, for example for testing purposes, this becomes a tedious, repetitive task.
In this post, I present my answer to this challenge. In one of the biggest case studies during my PhD, two students and me developed several DSLs that automatizes the creation of complete IT infrastructures. I shortly present each of these DSLs, and show you how to use them.

]]> <![CDATA[rbFeatures: Feature-Oriented Programming in Ruby]]> 2012-02-05T00:00:00+01:00 http://www.sebastianguenther.org/blog/2012-02-05-rbfeatures_feature_oriented_programming_in_ruby.html Feature-Oriented Programming is a paradigm that addresses the configurability of your application. It helps you to modularize your source code according to its functional features. Features can be as coarse granular as complete modules or classes, or as fine granular as statements inside method bodies.

In this post, I present rbFeatures, an extension to the Ruby programming language that enables Feature-oriented programming. With the simple expression Feature.code you can encompass any Ruby code – complete classes, methods, or individual source code lines – to mark what belongs to a feature. Then you just specify which features your program should activate, and you receive an appropriate customized program.

]]> <![CDATA[FOSDEM 2012 - The Free and Open Source Developer Conference in Europe]]> 2012-02-05T00:00:00+01:00 http://www.sebastianguenther.org/blog/2012-02-05-fosdem_2012.html The FOSDEM is a platform, forum, and gathering of open source enthusiasts around the world. This weekend, developers from all over the world are flocking to Brussels for this meeting. I visited some talks on the 3rd February, Saturday, and summarize what I learned.

]]> <![CDATA[Superscope Pattern]]> 2012-01-18T00:00:00+01:00 http://www.sebastianguenther.org/blog/2012-01-18-superscope_pattern.html In a DSL, you want to refer to the most important domain objects by a name that clearly represents the concept. Normally, you can refer to them by using their variable. However, in some cases, accessing the correct scope of these objects may not be usable, so that you need a reference.

But how to refer to objects that exist in another scope without introducing cumbersome and cluttering variable references?

Because such references may use syntactic tradeoffs, they hamper the readability of the DSL and can confuse it's users with semantic details.

Therefore, use symbols or strings as references to objects, and implement a lookup mechanism that refers to the correct object.

Then, you refer to objects at any scope without their actual variable references.

]]> <![CDATA[Seamless Constructor Pattern]]> 2011-12-22T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-12-22-seamless-constructor-pattern.html In languages with an object-oriented core, the creation of new objects is typically expressed with keywords like new. In a DSL, using this keyword explicitly may not be intended, especially not when the keyword has another, domain-specific meaning. More desirable is the behavior that an expression automatically instantiates an object, for example when you type 42, an integer object is created.

But how to avoid explicit object instantiation when this is not a domain concern?

Because explicit instantiation can disturb your DSL's syntax.

Therefore, Use a custom method that receives arguments that creates new objects seamlessly.

Then, the DSL's readability is not impaired.

Read more...

]]> <![CDATA[Method Chaining Pattern]]> 2011-12-12T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-12-12-method-chaining.html In some domains, expressions involve a high number of concepts and operations. For example in financial transactions, accounts, identification numbers, currency information, stock information and more need to be expressed. This complexity should be reflected in the DSL too.

But, do you use too much command-like expressions that fail to represent the relation of different domain concepts or do not read fluently enough?

Because of excessive command-like expressions, programs can be difficult to understand.

Therefore, it is better to combine repetitive methods in one sentence-like expression.

Then, you improve readability and understandability.

]]> <![CDATA[Keyword Arguments Pattern]]> 2011-12-10T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-12-10-keyword-arguments-pattern.html Methods implement the behavior of a DSL. They are vital language expressions and communicate much of the DSL's intention.

But does your DSL suffer from passing to many arguments to functions, confusing the user about the argument's meaning and order?

Because the order of arguments is not clear, hard to track bugs might occur that frustrate the user.

Therefore, define key-value pairs with the key as the argument’s meaning and the value the argument’s value.

Then, using key-value pairs clarifies the meaning of arguments, and allows more flexible argument orders.

]]> <![CDATA[Global Day of Coderetreat]]> 2011-12-07T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-12-07-global-day-of-coderetreat.html Last weekend was the global day of Coderetreat. Read the nutshell introduction to Coderetreat and about my impressions of the Coderetreat event in Ghent.

Read more...

]]> <![CDATA[Block Scope Pattern]]> 2011-12-04T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-12-04-block-scope-pattern.html Many domains have a natural hierarchy of objects. This hierarchy should be reflected in the DSL expressions too. For example, when building a structured document like HTML, the DSL should reflect the document's structure with syntactic indentation, and at the same time provide a separate lexical scope for its expressions.

But has your DSL a flat scope where you mingle objects together? Or is it difficult to express hierarchies of domain concepts that you create and combine to complex expressions?

Because this flat scope hides the context and natural connections between expressions, it is hard to spot what the expressions actually do.

Therefore, define an object that opens the block, and include all expressions that belong to the object's context.

Then, by defining a visual block, the hierarchy and scope of expressions becomes clear.

]]> <![CDATA[Pattern Structure]]> 2011-12-02T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-12-02-pattern-structure.html You remember from my previous article that there are two pattern forms. In this post, I explain why my DSL patterns use a combined form of the alexandrian form and the structured form.

]]> <![CDATA[The RSpec DSL]]> 2011-11-29T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-11-29-the-rspec-dsl.html RSpec is a DSL for writing test scenarios. It is often used for behavior-driven development - you first write the tests, and then the implementation. In this post, I introduce RSpec to serve as the ongoing example in the DSL pattern descriptions.

]]> <![CDATA[The Alexandrian and the Structured Pattern Form]]> 2011-11-27T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-11-27-the-alexandrian-and-the-structured-pattern-form.html Patterns document well-proven solutions to recurring problems. They generalize a set of related problems, carefully document the forces being applied in the context of this problem, and give a possible solution. In essence, patterns are building blocks of knowledge, small gems that you name, apply, and communicate to others. In this post, I further explain patterns and show the two most common forms how patterns are presented.

]]> <![CDATA[How to build DSLs in Ruby]]> 2011-11-26T00:00:00+01:00 http://www.sebastianguenther.org/blog/2011-11-26-dsl-pattern-series.html If you use Ruby, you will definitely stumble upon a Domain-Specific Language (DSL), even if you are not aware. What are DSLs? They are the useful little languages and expressions that we know from Rails, RSpec, Cucumber, Sinatra, and many more. For example, RSpec uses a mix of natural language like test case descriptions and assertions like in car.color.should_be "orange". Or in Sinatra and lately also in Rails, you use get '/customer' do ... end expressions to define a HTTP GET handler. There are several more examples like this. The power of DSLs is that they allow you to exactly communicate what the program should do. But how do you build such a DSL? This series explains the steps and the patterns behind DSLs, and helps you to understand how to successfully build DSLs.

]]> <![CDATA[TAP is a better 'Hello World' - Or The Challenge of Web-Application Development]]> 2010-05-20T00:00:00+02:00 http://www.sebastianguenther.org/blog/2010-05-20-the-better-hello-world.html 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.

]]> <![CDATA[Understanding Metaprogramming as Scope Manipulation]]> 2010-05-14T00:00:00+02:00 http://www.sebastianguenther.org/blog/2010-05-14-understanding-metaprogramming-as-scope-manipulation.html 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.

]]> <![CDATA[Combining and Testing a joint Ruby Rack and Sintra Application]]> 2010-03-28T00:00:00+01:00 http://www.sebastianguenther.org/blog/2010-03-28-combining-and-testing-sinatra-and-rack-applications.html Having explored basic Rack features in previous posts, I will today venture into using Rack with Sinatra and cover testing.

]]> <![CDATA[Short Taxonomy of Domain-Specific Languages]]> 2010-03-08T00:00:00+01:00 http://www.sebastianguenther.org/blog/2010-03-08-short-taxonomy-of-domain-specific-languages.html This article introduces how Domain-Specific Language can be separated along their origin, appearance, and implementation.

]]> <![CDATA[Ruby Rack Using Objects and defining Middlewares]]> 2010-03-01T00:00:00+01:00 http://www.sebastianguenther.org/blog/2010-03-01-ruby-rack-using-objects-and-defining-middleware.html 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.

]]> <![CDATA[Introduction to Ruby Rack]]> 2010-02-28T00:00:00+01:00 http://www.sebastianguenther.org/blog/2010-02-28-introduction-to-ruby-rack.html 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.

]]>