Living in the programming world

Sou um Anti-Identação

O título desse post parece estranho, mas vamos lá. De fato, eu sou um anti-identação, não gosto de ver meu código identado.

Não estou dizendo que eu não idento meu código-longe disso. Apenas que eu prefiro evitar a identação sempre que for possível. Mas vamos por partes…

Primeira coisa, isso começou há algum tempo quando uma pessoa propôs o seguinte problema: montar uma lista encadeada (Linked List) com as seguintes regras:

1) A lista deve validar se ela está vazia, e lançar um erro caso tente-se retirar um item da lista vazia
2) Cada método pode ter, no máximo, uma linha
3) Não se pode usar “if” em momento algum

Claro que é uma bela loucura, mas depois que eu consegui resolver esse código, pensei: se eu consegui resolver um problema desses com apenas uma linha por método, será que meus códigos não tem coisa demais?

Aí, comecei a experimentar isso em código de produção. Isso meio que criou um estilo de codificar bem interessante, e vou tentar mostrar aqui com alguns exemplos:
(more…)

By Maurício Szabo, ago

Orientado a Objetos versus Funcional

Bom, esses dias estava estudando Scala. Uma linguagem multi-paradigma, mas que parece mais “funcional” do que “imperativa”. Scala cai numa posição ainda nebulosa para a maior parte das pessoas (e acho até que para o mercado também). Afinal, imutabilidade é “programação funcional”? Scala não faz nada que impede “side-effects” no código, como Haskell por exemplo, então ela é funcional mesmo?

Como mesmo eu não tenho muitos conhecimentos em linguagens funcionais, resolvi propor um problema para mim mesmo: implementar uma árvore binária em Ruby, e depois portá-la para Scala, tentar uma abordagem imutável em Scala, e depois portar para Haskell. O código está no github, mas algumas coisas vão ser discutidas aqui.

Primeiramente, a árvore imutável é feita recriando a árvore inteira. Claro, não podemos re-criar apenas um nó e apontar, digamos, a referencia de seu pai para esse novo nó, porque o pai é imutável (assim como qualquer outro aspecto do programa).

class Node[A <% Ordered[A]](value: A = None, left: Option[Node[A]] = None, right: Option[Node[A]] = None) {
    def insertNew(newValue: A): Node[A] = value match {
        case v if(newValue < v) => insertLeft(newValue)
        case _ => insertRight(newValue)
    }

<pre><code>private def insertLeft(newValue: A) = new Node(value, newChild(left, newValue), right)
private def insertRight(newValue: A) = new Node(value, left, newChild(right, newValue))
private def newChild(child: Option[Node[A]], newValue: A) = child match {
    case Some(child) =&amp;amp;gt; Some(child insertNew newValue)
    case None =&amp;amp;gt; Some(new Node(newValue))
}
</code></pre>

}

(more…)

By Maurício Szabo, ago

Testando Javascript no Rails

Continuando os estudos com Javascript e Ruby, esses dias tive um problema bem chato: existe uma gem (muito boa, por sinal) para Rails chamada “cells“, que basicamente cria uma camada, semelhante a “mini controllers” para coisas específicas em Rails (tipo “sidebar”, “carrinhos de compra”, “menus” e outras funcionalidades que são, basicamente, fragmentos de “views”, normalmente feitas com a combinação “partials+helpers” mas que ficam relativamente difíceis de testar). Junto com o Cells, foi criado o Apotomo, uma gem para criar “widgets”, e aí que está o problema: testar um widget. Claro, é possível testá-lo com integration test, mas “unit-tests”, quando envolvem Javascript+Rails, envolvem HTML Fixtures, linguagens de teste diferentes, enfim, nada produtivo.

Aí, entrou a gem Johnson. Basicamente, é um interpretador Javascript dentro de Ruby, de forma que seja possível rodar código JS dentro do Ruby (e o resultado vem como uma Ruby String, ou um Numeric, enfim). Já falei sobre isso quando estudei “The Ruby Racer” e os testes com V8 no Ruby, até me interessei pelo “env.js”, porém na época a versão que rodava com Johson estava muito ruim ainda (e infelizmente, ainda está)

Porém, o novo Env.JS (1.3) já roda no Johnson. E está muito melhor.
(more…)

By Maurício Szabo, ago

Em Patópolis, Programe como os Patos

Este é um post sobre “Duck Typing”, e finalmente eu escrevi ele (estava enrrolando para fazê-lo). Acho esse post bem importante porque eu percebi, com a experiência em Ruby, que poucas pessoas sabem lidar com o dinamismo da linguagem (e aproveitá-la ao máximo).

Então, vamos falar um pouco sobre Duck Typing. O básico, a maioria já sabe:

def imprimir(objeto)
  print objeto.falar
end

Ou seja, na declaração do método eu não defino nenhuma regra do que aquele objeto pode receber; apenas chamo os métodos que eu o objeto passado como parâmetro deveria implementar, e confio que vai dar certo. Parece simples, e até um pouco inseguro, então tem gente que prefere fazer umas checagens antes (tipo usando objeto.is_a?(Pessoa) ou objeto.respond_to?(:falar)), mas eu acho que isso quebra a idéia de Duck Typing. Para mim, tudo se resume a uma palavra: Protocolo.

(more…)

By Maurício Szabo, ago

Regras de Negócio e Rails

Bom, esse post é resultado de uma conversa que tivemos no Grupo de Usuários de Ruby de SP. Mas, antes de entrar no que interessa, vamos divagar um pouco sobre “Model” e “Rails”.

Muitos programadores Rails sabem a regra “Controllers magros, Models gordos”. É interessante também saber um pouco sobre o porque dessa regra, mas antes disso, vamos discorrer sobre o que é o “Model” de Rails, comparando com o “Model” da maior parte dos frameworks Java (lembrando que eu não sou programador Java, se eu falar qualquer besteira, me corrijam).

Pegando por exemplo o Hibernate, normalmente há uma classe que mapeia um objeto para uma tabela, e outra classe que faz as buscas (chamada normalmente de Facade). Então, teríamos um diagrama como: JDBC -> Model -> Facade. Já no caso do Rails, o mapeador ActiveRecord já abstrai a parte de “ter que mapear um objeto para uma tabela”, e também já nos oferece formas de buscar esses registros. Resultado, que o “Model” do Rails é meio que uma junção de “Model” e “Facade” do Java, e isso sozinho. Parece então óbvio que regras de negócio vão para ele, não é? Senão, qual o uso de uma classe vazia?

Bom, minha abordagem não é bem essa. E para isso, eu uso o princípio das CRC Cards, da metodologia XP.
(more…)

By Maurício Szabo, ago

AgileBrazil 2011 – parte 3

Por fim, essa parte é sobre Fortaleza. É um post nada técnico, mas acho que vale a pena comentar.

Fortaleza, logo nos primeiros dias, mostrou a minha insanidade. Sinceramente. Escancarou a insanidade que é viver em São Paulo, nessa selva de pedra, completamente desumana. Para começar, logo no primeiro dia, o taxista conversando conosco (às 0h), e, do nada, vê que passou o hotel e resolve dar ré… numa avenida. E tudo bem, um outro carro passou por ele como se nada tivesse acontecido.

A população tem um olhar mais vivo por lá. Os passos são sadios, calmos, não apressados e ansiosos como em São Paulo. Aliás, as pessoas olham para você. Parece bobo, e de fato é, mas tente andar na Paulista e impressione-se em ver como as pessoas não fazem contato visual. Nem na Berrini, ou qualquer um desses “centros comerciais” de São Paulo.

Mercado, e as pessoas comentando: “o quê, você vai embora às sete?”. Detalhe, o mercado fecha oficialmente às sete mas, seis e meia, o pessoal já está arrumando as coisas, afinal o mercado fecha às sete, não às oito ou “até o último cliente”.
(more…)

By Maurício Szabo, ago

AgileBrazil 2011 – parte 2

Essa parte é sobre minha palestra no AgileBrazil 2011. Sexta-feira, resolvi que apenas apresentaria minha palestra, depois iria curtir Fortaleza (sério, aquele lugar é muito bom!).

Enfim, minha palestra foi Mantendo a Qualidade dos Códigos de Teste, e nela resolvi arriscar duas coisas novas: primeira, em fazer uma palestra para pessoas de nível intermediário, para não ter que ficar explicando o que são mocks, stubs, etc. Segundo, que a palestra seria de duas horas, para dar tempo de falar tudo o que eu queria.

Claro, a segunda opção quase me deu um tiro no pé. Primeiro, porque para não soar irreal, eu resolvi que todo o código da palestra (que por sinal, está disponível no link acima. Recomendo que vocês baixem o link, a versão do slideshare esconde algumas coisas) ficaria disponível no Github, com exemplos reais (assim, qualquer pessoa poderia rodar os códigos e ver que é possível sim fazer testes daquela forma). Segundo, porque essas duas idéias me tomaram um tempo absurdo para escrever a palestra. Demorei MUITO para fazê-la, bem mais do que eu esperava. E terceiro, porque descobri que duas horas também não é muito tempo…
(more…)

By Maurício Szabo, ago

AgileBrazil 2011 – parte 1

Bom, pensei em como escrever um post sobre o AgileBrazil E Fortaleza ao mesmo tempo, mas não dá. Há muito o que contar sobre ambos, então vai um post de cada vez. O de hoje, falarei sobre o evento.

O AgileBrazil é uma convenção muito boa de métodos ágeis de desenvolvimento de software. Frequentei-o ano passado, e esse ano achei a organização muito melhor do que da outra vez (e o lugar também foi uma excelente escolha). Porém, senti uma queda no nível das palestras, embora eu não sei se foi por má escolha minha ou porque o nível estava mais baixo mesmo. Por sinal, todas as palestras estão disponíveis no site oficial do AgileBrazil, para quem quiser baixá-las (a minha estará em breve também).

No primeiro dia, quarta-feira, optei pela palestra Slicing and dicing your user stories. Achei fraquíssima, até porque a palestra mesmo foi muito abstrata: o assunto foi tão vago que eu senti que, se eu estivesse falando de maçãs ao invés de user-stories, o resultado final seria o mesmo. Faltou profundidade, tudo ficou muito superficial, e sendo bem sincero eu não entendi direito aonde eles queriam chegar.
(more…)

By Maurício Szabo, ago

Auditando Métodos em Ruby

Mais um da série “Coisas que você nunca quis fazer com Ruby, e tinha medo de perguntar”, embora o título não seja tão correto assim: bem ou mal, eu precisei fazer isso algumas vezes em um ou outro trabalho meu, mas enfim, vamos ao cenário:

Imagine que você está mexendo num código de alguém. O código está com acoplamento muito alto, e antes de refatorá-lo você precisa entendê-lo – e é aí que entra o problema. Ruby, como todos sabemos, não tem uma IDE muito boa, com um debugger muito bom, e para fazer esse processo seria legal se, por exemplo, eu pudesse rodar um comando e ele me retornasse: “Entrei no método X, Entrei no método Y, Saí do método Y”, etc.

Bom, o fato é que é bem simples de fazer isso com Ruby:

Para tal, basta “apenas” reabrir todas as classes que formos auditar, puxar todos os métodos que são implementados naquela classe, e re-escrevê-los de forma que seja informado que aquele método foi chamado. Como não há muito desafio em fazer tal coisa, apresentarei duas formas de fazê-lo.
(more…)

By Maurício Szabo, ago

A Maldita “Parte Teórica”

Uma das frases que eu mais odeio, quando converso com alguém muito estudioso mas com pouca prática, é a frase “mas você sabe que, por definição…”. Isso sempre me lembra o velho ditado “na prática, a teoria é outra” e o post de hoje é sobre isso: como eu odeio teoria não aplicada.

Isso é especialmente verdade em programação. Graças à frase “mas por definição, a equipe que testa tem que ser diferente de quem desenvolve” atrasa ou freia completamente Test-Driven Development, assim como várias outras “verdades” são seguidas, metodicamente, desde os primórdios da programação e as pessoas nem sequer sabem se é ainda válido.

Pegando, por exemplo, Design Patterns. Eu não sou contra a idéia geral dos design patterns, apenas questiono (e questiono MUITO mesmo) quando usá-los. É comum ver códigos que são relativamente simples que usam três ou quatro patterns diferentes, sem nenhum motivo aparente.
(more…)

By Maurício Szabo, ago