programação radical

Um ambiente para praticar orientação a objetos (ou ActiveRecord sem Rails)

2011-02-14T01:03:00.004-02:00

Estava pensando em um modo de fazer alunos praticarem orientação a objetos em projetos não triviais (e nestes, necessariamente haverá persistência) mas sem acabar perdendo o foco por causa de parafernálias de frameworks e ORMs. Como venho utilizando Ruby on Rails em projetos reais há algum tempo, pensei em juntar as duas coisas. Usar Rails em aulas de orientação a objetos, porém, seria excessivo e me faria desviar o foco e perder tempo explicando detalhes do framework (imagine o desastre que seria enfrentar dúvidas sobre roteamento ou view helpers em aulas de OO) e mais tempo ainda seria gasto com gems, setup, dependências nativas e outras coisas que não são de interesse direto de orientação a objetos.

O grande lance é que para o objetivo eu não preciso do Rails inteiro, mas apenas do ActiveRecord. Como reutilização é tudo, antes de meter a mão na massa fui ver se alguém já havia se coçado com isto e encontrei aqui um roteiro. No mesmo blog, suporte a migrations. Assim, foi possível montar rapidamente um nanoframework para implementar domain models em Ruby. Disponibilizei a brincadeira no Github, sob o nome de OORB (muito criativo, não?). Certamente há muito o que ser melhorado e, como era tudo basicamente configuração, não me incomodei em escrever testes. Já que o objetivo era preocupação zero com bancos de dados, o banco configurado é o SQLite3.

A idéia é fazer tudo ser muito simples e rápido. Não há qualquer pretensão de que isto seja uma plataforma para escrever código para software real, mas simplesmente um ambiente simples para a prática de orientação a objetos, para além dos exercícios bobinhos de apenas uma ou duas classes, com acesso a persistência e tudo o mais que um modelo OO real teria. O readme do projeto traz maiores detalhes de configuração e outras informações.

Pretendo começar a utilizá-lo já neste semestre, assim que tiver resultados posto aqui.

Meu ambiente de trabalho em 7 itens

2011-01-04T18:00:00.004-02:00

Lá vou eu participar do meme de descrever o ambiente de trabalho em 7 itens:

Sistema Operacional

Sou um felicíssimo usuário do Ubuntu 10.10, sistema operacional que será trocado em breve, mais precisamente em abril deste ano, pelo Ubuntu 11.04.

Editor

Eclipse Helios para Java. GEdit - devidamente tunado por gedit-plugins, gmate e Batraquio - para todo o resto. Por "todo o resto" entenda-se mais de 95% do meu tempo atual, com Ruby, Python, JavaScript, HTML, HAML, CSS, LaTeX, RST, markdown, plain text e o que mais vier. Este texto, por sinal, está sendo escrito no GEdit. Hoje mesmo foi levantada uma discussão acerca de debugging na lista de discussão do (glorioso) NSI. Bom, não há maneira mais, digamos, técnica de dizer isto, mas a verdade é que debugging simplesmente não me faz falta na imensa maioria das situações. Na minoria, coisas como o pdb do Python atendem muito bem. TDD e passos de bebê também são de grande ajuda para não se necessitar de IDEs superpoderosas.

Terminal

O terminal é onde passo boa parte do tempo, então ele precisa de duas coisas, ser eficiente e bonito. A eficiência do terminal é item de série (Linux rulz!) e a beleza é garantida por um fundo semitransparente, um esquema de cores esperto e a belíssima fonte Monaco (a única coisa que eu tinha inveja do Mac!).

Além disto, uso algumas conveniências no prompt, como: mostrar informações do Git caso o diretório corrente seja um repositório; mostrar a versão e a gemset do RVM sendo utilizadas correntemente, caso exista alguma; e o Python virtual do virtualenvwrapper sendo utilizado, também caso exista.

Browser

Firefox, Chrome, Opera para validar layouts, Seamonkey para a maioria do lixo que "só funciona no IE", Firefox (com Firebug e Web Developer) para todo o resto. Atualmente, eu não preciso validar layouts no IE, portanto não tenho configuração para isto.

Software

TweetDeck, Exaile, K3B, Gimp, Skype, Google Talk, VLC. Por sinal, procuro um bom cliente Twitter que não use Adobe Air, que não exija o Chrome e que não seja o Echofon. Sugestões?

Código-fonte

Git, óbvio. E Subversion para projetos que ainda o utilizam.

Música

Uso o Exaile como player, sempre com fone de ouvido, e - se eu não estiver sozinho - com um dos fones um pouco fora do ouvido para sacar o ambiente e ouvir as conversas. Normalmente escuto música brasileira (rock, indie, regional), metal (grindcore, death metal, crossover, hardcore) e coisas estranhas em geral (experimental, math metal, misturebas e por aí vai). Não ouço música, porém, o tempo inteiro. Ouvir ou não e, quando ouço, o tipo de música, dependem do tipo de trabalho, do meu grau de concentração no momento e do ambiente.

E você, fala um pouco do seu ambiente aí!

Rodando testes offline com Selenium e Firefox

2010-12-26T18:30:00.008-02:00

O Firefox tem um curioso "recurso" que consiste em colocar o browser em modo "offline" quando o computador se desconecta da rede. Isto se torna um pequeno estorvo quando, por exemplo, se está fora da rede e acessando uma aplicação web local e acaba sendo necessário desmarcar a opção "Work offline". Enfim, todo mundo que usa Firefox e desenvolve para a web já deve ter passado por isto. Até aí, nada demais. O "pequeno estorvo", porém, torna-se um problema real quando se utiliza Selenium com Firefox com o computador desconectado. Aparentemente, isto aqui resolve o problema, que também é possível de ser resolvido manualmente a partir da versão 3.6 do Firefox setando uma variável oculta no Firefox, mas acabaria caindo no antipadrão "works-on-my-machine", pois apenas o meu Firefox funcionaria offline, quando o correto seria que qualquer máquina que rodasse as specs do projeto pudesse fazê-lo sem atropelos.

Tive este problema inicialmente com o Capybara (Ruby) e uma boa alma já havia postado a solução, reproduzida abaixo, que utiliza a API do Capybara para definir a variável network.manage-offline-status, a tal "variável oculta" que citei no parágrafo anterior.


class Capybara::Driver::Selenium
  def self.driver
    unless @driver
      profile = Selenium::WebDriver::Firefox::Profile.new
      profile['network.manage-offline-status'] = false
      @driver = Selenium::WebDriver.for :firefox, :profile => profile
      at_exit do
        @driver.quit
      end
    end
    @driver
  end
end

Para aplicações Python, há até pouco tempo não tínhamos algo como o Capybara, até que outro grupo de boas almas, o Cobrateam, formado pelos ex-colegas de NSI Hugo Lopes e Gustavo Rezende e mais alguns membros da Globo.com, decidiram fazer algo semelhamnte para Python, o Splinter. Apesar de ser um projeto bastante recente, o Splinter já é um ótimo substituto para boa parte das tarefas do dia-a-dia de quem escreve testes de aceitação. Porém, o Splinter não possui uma API para acessar detalhes e/ou configurar o browser utilizado. Assim, consegui resolver o problema fazendo um hack no Selenium.


from selenium.firefox.firefox_profile import FirefoxProfile
prefs = FirefoxProfile._get_webdriver_prefs()
prefs['network.manage-offline-status'] = 'false'
@staticmethod
def prefs_func():
    return prefs
FirefoxProfile._get_webdriver_prefs = prefs_func

Por sinal, o Splinter é um projeto muito legal, vale a pena dar uma olhada e ajudar, nem que seja só falando bem dele no seu blog, como eu fiz aqui :P Give back to open-source!

Update (05/01/2011, 13h50m): Francisco Souza abriu um issue no Splinter para uma API que possibilite customizar o perfil do Firefox no Webdriver, evitando - do ponto de vista do cliente do Splinter - o tipo de acesso de baixo nível mostrado aqui.

"Agile" nunca mais

2010-12-11T01:27:00.006-02:00

Outro dia, em uma thread na lista de discussão do núcleo de pesquisa onde trabalho (a.k.a. glorioso NSI), debatíamos a respeito de uma palestra apresentada na Agile Conference 2009, chamada "Let's stop calling it 'agile'", em cujo resumo constava:

Agile development has grown a lot since its rebeleous 2001 start. In fact, it has grown to be the mainstream way of developing software. The time has come to drop the word 'agile.' Agile development is just modern practices in software development. There is no need to explicitly mark practices as Agile. There is no need anymore for opposing camps. Keeping the word Agile and things like ""the Agile conference"" is holding the development of modern SW development practices back.

Ou, em português:

O desenvolvimento ágil cresceu bastante desde seu início em 2001. De lá pra cá, se tornou o modo "mainstream" de desenvolver software. É chegada a hora de abandonar a palavra "ágil". Desenvolvimento ágil é tão-somente o uso de técnicas modernas no desenvolvimento de software. Não há necessidade de nomear explicitamente estas práticas como ágeis. Não há mais necessidade para campos opostos. Manter a palavra "ágil" e coisas como "a Conferência Ágil" é atrasar a evolução das práticas modernas de desenvolvimento de software.

Eu não fui primeiro no NSI a repercutir a conversa: o Rogério Atem já falou sobre o assunto em seu blog. Com este post, quero apenas apresentar a discussão e oferecer meus dois centavos ao assunto. De cara, concordo plenamente com a ideia de que o termo "ágil" tem feito mais mal do que bem hoje em dia. Principalmente por ser relativamente fácil passar um verniz ágil em um projeto ("olha, estamos fazendo Scrum, temos daily meetings, post-its no vidro da janela, e agora o analista de sistemas se chama scrum master, tem até certificado"). Uma vez que está na moda ser "ágil", o modelo se prolifera como erva daninha. Mas isto é assunto para outro post.

A discussão, inicialmente, era sobre o agilismo e a preponderância, na academia, de um estranho ente teórico-prático chamado "modelo tradicional". Minha opinião é de que a camada pensante do mundo tradicional é cada vez mais um grupo deslocado em um mundo que já não mais compreende. Imagino como estariam fora de lugar em qualquer bom evento de desenvolvimento de software envolvendo desenvolvedores militantes (i.e. que efetivamente desenvolvem software), como, por exemplo, o Dev In Rio.

Vou tentar explicar melhor como eu vejo essa questão. A idéia de deixar a palavra "agile" de lado é simplesmente continuar vivendo a vida e trabalhando como se os métodos tradicionais fossem o que realmente são: uma etapa ultrapassada - e, hoje, sem qualquer sentido - da evolução da engenharia de software.

Tenho tentado seguir isto hoje em dia e deixado discussões envolvendo "métodos tradicionais" apenas para contextos específicos como aulas de disciplinas universitárias de "Análise de Sistemas" (pois a própria estrutura das grades de cursos de graduação tem visivelmente inscrita a cascata). Ou então em discussões diretas com tradicionalistas. Fora destes contextos, procuro simplesmente sustentar que TDD/BDD é o modo considerado correto de se criar grande parte aplicações modernas, que integração contínua é condição necessária para a saúde de um projeto, que ubiquitous language é uma obrigação em qualquer projeto de software que queira ter sucesso, que código limpo é um requisito para qualquer programador digno do nome. Sem precisar citar que são técnicas "ágeis" ou qualquer coisa do tipo. E normalmente ignorando completamente o fato de que existe, ou existiu, alguma outra coisa. Tradicionalismo, só em história da engenharia de software, arqueologia, sei lá.

Para quem está em ambientes modernos de desenvolvimento de software, tudo isto é chover no molhado, é o óbvio. Porém, a academia está muito longe disto, e é no "método tradicional" - o que quer que isto seja - que os estudantes ainda estão sendo educados.

Assim, penso que o melhor a fazer é apresentar os conceitos tidos como "ágeis" simplesmente como o modo certo de fazer engenharia de software e não como técnicas alternativas ou coisa do tipo. E apresentar rapidamente o tradicionalismo (caso alguém o traga à discussão) simplesmente como um conjunto de ideias ligado a um contexto técnico que já passou (linguagens de baixo nível, computadores pouco poderosos, ambientes de desenvolvimento precários, extrema dificuldade ou impossibilidade de verificação automatizada, inexistência de controle de versão etc). Em nichos específicos, como por exemplo EIS, agile ainda é "alternativo". Mas no geral, não há mais porque continuarmos uma briga (pelo menos no campo simbólico) com um adversário que já morreu de velho. Tratar o tradicionalismo como um adversário é reconhecer-lhe um valor que já não tem mais.

Let's stop calling it "agile"!

Mais sobre TDD e coding dojo

2010-11-27T02:32:00.010-02:00

Um post sobre o uso de baby steps em dojos, escrito pelo Mauricio Aniche, tem causado discussão. Eu escrevi sobre baby steps há algum tempo e concordo em gênero, número e grau com o post, mas há um ponto que ainda não vi ser tocado na comunidade.

Eu tenho observado há alguns meses que algumas práticas do dojo andam meio que passando uma visão incorreta sobre TDD, e não é só por causa das cascatas de ifs. Nada melhor que exemplos para mostrar o que quero dizer. Em TDD/BDD/whatever no mundo real, ninguém vai escrever um teste:

it 'dois mais dois é igual a quatro' do
   ...
end

def test_quatro_nao_e_um_numero_feliz(self):
    ...

Nestes códigos, o nome do método é a expectativa. Em TDD, uma expectativa, é o resultado que se espera que ocorra na execução do teste, seja uma expectativa padrão como order.clear |should| change(order.item_count).by(-3) ou uma verificação de mock como MailService.should_receive(:send).with("sos@batcave.com").

O nome do método de teste (ou a sua descrição, no caso do RSpec) não é e nem pode ser a expectativa, pelo menos a se julgar pela literatura de TDD. O nome do método de teste é o nome de uma responsabilidade da classe (o "test method names should be sentences" que é tão enfatizado em BDD).

O correto seria:


it 'soma dois números' do
   ...
end


def test_identifica_numeros_infelizes(self):
    ...

Em todos os casos, o nome dos métodos é uma descrição abstrata - no sentido de não trazer exemplos concretos - e as expectativas com seus valores objetivamente verificáveis vêm no interior dos métodos de teste. Ou seja, em TDD, cada método de teste representa algo que a classe é capaz de fazer e não infinitas variações de valores passados a uma mesma funcionalidade. No fim das contas, a expectativa acaba sendo escrita duas vezes: uma vez no nome do método e outra na expectativa propriamente dita. A questão aqui não é o uso ou não de baby steps, mas uma formulação de testes que é conceitualmente diferente daquela utilizada na literatura de TDD.

Veja um exemplo, do livro "Growing Object-Oriented Software, Guided By Tests", de Steve Freeman e Nat Pryce (Addison-Wesley, 2009):


public class CatalogTest {
    private final Catalog catalog = new Catalog();

    @Test
    public void containsAnAddedEntry() {
        Entry entry = new Entry("fish", "chips");
        catalog.add(entry);
        assertTrue(catalog.contains(entry));
    }

    @Test
    public void indexesEntriesByName() {
        Entry entry = new Entry("fish", "chips");
        catalog.add(entry);
        assertEquals(entry, catalog.entryFor("fish"));
        assertNull(catalog.entryFor("missing name"));
    }
}

Neste código, os testes são:
- contains an added entry - indexes entries by name

Ou seja, são responsabilidades abstratas e não exemplos concretos.

Kent Beck, em seu cĺássico "Test-Driven Development By Example" (Addison-Wesley, 2003), vai na mesma linha: seus testes na classe Money que foi citada no post se chamam "multiplication", "equality", "currency". Ou seja, nada de "twoDollarsPlusThreeDollarsEqualFiveDollars".

Outra referência de TDD que gosto bastante, "Test Driven: TDD and Acceptance TDD for Java Developers", de Lasse Koskela (Manning, 2007), também segue a mesma ideia. Este livro, por sinal, tem disponiblizado o segundo capítulo para download, contendo um excelente exemplo de baby steps que vale mesmo a pena ser lido. Neste exemplo, novamente, os testes são "unknownVariablesAreIgnored", "multipleVariables" ou "missingValueRaisesException". Novamente, nada de expectativas nos nomes dos testes.

Certamente, não há "culpados" por isto, e também é provável que muitos não vejam assim tanto problema no que expus. Coding dojos são dinâmicos e não hierárquicos por definição, portanto evoluem e se alteram com o tempo e com o contato de diferentes pessoas. Assim, o "desvio" de TDD pode até não ser um problema em si, afinal o coding dojo é um jogo, mas temos que perceber que estamos praticando sob o nome de TDD uma coisa que não é exatamente TDD. E, na verdade, estamos praticando e aprendendo, uma vez que o coding dojo, pelo menos aqui no RJ, tem sido visto como ferramenta de aprendizado de programação. Quando o desenvolvedor está consciente que nos dojos é praticada uma variação do TDD, tudo bem. Porém, no caso de um iniciante, nós temos, sim, um problema, pois as pessoas vão aprender como TDD algo que poderia até mesmo ser considerado um antipattern.

Talvez pelos problemas utilizados em dojos serem bastante simples, muitas vezes com apenas uma feature, a única forma de ter mais de um método de teste acaba sendo a fatoração das classes de teste por expectativas e não por features. Na verdade, não sei nem se isto é um problema para todo mundo. Pessoalmente, é algo que não gosto e que me incomoda, me soa como se o código estivesse pulando e gritando "ei, eu estou errado, você não está vendo?". Mas é o meu ponto de vista. E aí, qual é o seu?

Como foi o PythOnCampus IFF 2010

2010-11-24T16:06:00.008-02:00

No dia 12/11/2010, realizou-se um PythOnCampus no IFF, em Campos dos Goytacazes/RJ. O evento, organizado por nós do Núcleo de Pesquisa em Sistemas de Informação (NSI) do Instituto Federal Fluminense (IFF), foi muito legal!

Apesar de ser uma sexta-feira véspera de feriadão, o evento contou com um bom público (e boa parte dele ficou lá até depois das 22 horas) e com minicursos bem legais e palestras de altíssimo nível. Pela manhã, três minicursos simultâneos começaram os trabalhos: "Utilizando OpenCV com Python", com Whanderley Souza (NSI), mostrou como a linguagem Python pode ser usada para trabalhar com visão computacional; em Coisas que até Guido duvida: Metaprogramação em Python, apresentei técnicas de metaprogramação usadas na construção do Should-DSL; e, como não poderíamos deixar de oferecer, Romulo Machado (NSI) apresentou Getting Started with Python, uma introdução à linguagem para já ambientar os novatos no que estaria por vir.

À tarde, enquanto rolava um coding dojo liderado pelo Tarsis Azevedo e contando com as presenças dos palestrantes da noite Henrique Bastos e Rodolpho Eckhardt, aconteciam mais dois minicursos: "Aquecendo os motores com MongoEngine", por Vanderson "Argentino" Mota (Myfreecomm), mostrou na prática o uso de MongoDB com Python; e Rodrigo Pereira (COPPE/UFRJ) apresentava programação orientada a aspectos com Java (sim, Java!). Este minicurso seria do Circuito de Tecnologia da Informação do IFF, que aconteceu na mesma semana, mas devido a problemas de agenda só pode ser ministrado na sexta, sendo acolhido pela PythOnCampus. Todos os minicursos contaram com um ótimo público, tanto em número quanto em participação!

Na parte da noite, Rogério Atem, El Jefe do NSI, apresentou o evento e deu início às palestras, que foram um show à parte. Fabricio Barros (Centro Universitário São Camilo - ES) apresentou sua pesquisa em computação soberana que gerou uma implementação em Python, mostrando que a linguagem pode ir bem além do convencional. Henrique Bastos (PythonRio) abriu a cabeça do pessoal sobre valores e práticas ágeis e mostrou que desenvolvimento de software pode e deve ser sustentável. Gustavo Rezende (Globo.com) mostrou como é o desenvolvimento de software em uma grande empresa, no caso a Globo.com; Rodolpho Eckhardt (Google) apresentou as novidades do Google App Engine para desenvolvedores Python; e Hugo Lopes Tavares (Globo.com) apresentou Behaviour-Driven Development (BDD) e mostrou uma pilha de ferramentas BDD em Python desenvolvidas no NSI. No final, o Rogério fechou o evento conclamando a academia a se abrir ao novo em desenvolvimento de software, no que foi referendado pelo Henrique, que, aliás, deu uma declaração sobre o NSI que nos orgulhou a todos! Valeu mesmo!

Depois do evento, claro, a galera do NSI (atuais e ex) e mais Henrique e Rodolpho partimos direto pro #horaextra. Sem falar que foi memorável reunir o pessoal todo: sabe lá quando vamos ter novamente um #horaextra com Hugo, Gustavo e Vanderson.

O evento foi muito, mas muito legal! Ao público presente nas palestras e nos minicursos, muito obrigado por ser o principal ingrediente no sucesso do evento! Quem não participou, perdeu! Mas fique esperto porque ano que vem tem mais.

Finalizando, gostaria de agradecer, em nome da organização do evento, a Henrique Bastos, Rodolpho Eckhardt, Fabrício Barros, Gustavo Rezende, Hugo Lopes e Vanderson Mota, que vieram a Campos só para o evento. Além disso, agradecer ao IFF pela estrutura e pelo suporte e ao pessoal do Circuito de Tecnologia da Informação (CITI) pela força e propaganda. Fora a galera do NSI que comprou a briga e participou da parada com vontade. Sem palavras para agradecer!

Semana Cheia

2010-11-07T06:38:00.004-02:00

Esta semana que se inicia neste domingo vai ser pequena pra tanto evento aqui na terra plana.

Explico: teremos, de terça a quinta (9 a 11/11), o 6º Circuito de Tecnologia da Informação do IFF (Instituto Federal Fluminense). O evento está dividido em minicursos pela manhã, workshops acadêmicos à tarde e palestras à noite. Eu vou ministrar um minicurso de Ruby on Rails de terça a quinta (dividido em Ruby, Rails e BDD) e vou participar de um debate agilismo x engenharia de software tradicional na terça-feira às 17 horas. As palestras prometem ser de altíssimo nível, confira a programação.

Na sexta-feira (12/11), temos a PythOnCampus IFF, evento que estou organizando junto com os colegas do NSI, um evento exclusivamente de Python, que ocorre periodicamente em diversos lugares. Neste vou ministrar um minicurso chamado "Coisas que até Guido duvida: Metaprogramação em Python". Para quem ficou boiando, "Guido" se refere a Guido Van Rossum, criador da linguagem Python. O nome, claro, é uma piada: não há nada que eu vá dizer que surpreenderia o sujeito que criou a linguagem, mas eu gostei do trocadilho e, afinal, marketing é tudo... :-P

O PythOnCampus terá minicursos de manhã e à tarde e palestras à noite, confira a programação. Se as tarefas da organização permitirem, pretendo assistir ao minicurso de MongoEngine e participar do coding dojo à tarde. Mas duvido que consiga...

Para completar, esta semana ainda tem Bienal do Livro aqui em Campos, mas sobre isto, se eu escrever algo, é assunto para meu outro blog.

Um diálogo sobre orientação a objetos

2010-11-03T06:27:00.007-02:00

Sempre que leciono Programação Orientada a Objetos, quando estou falando de encapsulamento, eu mostro uma pequena história para desmistificar a lenga-lenga de que "encapsulamento é ter atributos privados". Fiz, para publicar no blog, uma versão em forma de diálogo. Tentei minimizar o tom professoral, mas o texto não nega a origem. Segue.

- Aí cara, a galera criou um fork de orientação a objetos, e uma das coisas que ficou como exercício foi criar um programa orientado a objetos que calcule o fatorial de um número, mas sem utilizar estruturas de repetição. Essa é fácil, implementei rapidinho! Vê aí se ficou legal:

- Este programa calcula certinho o fatorial, mas não faz o que foi pedido, porque isso aí é tudo menos orientado a objetos.

- Mas como não? Eu utilizo uma classe e um método! Logo, estou programando orientado a objetos, não?

- Nada disso! O fato de utilizar abstrações e terminologia de OO como classes e métodos não torna automaticamente um programa orientado a objetos. É muito comum ver programas completamente procedurais escritos em linguagens orientadas a objetos. Logo de cara, pense comigo: há sentido em um objeto fatorial no contexto deste programa? Você criou um método chamado fatorial e uma classe Fatorial. Não tem uma coisa errada aí? Afinal, fatorial é uma classe ou um método?

- Bom, que fatorial é um método está claro. Agora eu já não estou mais tão seguro em relação a ser uma classe.

- Então, se fatorial é um método, é só pensar qual é o objeto que tem a responsabilidade de oferecer esse método. Objetos pilha tem métodos push e pop, que inserem e retiram um elemento de si mesma. Objetos conta bancária oferecem saques e depósitos em si próprios. Pensando assim, qual objeto deve oferecer o cálculo do fatorial?

- Ahhhhh!!! O número é que deve oferecer um fatorial! É tão óbvio! Então fica assim:

- Mas isso continua do mesmo jeito. Como você disse, procedural. Foi só uma mudança estética, certo?

- Mais ou menos. Nomes são importantes e nos ajudam a pensar mais claramente a respeito dos problemas. Pensa aí, como é que a gente pode melhorar mais isso aí? Se eu chamar um new Numero(), o que este meu objeto vai representar? Qual é o seu significado? Não tá faltando nada aí não?

- Ah, claro! Qual é o número do meu Numero... Um atributo!

- Certo! Manda ver então!

- Realmente, está ficando cada vez mais com cara de código OO. Mas ainda está estranho, pois eu posso fazer algo assim:

Numero numero = new Numero(3);
numero.fatorial(5);

- Não faz o menor sentido eu pedir a 3 para calcular o fatorial de 5.

- E o que isto significa?

- Já estou entendendo: o raio do método ainda é procedural, e ele é que está bagunçando a história toda...

- Esse método é procedural. Se ele fosse escrito em C, seria exatamente igual (tirando o public, claro!). Na programação procedural, rotinas processam dados. É exatamente isto que o nosso método fatorial faz. Na OO, a comunicação se dá por troca de mensagens, não por fluxos de dados. Ou seja: quando você pede a 3 para calcular um fatorial, deve ser o fatorial de quem?

- De 3, claro.

- Então...

- Rala peito, parâmetro!

- Agora ferrou! Como fazer a parada funcionar?

- Você ainda está pensando de modo procedural. Ali dentro do método, você quer o fatorial de quem?

- De valor - 1.

- Então por que você está pedindo o fatorial de valor novamente? Lembre-se que ali você está chamando fatorial sobre o próprio objeto, this. Se você quer o fatorial de valor - 1, não deveria chamar o fatorial sobre o objeto que representa valor - 1?

- Peraí, agora pegou aqui! Deixa eu pensar... Tá, tudo bem, eu entendi a sua ideia, mas não sei como implementar.

- Como é que você obtém um objeto Numero que seja valor - 1?

- Fazendo new Numero(valor - 1).

- Então está pronto!

- Ahhh claro!!! Lá vai!

- Depois que você vê pronto é muito, muito simples!! Agora sim!

- A gente pode parar por aqui se você quiser.

- Como assim se eu quiser. Tem mais?

- Imagine que eu estou usando seu código em uma aplicação, e começo a criar códigos como:

long resultado = numero.fatorial();

- Aí um belo dia eu faço o seguinte código:

Numero numero = new Numero(50);
long resultado = numero.fatorial();

- E o resultado que obtenho é obviamente errado: -3258495067890909184. Estourou o tamanho do tipo long.

- Poderia usar double?

- Até poderia, mas já começa a virar gambiarra, concorda? Fatorial, matematicamente, é uma função aplicada sobre um número natural, que retorna um número natural. Meter números reais na história não vai cheirar nada bem. De qualquer modo, a gente pode pensar com razoável grau de segurança que ninguém vai querer um fatorial de 50, e depois, se alguém pedir, a gente troca. Um dos preceitos da OO é o encapsulamento, sob o qual mudanças na implementação interna de uma classe não alteram o mundo exterior a ela. Como acreditamos que nosso programa está orientado a objetos direitinho... Acreditamos, certo?

- Sim, eu acho que agora está ok, o atributo privado, só o método público lá fazendo só o que deve fazer... Eu acho que está ok.

- Podemos liberar esta classe para produção então?

- Manda ver!!

- Agora imagine que você escreveu este código e todos os 200 desenvolvedores da empresa estão utilizando esta classe em 30 aplicações.

- Que responsa!

- Pois é! Aí chega uma demanda dos usuários de algumas das aplicações por fatoriais de números na casa dos 200.

- A gente pode usar, sei lá, BigInteger para representar o número.

- Você está confiando no encapsulamento da classe pra fazer isso? Tenta lá.

- Legal, só que isto vai quebrar TODAS as milhares de chamadas ao método fatorial (estamos imaginando aqui que fatorial é uma funcionalidade muito popular, ok?). Tudo bem, aqueles que querem fatoriais gigantescos nem vão reclamar tanto, mas e os que não têm nada a ver com isso? E ainda são obrigados a importar mais uma classe! E imagine que coisa fede ainda mais se criarmos um método getValor(). A solução seria criar um método Frankenstein, tipo bigFatorial e manter o fatorial normal? Manter duas classes diferentes? E cadê o desgraçado fidumaégua do encapsulamento que não te salvou? Era tudo mentira isso de "mudanças na implementação não alteram o mundo externo"?

- É aquele papo, de uma "mudancinha à toa" pro cliente ser um pesadelo de manutenção pros desenvolvedores.

- Isso! E muitas vezes (como no nosso caso atual) isto é fruto de mau design.

- E como resolver isso? Eu não tenho idéia.

- Na verdade há um problema conceitual na nossa classe. Ou, dizendo de outro modo, não está suficientemente OO.

- Como assim?

- Primeiro, há um vazamento no encapsulamento: o tipo de retorno de fatorial. Ele espelha exatamente a implementação interna, o modo como a classe Numero armazena o atributo valor. Se houver futuramente uma alternativa a BigInteger e quisermos eliminá-lo, estaremos escolhendo novamente entre quebrar os clientes ou fazer gambiarras de duplicar métodos. Ter simplesmente "atributos privados" não é o bastante. Linguagens como Python não têm suporte a membros privados e não deixam de ter encapsulamento por isto. Encapsulamento é um conceito, não uma palavra-chave como muita coisa que se lê por aí faz supor.

- Certo.

- Este vazamento de encapsulamento é causado pelo problema conceitual de que falei. Quando criamos uma classe, a única representação daquele conceito no nosso modelo passa a ser a classe. Nós criamos uma classe para números, mas representamos números de duas formas: objetos Numero e objetos BigInteger. Deveríamos usar apenas uma. Pense: o que um fatorial retorna?

- Um número.

- E o que é um número no mosso modelo?

- Entendi!! Um objeto Numero!

(começa a escrever o código)

- Mas se eu quiser realmente encapsular por completo o tipo utilizado eu vou ter que...

- Reescrever todos os operadores? Sim, não tem outro jeito neste caso.

- E então?

- A classe Numero agora é um número de pleno direito dentro do software. Agora qualquer coisa que ela faz retorna outro objeto Numero. Tudo está realmente encapsulado.

- Mas continua um problema, aquilo que você falou sobre ter duas representações. Internamente só vamos ter uma, mas o cliente da classe vai continuar vendo duas: o nosso objeto Numero e os números (int, long, etc) que a linguagem Java oferece. Além disso, ter que reescrever todos os operadores dá um trabalhão. Ali eu só reescrevi os que foram necessários, em um caso real todos os outros teriam que ser reescritos também.

- Bom, aí chegamos aos limites da linguagem Java em termos de orientação a objetos. Se você quiser, podemos parar por aqui.

- Como assim "se você quiser"? Eu não acredito que ainda tem mais!?

- Bom, podemos falar, por exemplo, de Ruby e colocar a orientação a objetos em um nível bem mais alto, tanto de simplicidade quanto de praticidade e poder. Partiu?

(mas isso fica pra outro dia, ainda que, provavelmente, não em outro diálogo...)

para o alto e avante!

2010-11-03T04:24:00.004-02:00

Como qualquer um que tenha estado aqui pelos últimos dois anos deve ter percebido, este blog esteve praticamente abandonado durante este período. A mim mesmo, a desculpa era sempre a mesma: eu estava esperando "o momento certo" para voltar a escrever no blog. Assim como na música de Humberto Gessinger, "esperei chegar a hora certa por acreditar que ela viria". E, por certo, ela não vem. Se formos esperar o momento no qual tudo estará calmo e tranquilo, céu azul de brigadeiro, para colocarmos nossos projetos em prática, nunca faremos coisa alguma. Assim, aqui estou eu reabrindo a casa. Por outro lado, se o presente escrito é só o manifesto de meia dúzia de posts e outros dois anos de silêncio, ninguém sabe. De qualquer modo, tudo vale a pena, já dizia outro poeta. Vamos?

1º NSI Tech Talks: um balanço

2010-05-24T23:55:00.002-03:00

Na tarde do dia 30/04/2010, ocorreu o 1º NSI Tech Talks, um evento mensal sobre tecnologia organizado pelo Núcleo de Pesquisa em Sistemas de Informação (NSI) do Instituto Federal Fluminense (IFF).

O evento foi pensado inicialmente como uma espécie de workshop interno (nossa equipe tem cerca de 30 pessoas distribuídas em diversos projetos), mas acabamos por decidir fazer um evento aberto. No núcleo temos desde pesquisadores doutores até alunos de curso técnico, todos abrangendo um leque bastante amplo de habilidades e conhecimentos.

A primeira edição foi organizada em pouco mais de uma semana e, por consequência, não foi tão divulgada como deveria, mas mesmo assim houve público em um bom número.

Na apresentação "OpenOffice: Dominando a Fera com Python", Gabriel Monnerat mostrou em detalhes como o Python é usado para realizar a automação do OpenOffice.org, com o projeto OOOD, criado pelo próprio em uma parceria do NSI com a empresa francesa NEXEDI, utilizado principalmente para conversão de documentos e como resolver questões de escalabilidade, concorrência e como contornar instabilidades do OpenOffice.

Na segunda apresentação do dia, "Collaborative Coding: Git+Github", Hugo Lopes Tavares explicou como funcionam os sistemas de controle de versão, mostrando as diferenças entre VCS centralizados e distribuídos e expôs o funcionamento do Git, um dos mais modernos e eficientes DVCS disponíveis, e mostrou como o Github pode tornar simples e eficiente o compartilhamento de código e o desenvolvimento colaborativo de software livre.

Para as próximas edições já estão agendadas palestras com temas como manipulação de vídeo com gstreamer e Python, lean thinking aplicado ao desenvolvimento de software, clean code e qualidade de código, heurísticas para extração de frames significativos em videos, análise de licenças para software livre, o framework web Grok, técnicas para criação de DSLs em Python e integração contínua.

Pretendíamos disponibilizar os vídeos das apresentações, mas muito infelizmente tivemos um problema com o som dos vídeos e até agora não conseguimos resolver. Caso haja alguma novidade em relação aos vídeos, posto aqui. Também infelizmente, confiamos demais nos vídeos e - adivinhe! - não tiramos fotos.

Enfim, o 1º NSI Tech Talks, a meu ver - mas sou suspeito para falar, claro! - foi, exceto em termos de registro, um sucesso e só tende a melhorar. É um evento muito interessante, de palestras com um nível técnico bem mais alto do que se costuma encontrar, e uma ótima fonte para quem se interessar em questões atuais sobre desenvolvimento de software.

O evento possui um site (sim, nós temos que melhorá-lo), onde serão divulgadas as novas edições.

A segunda edição já está marcada para a próxima segunda-feira, 31/05/2010, às 15 horas, no auditório Reginaldo Rangel, no Instituto Federal Fluminense (antigo Cefet) em Campos/RJ.

Agilismo em perigo?

2008-11-20T00:11:00.006-02:00

Há poucos dias James Shore, um dos grandes nomes do agilismo mundial (autor do ótimo The Art of Agile Development), escreveu um polêmico post em seu blog, chamado "The Decline and Fall of Agile" e suscitou um monte de polêmica. Eu concordo com o que ele escreveu em praticamente tudo.

Meses atrás, o Ivan Sanchez havia levantado, ainda que de modo menos incisivo, a mesma coisa em seu blog em português. Hoje, ele voltou a postar reivindicando o pioneirismo e reafirmando suas posições. Neste post há também links para a repercussão do artigo do Shore na blogosfera brasileira. Aliás, o post também traz a promessa de se manter atualizado quanto aos links para a repercussão, portanto fique de olho.

O Uncle Bob (Robert C. Martin) também se manifestou a respeito, discordando em certa medida das posições de Shore.

Pessoalmente, tendo a concordar com o Shore. A culpa não é do Scrum, certamente. Mas agilismo é como uma faca: é um excelente instrumento, mas não é bom que fique nas mãos de crianças nem de psicopatas. O problema é que Scrum, por ser fácil de compreender e ter forte apelo gerencial, tem sido vendido e comprado por crianças (sem avisar que elas deveriam crescer antes de utilizar) e psicopatas (sem um devido tratamento psiquiátrico). E aí não há boa vontade que impeça a faca ágil de fazer o que não deveria: mutilar o próprio usuário e qualquer um que esteja por perto.

leia isto >> Iterações pra que te quero

2008-10-03T10:48:00.005-03:00

_{Na seção "leia isto", linkarei bons textos e posts relacionados ao tema do blog.}

http://blog.thiagoarrais.com.br/2008/10/02/iteracoes-pra-que-te-quero/

Quando chegarmos a este ponto, será que deveríamos parar aí? A beleza deste processo de encolhimento das iterações é poder continuar diminuindo-as. Iterativamente, se você me permite. O limite será alcançado quando em uma iteração couber somente um requisito. Neste ponto, a única maneira de continuar encolhendo as iterações é encolher os próprios requisitos, tornando-os cada vez mais simples e atômicos.

Mas será que sua organização vai ter coragem para chegar lá?

Passos de bebê

2008-10-02T01:52:00.004-03:00

Na lista de discussão do núcleo de pesquisa de que faço parte, surgiu uma polêmica a respeito do uso da técnica de passos de bebê. Resumindo a história, alguém estranhou os passos minúsculos preconizados pela literatura de TDD. Por exemplo, em se tendo apenas o teste (em Java):

Template template = new Template("#{tecnica-agil} é legal!");
template.set("tecnica-agil", "TDD");
assertEquals("TDD é legal!", template.parse());

a implementação seria necessariamente

...
public String parse()
{
    return "TDD é legal!";
}
...

Bom, vamos à minha visão da coisa toda: a técnica de "passos de bebê" serve para evitar complexidade desnecessária, como generalização prematura e overengineering. O tamanho do passo - o que parece ser o centro da polêmica - deve ser baseado no bom senso e no quanto é confortável para o desenvolvedor. Se um desenvolvedor ou par se sente confortável em utilizar a técnica de modo mais ortodoxo, ótimo. Se não, é uma questão de ajuste fino. Eu, por exemplo, normalmente utilizo passos um pouco (mas não muito) maiores, exceto quando o domínio é pouco conhecido.

Os passos de bebê estão diretamente ligados a Test-Driven Development. Em TDD, a implementação deve ser unicamente aquela suficiente para passar nos testes, e nada mais. Deste modo, os passos de bebê não estão na implementação, mas na elaboração dos testes. Caso se queira que os passos sejam maiores, basta aumentar a granularidade dos testes unitários. Escrever um teste apenas para, por exemplo, uma entrada "N" e implementar uma solução genérica para o alfabeto inteiro é algo que contraria diretamente os princípios do agilismo (ou seja, da engenharia de software moderna), é implementar a solução para um problema ainda não formulado. Do ponto de vista da programação, os testes unitários são a especificação de requisitos. Assim, uma solução geral para o alfabeto inteiro com um teste só para "N" recairia em uma das duas situações: (1) ou há implementação desnecessária, ou seja, desperdício e complexidade inútil ou (2) o conjunto de testes é deficiente, o que mostra requisitos mal formulados e pode ter consequências ruins como bugs de regressão.

A questão é que a implementação tem que ser a coisa mais simples (sem ser simplória, já dizia Einstein) que possa passar nos testes (e uma cascata de if-elses é tosqueira, não simplicidade). Se você consegue ter uma função que passa nos testes com um mero return "n", o problema está em um conjunto fraco de testes. A implementação está correta, pois cumpre os requisitos (testes unitários) de modo claro, simples, rápido e manutenível.

Toda e qualquer prática ágil deve estar ancorada em princípios e valores. No caso em questão, o valor é a já citada simplicidade, traduzida nos lemas KISS e YAGNI. Os passos de bebê asseguram que o software terá apenas a complexidade necessária e nada mais.

Olá mundo!

2008-10-01T23:45:00.003-03:00

Esta é a estréia do blog. Por aqui teremos, certamente com periodicidade halleyana, programação em geral, orientação a objetos, metodologias ágeis e devaneios relacionados.

Que ninguém espere nada de revolucionário ou impressionante feito aqui. Coisas assim aparecem nos links aí do lado e na seção leia isto. Por aqui só tijolinhos sem muita importância. Até breve!