Pois bem. Após quase três anos de serviços prestados e vários projetos desenvolvidos ao longo desse tempo, chegou a hora de me despedir de meu principal cliente, a GSP, uma das maiores loteadoras do Brasil. Um abraço aos amigos que ficaram, e aos que já não estão mais lá. Foi um prazer!

A principal tecnologia com que eu trabalhei nesse período foi Java, com uma pitada de Python aqui e ali. Mas, como irremediável curioso que sou, não pude deixar de brincar com outras coisas também.

Agora, no entanto, é hora de pensar no futuro. Se você precisa de um profissional com o meu perfil, ou conhece alguma empresa que precise, entre em contato comigo ou passe o link deste post adiante. Busco trabalhar com empresas ou pessoas que:

1. Tenham projetos não convencionais;
2. Tratem a tecnologia com a devida atenção;
3. Contem com equipes multi-disciplinares, com gente que ama o que faz e que busca melhorar a todo instante.

Apesar de morar no interior de São Paulo, estou aberto a propostas de outras cidades, de preferência em tempo integral.

Valeu!

Infelizmente, por razões de força maior eu não pude comparecer na primeira edição do evento, mas este ano eu estarei presente, e ainda por cima como palestrante.

Por isso, antes de mais nada, eu gostaria de agradecer àqueles que votaram na minha palestra. Isso mostra que Clojure anda despertando o interesse da rapazeada também no Brasil, o que é muito bom.

Update: Apresentação e códigos-fonte disponíveis para download.

Sobre a palestra

Apresentar uma linguagem de programação numa palestra de 50 minutos é sempre uma tarefa complicada, especialmente se essa linguagem de programação traz consigo uma bagagem que vai muito além da sintaxe.

Quando eu assisto uma palestra sobre linguagens de programação, existem duas coisas que me irritam. A primeira é quando o palestrante soca um monte de código e se limita à sintaxe, explicando tudo vírgula por vírgula, sem nenhum contexto. A outra é quando o palestrante fala sobre uma linguagem mas não mostra nenhum exemplo.

Para não repetir esses erros, eu optei por um estilo diferente, onde a linguagem é abordada e explorada aos poucos, mas sempre seguindo uma linha para que haja um começo, um meio e um fim.

Meu objetivo não será ensinar ninguém a programar em Clojure, e sim mostrar alguns dos recursos que eu considero importantes. Assim, quem se interessar pode pesquisar mais por conta própria. Afinal, não somos todos auto-didatas?

Quem tiver dúvidas ao final da palestra, ou quiser apenas jogar conversa fora, é só me chamar pelo Twitter. Também não irei reclamar se alguém quiser pagar meu almoço.

O “pós-evento”

Ao final, a apresentação será disponibilizada para download no GitHub, juntamente com os muitos exemplos de código. Os slides virão acompanhados de notas que poderão ser lidas como uma espécie de artigo.

Deixarei os comentários deste post habilitados para quem quiser deixar dúvidas ou mensagens sobre a palestra.

É isso aí. Nos encontramos lá!

And with the World Cup comes the sweepstakes. Lots of.

Although the rules might change from one place to another, these are the ones we use the most here in Brazil:

1. Everyone try to predict the score of a particular match, paying a fixed amount for each guess (eg $1.00).
2. At the end, the ammount collected is divided equally among the winners. If there are no winners: (a) the sweepstake “accumulates”¹, or (b) everyone get their money back, or (c) you-crazy-rule-here.

I like this kind of sweepstake, but it could be better in some respects.

First, not everybody has the habit of carrying small bills around, so the sweepstakes manager (a.k.a. YOU) loses a lot of time chasing change. Besides, I think the fixed-valued bet is kind of boring since the amount collected is divided equally among the winners. I think things get more exciting when people can choose how much to pay for each guess, so the amount collected is divided proportionally among the winners. In this case, when several people win, earns more who bets more.

Since I don’t like to do the math myself, here’s the challenge: create a program that receives a list with all guesses and returns the list of winners along with the proportional amount to be paid to each one of them.

So, shall we?

Solving the problem… with Clojure

Write more code than necessary is going out of style these days, so I decided to code a solution in Clojure, a functional programming language that makes this sort of “problem” really easy to solve. Just launch the REPL and profit!

The first thing to do is define how to represent each guess:

(defstruct bet :name :amount :guess :rate)

All guesses has the same information. That’s why we defined a StructMap with the keys :name, :amount, :guess, and :rate.

A list of possible guesses might be:

(def pool
     [(struct bet "Daniel" 2.0 [2 0]) ;; Daniel bets $2.00 on score 2x0
      (struct bet "John"   4.0 [0 0]) ;; John bets $4.00 on score 0x0
      (struct bet "Maria"  1.0 [2 0]) ;; Maria bets $1.00 on score 2x0
     ])

Okay, we already know how each guess is represented. Now, how to find the sweepstake’s total amount? Simple, all we have to do is to sum the amount of all guesses:

(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
;; testing
(pool-amount pool)
=> 7.0

Great, but how much each guess represent in relation to the whole, that is, what’s the proportion of each guess? All we have to do is to divide the amount of each guess by the sweepstake’s total amount:

(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
;; testing
(map :rate (pool-rates pool))
=> (0.285 ..., 0.571 ..., 0.142 ...)
 
(reduce + (map :rate (pool-rates pool)))
=> 1.0

Note that, if everyone wins, the amount earned by John would be the double of the amount earned by Daniel, which would be the double of the amount earned by Maria. Justice, finally!

To finish the code, we just need a function that filters the winners and calculates how much to pay to each winner:

(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))
 
;; testing
(pool-winners pool [1 0]) ;; no winners
=> ()
 
(pool-winners pool [0 0]) ;; just one winner
=> ({:name "John", :amount 7.0, :guess [0 0], :rate 1.0})
 
(pool-winners pool [2 0]) ;; several winners
=> ({:name "Daniel", :amount 4.66 ..., :guess [2 0], :rate 0.66 ...}
    {:name "Maria", :amount 2.33 ..., :guess [2 0], :rate 0.33 ...})

A major advantage of this solution is that it allows you to bet on anything. Want to bet on the sex of a baby shortly after the good news (or bad news, whatever)?

(def pool [(struct bet "Daniel" 3.0 :male)
           (struct bet "John"   5.0 :female)
           (struct bet "Maria"  1.0 :female)])
 
(pool-winners pool :female)
=> ({:name "John", :amount 7.5, ...} {:name "Maria", :amount 1.5, ...})

There you go, a simple solution for a simple problem.

The code

Although it’s possible to solve this problem in Lisp/Clojure with a one-liner (the Reader works with data structures after all), I decided to write a code that is as readable as possible for those who are starting with Clojure:

(defstruct bet :name :amount :guess :rate)
 
(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))

Your turn

Do you program in Haskell? Python? Ruby? Brainfuck? How would you solve such problem in your favorite programming language?

Update (Nov 3, 2010). Common Lisp solution, using copy-* to avoid changes in state:

(defstruct bet name amount guess rate)
 
(defun pool-amount (pool)
  (reduce #'+ (mapcar #'bet-amount pool)))
 
(defun pool-rates (pool)
  (let ((sum (pool-amount pool)))
    (mapcar (lambda (bet)
              (let ((x (copy-bet bet)))
                (setf (bet-rate x) (/ (bet-amount x) sum))
                x)) pool)))
 
(defun pool-winners (pool result)
  (let ((sum (pool-amount pool))
        (winners (loop for bet in pool when (equal (bet-guess bet) result) collect bet)))
    (mapcar (lambda (winner)
              (let ((x (copy-bet winner)))
                (setf (bet-amount x) (* (bet-rate x) sum))
                x)) (pool-rates winners))))

E com a Copa do Mundo vem os bolões. Muitos bolões.

Todo mundo já sabe como funciona um bolão, embora a mecânica possa mudar de um lugar para outro:

1. Cada palpite tem um valor fixo (ex: R$2,00).
2. Cada um pode dar quantos palpites quiser.
3. No final, o montante arrecadado é dividido igualmente entre os vencedores. Se não houverem vencedores: (a) o bolão “acumula”¹, ou (b) todo mundo recebe seu dinheiro de volta, ou (c) sua-regra-maluca-aqui.

Esse tipo de bolão é interessante, mas ele podia ser melhor em alguns aspectos.

Primeiro, o organizador acaba perdendo muito tempo correndo atrás de troco, afinal não é todo mundo que anda com dinheiro trocado na carteira. Além disso, valor fixo de palpite é muito chato, pois o valor arrecadado é dividido por igual entre os ganhadores. O bolão fica muito mais interessante quando o valor do palpite é variável e o valor arrecadado é dividido proporcionalmente entre os ganhadores. Assim, no caso de vários ganhadores, ganha mais quem apostar mais.

O problema de se fazer bolões com palpite variável é ter que ficar calculando o valor proporcional a ser dado a cada ganhador. Portanto eis o desafio: criar um programa que receba uma lista com todos os palpites e retorne uma lista com os palpites vencedores juntamente com o valor proporcional a ser pago a cada ganhador.

E aí, topa?

Resolvendo o problema… em Clojure

Como escrever mais código do que necessário está saindo de moda, optei por codificar uma possível solução em Clojure. Por ser uma linguagem funcional, Clojure é excelente para esse tipo de tarefa. Basta iniciar o REPL e mãos à obra!

Primeiramente, devemos definir como um palpite deve ser representado:

(defstruct bet :name :amount :guess :rate)

Todos os palpites possuem o mesmo conjunto de informações, por isso definimos um StructMap com as chaves :name, :amount, :guess e :rate.

Abaixo, uma possível lista de palpites:

(def pool
     [(struct bet "Daniel"  2.0 [2 0]) ;; Daniel aposta R$2,00 no placar 2x0
      (struct bet "Antônio" 4.0 [0 0]) ;; Antônio aposta R$4,00 no placar 0x0
      (struct bet "Marcela" 1.0 [2 0]) ;; Marcela aposta R$1,00 no placar 2x0
     ])

Certo, já sabemos como os palpites são representados. Agora, como saber o montante total de uma lista de palpites (a.k.a. bolão)? Simples, basta calcular o somatório dos valores de todos os palpites:

(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
;; testando
(pool-amount pool)
=> 7.0

Beleza, mas quanto cada palpite representa em relação ao total arrecadado? Afinal, precisamos calcular o valor proporcional a ser pago a cada ganhador.

Sem problemas, basta dividir o valor de cada palpite pelo montante total:

(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
;; testando
(map :rate (pool-rates pool))
=> (0.285 ..., 0.571 ..., 0.142 ...)
 
(reduce + (map :rate (pool-rates pool)))
=> 1.0

Repare que, se todos os participantes ganhassem um bolão, o valor recebido pelo Antônio seria o dobro do valor recebido pelo Daniel, que seria o dobro do valor recebido pela Marcela. Justiça, finalmente!

Pronto, agora só falta uma função para filtrar os ganhadores da lista de participantes e calcular o valor proporcional a ser pago a cada um deles:

(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))
 
;; testando
(pool-winners pool [1 0]) ;; sem ganhadores
=> ()
 
(pool-winners pool [0 0]) ;; apenas um ganhador
=> ({:name "Antônio", :amount 7.0, :guess [0 0], :rate 1.0})
 
(pool-winners pool [2 0]) ;; vários ganhadores
=> ({:name "Daniel", :amount 4.66 ..., :guess [2 0], :rate 0.66 ...}
    {:name "Marcela", :amount 2.33 ..., :guess [2 0], :rate 0.33 ...})

Uma grande vantagem dessa solução é que ela permite que você aposte em qualquer coisa. Quer apostar no sexo de um bebê logo após a boa notícia (ou má notícia, sei lá)?

;; :male = masculino, :female = feminino
(def pool [(struct bet "Daniel"  3.0 :male)
           (struct bet "Antônio" 5.0 :female)
           (struct bet "Fran"    1.0 :female)])
 
(pool-winners pool :female) ;; testando
=> ({:name "Antônio", :amount 7.5, ...} {:name "Fran", :amount 1.5, ...})

Aí está, uma solução simples para um problema simples. Como deveria ser sempre.

Minha solução, na íntegra

Embora seja possível resolver isso com um one-liner em Lisp/Clojure (afinal o Reader não trabalha com linhas, mas com estruturas de dados), eu optei por escrever um código que fosse o mais legível possível para quem não conhece ou está aprendendo Clojure:

(defstruct bet :name :amount :guess :rate)
 
(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))

Levando adiante

Você programa em Haskell? Python? Ruby? Brainfuck? Qual seria a sua solução para este problema de extrema importância para o desenvolvimento da raça humana?

Atualização (03/11/2010). Solução em Common Lisp, usando copy-* para evitar mutabilidade:

(defstruct bet name amount guess rate)
 
(defun pool-amount (pool)
  (reduce #'+ (mapcar #'bet-amount pool)))
 
(defun pool-rates (pool)
  (let ((sum (pool-amount pool)))
    (mapcar (lambda (bet)
              (let ((x (copy-bet bet)))
                (setf (bet-rate x) (/ (bet-amount x) sum))
                x)) pool)))
 
(defun pool-winners (pool result)
  (let ((sum (pool-amount pool))
        (winners (loop for bet in pool when (equal (bet-guess bet) result) collect bet)))
    (mapcar (lambda (winner)
              (let ((x (copy-bet winner)))
                (setf (bet-amount x) (* (bet-rate x) sum))
                x)) (pool-rates winners))))

Ultimamente, tenho visto a forma como certos desenvolvedores escrevem seus JSPs, e o que me preocupou foi ver o quanto eles desconhecem a tecnologia. Não é raro achar páginas cheias de scriptlets, includes malucos, código du-tri-quadri-plicado e nenhuma taglib além da fornecida pelo framework web em uso.

É muito fácil escrever JSPs da forma errada, mas fazer as coisas de um jeito melhor é mais fácil ainda. Ao contrário do que muitos pensam, é possível sim criar JSPs limpos sem o uso de qualquer framework de layout (como Sitemesh) ou biblioteca (com exceção da JSTL, é claro).

Um exemplo

O primeiro passo é definir o template base para as páginas da aplicação. Considere o seguinte exemplo de XHTML e sua representação gráfica:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
        <meta name="keywords"    content="keyword1, keyword2, keyword3" />
        <meta name="description" content="Page description" />
        <title>Page title</title>
 
        <!-- Essential scripts -->
        <link rel="stylesheet" type="text/css" href="css/style.css"/>
        <script type="text/javascript" src="js/query.js"></script>
 
        <!-- Extra header -->
        <script type="text/javascript" src="js/util.js"></script>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <div id="header"></div>
            <div id="content"></div>
            <div id="footer"></div>
        </div> <!-- Main -->
 
        <script type="text/javascript">
            // Other scripts (e.g. Google Analytics)
        </script>
    </body>
</html>

Representação gráfica do layout

O que costuma acontecer, mesmo em um layout simples como esse, é o alto índice de duplicação de código entre as diferentes páginas, principalmente em função do uso de Copy and Paste Programming. Muitos desenvolvedores por aí escreveriam o seguinte JSP para representar o layout proposto:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
        <meta name="keywords"    content="keyword1, keyword2, keyword3" />
        <meta name="description" content="Page description" />
        <title>Page title</title>
 
        <!-- Essential scripts -->
        <jsp:include page="scripts.jsp"/>
 
        <!-- Extra header -->
        <script type="text/javascript" src="js/util.js"></script>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <jsp:include file="header.jsp"/>
            <div id="content">Page content here</div>
            <jsp:include page="footer.jsp"/>
        </div> <!-- Main -->
 
        <script type="text/javascript">
            // Other scripts
        </script>
    </body>
</html>

Viu o problema? De nada adianta separar os pedaços com e continuar duplicando código. O ideal seria traduzir o layout em algo assim:

<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
<layout:page title="Title" description="Page description" keywords="keyword1, keyword2, keyword3">
    <jsp:attribute name="extraHeader">
        <script type="text/javascript" src="js/util.js"></script>
    </jsp:attribute>
    <jsp:attribute name="extraBottom">
        // Other scripts (e.g. Google Analytics)
    </jsp:attribute>
    <jsp:body>
        Page content here
    </jsp:body>
</layout:page>

A boa notícia é que isso é possível, através de tag files.

Reúso de conteúdo com tag files

Existem pelo menos três formas de se criar custom tags em JSP, cada qual com seu propósito: classic tag handlers, simple tag handlers e tag files. Neste post tratarei somente das tag files, mas saber como e quando utilizar simple tag handlers também é extremamente recomendado a todos que usam JSP no dia-a-dia.

A primeira coisa a fazer é criar o diretório WEB-INF/tags/layout. É nesse diretório que as tag files referentes ao template devem ficar. Agora, crie dois arquivos neste diretório, um para o cabeçalho e outro para o rodapé:

header.tag

<%@ tag body-content="empty" description="Header tag file" %>
<div id="header">
    <!-- Header section here -->
</div>

footer.tag

<%@ tag body-content="empty" description="Footer tag file" %>
<div id="footer">
    <!-- Footer section here -->
</div>

Como podemos ver, as tag files são como JSPs, mas com algumas propriedades especiais.

A última tag file, page.tag, define o esqueleto das páginas da aplicação:

<%@ tag description="Page layout" %>
 
<%@ attribute name="title"       required="true" description="Page title" %>
<%@ attribute name="keywords"    required="true" description="Page keywords to improve SEO" %>
<%@ attribute name="description" required="true" description="Page description" %>
 
<%@ attribute name="extraHeader" fragment="true" description="Extra code to put before </head>" %>
<%@ attribute name="extraBottom" fragment="true" description="Extra code to put before </body>" %>
 
<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
 
        <!-- Displaying the attributes using EL -->
        <meta name="keywords"    content="${keywords}" />
        <meta name="description" content="${description}" />
        <title>${title}</title>
 
        <!-- Essential scripts -->
        <link rel="stylesheet" type="text/css" href="css/style.css"/>
        <script type="text/javascript" src="js/query.js"></script>
 
        <!-- Process the given input fragment -->
        <jsp:invoke fragment="extraHeader"/>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <!-- Renders the page header -->
            <layout:header/>
 
            <!-- Renders the tag body inside a DIV -->
            <div id="content"><jsp:doBody/></div>
 
            <!-- Renders the page footer -->
            <layout:footer/>
        </div> <!-- Main -->
 
        <!-- Process the given input fragment -->
        <jsp:invoke fragment="extraBottom"/>
    </body>
</html>

Esta última tag file é mais complexa que as anteriores, pois recebe dados e blocos de código (através de fragments). Além disso, ela aceita um corpo, que é executado com <jsp:doBody/>.

O exemplo usado aqui é razoavelmente simples e, por isso, não precisamos apelar para outros recursos mais avançados como variables e dynamic attributes. De qualquer forma, procure conhecer bem a tecnologia, pois você nunca sabe quando um ou outro recurso lhe pode ser útil.

Exemplo de uso

Novamente, um exemplo de uso das tags que criamos:

<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<layout:page title="Index page" description="This is the index page of my amazing app" keywords="amazing, app">
    <jsp:attribute name="extraHeader">
        <script type="text/javascript" src="js/util.js"></script>
        <script type="text/javascript" src="js/some_jquery_plugin.js"></script>
    </jsp:attribute>
    <jsp:attribute name="extraBottom">
        $(function() {
            // Call some JQuery function here, specific for this page
        });
    </jsp:attribute>
    <jsp:body>
        Welcome to my amazing app!<br/>
        1+1 = ${1+1}
 
        <ul>
        <c:forEach items="${objects}" var="obj">
            <li>${obj.attr}</li>
        </c:forEach>
        </ul>
    </jsp:body>
</layout:page>

Embora a aplicação como um todo siga um mesmo padrão visual, cada página pode necessitar de recursos adicionais (JavaScript, CSS, etc). Isso não chega a ser um problema, pois nosso template contempla a inclusão de conteúdo extra, se necessário.

Outra vantagem é que as tag files permitem o uso de custom tags e unified EL, mas proíbem o uso de scriptlets, o que já é meio caminho andado rumo a um JSP mais limpo.

Leitura recomendada

• The Java EE 5 Tutorial;
• Head First Servlets & JSP;

This is a fairly common thing, at least for the companies I worked for so far, and that’s what scares me the most. Hopefully, you can easily make things better if you want to.

In this post, I’ll show you a few techniques that can be used to write clean JSPs without resorting to any kind of templating system whatsoever.

An example

The first step is to define the base template for the application pages. Consider the following XHTML example and its graphic representation:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
        <meta name="keywords" content="keyword1, keyword2, keyword3" />
        <meta name="description" content="Page description" />
        <title>Page title</title>
 
        <!-- Essential scripts -->
        <link rel="stylesheet" type="text/css" href="css/style.css"/>
        <script type="text/javascript" src="js/query.js"></script>
 
        <!-- Extra header -->
        <script type="text/javascript" src="js/util.js"></script>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <div id="header"></div>
            <div id="content"></div>
            <div id="footer"></div>
        </div> <!-- Main -->
 
        <script type="text/javascript">
            // Other scripts (e.g. Google Analytics)
        </script>
    </body>
</html>

Template graphic representation

What usually happens, even with a simple template such as this, is a high level of code duplication among the different pages due to the heavy use of Copy and Paste Programming:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
        <meta name="keywords"    content="keyword1, keyword2, keyword3" />
        <meta name="description" content="Page description" />
        <title>Page title</title>
 
        <!-- Essential scripts -->
        <jsp:include page="scripts.jsp"/>
 
        <!-- Extra header -->
        <script type="text/javascript" src="js/util.js"></script>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <jsp:include file="header.jsp"/>
            <div id="content">Page content here</div>
            <jsp:include page="footer.jsp"/>
        </div> <!-- Main -->
 
        <script type="text/javascript">
            // Other scripts
        </script>
    </body>
</html>

See? Why break the template into small pieces if you are going keep duplicating code anyway? The best thing to do is to translate that template into something like this:

<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
<layout:page title="Title" description="Page description" keywords="keyword1, keyword2, keyword3">
    <jsp:attribute name="extraHeader">
        <script type="text/javascript" src="js/util.js"></script>
    </jsp:attribute>
    <jsp:attribute name="extraBottom">
        // Other scripts (e.g. Google Analytics)
    </jsp:attribute>
    <jsp:body>
        Page content here
    </jsp:body>
</layout:page>

Content reuse with tag files

There are three types of JSP tags, each with its own strengths and weaknesses: classic tag handlers, simple tag handlers and tag files. Today I’ll cover the basics of tag files, but every Java developer should learn when and how to use the other two.

The first thing we need to do is create the WEB-INF/tags/layout directory, which will keep the tag files we are about to create. Now, create two files inside this directory, one for the header and the other for the footer:

header.tag

<%@ tag body-content="empty" description="Header tag file" %>
<div id="header">
    <!-- Header section here -->
</div>

footer.tag

<%@ tag body-content="empty" description="Footer tag file" %>
<div id="footer">
    <!-- Footer section here -->
</div>

As we can see, tag files are just like JSPs, but with some special properties.

The last tag file, page.tag, defines the overall page structure:

<%@ tag description="Page layout" %>
 
<%@ attribute name="title"       required="true" description="Page title" %>
<%@ attribute name="keywords"    required="true" description="Page keywords to improve SEO" %>
<%@ attribute name="description" required="true" description="Page description" %>
 
<%@ attribute name="extraHeader" fragment="true" description="Extra code to put before </head>" %>
<%@ attribute name="extraBottom" fragment="true" description="Extra code to put before </body>" %>
 
<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
 
        <!-- Displaying the attributes using EL -->
        <meta name="keywords"    content="${keywords}" />
        <meta name="description" content="${description}" />
        <title>${title}</title>
 
        <!-- Essential scripts -->
        <link rel="stylesheet" type="text/css" href="css/style.css"/>
        <script type="text/javascript" src="js/query.js"></script>
 
        <!-- Process the given input fragment -->
        <jsp:invoke fragment="extraHeader"/>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <!-- Renders the page header -->
            <layout:header/>
 
            <!-- Renders the tag body inside a DIV -->
            <div id="content"><jsp:doBody/></div>
 
            <!-- Renders the page footer -->
            <layout:footer/>
        </div> <!-- Main -->
 
        <!-- Process the given input fragment -->
        <jsp:invoke fragment="extraBottom"/>
    </body>
</html>

This last tag file is more complex than the other two, because you can pass to it both values and fragments. Besides, this tag accepts a body, which gets executed with <jsp:doBody/>.

Of course, the example shown here is fairly simple, so we didn’t have to use more advanced features like variables and dynamic attributes. Be that as it may, it’s a good idea to know what the technology has to offer. You’ll never know when a feature will be useful until you need it.

Usage

Now, let’s put those tag files to use:

<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<layout:page title="Index page" description="This is the index page of my amazing app" keywords="amazing, app">
    <jsp:attribute name="extraHeader">
        <script type="text/javascript" src="js/util.js"></script>
        <script type="text/javascript" src="js/some_jquery_plugin.js"></script>
    </jsp:attribute>
    <jsp:attribute name="extraBottom">
        $(function() {
            // Call some JQuery function here, specific for this page
        });
    </jsp:attribute>
    <jsp:body>
        Welcome to my amazing app!<br/>
        1+1 = ${1+1}
 
        <ul>
        <c:forEach items="${objects}" var="obj">
            <li>${obj.attr}</li>
        </c:forEach>
        </ul>
    </jsp:body>
</layout:page>

Although the application as a whole follow the same visual standard, each page may need additional resources (JavaScript, CSS, etc.). This is hardly a problem because our template allows us to include extra content if necessary.

The other advantage is that tag files allow the use of custom tags and unified EL, but deny the use of scriptlets, which is a good thing if you want to get rid of messy JSPs.

Recommended reading

• The Java EE 5 Tutorial;
• Head First Servlets & JSP;

Modelo-exemplo de banco de dados

Nem irei perder tempo explicando esse modelo, até porque não há nada nele que precise de explicações. Bem, na verdade, há uma coisa sim: por que raios existe uma tabela só para armazenar os tipos de contato?! Qual é o problema com os bons e velhos códigos fixos (1-email, 2-celular, N-…)?

Um argumento a favor dessa abordagem é que “o usuário pode querer cadastrar um contato cujo tipo não seja suportado pela aplicação”. Mas será mesmo que colocar essa informação no banco de dados resolve o problema? E, mais importante, existe algum efeito colateral?

Bem, na minha experiência, embora essa abordagem pareça boa o bastante para resolver a questão num sistema simples de “cadastro”, a bomba explode quando o sistema passa a depender dessas flags para a realização de lógicas de negócio que vão além do famigerado CRUD.

Anti-pattern?

E se eu te dissesse que usar tabelas no banco de dados para armazenar flags é um anti-pattern? Digo isso pois, como veremos a seguir, as vantagens são irrisórias frente às desvantagens:

Poluição do modelo de dados. Um sistema não muito grande provavelmente conta com mais de uma centena de tabelas. Isso todo mundo sabe. O que todo mundo também sabe, mas parece ignorar, é que não seria surpreendente constatar que 10-15% dessas tabelas serviriam apenas para armazenar flags (situação de pedido, estado civil, forma de pagamento, e por aí vai). E o pior: essas tabelas, quase sempre, possuem exatamente a mesma estrutura, que apelidei carinhosamente de tabelas código-descrição. A tabela TipoContato, mostrada no diagrama que encabeça este texto, é um exemplo desse tipo de tabela.

Ruim para o meio ambiente. Poluir o modelo de dados com dezenas de tabelas código-descrição torna o modelo desnecessariamente maior e mais difícil de compreender. Imprimir um modelo desses consome mais papel, o que é ruim numa época onde o desenvolvimento sustentável está em voga. Quantas árvores suas tabelas código-descrição já derrubaram?

Ultra-normalização. Quanto mais tabelas uma consulta envolver, mais joins, e mais dados indo e vindo para o banco de dados. E, considerando que o banco de dados é (quase) sempre o gargalo, isso não é muito bom para a performance do seu sistema.

Poluição do modelo de objetos. As linguagens com suporte à orientação a objetos figuram entre as mais usadas atualmente, por isso eu diria que muito provavelmente você utiliza esse paradigma no desenvolvimento dos seus sistemas. Se este for o caso, também é bem provável que você utilize algum framework ORM para facilitar a tarefa de integração do software com o banco de dados. Como muitos frameworks ORM exigem um modelo de objetos compatível com o modelo de dados, bem, você acaba sendo forçado a poluir seu modelo de objetos com classes burras que apelidei carinhosamente de (pasmem!) classes código-descrição.

Se tem tabela, tem cadastro. Bom, já que todas as flags possuem suas tabelinhas no banco de dados, isso significa que você, pobre desenvolvedor, terá que fazer “cadastros” para todas elas (e reze para não precisar fazer relatórios, também). Além da chatisse costumeira de se fazer um cadastro, devemos levar em consideração que fazê-los consome tempo e, tempo é dinheiro.

Código quebradiço. Essa é feia. Vamos supor que, nessa nossa aplicação de gerenciamento de clientes/contatos, você queira incluir uma funcionalidade que permita enviar um torpedo ao cliente caso ele possua um contato do tipo Celular. Como mostrado no trecho de código a seguir, você fatalmente terá que incluir no código-fonte referências a registros armazenados no banco de dados, tornando o código quebradiço. Consequentemente, um único UPDATE ou DELETE executado por engano no banco de dados pode fazer o sistema cair de joelhos.

Enviando torpedos a um cliente:

public void enviarTorpedo(Cliente cliente, String texto) {
    // Tenta localizar um contato do tipo celular
    for (Contato contato : cliente.getContatos()) {
         // WTF!! Estamos referenciando um registro do banco de dados!!
         if (contato.getCodigo() == 10L) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

A solução

Com certeza existem outros problemas que eu acabei deixando passar, mas espero que os problemas que listei já sejam o suficiente para te convencer que guardar flags em tabelas no banco de dados é uma má idéia.

Mas, como resolver isso então? Simples: use enums sempre que possível. A única desvantagem é que os usuários não poderão mais sair criando novas flags a torto e a direito, o que não é realmente um problema frente às vantagens que as enums oferecem.

Poluição do modelo de dados? As flags virariam campos numéricos ou alfanuméricos nas tabelas que as usam e o framework ORM se encarregaria de converter esses campos de/para objetos enum. Diga adeus às tabelas código-descrição.

Ruim para o meio-ambiente? Sem as tabelas código-descrição, seu modelo fica menor, mais enxuto, facilitando a visualização e gastando menos papel ao imprimí-lo. A natureza agradece.

Ultra-normalização? Usando enums você diminui a quantidade de ligações entre as tabelas, tornando as entidades um pouco mais auto-contidas. Menos tabelas, menos joins, mais performance.

Poluição do modelo de objetos? As enums tomariam o lugar das classes código-descrição, o que por si só tornaria o código mais claro, pois, ao contrário das classes “normais”, as enums possuem um propósito bem definido.

Se tem tabela, tem cadastro? Ué, por que você está com esse sorriso estampado no rosto?

Código quebradiço? Quem mais se beneficia das enums são os trechos de código onde as lógicas de negócio são definidas. Mais especificamente, seu código deixa de referenciar registros do banco de dados, eliminando a fragilidade e melhorando a legibilidade. As enums também impedem que valores arbitrários sejam usados em atribuições e comparações, tornando o código ainda mais confiável. Um exemplo disso pode ser visto no código a seguir, que é uma adaptação da atrocidade do código mostrado anteriormente:

public void enviarTorpedo(Cliente cliente, String texto) {
    for (Contato contato : cliente.getContatos()) {
         // Bem melhor agora!
         if (contato.getTipo() == TipoContato.CELULAR) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

O fato de a sua linguagem do coração não ter suporte nativo a enums não deve ser um impedimento para que você deixe de usufruir de suas vantagens. Existem formas de se conseguir uma funcionalidade semelhante sem muito esforço.

Conclusão

Desenvolver software é, antes de tudo, fazer escolhas. É o custo/benefício, os prós e contras antes de se tomar uma decisão. A boa notícia é que o nosso produto, o software, é maleável o suficiente para permitir que decisões ruins sejam re-feitas sempre que elas resultam em problemas como o descrito neste texto.

Bom carnaval!

Essa automatização por si só já quebra uma árvore, mas ela possibilita ainda o uso de Integração Contínua, uma prática extremamente importante que costuma ajudar muitas equipes a manter seus projetos nos trilhos. Para mais informações sobre Integração Contínua, eu recomendo a leitura deste artigo, até porque este post terá um enfoque mais prático.

Neste texto será mostrado como configurar um projeto Python no Hudson, um servidor de Integração Contínua muito simples de configurar e utilizar. O sistema de controle de versões que eu utilizo aqui é o Git, mas usuários de outros sistemas também poderão achar este texto útil.

Baixando o Hudson

Acesse o site do Hudson e baixe o arquivo .war através do link disponível na página principal. Quando o download terminar, basta rodar o comando abaixo para subir o servidor na porta 8080:

java -jar hudson.war

Tela inicial do Hudson

Perca uns cinco minutos dando uma navegada no Hudson para ter uma idéia melhor do que é possível de ser feito com ele.

Hudson e plugins

O Hudson vem com suporte a Maven e Ant, duas das mais populares ferramentas para build de aplicações Java. Mas não se engane: o Hudson pode ser aproveitado em praticamente qualquer projeto, independente da linguagem e dos frameworks utilizados.

As funcionalidades do Hudson podem ser estendidas através de plugins, sendo que neste artigo utilizaremos dois deles: o Git Plugin, necessário para que o Hudson consiga trabalhar com repositórios Git, e o Violations, que consegue interpretar a saída de diferentes verificadores de código (dentre eles o pylint, um analisador de código Python!) e exibir informações a respeito da qualidade do código-fonte.

Para instalar esses plugins, basta acessar a tela de gerenciamento de plugins, marcar o Git Plugin e o Violations, e confirmar:

Instalando os plugins

Assim que a instalação terminar, reinicie o Hudson.

Integrando testes escritos com PyUnit ao Hudson

Apesar de existirem várias opções para criação e execução de testes unitários para Python, o PyUnit costuma ser o mais usado pelo fato de já estar incluído na distribuição padrão do Python.

Quem já fuçou no código do PyUnit sabe que ele define apenas um TestRunner, o TextTestRunner. O que este TestRunner basicamente faz é gerar em um fluxo qualquer (geralmente no sys.stderr) uma saída parecida com a seguinte:

.....
----------------------------------------------------------------------
Ran 5 tests in 0.067s

Apesar de eu me contentar com essa saída mais simples, bom, ferramentas como o próprio Hudson não se contentam; elas preferem algo como o bom e velho XML, que, convenhamos, é muito mais fácil de parsear.

Perdi algumas horas na Internet procurando por um TestRunner que conseguisse gerar arquivos XML no mesmo formato que os gerados pelo Ant e Maven, mas não encontrei nenhuma opção que fosse minimamente confiável. Por isso, eu tomei a liberdade de escrever meu próprio TestRunner: XMLTestRunner. O código deste “projeto”, disponibilizado no Github, contém instruções de uso e scripts de exemplo. Clonem e forkem à vontade!

Antes de prosseguirmos, baixe o módulo xmlrunner.py do site do projeto e o copie em algum lugar dentro do seu PYTHONPATH.

Integrando um projeto Python no Hudson

Para não perdermos tempo criando do zero um projeto de exemplo em Python, eu mostrarei como fazer para integrar o próprio XMLTestRunner com o Hudson.

Abra o console administrativo do Hudson e clique no link New Job:

Criando um projeto "free-style"

Na próxima tela, precisamos configurar o Job com os dados necessários:

Configuração de projeto

Configuração de projeto

Isso é tudo! Confirme as alterações e clique no link Build now. Aguarde alguns segundos enquanto o projeto é baixado do repositório Git e testado:

Exemplos de builds feitos pelo Hudson

Relatório de execução de testes

Análise de código feita pelo pylint

Como disparar o build de forma automática?

Uma vez que o projeto tenha sido configurado corretamente, basta um clique do mouse para que o Hudson faça todo o trabalho sujo. O problema agora é lembrar de fazer o build sempre que alguém modificar código no repositório.

Felizmente, temos duas opções para nos livrar de mais essa tarefa manual: a primeira seria configurar, nas propriedades do Job, uma expressão Cron que indique de quanto em quanto tempo o build deve ser feito; a segunda alternativa é apenas disparar o build quando alguém modificar código no repositório.

Como acontece com outros sistemas de controle de revisão, o Git possui hooks que nos permite executar ações em determinados momentos. Esses hooks nada mais são do que scripts executáveis localizados no diretório .git/hooks.

Mas enfim, quando disparar o build? Se o repositório Git e o servidor Hudson não são capazes de se comunicar diretamente, talvez a única alternativa seja disparar o build periodicamente. Para isso, você deve configurar um ou mais Build Triggers, na tela de configuração do Job.

Entretanto, se você mantém o repositório Git e o servidor Hudson na mesma máquina, ou mesmo em máquinas diferentes mas capazes de se comunicar via rede, podemos considerar a utilização dos hooks como ferramenta de integração entre o repositório Git e o Hudson.

Agora a pergunta que não quer calar: como integrar o Git e o Hudson? Bem, isso ficará como exercício para o leitor.

Dicas:

• O Hudson disponibiliza uma API através da qual se pode agendar builds, alterar as configurações do Job, criar Jobs, entre outras coisas.
• Para conhecer os hooks oferecidos pelo Git, consulte a documentação.

Conclusão

Já faz algum tempo que eu venho utilizando o Hudson para integrar projetos Java, e esta ferramenta vem se mostrando muito útil no meu dia-a-dia. Só quem pratica Integração Contínua sabe o quanto é complicado não contar com a segurança que ela proporciona ao desenvolvimento.

O problema, no entanto, começou quando eu optei pelo Python em vez do Java em certos projetos. Obviamente, eu queria aproveitar o ambiente de Integração Contínua que eu já utilizava, o que foi bastante complicado já que o PyUnit, framework de testes que eu costumo utilizar, não oferece uma forma de gerar relatórios XML, da mesma forma que Ant e Maven fazem.

Depois de estudar o funcionamento interno do PyUnit, eu decidi implementar um TestRunner que fosse capaz de gerar arquivos XML no formato esperado pelo Hudson. Deu um bocado de trabalho, é verdade, mas pelo menos agora eu consigo utilizar os excelentes relatórios gerados pelo Hudson para acompanhar a execução dos meus testes PyUnit.

Como o Brasil é grande, seria burrice achar que eu fui o único a enfrentar esse tipo de dificuldade. Por esse motivo, eu resolvi escrever este texto e, quem sabe, ajudar àqueles que enfrentam um problema semelhante.

Seguem as regras do desafio nas palavras do próprio Rodrigo:

Escrever em qualquer linguagem de programação um programa que realize 100.000 sorteios de um numero entre 1 e 60 e mostre na tela os 6 mais freqüentes.

Ganha quem fizer o programa com o menor numero de linhas possíveis, lembrando que a linha considerada é a linha da unidade léxica da linguagem, portanto a seguinte linha em Java seria considerada duas: int i =0; sysout(i);

Como na época eu estava aprendendo Groovy, não podia deixar esta oportunidade passar. E, de fato, não deixei!

Veja, abaixo, uma solução para o “problema” proposto, usando a linguagem Groovy:

def hist = [:], v
100000.times{hist[v = 1 + Math.random() * 60 as int] = !hist[v] ? 1 : hist[v] + 1}
println hist.keySet().toList().sort{-hist[it]}[0..5].join(',')

Será que dá para reduzir ainda mais esse código?

Update: Resolvi tentar resolver o mesmo problema, só que agora usando Smalltalk:

| s |
s := ((OrderedCollection withAll: ((1 to: 100000) collect: [:each | 60 atRandom])) groupBy: [:each | each] having: [:each | true]) asSortedCollection: [:a :b | b size < a size].
1 to: 6 do: [:each | Transcript show: ((s at: each) at: 1); cr]

Habilitando o modo de debug

Existem duas maneiras de se habilitar o modo de debug no Glassfish: através do painel de administração ou durante a inicialização do domínio.

Para habilitar o modo de debug por padrão, através do painel de administração, basta marcar o campo Debug na tela JVM Settings e clicar em Save:

Habilitando o modo de Debug

Basta reiniciar o domínio para ver que o servidor abre a porta 9009, através da qual podemos conectar um debugger:

asadmin start-domain domain1

Eis um resumo da saída ecoada pelo Glassfish:

Starting Domain domain1, please wait.
Log redirected to .../server.log.
Redirecting output to .../server.log
Listening for transport dt_socket at address: 9009
Application server is listening at address 9009 for debugger to attach using transport dt_socket
...

A outra forma de se habilitar o modo de debug é fornecer o parâmetro --debug ao iniciar o domínio. Por exemplo:

asadmin start-domain --debug domain1

Conectando o debugger da IDE ao servidor

Agora, basta usar os recursos de debugging presentes na sua IDE Java para debugar o código. Por exemplo, se você usa o NetBeans 5.5, basta acessar o menu Run – Attach Debugger… e o configurar da seguinte forma:

Anexando o debugger do NetBeans

O procedimento é semelhante em outras IDEs Java.

Pronto! Feito isso, é só colocar os breakpoints e disparar a execução do código problemático.