Being concise means express a lot, with a few words; being clare and sucint; brief, but with all the required information; having characteristics of brevity and clarity. Note how all definitions imply in being brief, but also about the clarity of the information. Those are two fundamental factors for searching high quality code, easy to be maintained in the long run, affecting the project’s maintainability as much as its architecture does.

Let’s take the act of saving an user in the only database accessed by the application as an example:

user.saveInTheDatabase(database)

It’s clear, it’s even redundant once the name of the method is “typified” whilst repeating the word database. The following code keeps the same clearness related to the same responsibility, but its also succint:

user.save

In another situation, the same code presented above might be implemented by executing other tasks, such as inserting objects related to the user in somewhere else:

def save
  super
  machines_to_install.each do |instance|
    create_machine(instance)
  end

  # or any other effect, collateral or returned
end

The same code is still succinct, but not clear:

user.save

In fact, it lies. It does not say what it will actually do. The search for the “shortest” possible code introduced the possibility of misreading, misinterpreting, even worse, the name of the method induces the error: the code is not concise, it’s just brief.

For this reason, some advanced techniques, such as AOP or even reflection, should be used with care when dealing with domain code. Transparent remotability, EJBs, JPA, ActiveResource, ActiveRecord and any other libraries that work with a layer that it tries to obfuscate might generate problems if the end developer does not fully understands whats beyond it – and the developer who just joined the company *does not*. This is the case where multiple remote invocations or N+1 sql queries, which the mentioned frameworks might induce if not used properly.

Concise does not mean a brief text. One of the biggest challenges of an author is to be concise, trying not to bore his readers, keeping the text’s clarity. Some languages or even libraries might speed up or down the process to say something in a few words, which does not mean the code will be easier to understand and, consequently, to maintain in the long run.

Writing less – the lines of code metric – brings the shortest code, but not necessarily the clearest or best. In the following example, is the client just being saved or is there something else going on, and this “pseudo-conciseness” is tricking us?

cliente.save()

You can create them in Java using class inheritance, or in Ruby using class inheritance or module mix-ins. It is the “inheritance way”. Typically connected with “global variables and methods” and “thread locals”.

In this post we will go through an example of such object with hundreds and methods and show how to decouple our code from that. Moving away from the “Inheritance way” into the “Favor composition over inheritance” way, totally unrelated to language of choice.

Nick Kallen has recently described how to use OO principles to compose behavior in any desired aspect. Yehuda Katz showed how to implement the same behavior in Ruby.

Nick complains about some Ruby code he has seen around, while Yehuda about the Java, and this is the real problem: there is bad OO design out there, no matter which language. Both are correct in their design complains, and both languages can provide the good design techniques and results they are expecting. The question is not about the language, but about the design pattern.

For instance, Rob Olson suggested that, for a typical inheritance problem, the solution was to use meta programming. Yehuda came up with a simple and better solutions, simply use OO: “super”. The original problem arrived because mixing in a module present the same kind of inheritance coupling as from inheriting from a class. So Yehuda’s solution is good for a module with a couple of methods, but dangerous for the design when several mix-ins are included (is 30 too many?) and hundreds of methods made available in the same scope.

But does Ruby code have to end up with hundreds of methods in one object? Douzens of mixins? Surely not. Although, sometimes, it does, as we will see in the following example. As with some Java code sometimes ends up with amazingly huge inheritance trees.

There is no problem in using mix-ins or inheritance once you are aware of its effects in your design. Pretty much in the same way, anyone can do a lot of bad code in Java (and any other OO language) if he is not aware of good OO design principles.

Let’s move to an example of bad usage of inheritance, that can be done either in Java (through mutiple class inheritance and interface implementation) and Ruby (through class inheritance and multiple mixins).

Mixins, coupling issues and the single responsibility principle

The example of “over usage” of inheritance and mix-ins: Rails has greatly improved web applications productivity due to its Convention over Configuration approach. Still, its internal design choices show some famous object oriented design issues. Between those, one that is easily spotted is the need to inherit from ActionController and ActiveResource.

Class inheritance or mix-ins inclusions in Ruby imply in tighter coupling, and a simple test can show how much this coupling implies in 560 methods being inherited and due to Ruby design, private methods also affect this coupling:

rails console

> ActionController::Base.instance_methods.size
306

> OMG
NameError: uninitialized constant Object::OMG

> (ActionController::Base.instance_methods + ActionController::Base.private_instance_methods).size
410

An object having 36 ancestors, 410 instance methods and 353 class methods indicate loss of cohesion, and breaks the SRP and ISP principles from solid.
Usually those approaches with a few scopes and several methods come from procedural programming, while functional programming would use functions as a a higher order element
for composing behavior – which would be great! Unfortunately in this case, those methods are used as almost-global procedures. This can be easily found in other OO languages and frameworks too, just try to find code based in inheritance which provides a huge interface with hundreds of methods being exposed.

This loss of cohesion can be seen when a controller has in its scope methods related to html rendering,
http request and response processing, uri lookup, scope access and more: everything within an instance of ActionController::Base. Cohesion gets weaker when adding new unrelated methods to an ApplicationController, the typical approach.

Unit testing, a technique that easily shows loss of cohesion and tight coupling, easily shows the problem. One needs to either test the class alone by setting expectations to methods contained in the parent class (such as any invocations to param and path methods), or test it only with its parent, by
creating an instance and invoking the desired method. Both approaches show that to create a Controller one needs information from several
different sources, with different goals. This is the sign of coupling and loss of cohesion.

This post implements a work around Rails to show how to remove that coupling and avoid inheritance and mix-ins, while defining a framework (on top
of Rails) that is capable of providing the same functionalities. It is just a working proof of concept. Although it can be used, it needs a lot of enhancements
to provide helpers for every controller-coupled-functionality.

The first example is an action using a few of those different-responsibilities contained within the controller to log in a client:

class ClientsController < ApplicationController
  def create
    @client = Client.find(params[:client])
    session[:current_user] = @client
    flash[:message] = "Client logged in unit!"
    redirect_to client_home_path(@client)
  end
end

Some of those methods could be extracted to ApplicationController, with the same lack of cohesion (those methods would be inherited).
Instead of having the responsibility to deal with parameters, let’s leave it to the framework:

class ClientsController < ApplicationController
  def create(client)
    session[:current_user] = client
    flash[:message] = "Client logged in unit!"
    redirect_to client_home_path(client)
  end
end

class ApplicationController

  private

  def send_action(sym)
    params = ParamsExtractor.extract_for(method(sum), self)
    super(sym, *params)
  end

end

Instead of containing the responsibility of the flash scope, a conversational artificial “http” scope; the session lookup;
and the redirecting, all in one object, those responsibilities can be broken and one would be able to:

class ClientsController < ApplicationController
  def create(client, current_user, redirect_to)
    current_user.login(client)
    redirect_to.client_home(client)
  end
end

class CurrentUserHelper
  def initialize(controller)
    @controller = controller
  end
  def login(client)
    @controller.session[:current_user] = client
    @controller.flash[:message] = "Client logged in unit!"
  end
end

Now its time to implement the parameters provider:

class ParamsExtractor
    def extract_for(method, controller)
      types = method.parameters
      if has_parameters(types)
        provide_instances_for(types, controller)
      else
        []
      end
    end

    private

    def has_parameters(types)
      types.size!=0 && types[0]!=[:rest]
    end

    def provide_instances_for(params, controller)
      params.collect do |param|
        providers.provide(param[1], controller)
      end
    end

end

One needs to implement a provider for each and every desired behavior. For example, to instantiate AR objects:

    class Instantiate
      def extract(controller, name)
        name.camelize.constantize.new(controller.params[p])
      end
      def handles?(controller, name)
        defined?(name.camelize.constantize)==true && name.camelize.constantize.is_a?(ActiveRecord::Base)
      end

Inheritance as a way to get access to new methods is not required any more. Notice how unit testing will provide feedback as higher cohesion and lesser coupling:

class ClientsControl # no inheritance FTW
  def create(client, current_user, redirect_to)
    current_user.login(client)
    redirect_to.client_home(client)
  end
end

Therefore its time to trick Rails to “remove” the inheritance need internally:

def method_for_action(method)
  # TRICKing rails... no inheritance support
  method
end

def send_action(sym)
  type = self.class.name
  control_type = remove_ler_from_controller(type)
  if (class_exists?(control_type, sym))
    type = control_type.constantize
    control = di_instantiate(type)
    params = extract_params_for(control.method(sym))
    ret = control.send sym, *params
    control.instance_variables.each do |x|
      value = control.instance_variable_get x
      instance_variable_set x, value
    end
    super(sym)
  else
    params = extract_params_for(method(sym))
    super(sym, *params)
  end
end

But Rails will complain that at some point the type did not even exist. It shows that checking the existence of the type, method and so on is used in more than one place (loss of cohesion, tighter coupling). Unfortunately, changing all of them requires knowing them all, therefore let’s hack it:

  def pimp(what)
    eval "class #{what.to_s.camelize}Controller < ApplicationController; end"
  end

  pimp :clients

You can see sample helpers, handlers and a few results on what can be achieved with composition instead of inheritance here.

Someone with more knowledge of Rails codebase could remove the pimp hack itself but will soon realize that several points of Rails rely on the fact that this inheritance exists, portraying the high level of coupling and low cohesion of the original procedural approach. The problem with a simple scope control
(one huge object, lots of methods, lots of internal state) is that as more and more code is produced against those expectations, this God object becomes
more and more tighter coupled and the cohesion drops.

This is a proof of concept. Other design change that can be applied is removing the use of thread local variables through public global acessors, which can be redesigned into well-controller scoped objects. Let’s do it?

Knowledge requires practice and takes time to settle, so it is natural to see that, in a currently fast paced changing industry like ours, some individuals are amazingly away out of the mean quality. Feather suggests a graph showing the distribution of people in terms of efficiency. The X axis represents the efficiency and the Y axis the % of people (their representation) in the industry.

Our market does not usually behave in a stabilized way so that a normal distribution would be a perfect fit. A long tail distribution, as the market grows every year, seems more plausible. Most of those distributions (including the Normal) are part of the exponential family.

Exponential family based distribution of efficacy: taking in consideration newcomers and specialists

Points in that distribution are related to people. Over time, points (people) that move to the right increases the mean. People that move to the left decreases it. If a small group moves to the right, the mean might increase more than the deviation. If more people arrive in the market on the left side of the distribution, the mean might decrease and the deviation might decrease or increase.

A mathematic comparison has to fix one variable, and the results of that comparison are related to that variable. Comparing different groups over time is neither a comparison of time nor groups. A fair comparison would be the same domain over time or different domains at the same point in time. Therefore, it is not possible to conclude that improving your skills increases the mean (domain analysis) or that the industry does not evolve because of the mean.

We could focus on the efficiency of a few individuals, boosting them and creating super specialists who produce amazing code in a short period of time – a “must have” in a big enterprise. This will improve just one individual’s efficiency, with very little effect in the market.

Ideas and technologies which only a specialist was able to benefit from, over time, are better understood and taught to the market: increasing the entire market efficiency.

If my students were able to increase their efficiency by 10% over the course of one year while I, as a teacher, increased mine by 20%, I would have achieved a much more valuable result for the industry (and mankind) than doubling my efficiency. Fortunately, I believe most of our students increase their efficiency by numbers much higher than 10%.

Either way, surely it is not true that “you can’t have the goal of advancing the whole of the industry. It isn’t going to happen.”. The industry is advancing, nowadays we develop software that 10 years ago was unthinkable of. Finding real teaching and learning practicing are the basis of efficiency improval. Teaching is not about exposing ideas. Coming from a family of teachers, there are methods that increase the efficiency of acquiring knowledge and a teacher must know how to use those.

One single person improving himself affects the entire industry in a minimal way, while teaching newcomers the wrong way affect the mean in a negative way.

Some will choose to improve their knowledge, slowly increasing the variance, others will choose to aid the industry, slowly increasing the average. Both are important for the industry. We have chosen to improve efficacy of the industry and, from the results we have been achieving, we shall not give up so soon.

VRaptor was an early adopter of Paul’s Paranamer and constructor DI, several years after its first public release, a typical controller is a simple:

@Resource
public class ClientsController {

  private final Clients clients;
  private final Result result;
  ClientsController(Clients clients,
                               Result result) {
     this.clients = clients;
     this.result = result;
  }

  @Post @Path("/clients")
  void add(Client client) {
    clients.save(client);
    result.redirectTo(ClientsController.class)
                  .show(client);
  }

  @Path("/clients/{example.id}")
  Client show(Client example) {
    return clients.find(example);
  }

}

VRaptor and Restfulie are refactor friendly: those who use Java must avoid “string based programming”, as shown in the redirection example, where renaming the show method, or changing its path will neither result in a failing test or failing feature.

VRaptor’s DI allows easy (real) unit testing as its coupling to its dependencies is minimized; and it is built on top of either Spring, Guice and PicoContainer.

Inheritance is only used to partially modify a component’s behavior and, if required, one own’s component can be provided with just one single annotation. Your models or controllers do not inherit dozens of methods that do not belong to your class domain, minimizing public method exposition.

Intercepting behavior is simple either on VRaptor (server) and Restfulie (client), through Interceptors and Request/ResponseFeatures. Creating components to be injected is also trivial such as the DAO from the Clients example:

@Component
class ClientDao implements Clients {
  // thats all
}

On the client side, Restfulie usage is straightforward and the default marshalling mechanism is provided through XStream:

String uri = "http://localhost:8000/clients/15";
Result r = Restfulie.at(uri).get();
System.out.println(r.getCode());

The at method has no side effect and is a domain entry point (instead of new). Navigating through hypermedia is also easy:

Result result = Restfulie.at(uri).get()
Client client = result.getResource();

result = resource(client).getLink("payments").get();

With such performance and code improvements,
VRaptor and Restfulie stay on track of not only solving problems, but following good design principles that try to minimize maintainance costs over time.

Yet there is one thing one can add to some of those systems that might make clients and services less bound to each other. Hypermedia. On my talk at QCon San Francisco 2010 I was able to show how the future of the systems integration over the web might look like.

Restfulie‘s first attempt to create a Ruby client for hypermedia services was in late 2009 with 100 lines of spaghetti ruby code. Eighteen months and lots of contributions later, Restfulie Ruby 1.0 is out: tackling both the server and client side on hypermedia based systems.

On the server side it is compatible both with Rails, Sinatra, while the its template engine can also be used anywhere else. On the client side, Restfulie provides an api that allows developers to bind their code to the media type and link relations, as expected with REST systems. Navigating a service is easy:

# entry points
response =Restfulie.at(order_uri).get
puts response.body

# unmarshalling
order = response.resource
puts order.price

# using hypermedia
response = order.link.payment.post(my_payment)

Restfulie has grown to support other media types such as open search:

description = Restfulie.at("http://myserver.com/opensearch.xml")
    .accepts('application/opensearchdescription+xml')
    .get.resource
items = description.use("application/xml")
    .search(:searchTerms => what, :startPage => 1)

We will be releasing the series Rest from Scratch again, using this latest release of Restfulie, wait for upcoming posts.

In the near future, Restfulie Ruby shall support forms and more. What are you waiting for to start decoupling those nasty client ideas of early 2000s? Or are you sticking to plain old coupling?

Its current API uses a fluent interface through Ruby hashes that allows easy output customization. This is the current version of simple_form that allows one to configure the building process of a form:

The video shows how one could add a domain specific language on top of its API and remove some of our api code without breaking compatibility. Using the implemented DSL:

The commit can be found here and you are welcome to enhance the DSL further.

If you have any suggestions for our next screencast, let us know at @guilhermecaelum and subscribe to our channel.

Bob posts a few questions that are important for the community to find better ways to solve problems. One of them is whether it is possible to find an ordered set of simple transformations that, applied in a series, favoring the ones at the top whenever possible, until all tests are passing, gives us the best algorithm?

An important point is that simple steps might give the best solution but do not guarantee it, as it envolves knowledge from the developer that he might not have prior to that.

It is better (or simpler) to change a constant into a variable than it is to add an if statement. So when making a test pass, you try to do so with transformations that are simpler (higher on the list) than those that are more complex.

Simple and better are not the same concept, so it might be simpler to change a constant into a variable but it might be better to add the if statement. In an, at least, amazing example, Bob shows us how one priority last is capable of giving the quicksort result to a sorting problem, while not using it might lead the developer to bubble sort (known to be worse, although one can argue that it is simpler to understand).

The priority list used for this example favors stateless code, code that does not change a variable pointer, as variable assignment is the lowest priority on the list. Another question posed is whether this priority list is “the best one”, and Bob mentions that it probably is not, eventhough it led to a great solution to the sample problem. In order to find a counter example for this priority list, one needs to pick an algorithm where maintaining state is important for a better solution which again, might, might not be the simplest. Calculating fibonacci(n) or other dynamic programming problems have this characteristic.

Taking Fibonnaci as an example and the following set of tests:

1. f(0) =1
2. f(1) =1
3. f(2) =2
4. f(3) =3
5. f(4) =5
6. f(5) =8

Following the sample priority list and implementing the constant rule (2nd rule), both tests f(0) and f(1) pass:

int f(int k) {
  return 1;
}

Adding an if (6th conditional rule) solves f(2):

int f(int k) {
  if(k<2) return 1;
  return 2;
}

Looking closely on the list priority list, one will find that adding an if is top priority than doing recursion so the solution would be the usage of the 6th rule again, thus the solution for all prior tests and f(3) is now:

int f(int k) {
  if(k<2) return 1;
  if(k==2) return 2;
  return 3;
}

Following the same priority list, it turns out that adding extra ifs is always a perferable step than recursion. As a single step, adding an if is simpler than recursion, but seen as a series of steps we are aware it is not, that’s why refactoring is important – allowing the change of the simple step decisions that were made in the past. In this example, finding the simplest solution is not the same as following the steps from that specific priority list. Still, we can rearrange the list and check if favoring recursion would give us the best solution:

int f(int k) {
  return k<2 ? 1 : f(k-1) + f(k-2);
}

Using the one where recursion had precedence over the ifs, one is able to end up with a simple solution to all tests – possibly the simplest solution ever. But recursion is known not to be the fastest solution for fibonacci. Following simple steps and solving our problem gave us a solution which is not the best one.

That only means that following the two lists do not guarantee the best (or the simplest) solution. Those two lists guided the developer through simple steps, which is positive thing, together with prior developer knowledge of the problem, its possible solutions and refactoring, one can improve the resulting code.

Creating an array (7th rule), during a loop (10th rule) and attributing different values to it than the default one (12th rule) would give the best (as in fastest – in the same way as the quicksort x bubblesort) solution. That means using a completely different list of priorities, a more dynamic one.

One could argue that assigning value to the array, overriding its default value, is not the use of the 12th rule (although it has already broken the priority list when following the 7th and 10th). In this case, other dynamic programming problem which envolves reassigning values to an array, such as the knapsack, would result in sub-optimal solutions, because the optimal solution involes reassigning values to variables (copying arrays would be suboptimal, again).

What’s more, when you pose a test, you try to pose one that allows simpler transformations rather than complex transformations; since the more complexity required by the test the larger the risk you take to get that test to pass.

Simple steps differ from simple and better solutions: the simplest step to take might not lead the code neither to the simplest nor the best solution, but they aid the developer to not take a huge step which might be hard to step back from. Together with refactoring, as described in Bob’s first paragraph, and problem solving knowledge, a priority list is a good tool to help avoiding some pitfalls, as shown on the bubble sort example.

The functions that takes the current code, the current set of tests, and a new test case, giving us the best, simplest and simple step change that solves the new set of tests always depend on the current code.

The impasse problem is somehow related to how TDD is done during DOJO sessions, where the steps are so small that they might not give you the direction to the best and simplest algorithm and when the developer realizes it, it is too late, all the code needs to be rewritten. This could have been avoided if the steps were not so small; instead of baby ones, children ones, or if the code was under constant refactoring. Test first, refactor all the time and priorizing simple steps over complex ones are important for good software quality and algorithm implementation, but they still rely on the developer knowledge. Someone who never implemented the knapsack problem might not come up with the solution in a reasonable timeframe, but the three practices (suggested in different parts of time by Bob Martin) will be there to aid the developer find his way.

The image below presents a situation where a new feature needs to be implemented because the software does not solve the current problem the company is facing:

a) red: represents all possible systems that do not solve the problem;
b) yellow: the current situation of our software;
c) green: possible solutions for both the previous solved problems and the current one.

Possible solutions for a problem

However, inside the possible solutions, there are those that are simple to be done. For example, writing an “if” or simply do a copy and paste some piece of code. This is a little step, a simple change, a baby step. The graphic below represents simple changes that solve the problem in dark green:

Simple changes

In addition, there are the simpler solutions for the problem. The simpler solution might be to extract a class or to make use of a library that does the logic. The diagram below represents the simpler solutions, in blue:

Simple solutions

It is possible to make some small changes, baby steps, that will put our system back in the track: inside the set of situations where a simple change solves the problem. But the simplest solution to our problem might be something completely different. It might not envolve the simplest change, it might even be on the different direction; doing small simple changes might lead us to a increasingly bigger technical debt. A typical 90′s example of that is the copy and paste solution, that will solve a lot of problems – and even professional developers stick to it in some situations – but will increase our debt over time, going in the wrong direction.

Even worse, the blind adoption of baby steps or simple changes with no practices to improve the quality of the design may take the code to a situation where it would be impossible to go back to a simple solution: your system becomes a big ball of mud. This is the worst situation: baby steps are not capable to keep things simple anymore, a typical situation where clients will say “we need to restart this project even before it was released”.

The pure use of baby steps do not assure quality. Too much simple steps may lead your system to negative situations.

In some situations, baby step may imply in one of the best solutions. But, to make it possible, the developer must have a deep knowledge in the technology, in the business domain, software design and programming language, which is not always true.

Baby step by a developer with strong knowledge in the technology, language, business domain and system.

As it is hard to make a smooth step-by-step and come to a simpler solution, developers require extra techniques, such as refactoring. Each simplification step through refactoring puts the code closer to the ideal system: the simplest thing that solve the set of required problems.

Refactoring that takes the code closer to the best solution.

With continuous refactoring, each step programmers take to implement a new feature keeps the code still close to simple solutions. Even more important than doing tiny steps (baby steps) is to walk in direction that takes to the better solution (and not only to the simplest change). In order to do that, programmers can not forget to refactor. And not only low-level refactoring (i.e. renaming variables, extracting methods, etc), but high-level refactoring (e.g. creating new abstractions).

The following piece of code is responsible for calculating the salary of a employee. It depends on the employee’s position on the company.

public class SalaryCalculator {

  public SalaryCalculator(FiscalRules fiscalRules, ...) {
    // ...
  }

  public double calculate(Employee f) {
    if(f.getPosition() == Position.SALESMAN) {
      // calculate salesman salary using fiscal rules, etc.
    }

    if(f.getPosition() == Position.MANAGER) {
      // calculate manager salary using fiscal rules, etc
    }
  }
}

Suppose that the company has a new position. The software should calculate the salary for this new employee as well. The simplest code that solve the problem would be:

public class SalaryCalculator {

  public SalaryCalculator(FiscalRules fiscalRules, ...) {
    // ...
  }

  public double calculate(Employee f) {
    if(f.getPosition() == Position.SALESMAN) {
      // calculate salesman salary using fiscal rules, etc.
    }

    if(f.getPosition() == Position.MANAGER) {
      // calculate manager salary using fiscal rules, etc
    }

    if(f.getPosition() == Position.MARKETING) {
      // calculate marketing salary using fiscal rules, etc
    }
  }
}

However, this is not the best solution. Moreover, the code gets more and more far from the best solution after any new “if” inserted in the code. Design gets more rigid. And worse: it makes the code harder to refactor: even the second “if” wasn’t the simplest solution.

When implementing a new feature, the programmer should check if the current design enables him to move his system to the next stage of simplest solutions, which might not be the simplest step. If the current design already provides an easy way to implement it, go ahead. Otherwise, the developer should refactor the design in order to make the implementation of this feature as easy as possible.

Steps do not need to be the smallest as possible. If the shortest step is a baby one, developers are free to do children steps when those will improve the software in question. Every design decision requires more and more knowledge out the developer, the small step and refactor techniques are one way to get good feedback to a software designer, allowing him to make good decisions, but still limited to his reachings.

In the example above, one solution would be to create an Strategy (GoF) to calculate the right salary for each position. And each position would be responsible to give the right algorithm:

public class SalaryCalculator {

  public SalaryCalculator(FiscalRules fiscalRules, ...) {
    // ...
  }

  public double calculate(Employee f) {
    SalaryAlgorithm calc = f.getPosition().getCalcAlgorithm(fiscalRules);
    return calc.calculate();
  }
}

It is hard to say if this is the best solution. Yet, it is much better than the ones before. Now, if the programmer needed to implement another salary algorithm, that would be much easier. Now, the programmer can go back to small steps, as the current implementation is on a safe place.

All this post may be summarized in one phrase that came up during a conversation between Guilherme Silveira and Mauricio Aniche:

The simplest change that allows you to solve a problem is not necessarily the simplest solution in the long run.

In this first video, we show how to enhance the amazing Cells gem by providing a simple DSL on top of it, leaving only your domain language. In Rails code, that is translated to “no appearances of the words render, partial or alike”. Testing first and trying to bring some of the domain language into the code.

This is a 6 minute video going through adding a new feature into the gem, it should be straight forward even for non ruby developers.

This implementation makes use of method_missing, which envolves dispatching the invocation twice. It should be no user perceived performance bottleneck in a typical scenario – we are using an interpreted language with IO through the network in two endpoints (to the browser and to the database). For those willing to contribute, the next improvements would be to only respond to method invocations that are really a cell.

Another one is to dinamically add the methods instead of using method_missing.

Send in any suggestions for the next episodes: open source suggestions with any of the following characteristics:

• code to be refactored
• great apis that can be improved with domain specifics
• legacy code without tests, waiting to be tested
• libraries with integration tests, with no unit ones
• libraries with unit tests, without integration ones

In parallel, through Respondie one is capable of extending and composing behavior on resource rendering. The following example shows a simple trait that renders an etag whenever the resource responds to etag:

Respondie is a Rails Responders extension that avoids mixins and thus allows us to avoid multiple inheritance hell (at least for the end programmer: a common problem is the diamond one) and compose your responder behavior by configuring it through composition:

In order to return to thread safe mode, some objects within the DSL were changed to become immutable although not all of them have already been moved.

Restfulie features can be composed in many different ways using an interceptor stack – much similar to servlet’s filter, a chain alike pattern. This means, client programmatic configuration as:

Opensearch support is now built in and as easy as:

Several other issues were closed in this new release and we can only wait for a new release with even nicer support to Tokamak templates and partial rendering: that will make our 1.0 ship. Again, this release of Restfulie is Rails3 compatible.

There is a sample application used during the workshop at QCon San Francisco that can be found at github.