On using Laravel with the repository pattern and Eloquent

Aug 11, 2014 in laravel, php | blog

Separation of concerns is a design principle, and states that each part of a software addresses a separate concern. Different patterns and abstractions can be used for that like MVC, DAOs and repositories.

Repositories help in the abstraction of the data layer. It provides an interface for retrieving data, independent of the implementation, acting like a collection of objects.

Fig1. - Repositories

In Nestor-QA I had implemented repositories using some Java code I had in my mind, without paying too much attention to the abstraction layers. Two weeks ago, while working on some complicated issue in Nestor I noticed that the repositories in Nestor had been implemented using the Eloquent classes.

Eloquent is a library used in Laravel for data abstraction. It provides access to databases like MySQL and SQLite, kind like DAOs (and sometimes like repositories too). However, for Nestor being a test management tool, we are trying to be platform and framework independent. Here’s the old repository code in action:

class DbProjectRepository implements ProjectRepository {

    public function all()
        return Project::where('project_statuses_id', '<>', 2)->get();

    // ...


As you can see, we were returning the result of the get() method from Eloquent. Another big mistake was using these objects in the views. In the end we were not only using data layer elements in the wrong place, but we also had many queries to render an UI.

abstract class DbBaseRepository extends BaseRepository {

    protected $model;

    public function __construct($model)
        $this->model = $model;

    public function all()
        return $this->model->all()->toArray();

    // ...

After searching for a while, I found a nice example of a class design for repositories, where the return type is always an array. In the views you will have the array and keys, and in case someday you decide moving to another framework, you can leave the views unchanged (hopefully :-). Neat, no?

Ahn ahn

Happy hacking

Continuation Passing Style

Jun 15, 2014 in jenkins, functional programming | blog

Continuation Passing Style

In Continuation Passing Style (CPS), the program is comprised of several continuations. The methods in CPS programming do not return a value, rather, they pass control (including the current context) to the next continuation.

Each continuation receives a context, which stores the state of the current chain of continuations at a given time, and can alter this context and call the next continuation. There can exist different types of continuations too, for handling exceptions, suspending the program, or simply calling other continuations.

In some functional programming languages CPS is supported and can be used in conjunction with tail-call optimization to try to control the call stack size.

Use cases of CPS in Java

Apache Commons contains a component in its sandbox, Apache Commons JavaFlow, that hasn’t been updated in a while, but that supports continuations in Java. It requires the code to be instrumented, and provides ways to restore the execution of the code.

The Jenkins Workflow Plug-in was presented during the Jenkins User Conference 2014 in Boston. The plug-in has several Maven modules, among is the cps Maven module. This maven module provides CPS to the plugin. If you take a look at the team page of the JavaFlow project, you will find it interesting that Kohsuke Kawaguchi (Jenkins creator) is listed there too :-)

From what I could tell, the Jenkins Workflow Plug-in utilizes CPS to break down the workflow execution in several continuations, that are persisted to the disk and can be resumed in case the job execution is interrupted.

There are several differences between the cps module and Apache Commons Javaflow - such that in the latter the running code needs to be instrumented. I haven’t investigated all of them yet, but it sounds very interesting! I’m waiting for one of those rainy weekends so that I can spend many hours reading the code of the two and taking notes.

Final thoughts

CPS is a very interesting concept, and while probably the enterprise Java developer is not going to use it for his every day corporate web application (though some FP programmers might be using it), it is an interesting technique that can probably be applied in some specific scenarios - as it was in the Jenkins Workflow Plug-in.

There are optimizations available for CPS 12 too, so I believe the workflow-plugin has space for more innovation, and lots of fun for hackers.

Happy hacking!

LabLua aceito no GSoC 2014

Feb 27, 2014 in lua | blog

O LabLua, laboratório de pesquisa da PUC-RIO, foi aceito no Google Summer of Code 2014. Isso quer dizer que estudantes podem se candidatar para trabalhar nas ideias propostas. Os alunos selecionados podem receber uma remuneração total de até USD 5.500 (aproximadamente R$ 12.900,00).

O LabLua é o único projeto Open Source brasileiro na lista de aprovados. Se você é estudante e tem interesse em programar em Lua esta é uma ótima oportunidade.


Increasing logging level in Tomcat to solve org.apache.catalina.core.StandardContext listenerStart error

Oct 25, 2013 in tomcat, java | blog

Sometimes during the deployment of new applications in Tomcat you may see errors like ‘org.apache.catalina.core.StandardContext listenerStart’ in your startup log.

This may be caused due to many reasons (missing classes, including javax.servlet.* jars with your application, etc), but the reason is not displayed in the startup log.

But you can find out what is causing this error by adding to your $TOMCAT_HOME/conf directory, with the following content:

org.apache.catalina.core.ContainerBase.[Catalina].level = DEBUG
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler

After that you should be able to see the whole exception and figure out what is causing your application to fail.

Happy hacking!

Evento SPIN SP - 64ª reunião - Tema central Application Lifecycle Management

Oct 23, 2013 in events, news | blog

Acontece amanhã (24), no campus Butantã da Universidade São Judas, a 64ª reunião do SPIN de São Paulo, com o tema principal sendo Application Lifecycle Management (Gerenciamento do ciclo de vida de aplicações). Do site do evento:

Gerenciamento de Ciclo de Vida de Aplicativos (ALM) é a integração entre Gerência de Negócios com Engenharia de Software, que se tornou viável graças a ferramentas que facilitam e integram processos como análise de requisitos, modelagem de arquitetura, desenvolvimento de código, gerenciamento de mudanças, gerenciamento de testes e gerenciamento de versões de produtos realizados. Cada um destes processos faz parte de uma etapa de um ciclo de vida de um software.

O evento começa após o almoço e vai até as 18:00. Fomos no último encontro da SPIN-SP, onde o tópico era Integração Contínua, e todas as palestras que vimos foram ótimas. Confira o nosso relatório do evento passado.

Se você estiver em São Paulo compareça! Vamos estar por lá, e vamos deixar alguns adesivos do Jenkins e já promover o Jenkins Meetup São Paulo.