Living in the programming world

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

Minha Saída de um Cargo Público

Bom, para os que não sabem, eu deixei um cargo público, estatutário, numa universidade federal. Na verdade, pedi um afastamento, mas gostaria de não voltar para lá e conseguir guiar minha vida de outras formas. O motivo é muito parecido com outros que já vi, mas acho legal contar um pouco da história também.

Quando se usa o termo “a máquina do governo”, acredito sinceramente que o termo é bem apropriado. Quando se fala a palavra “máquina”, eu pelo menos imagino aquelas máquinas antigas, totalmente mecânicas, que fazem um barulho absurdo e soltam fumaça e cheiros enquanto funcionam. O engraçado dessas máquinas antigas é que, mesmo com essas características peculiares, digamos assim, elas funcionam. Claro, comparando com modelos mais modernos, elas são BEM piores, são mais lentas, tem BEM menos recursos, mas com essas máquinas antigas, mesmo acumulando um pouco de ferrugem aqui, ou arrebentando uma correia ali, elas continuam funcionando como se nada tivesse acontecido. Detalhe que essas máquinas antigas gastam mais de energia, combustível, etc, e isso também é uma metáfora apropriada…

Assim é o governo. Pior ainda, há uma completa resistência em adotar coisas mais modernas, em mudar algo que funciona mal, mas que está em produção há anos, ou de arriscar algo novo: desde linguagens até frameworks diferentes.

E isso não é a pior parte.
(more…)

By Maurício Szabo, ago

Bytecodes, e JIT

Resolvi escrever este post por muitos motivos, mas o principal deles é porque vi muitos amigos e colegas meus sem saber, direito, o que é um bytecode. Muitos acham que apenas linguagens como Python (com seus arquivos .pyc) e Java (com seus arquivos .class) possuem bytecodes, justamente porque ao “compilar” o programa, um novo arquivo é criado.

Nada poderia estar tão longe da verdade.

Bytecode é um conjunto de instruções, em forma binária ou seja, em uma forma não legível por humanos, que instrui uma máquina virtual a fazer determinadas ações. Bytecode não é apenas um arquivo, ou um código intermediário entre o executável nativo e a linguagem, e na maioria das vezes nem sequer é um código otimizado, com algumas raras exceções (scala 2.8, por exemplo, pode otimizar “tail call” em recursões). É importante entender essa parte, porque nem sempre um bytecode é gravado em um arquivo, e em algumas vezes sequer é um formato simples.
(more…)

By Maurício Szabo, ago