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.
segunda-feira, 14 de fevereiro de 2011
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:
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.
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.
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.
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.
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?
Git, óbvio. E Subversion para projetos que ainda o utilizam.
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í!
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
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.
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.
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, 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:
ou
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
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:
ou
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):
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
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?
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
...
endou
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!
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.
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.
quarta-feira, 3 de novembro de 2010
Um diálogo sobre orientação a objetos
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...)
Assinar:
Postagens (Atom)