Resenha Fisl 10

Abaixo, é feita uma resenha das palestras assisitidas durante o FISL 10 (que ocorreu de 24/06/ 2009 a 27/06/2009). São analisadas apenas as palestras das quais se pôde aproveitar idéias para melhorias de práticas no ambiente de desenvolvimento na DIRINF-TRF4, tendo em vista, por exemplo, o nosso framework de desenvolvimentro, aqui chamado de InfraEstrutura ou Infra.

Palestra: Desenvolvimento de Software de Qualidade com Métodos Ágeis e Software Livre (Dr. Fábio Kon) • Referência ◦ CCSL-USP: http://ccsl.ime.usp.br ▪ E-mail: [email protected] ◦ www.agilcoop.org.br ▪ E-mail: [email protected] ◦ Apresentação: http://ccsl.ime.usp.br/files/FISLMetodosAgeisESoftwareLivre.pdf ▪ Desenvolvimento de Software de Qualidade com Métodos Ágeis e Software Livre ◦ Outros links ▪ Falando em Agile 2008 ▪ http://www.caelum.com.br/falando-em-agile/ ▪ http://andrefaria.com/2008/10/26/participacao-nofalando-em-agile-2008/ ▪ Integração Contínua ▪ http://malditacomedia.blogspot.com/2007/10/integraocontnua.html Visão Clássica da Engenharia de Software • Qualidade de software é sinônimo de qualidade processo ◦ produção de documentos/papéis • Se usa linguagem "x" e possui certificação "y", então o software é bom • Processo para melhorar o processo de documentação ◦ ciclo vicioso Espírito do Método (Manifesto Ágil) • Indivíduos e interações são mais importantes que processos e ferramentas. • Software funcionando é mais importante do que documentação completa e detalhada. • Colaboração com o cliente é mais importante do que negociação de contratos. • Adaptação a mudanças é mais importante do que seguir o plano inicial. Ex. de Aplicativos • IDE's ◦ Eclispe, Netbeans ▪ Refatoração embutida ▪ Plugins para automatização de builds e de testes • Teste de Software (XUnit - até 50% do código é teste) ◦ SUnit, JUnit, CPPUnit, CUnit, etc ◦ PDFUnit ▪ Verificação de Pdf's

• Wiki

•

• • • • •

•

▪ ex.: duas vezes ao dia, a integridade do programa é automaticamente testada

◦ texto colaborativo ▪ documentação ▪ estórias ◦ wiki 2.0 ▪ ex.: MediaWiki e extensões ▪ desenvolvimento de sistemas web com perfil colaborativo ▪ rapidez e redução do custo ▪ interface padronizada ▪ customizável pelo próprio usuário ▪ acesso controlado ▪ histórico de edições ▪ repositório e versionamento de informações ▪ categorias de documentos ▪ notificação de alterações ▪ auditabilidade em um mesmo ponto ▪ integração possível ▪ E-mail ▪ ex.: aviso para procedimento de correção ▪ Autenticação Selenium ◦ teste de aplicação WEB ▪ finge ser um humano no site ▪ grava ações do usuário e reproduz com um comportamento esperado XPlanner ◦ gerenciamento de projetos ▪ acompanhamento de atividades, com percentual de conclusão Trac ◦ tickets ◦ bugs Cruise Controle ◦ caso os testes demorem a rodar AutoTeste, Testability-Explorer ◦ analisa o quão difícil é testar um certo código CVS ◦ nova família ▪ Git ▪ Mercurial ▪ mais simples ▪ Bazaar ◦ repositórios distribuídos ◦ repositórios locais ◦ merges melhorados ◦ remoções Métricas ◦ medir complexidade do código ▪ ex.: tamanho da linha do método vezes número de parâmetros ▪ se muito grande, pode-se concluir que o software é difícil de manter ▪ templates de complexidade para cada autor ▪ um bom código ou método para um autor pode diferir do que é bom para outro ◦ avaliação automática da qualidade do código ◦ Metrics ◦ JaBUTi

Grande Maioria dos Projetos não utiliza metodologia nenhuma, e boa parte falha • Método Tradicional ◦ MS Project: supõe-se que pode prever o futuro (ex.: por 2 anos) ◦ Progresso baseado na evolução da Burocracia e não do código ◦ Baseado em documentos, formulários, UML's, processos, controles etc... ◦ ...quando, na verdade, Software é código fonte! • Como melhorar este percentual? ◦ Buil automático (em 10 minutos - colocar em produção de forma automática) ◦ Integração contínua (controle de versão distribuída [ex.: Software Mercurial]) ◦ TDD (Desenvolvimento Orientado a Testes) ▪ 1º escreve o teste ▪ já ajuda a antever erros ▪ implementa depois ◦ Padrões de formatação/estruturação do código (InfraEstrutura já o faz) ◦ Arquitetura Smiples ◦ SCRUM ▪ Estórias criadas colaborativamente ▪ usar wiki ▪ Usuários tem uma qtde máxima de votos para pedir priorização de funcionalidades ▪ Alguns usuários com mais votos (poder) do que outros ▪ Lançamento de versões (releases) freqüentes/instantâneos ▪ Dois tipos: ▪ Estáveis (como os releases do SCRUM planejamento de objetivo e tempo) ▪ Versões Instáveis ▪ gerados sob demanda dos usuários ▪ geradas automaticamente, sob um id ▪ contextualização de bug reports ◦ XP ▪ Práticas mais complexas de aplicar ▪ Programação em Pares ▪ Commiters podem cumprimir o papel do par, assincronamente ▪ Time Completo ▪ Sentar Junto ▪ Cliente Presente ▪ Papo em Pé (Daily Meeting do SCRUM) ▪ Trabalho Energizado

Palestra: Frameworks para Desenvolvimento Rápido de Aplicações Web: um Estudo de Caso com CakePHP e Django (Adriano Pereira, Vinícius Cogo, Andrea Charao[UFSM]) Resumo: Nos últimos anos surgiram vários frameworks que aceleram o desenvolvimento de aplicacoes para a Web. Face a diversidade existente, torna-se relevante conhecer casos de utilizacao de tais ferramentas antes de optar-se por uma ou outra. Este trabalho faz uma análise dos frameworks CakePHP e Django para desenvolvimento rápido de aplicacoes Web, utilizando como base o caso de um sistema gerenciador de estoque de materiais. Para isso, foram construídas duas versões do sistema, uma com Django e outra com CakePHP, permitindo comparar diferentes

características de ambos os frameworks. • Referência: ◦ http://www-pet.inf.ufsm.br/www/?q=content/frameworks-paradesenvolvimento-r%C3%A1pido-aplica%C3%A7%C3%B5es-web-umestudo-caso-com-cakephp-django-0 • Framework ◦ Reaproveitamento de código ◦ Implementação de funcionalidades comuns ◦ Automatização de funcões triviais ◦ Diversidade de linguagens e metodologias ▪ Exemplos: ▪ Django (Linguagem Python) ▪ CakePHP (linguagem PHP) ▪ InfraEstrutura (usada na DIRINF, linguagem PHP) • Características em comum (comparação entre os três citados) ◦ Suporte a diversos SGBD (MySQL, Postgres, SQL Server etc) ◦ Modelo Objeto-Relacional (Banco de Dados Relacional mapeado no Modelo de Objetos da Linguagem) ◦ Três Camadas (MVC) ◦ Criação de operações CRUD • Diferenças/Comparações ◦ Model ▪ Igual nos três ▪ representação da modelagem de dados ◦ View: ▪ CakePHP e InfraEstrutura ▪ visualização dos dados ▪ Django ▪ escolha do conteúdo a ser apresentado (a visualização ocorre em Templates) ◦ Controller: ▪ CakePHP ▪ fluxo entre banco de dados e exibição ▪ Django ▪ aplicação é considerada o controller ▪ InfraEstrututura ▪ navegação entre as páginas (através do 'controlador.php' e 'acao') ◦ Mapeamento Banco-Tabela (ORM) ▪ CakePHP ▪ um arquivo por classe/tabela (extende AppModel) ▪ Django ▪ um arquivo para todas as classes/tabelas (extende AppModel) ▪ InfraEstrututura ▪ um arquivo por classe/tabela (extende InfraDTO) ◦ Detalhamento da tabela em classes ▪ CakePHP e InfraEstrutura ▪ preocupação apenas com os detalhes ▪ Django ▪ campos do BD completamente especificados no arquivo ▪ manutenção da estrutura do BD diretamente na aplicação ◦ Relacionamento do BD

▪ CakePHP ▪ associaçoes "hasMany", "belongsTo" etc ▪ Django e InfraEstrutura ▪ define-se que campos são chaves estrangeiras ◦ Campos de seleção com relacionamento ▪ Padrão é igual nos três ▪ exibição da chave estrangeira na Interface ▪ CakePHP e Django ▪ permite modificar facilmente tal campo de relacionamento ◦ Herança ▪ CakePHP e InfraEstrutura ▪ sem ligação com o modelo do BD ▪ Django ▪ responsável por especializações do modelo relacional

Desenvolvimento de Geradores com PHP (Marcelio Leal - PHP Pai D'Égua) Resumo: Atualmente a utilização de frameworks/geradores é grande principalmente em tecnologias mais modernas devido aos benefícios deste tipo de ferramenta. Esta palestra apresenta as técnicas de desenvolvimento de geradores em PHP associado com frameworks de mercado e independente da plataforma final. Além disso, são apresentados os tipos de geradores, situações onde estes geradores podem agregar valor ao projeto e restrições para manutenção e compatibilidade futura. • Referência ◦ http://fisl.softwarelivre.org/10/papers/pub/programacao/488 • Tipos de Geradores ◦ Gerador de Aplicação ◦ Gerador de Código ▪ caso do Gerador de Código da InfraEstrutura ◦ Gerador de Artefatos ▪ Alto Nível • Customização ◦ Hot-Spots ▪ nomes dos métodos ▪ InfraEstrutura não possui para preservar padrão ◦ Frozen-Sopts ▪ Sintaxe ▪ InfraEstrutura não possui para preservar padrão • Orientação ◦ MDD - Model Driven Development • Riscos dos Geradores ◦ Código em Excesso ◦ Vicia os desenvolvedores ◦ Dependente do Gerador ▪ caso o gerador seja descontinuado ▪ problema minmizado pelo fato da InfraEstrutura ter sido desenvolvida aqui dentro ◦ Problemas de Escalabilidade ▪ a construção de sistemas de grande porte deve se isso se confirma na InfraEstrutura • Vantagens

◦ Produtividade ◦ Mais confiabilidade no código ◦ Padronização ◦ Foco nas atividades mais difíceis ◦ Maior motivação • Desejável ◦ Independência do Gerado ▪ InfraEstrutura cumpre ◦ Regeração de Código (Refactoring) ▪ InfraEstrutura não possui, e é algo que faz falta ◦ Flexibilidade no padrão de nomenclatura ▪ ex.: mudanças no BD ▪ InfraEstrutura não possui • Técnicas ◦ Baseado em Templates ◦ Fixed Code ◦ Configuráveis ▪ Wizards ▪ caso da Infra • Estudo de Caso: Zend Code Generation (comparação com Gerador da Infra) ◦ Possui Reflection ▪ recriação de classe (atributos e métodos) ▪ Implementação ▪ $meuMetodo = new Method(); $meuMetodo->setName("produzirHelloWorld"); $meuMetodo->setMethod("echo 'Hello World';"); ▪ Implementação em XML ▪ definição de atributos da classe e da própriae classes em XML ◦ Geração de Arquivos de Configuração ▪ ex.: arquivo ".php" de config. de conexão com o BD ▪ forma como a Infra faz ▪ utilização de arquivos XML ▪ Infra poderia usar, por exemplo, na definição das strings (ususuario, senha etc) de conexão com o BD ▪ Não ficaria "solto" dentro dos arquivos de config. em php ▪ Poderia nelhorar interface de alteração dos dados, e o controle ◦ Documentação de classe ▪ ex.: documentação inicial da classe ▪ version, revison, author etc ▪ Php docblock

PHP Framewarks (Leonardo Thomas, Marcelo Curi, Márcio Albuquerque e Sandro Franco - SERPRO-BA) Resumo: Com fundo de pano "militar", quatro desenvolvedores PHP tentam defender seu framework. Numa das maiores batalhas já vistas nas comunidades de desenvolvimento PHP, eles apontam vantagens de seu framework e desvantagens dos outros. • Referência ◦ http://fisl.softwarelivre.org/10/papers/pub/programacao/338

• Comparação entre 4 Frameworks PHP Diferentes ◦ Zend Framework ▪ v 1.8.4 ▪ PHP 5.x ▪ MVC ▪ ORM ▪ Gerador de Código ▪ CRUD ▪ Liberdade na Arquitetura ▪ Todo Orientado à Objeto ▪ ex.: ..->setLabel("Nome")->setRegraXX(true); ▪ baixo acoplamento ▪ Cache ▪ Backend e Frontend ◦ CakePHP ▪ v1.2.3.866 ▪ PHP 4.x e PHP 5.x ▪ MVC ▪ ORM ▪ Gerador de Código por linha de comando ▪ CRUD ▪ Active Record ▪ Fácil Instalação ▪ Desenvolvimento Rápido ▪ Alto Acoplamento ◦ Code Igniter ▪ v1.7.1 ▪ PHP 5 ▪ MVC ▪ alto acoplamento ▪ Active Record modificado ▪ difícil de "sair da linha" ▪ usa SQL em funções ▪ ex.: $db->select('nome'); ▪ Muito rápido ▪ Não possui ▪ segurança nativa ▪ autenticação e autorização ◦ Symfony ▪ v1.2.7 ▪ PHP 5.2.x ▪ MVC ▪ ORM ▪ Projeto Propel ▪ Doctrim ▪ Gerador de código ▪ CRUD ▪ 3 opções de instalação ▪ Sandbox ▪ para testes ▪ Pear ▪ Download ▪ Criação de Projeto e Aplicação ▪ YAML ▪ cache ▪ segurança ▪ Classes desacopladas ▪ a partir da v1.1

▪ Helpers para Internacionalização ▪ XML de tradução ▪ Princípios: ▪ Kiss ▪ Dry ▪ XP ▪ Foco em aplicações robustas ▪ Curva de aprendizado maior ◦ InfraEstrutura ▪ v1.2.7 ▪ PHP 5.x ▪ MVC ▪ Alto acoplamento ▪ ORM ▪ Gerador de Código ▪ CRUD ▪ Não possui instalador ▪ uso interno ao TRF4 apenas ▪ precisaria melhor Interface com usuário ▪ empacotamento para instalação em outros ambientes ▪ Sistema de Permissões (SIP) ▪ Segurança ▪ Hash code na url ▪ Autenticação ▪ Helpers ▪ Ajax ▪ Formulários ▪ Javascript ▪ Curva de aprendizado pequena ▪ Desenvolvimento rápido ▪ Adaptado às necessidades da DIRINF-TRF4

Thrift: um framework open source para construção de serviços para comunicação inter-linguagens ( Bruno Atrib Zanchet ) Resumo: O Thrift é uma solução para a construção de serviços com alta performance, surgindo como uma alternativa tão ou mais simples do que webservices baseados em HTTP. Ele destaca-se também pela grande compatibilidade entre linguagens - talvez estes alguns dos motivos da sua utilização por grandes empresas de internet. • Referência ◦ http://fisl.softwarelivre.org/10/papers/pub/programacao/191 • Comunicação Remota de Alto Nível existente até os anos 90 ◦ RPC ◦ Objetos Distribuídos ▪ Corba ▪ Microsoft COM ▪ Java RMI ▪ RPC em OO ▪ XML-RPC ▪ depois SOAP ▪ EJB

• REST (criado em 2000) ◦ estilo de especificar um webservice ◦ estado abstraído para recurso ▪ ex. de recursos: GET, POST ◦ sintaxe universal para links ▪ RFC ◦ operações e content-types bem definidos ▪ exs.: get, put, delete ◦ stateless ◦ melhor para serviço externo ▪ HTTP ◦ mais ubíquo ◦ mais maduro ◦ mais óbvio • Thrift (2007) ◦ baseado em RPC ▪ não faz parte de nnehum plataforma ou comitê ◦ suporta C, Java, Python, Perl, Ruby, Cocoa, Smalltalk, etc ◦ dispensa uso de JSON ▪ já faz a serialização dos dados ◦ trata regras de negócio, codificação, etc ◦ usa sockets diretamente ▪ ganho de velocidade ◦ Camadas ▪ Compilador ▪ interface no cliente ▪ Protocolo ▪ Transporte ▪ nem sempre usa HTTP ▪ Servidor •

Analisar: ◦ caso Trift suporte Mumps ▪ pode servir para comunicação Mumps-WEB via um webservice interlinguagem ▪ melhor que comunicação pelo terminal/XML ▪ menos sujeito a BUG's ▪ melhor definição e publicação de parâmetros e métodos

Modelagem literária e documentação automática em PostgreSQL e outros SGBDs livres (Leandro G. F. Corcete Dutra) Resumo: Uma das dificuldades de programar é manter documentação de bases de dados, principalmente em ambientes onde os esquemas são dinâmicos e não há processos para evolução do modelo de dados. Embora nada substitua a administração de dados, pode-se gerar a documentação essencial de dados para usuários e programadores automática e regularmente. • Referência ▪ http://fisl.softwarelivre.org/10/papers/pub/programacao/582 ▪ http://wiki.postgresql.org.br/ilustrado • Modelagem com Diagramas

◦ Postgres ▪ PgDesigner ◦ MySQL ▪ Workbench • Modelagem com código fonte ◦ IsO SQL ◦ D4 ▪ Modelagem Completa ▪ inclui Regras de Negócio ▪ create table, create view, ... ◦ Tutorial D ◦ Autodoc ▪ gera automaticamente a documentação de modelagem ▪ diagramas ER ▪ gráficos ▪ docbooks ◦ SQL::Fairy ▪ funciona em vários SGBD's ▪ Gráficos ▪ gera em Latex ◦ SchemaSpy ▪ diagramas hiperlinkados ▪ gera em HTML • Processo Tradicional de Modelagem/Documentação ◦ Requisitos ◦ Modelos ◦ Diagramas ◦ Documentos de várias páginas • Modelagem Literária ◦ criada por Donald Knuth ◦ gerado em Latex ou HTML ◦ definição de DOMAINS ▪ mantém consistência ▪ ex.: create function valid_email_address(text) return boolean "código Perl, C, etc" ◦ Regras de Negócios podem estar definidas apenas no Banco ▪ não mais no código da aplicação ▪ regras executadas mais rapidamente e mais usáveis ◦ ORM que represente bem e fielmente os dados ▪ SQLAlchemy ▪ Rails (a partir da versão 3) ▪ parou de usar ActiveRecords ◦ Normalização de Tabelas ▪ separar em tabelas menores ▪ operações de cache, índice, concorrência melhores ◦ Checagem de chave candidata, estrangeira ◦ Utilização de chaves primárias naturais ▪ ex.: cpf ▪ evitar uso de id como chave ▪ Infra não faz uso disso ▪ restrição de integridade no próprio banco

Joomgen: Geração automatica de componentes para CMS por meio de UML (Rodrigo Smania Spillere) Resumo: Esta palestra tem por objetivo apresentar a ferramenta Joomgen. A mesma, consiste em criar automáticamente a estrutura de um componente Joomla! apartir de seu projeto de engenharia de software, especificamente a partir dos metamodelos de diagramas de classes UML, que são exportados das ferramentas case em um formato padrão XMI. • Referência ◦ http://fisl.softwarelivre.org/10/papers/pub/programacao/475 ◦ Apresentação ▪ http://www.joomla.com.br/downloads/doc_details/ 67-slides-da-palestra-sobre-o-joomgen-no-fisl-100.html ◦ Vídeo-Aulas ▪ http://www.spillere.info/ ◦ Colaboração e download ▪ http://github.com/spillere/JoomGen • Arquitetura Orientada a Modelos • Desenvolvido em PHP • Geração automática de componentes CMS a partir de diagramas UML ◦ abstração do código fonte ao programador • Projeto no Início ◦ apenas para Joomla! ▪ extender para outros ▪ Drupal ▪ Xoops ▪ etc ▪ testar com outras ferramentas case UML

Git e Mercurial: uma introdução ( Luciano Ramalho - Python Brasil) Resumo: Git e Mercurial estão na moda. Para quem ainda não adotou um deles, e mesmo para quem nunca usou CVS ou Subversion, será apresentada de forma didática a filosofia e a prática destes sistemas, com exemplos nos dois pois eles têm muito mais semelhanças que diferenças. • Referência ◦ http://fisl.softwarelivre.org/10/papers/pub/programacao/244 • Nova família de software para controle de versão ◦ DVCS (Distributed Version Control Systems) ▪ Ambiente central, onde são publicadas versões estáveis ▪ Cada desenvolvedor possui o ambiente completo em sua própria máquina ▪ Permite trabalhar Offline ▪ não precisa ter permissão de escrita no repositório central para começar a desenvolver ▪ meritocracia

• Git

▪ Commits são feitos localmente, com número de revisões locais ▪ Merges foram evoluídos ▪ Fácil e rápido para criar branches expirimentais ◦ ◦ ◦ ◦

mais complexo mais funcionalidades mais rápido TAGS assinadas ▪ GPG ◦ não funciona bem no Windows ◦ vem sendo o mais usado ▪ github ▪ gitoreous • Mercurial ◦ recomendado para iniciar ▪ mesmo para quem não usou as famílias anteriores ▪ CVS ▪ SVN ◦ funciona bem no Windows ▪ TortoiseHg ◦ muito fácil de criar um respositório e começar a trabalhar ◦ menos comandos ◦ documentação excelente em http://hgbook.red-bean.com