Caminhos para seguir na computação

No ínicio desse mês fui convidado para dar uma palestrar pra um turma de calouros do CESUPA. O foco era dar uma idéia inicial sobre o curso (Bacharelado em Sistema de Informação) e algumas dicas do eles deveriam encontrar, e o que poderiam esperar nos próximos anos de graduação. Acabei focando mais no mercado de trabalho (acadêmico e empresarial), e nas diversas oportunidades que estão disponíveis pra quem quiser (e tiver muita disposição) trabalhar na área de TI.

Pra quem quiser conferir a apresentação, segue os slides.

Anúncios

A síndrome beta

Voltando para o mundo corporativo, vivencio novamente aquilo que eu já havia, em partes, esquecido. Produto sendo entregue com baixa qualidade, prazos não realísticos, processos burocráticos que mais atrasam do que aceleram o time. Essa avalanche de maus cuidados acaba  em quem está no final da cadeia alimentar: os desenvolvedores.

A vivência na academia me mostrou muitas coisas, dentre as quais: Não importa qual o trabalho que você pretende desenvolver, se ele não estiver bem (leia-se *muito* bem) fundamentado, avaliado e testado, você não terá impacto com ele. Nesse caso o usuário (algum  avaliador do seu projeto) será critico o bastante para mencionar que a sua abordagem não está plenamente segura. Métodos, métricas e algoritmos são construídos tão somente com esse propósito, e grande parte do tempo para elaboração destes trabalhos está na avaliação destas medidas de resultados.

Voltando para o meio empresarial, acontece o que eu  chamo de síndrome beta. Algo que está longe de estar pronto, mas é passado para o cliente sob o status de beta , e caso algum problema aconteça, este estaria previamente justificado. Irônico, não?  Quem por volta e meia passa no blog, percebe o quanto eu bato na tecla na questão do teste de software. Muitos simplesmente dizem que tanto estudo é desnecessário. Concordo também que a aplicação de métricas de software é custoso e exige bastante esforço. Mas se abster é jogar a responsabilidade para aqueles que tem o único compromisso de utilizar, e não avaliar o que foi feito.

Parte desse problema é ideológico. Explico. Empresas e gerentes tratam desenvolvimento de software como um processo de fábrica,  inibindo a capacidade de criação e investigação, tão valiosas em um meio que respira dinamismo e inovação. Aplicando esse modelo, espera-se encurtar prazos, aumentando o hall de cliente.

Mas com o curto tempo,  como pensar em testes ou inovação?  O processo deveria ser tratado como uma tarefa artesanal, e não mecânica.

Categorias:Desenvolvimento

Ferramentas para teste de software em Python – Parte 1

Não querendo ser pretensioso demais, esse post vai tentar abordar algumas das ferramentas que podem ser utilizadas no teste de software específicos para linguagem Python, visto que esse é um cenário muito extenso e diversas abordagem podem ser utilizadas. Mas primeiramente, um grande questão: O que deve ser considerado no teste do software? Antes de responder, permita-me voltar um pouco com a história.

Quando se fala em testar, diversas variáveis podem ser consideradas: o custo do teste; o tipo do teste; a cobertura alcançada no código; a capacidade do teste revelar algum defeito, dentre várias outras. Responder a questão anterior está diretamente relacionado com a escolha de alguma destas, ou de outras métricas. E para cada característica, um tipo ferramenta pode ser utilizada. Por essa profundidade, inicia agora uma série de posts relacionados ao tema. Para começar, vamos falar do básico sobre o teste em Python.

Nota: Se você nunca criou testes, nem escreveu uma linha em Python, não se preocupe. Apesar de ser um assunto bastante abrangente, ele é de fácil compeensão.

Motivação

O teste ajuda a definir e restringir o problema em questão. Com ele você de garantir que o software que está sendo entregue ao cliente funciona como foi especificado, com uma maior garantia que no meio da noite não terá ninguém te ligando dizendo que ocorreu uma falha inesperada. Princípios como do Test Driven Development encorajam a escrita do teste antes da escrita do código de negócios. Mas o teste pode ser escrito em várias fases do processo de desenvolvimento. O importante é que ele deve ser escrito.

O primeiro passo é aplicar o teste de unidade. Entende-se por unidade a menor parte testável do programa. Em linguagens Orientadas a Objeto, este pode ser considerado tanto como a classe, quanto o método. Jamais um atributo, pois não existe um comportamento. Python é uma linguagem que pode ser utilizada no paradigma OO, e é também conhecida por ‘vir com as pilhas’ (componentes prontos para uso), logo no teste de unidade não é diferente. O unittest foi o primeiro framework desenvolvido para o teste de unidade, e  ainda é o mais conhecido e utilizado. Este é uma releitura do famoso JUnit, utilizado em programas Java. Para sua aplicação, alguns conceitos precisam ser introduzidos.

  • Dado de teste: É a menor unidade do teste. Verifica dados da especificação para um particular conjunto de entrada.
  • Suite de teste: É uma coleção de dados de teste.

O unittest fornece um rico grupo de ferramentas para construção e execução dos testes. Veremos que é possível satisfazer, com poucas linhas, as principais necessidades do teste de unidade. Para isso, considere o arquivo exemplo1.py, representado pela próxima figura:

O código praticamente fala por sí próprio. Na primeira linha é definido um método reverse aceitando lista como parâmetro. Na segunda linha, a lista é invertida, e em seguida, é retornada. O dado de teste para este código é apresendo a seguir.

Apesar do teste escrito ser bastante simples, ele apresenta as principais características necessárias de um dado de teste. Na primeira linha é feito um import para o unittest. Posteriormente, é criada a classe ReverseTests. O nome Test é necessário, pois informa ao compilador que este é um arquivo de teste. A classe ainda herda de unittest.TestCase. Isso é necessário, pois um dado de teste necessáriamente deve estender essa classe. A linha 5 faz um import específico para o método criado anteriormente, e a linha 6 representa o ponto crucial do teste, chamado assertEqual(). Este método verifica o resultado experado (primeiro parâmetro) com o resultado que é obtido (segundo parâmetro), realizando essa comparação. O último bloco apresenta uma maneira simples para rodar o teste. O método unnittest.main() fornece uma interface em linha de comando para o script. Quando o teste acima é executado, uma saida similar a esta é obtida:

--------------------------------------------------------
Ran 1 tests in 0.000s
OK

Nesse momento, você conseguiu executar o seu primeiro teste. E ele foi bem sucedido. Agora, mude o valor passado no método assertEqual e veja qual será a saida apresentada. Além do assertEquals, outros métodos são de importância: setUp() e tearDown().

O método setUp()é utilizado para preparar variáveis e/ou objeto que vão ser usadas nos métodos de teste. Este método é chamado imediatamente antes de todos os outros métodos de teste. Qualquer exceção lancada por esse método é considerado um erro, ao invez de uma falha no teste.

No caso do método tearDown(), o método é chamado após todos os métodos de teste serem executados. Esse método só vai ser chamando se o método setUp() for executado também. Com a inclusão destes métodos, o nosso arquivo de teste refatorado se tornou o seguinte:

O código acima ficou muito simples e claro, e ainda conseguiu atender todas as nossas necessidades. Estes foram os passos básicos para o teste de unidade ser atendido. No próximo episódio, os caminhos para tornar sua documentação testável. Não perca!

Categorias:Teste de Software

Tecnobrega e pirataria: a dominação do mundo partindo da capital paraense

Vocês lembram daquele programa da Regina Casé que passava no Fantástico sobre as periferias do Brasil, cujo nome era Central da Periferia? Se lembrar, agora vem a pergunta mais difícil: Lembram do programa que foi ao ar em Belém, e que falaram do Calypso, e do rítimo que tomava conta da cidade, o Tecnobrega?

Quem não é de Belém, acho muito pouco provável que a resposta seja sim. Caso eu esteja certo, o youtube pode refrescar essas memórias. Vide link abaixo.

Acontece que o programa foi curto e pouco apresentou da verdadeira realidade que acontece em Belém. A rotina da Banda Calypso e do DJ Dinho, hoje em dia, nada se compara com o resto das milhares (isso mesmo, *milhares*) de bandas que balançam a parte periférica da cidade. Para preencher esse vazio na mídia, o filme ‘Brega S/A’ entra em ação. Confesso que até eu, que morei por 20 anos na capital paraense, não sabia de muito sobre esse mundo que gira ao redor de um rítmo musical.

Até mesmo para quem não reside, ou morou, em Belém a obra acrescenta muito. Em resumo: Vale a pena!

Confira: http://musica.uol.com.br/ultnot/2009/11/06/tecnobrega-e-trilha-sonora-da-periferia-de-belem-do-para-veja-o-filme-brega-sa-e-ouca-os-hits-do-estilo.jhtm

Uma boa razão para não se ouvir mais música

Pelo menos a música atual.

O site estado-unidense especializado em música pitchfork.com (quem são eles?) lançou uma relação dos melhores 20 albuns desta década. Se fosse no Senado brasileiro, daria em pizza, mas como foi internacional, deu em merda mesmo. Segue a lista:

01. Radiohead – “Kid A”
02. Arcade Fire – “Funeral”
03. Daft Punk – “Discovery”
04. Wilco – “Yankee hotel foxtrot”
05. Jay-Z – “The blueprint”
06. Modest Mouse – “The moon & Antarctica”
07. The Strokes – “Is this it”
08. Sigur Rós – “Ágætis byrjun”
09. Panda Bear – “Person pitch”
10. The Avalanches – “Since I left you”
11. Ghostface Killah – “Supreme clientele”
12. The White Stripes – “White blood cells”
13. OutKast – “Stankonia”
14. Animal Collective – “Merriweather Post Pavillion”
15. The Knife – “Silent shout”
16. Sufjan Stevens – “Illinois”
17. LCD Soundsystem – “Sound of silver”
18. Kanye West – “Late registration”
19. Spoon – “Kill the moonlight”
20. Interpol – “Turn on the bright lights”

Começando pelo nome das bandas, acho que só umas 5 me fazem lembrar algo um pouco mais familiar. São sou especialista em música, mas será que eu o único que não conhece Sufjan Stevens?? O que mais me intriga, é como o Radiohead consegue estar no topo da lista com um album que nem por eles é considerado um dos melhores da banda.

E ah, foi lançado em 2000. Ou seja, praticamente com os dois pés na década passada.

Categorias:Cultura Tags:, ,

Mais um blog na blogosféra

setembro 23, 2009 1 comentário

Eu sempre tenho relutado em escrever textos que falam sobre temas que envolvam trabalho aqui no blog. Mas como é de se perceber, não tem dado muito certo. Mas agora, por bem ou por mau, isso há de acontecer. O motivo é simples, eu e mais uns colegas do antigo e bem quisto CESUPA, inauguramos um blog só pra falar de tecnologia. Melhor né? E como ele vai ser escrito por uma meia dúzia de mãos, fica mais difícil dele ficar ao relento 🙂

Bom, é isso. Se algum dia você já passou por aqui e o que você queria encontrar não estava em todas essas linhas escritas, quem sabe agora você tem um pouco mais de sorte, heim?

Ah, o endereço do blog é: amazontic.wordpress.com

Abraços galera, boa semana pra todos!

Categorias:Sem categoria Tags:,

Test-driven Development (TDD) em Curitiba

Cansado de ver seus códigos funcionarem em um momento, e no dia seguinte a mesma rotina não funcionar. Sempre sente receio em refatorar uma funcionalidade já implementada com medo de alguma coisa do outro lado do projeto simplesmente parar de funcionar?

Parece brincadeira, mas uma pesquisa feita em 2002 pelo Departamento de Comércio do EUA afirmar que falhas em software causam em torno de 60 bilhões de dolares em prejuízo por ano! Ou seja, você está muito longe de ser o único sortudo que sofre de mal, muito pelo contrário, defeitos em software vão sempre existir. O que podemos fazer é um esforço para tentar minimizar a existência desses defeitos, ou, simplesmente indentifica-los e remove-los de forma mais segura e eficaz.

Mas como fazer isso, levando em consideração toda a heterogeniedade entre as arquiteturas, linguagens, ou simplesmente, especificações de software?

Uma metodologia ágil que vem ganhando destaque e notoriedade nesse contexto é o Test-driven Development, também conhecido como TDD. Em resumo, o TDD é uma outra maneira de elaborar projetos de software, baseado em pequenas iterações que valorizam primeiramente a escrita do teste, para posteriormente ser escrito o código. Achou interessante? Já ouviu falar, mas nunca colocou em prática?

Se tiver interesse e se estiver em Curitiba nos próximos dias, no ENECOMP vou apresentar uma visão geral sobre essa metodologia, com uma linguagem simples e direta, sem toda a burocracia da engenharia de software. De quebra, ainda tem a aplicação de um pequeno estudo de caso. Mas se você não estiver em Curitiba, ou não poder ir ao evento, na próxima terça-feira (08/09) eu compartilho a apresentação no blog, e eventuais dúvidas podem ser tiradas por aqui mesmo.

Abraços, e até breve.