Fork me on GitHub

segunda-feira, 14 de fevereiro de 2011

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

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.

terça-feira, 4 de janeiro de 2011

Meu ambiente de trabalho em 7 itens

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í!

domingo, 26 de dezembro de 2010

Rodando testes offline com Selenium e Firefox

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.

sábado, 11 de dezembro de 2010

"Agile" nunca mais

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 Atemfalou 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"!

sábado, 27 de novembro de 2010

Mais sobre TDD e coding dojo

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


ou

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

ou

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?

quarta-feira, 24 de novembro de 2010

Como foi o PythOnCampus IFF 2010

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!

domingo, 7 de novembro de 2010

Semana Cheia

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.