Escada acima: doutorado
Depois de voltar pra casa e passar alguns bons meses debaixo da sobra e água fresca, no sentido de moradia, mas trabalhando como nunca, decidi [re]testar minha maturidade longe da zona de conforto. Em 2011 me mudo novamente. Próximo destino? Recife. Ou melhor: UFPe. No caminho, visível somente o tapete de uma looonga estrada com uma caminhada prevista de quatro anos estudando aquilo que eu me adaptei a ouvir diariamente desde 2004, quando entrei na graduação.
De lá pra cá, muitas opções e idéias do que fazer e/ou qual profissão seguir. O mercado de TI anda bem aquecido de norte a sul do pais, e empregos não faltam pra quem é competente. Idéias pra abrir o meu próprio negócio já surgiram, mas nenhuma que me faça acreditar que vale a pena investir e, principalmente, que vai ser legal o efeito colateral de se ganhar preocupações com clientes que não pagam, e funcionários que não trabalham. Decidi investir em mim e colocar o último pilar formal da educação.
No final, mais de uma década estudando e criando computação. No meio disso, muito trabalho, escrita, leitura, implementação. Resumindo: Muito gás! Mas por enquanto, apenas a anciosidade..
Espero ainda manter esse blog pra contar parte dessa nova jornada 🙂
Longevidade para seu código
No inicio de dezembro, em um periodo próximo ao do JavaOne Brasil, aconteceu o já famoso BelJungle, encontro anual do grupo de usuário Javas do estado do Pará. E como eu andava meio, pra não dizer muito, afastado dos eventos e encontros por rasões obvias [3 mil km de distância faz disso obvio, não?] , resolvi dessa vez ajudar um pouco mais. Claro que toda a parte da divulgação e corrida por patricinio, colaboradores, não foi feito por mim. Mas aproveitei pra compartilhar algumas das experiências que eu andei vivenciando nesse meio tempo que eu passei programando.
Aproveitando a dica, coloco os slides a disposição. Eles estão bem intuitivos, mas qualquer duvida ou questionamento, só usar o blog 🙂
ps: Caso os slides demorem mais que o habitual para carregar, talvez seja melhor baixar a apresentação neste link: http://bit.ly/hg6nB4. É seguro, prometo 🙂
spam real?
Você abre a sua caixa de mensagens, e lá está aquela mensagem dizendo: “Emagreça 10 kilos em uma semana”, ou “Tire agora o seu nome do serasa”. Seja qual for o fornecedor do seu email, um endereço novo ou antigo, sempre vai ter um spam na sua caixa de entrada.
Com o tempo, eles foram ficando mais elaborados. Agora não são mais enviados por qualquer adolescente que tenta passar um vírus por email para um usuário desavisado. Spams agora focam no conteúdo. Coisas do seu cotidiano vem escritas nas mensagens. Mas, como eles tiveram acesso a essa informação? Quem passou meu email?
Com a quantidade de serviços disponíveis na internet, qualquer cidadão que acessa a rede passa a ser monitorado. Pare agora e veja quantas abas do seu navegador estão abertas, e quantas delas são da mesma empresa? O monopólio dessa informação pessoal é controlada por uma única empresa. Location-Based Services é o termo usado por serviços focados em localização. Poucas pessoas usam ele atualmente, mas a previsão é que em 2012 sejam mais de 1 trilhão de dispositivos conectados ao LBS.
Revolução na maneira de se locomover, encontrar lojas, amigos e serviços físicos, tudo pelo celular. E de ser encontrado também. Agora supondo que essa empresa que detêm a maior parte das suas informações pessoais, adote também esse serviço. Ela sabe onde você esta e o que você procura. Tudo isso em tempo real.
Quanto surpreendente seria se você entrasse em um pub, ao invés de receber o menu do garçom, já recebesse um chopp escuro sem colarinho, da maneira que você gosta. Muito agradável, de fato. Mas basta estender esse pensamento para notar que as informações gravadas hoje, poderão ser facilmente utilizadas a favor de terceiros. Contratos garantem que, ao apagar sua conta na maioria dessas empresas, seus dados são apagados juntos. Mas até que ponto isso é verdade? E qual será esse impacto? A única certeza é das oportunidades de negócios que se abrem com o LBS.
Python Brasil chegando
Pessoal, pra quem não conhece, a Python Brasil é um dos maiores eventos sobre Python, e filiados, da América Latina, e nesse ano, como no ano passado, vai ser sediado em uma cidade mega fria: Curitiba. Sempre no fim do inverno, mas a tempo de aproveitar um bom vinho (isso pra aqueles que não são de lá, porque frio só é legal pra turista). Pra mim, uma pena, pois alguns poucos meses depois que eu voltei da terra das araucárias, o mesmo departamento que eu trabalhava vai receber e sediar o evento.
Bom, mas se eu não vou, porque eu to fazendo propaganda? Simples, pelo empenho que eu tenho visto de todos da lista grupy-pr. Não vou citar nomes (pois posso cair naquele velho problema de deixar alguém de fora), mas um precisa ser lembrado, que é o Ramiro, que desde a candidatura, tem feito um excelente trabalho, tanto em levantamento de recursos, datas, locais, agências de viagens, palestrantes convidados, palestras iniciais, assim como foi o aquecimento pra Python Brasil, o PythOnCampus.
Pra todos, espero que tenham um grandioso evento, com muita troca de networking e de experiências, e é claro, não deixem de conhecer Curitiba, a tal da cidade modelo. Uma dica de passeio rápido e low cost é procurar o ônibus da linha turismo. É bem legal.
E, se der certo, ano que vem nos encontramos novamente, quem sabe ainda em uma terra um pouco mais quente 🙂
Grails from scratch
Alimentando o já movimentado assunto sobre frameworks para desenvolvimento web, hoje eu apresento uma opção que, acredito eu, será realidade no mercado de software nos próximos anos: Grails. O motivo? Agilidade. Principalmente no presente momento em que todo mundo quer (leia-se precisa) ser ágil.
Em alguns cenários, o principal empecilho pra dar uma acelerada no processo de desenvolvimento/entrega de algum produto, está relacionado com a tecnologia em uso, além é claro de problemas como maturidade da equipe, elevada curva de aprendizado, etc. Quando se foca em tecnologia, algumas questões precisam ser respondidas, como: É possível elevar a produtividade sem, necessariamente, aumentar o esforço? Quais os ganhos eu terei, a curto prazo, com o framework x? Terei como utilizar o código legado com essa nova aplicação?
Em muitos casos, é capaz de você mesmo ter criado a sua solução from scratch para responder essas perguntas. Por outro lado, se você ainda está pesquisando quem poderia melhor sanar essas dificuldades, eu lhe indicaria fortemente o uso do Grails.
O porque de toda essa confiança vem nos próximos slides que apresentam um step-by-step bem básico pra criação do esqueleto de uma pequena aplicação, que utilizei em um minicurso na última semana. Aproveitando a deixa, fica pra quem também tiver interesse.
Lembrando que os exemplos foram todos retirados do livro Getting started with grails.
Dica em JSF: não coloque negócio nos métodos gets/sets
Esse problema começa, primeiramente, com a péssima prática de criar gets/sets indiscriminadamente. Essa é uma cultura que vem de casa, ou melhor, das universidades que ensinam os alunos a criar os objetos sem comportamento, os POJO como são mais conhecidos. Até então não há nada de errado, até porque essa é uma das maneiras mais simples de entender a orientação a objetos. O problema só ocorre quando você leva esse conceito para objetos que não deveriam ser tratados como um POJO.
Vejamos um exemplo: Temos uma classe Estoque, com um atributo capacidadeTotal. Em que momento você usaria o método setCapacidadeTotal no dia-a-dia da aplicação? A não ser que o espaço físico tenha aumentado, é pouco provável que esse método seja invocado. É preciso restringir esse tipo de liberdade para não causar problemas futuros na implementação. A dica por hora é a seguinte: Só crie gets/sets que você tem certeza que serão utilizados no presente momento.
Esse é um problema que poucas pessoam encaram realmente como um problema, visto que não causa danos no código. E como esse é um caso que volta e meia aparece na lista de JSF, esse post serve como tentativa de eliminar esse mau cheiro de dentro do código. Agora mais especificamente no contexto de JSF, vejamos o exemplo do código a seguir:
<h:selectOneMenu required=”true” label=”Origem Recurso”
value=”#{linhaCreditoBean.idcidade}”>
<s:selectItems var=”cidade”
value=”#{linhaCreditoBean.cidades}”
noSelectionLabel=”Selecione” itemValue=”#{cidade.id}”
label=”#{cidade.siglacidade}” />
</h:selectOneMenu>
A maneira mais simples de se implementar o gerenciador desta página é com um atributo List de Cidade, e o método getCidade() com a consulta no banco. Bem claro e simples. Acontece que no decorrer do ciclo de vida do JSF os métodos get/sets são chamados várias vezes, dependendo do estado que o seu bean estiver atuando. O resultado é consultas indevidas e sobrecarga na aplicação.
Uma maneira simples de se resolver é criando um método somente para popular a lista. Além, é preciso avisar ao JSF que esse método deverá ser executado antes dos demais. Isso pode ser feito com a annotation @PostConstruct do JSF, ou a annotation @Create do JBoss Seam. Algo assim:
@Create
public void carregarCidades() {
cidades = dao.recuperarCidades();
}
Veja que é importante criar métodos com esse comportamento, pois no decorrer do ciclo de vida do JSF os métodos get/sets são chamados indiscriminadamente, dependendo do estado que o seu bean estiver atuando, o que gera consultas indevidas no projeto.
value=”#{linhaCreditoBean.idcidade}” id=”cidade”>
<s:selectItems var=”cidade”
value=”#{linhaCreditoBean.cidades}”
noSelectionLabel=”Selecione” itemValue=”#{cidade.id}”
label=”#{cidade.siglacidade}” />
</h:selectOneMenu>
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.
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.
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!
O mundo pessoal de Gustavo Pinto 