FISL10: Algumas Palestas do Último Dia

Daniel Ruso fez uma boa apresentação sobre Perl 6, que já está em desenvolvimento a 9 anos, mas ainda não foi lançado em definitivo. Contudo, muita coisa do Perl 6 já pode ser usado no Perl 5, por meio de módulos.

É uma linguagem bastante robusta e que promete revolucionar muito a forma de programar.Já existe uma implementação de teste do Perl6 chamada de Pugs, mas parece que é bem lenta.

Algo interessante mostrado na palestra é a possibilidade de usar a sintaxe de outras linguagens em blocos de código. Daniel mostrou um trecho de código escrito em Java, dentro do código Perl.

Depois desta palestra, tive a oportunidade de acompanhar Richard Stallman, palestrando sobre os perigos das patentes. Já tinha assistido uma sobre esse assunto a alguns FISL atrás, mas resolvi assistir novamente, para ver se tinha alguma novidade.

Interessante uma analogia que ele fez: imagine se tivessem resolvido patentear a música na época de Beethoven. Trechos de notas, arranjos e outras idéias similares não podendo ser usadas… Ao invés de Beethoven compor sinfonias que soassem bem, ele comporia músicas sem problemas de patentes, provavelmente sem a mesma qualidade sonora.

A única alternativa é não deixar as patentes serem difundidas pelo mundo. Inclusive ele alertou que a entidade responsáveis por patentes no Brasil estava tentando encontrar algumas falhas na legislação para tentar forçar a adoção aqui.

Em contato com o Lula, durante a visita, Stallman disse que conseguiu entregar um documento que fazia uma analogia similar a de Beethoven com a produção de novelas no Brasil. Ele acredita que conseguiu sensibilizar o presidente para acompanhar melhor isso.

Fizeram uma brincadeira colocando uma placa do “Steve Balmer” sobre a mesa dos palestrantes. Após alguém alertar a presença da placa ao final, Stallman afirmou não acreditar que ele fosse realmente comparecer e aceitou a brincadeira numa boa (será que foi a organização do evento que fez isso?).

Uma das palestras mais descontraídas desse fórum foi de Rubens Queiroz, sobre os 12 anos do Dicas-L. Dei muitas boas risadas, ótimo palestrante. Participei  mais para conhecer ele, já que é famoso na comunidade.

Outra bom palestrante, foi de Eduardo Maçan. Na verdade, ele acabou improvisando, já que o convidaram a apresentar este trabalho no evento segunda-feira de madrugada (ele já tinha apresentado outra palestra neste FISL). Ele falou sobre a cultura hacker x administradores.

Aparentemente ele lançou uma nova modalidade de slides para apresentação de um trabalho em um fórum, onde o próprio público prepara o material.

Segundo ele, após aproximadamente 3 anos longe da comunidade por motivos particulares, ele conseguiu ver o “outro lado”, o lado administrativo do negócio e acabou chegando a conclusão que, apesar das aparências, existem mais semelhanças do que diferenças. No fim, ele acredita que ser um bom hacker é igual a ser um bom líder.

Essa palestra teve a intenção de simbolicamente encerrar um ciclo, já que Eduardo Maçan foi o primeiro palestrante no FISL 1.

Uma palestra mais técnica que eu assisti hoje, foi de Cloud Computing, de Darlan Segalin. Ele acredita que essa tecnologia vai ser cada vez mais usada, com grandes empresas do mercado investindo de forma substâncial em soluções.

O pioneiro deste modelo computacional foi a Amazon, que em 2006 lançou o S3, para armazenar arquivos online e o EC2, que permite utilizar máquinas virtuais completas, pré-prontas, bastando apenas escolher as caracteríscitas pela web e acessar o ambiente como se fosse uma máquina real (usando SSH, etc).

FISL10: Documentação automática no PostgreSQL

Essa palestra foi apresentada por Leandro Dutra, que trabalha a mais de 10 anos com PostgreSQL, e foi muito interessante, pois lançou algumas idéias muito inovadoras ao atual modelo de modelagem de dados. Eu consideraria até que são idéias um pouco revolucionárias, pois estariam em desacordo com o que a gente aprende como “correto” em cursos de nível superior, etc.

Inicialmente, o Leandro listou as ferramentas tradicionais de modelagem de dados, que usamos:

- Cérebro, ou seja, inicialmente pensamos e imaginamos como será nossa implementação;

-  Livros-textos e documentação;

- Caneta e papel, ou seja, o ideal é que você faça um esboço inicial em papel, sem o comprometimento de ter que gravar isso;

- Programas de diagramação: nesse caso, ele não gosta de usar a palavra programas de modelagem de dados, porque ele acredita que estas ferramentas são muito improdutivas e não conseguem criar um bom modelo referencial para ser usado no banco de dados, sem mencionar que produzem um monte de código desnecessário na hora de importar para o banco de dados;

- Por fim, DDL (data definition language), que seria a linguagem de definição de dados.

Para o desenvolvimento da base de dados, o palestrante sugere aplicar a programação literária, ao invés de processo tradicional de desenvolvimento (esse processo tradicional, seria compostos por passos rígidos, como levantamento de requisitos, criação de um modelo, criação de diagramas, etc).

Na programação literária, ao invés de se elaborar um diagrama da base de dados, partiria direto para a modelagem dos dados em código fonte e após a implementação seria gerado os gráficos do diagrama, bem como toda a documentação da base de dados. Essa modelagem combinaria documentação com código fonte, com alguns identificadores, para que o computador pudesse separar os dados pertinentes a ele, quando necessário.

Para essa modelagem em código fonte, o palestrante sugeriu:

- O próprio PostgreSQL;

- ISO SQL;

- D4: no caso, o D4 seria um padrão muito interessante, na opinião do Leandro, pois ele não teria as limitações do SQL, conseguindo normalizar todas as regras do negócio, mas é algo que não está 100% pronto, tão pouco tem boa documentação.

Para a fase de geração dos diagramas e documentação, ele sugeriu:

- Autodoc, específico do PostgreSQL, com suporte a gerar gráficos, docbook e html;

- SQL::Fairy, um módulo do Perl, capaz de gerar gráficos e código em latex, com a grande vantagem de se comunicar com praticamente qualquer tipo de banco de dados, bem como converter para qualquer saída que se deseje;

-SchemaSpy, uma solução em Java, que gera HTML, com a vantagem de ter uma inteface gráfica para ajudar na hora de gerar a documentação da base de dados.

Algo que o palestrante deixou bem claro é que para isso funcionar é necessário usar muito definição de domínios.

Para finalizar, algumas curiosidades:

O Brasil está em terceiro lugar em importância de uso de PostgreSQL (boa parte por causa do CASE da CEF), sendo que em primeiro está o Japão e em segundou lugar os USA.

Sobre a CEF, ainda, ele disse que a solução deles de 750TPS (transações por segundo), corresponde, aproximadamente, a 1500 transações no banco de dados por segundo.

Uma dica que ele deu sobre a modelagem de dados é tentar usar muito chave natural, ao invés de joins tradicionais, pois além de melhorar a visualização das consultas, isso pode ajudar a melhorar o desempenho também.

FISL10: PgScript

A palestra “Um Elefante de barriga cheia: alimentando bases de dados PostgreSQL com pgScript”  foi bastante técnica, mas muito simples de se entender e é muito fácil de ser utilizada.

O pgScript é um “filho” do Google Summer 2008 e faz parte do PgAdmin III do Postgresql 8.4, mas a príncipio pode ser usada em versões mais antigas do SGDB, como por exemplo 8.3, desde que o PgAdmin seja o mais recente. Foi escrito em C++ e também pode ser executado em shell (e não apenas no ambiente do PgAdmin III).

Além do PgScript existem outras soluções para gerar dados de testes para o PostgreSQL, entre elas (que pretendo estudar mais no futuro próximo):

- DBGEN, que foi escrito em ansy C e utiliza TPC-H benchmark para “popular” a base de dados;

- Generatedata.com: um aplicação web para realizar a função de gerador de dados, com possibilidade de baixar. Em uma análise rápida me pareceu bastante robusto e simples de instalar;

- Módulo Data::Faker do Perl: me pareceu bastante extensível e permite gerar dados mais realistas (e não totalmente aleatórios, como no caso do PgScript tradicional). Facilmente extensível;

- Datagen e Faker no Ruby;

- DBMonster e dgMaster para quem gosta de  Java.

Até pouco tempo atrás eu nunca tinha me preocupado muito com testes de desempenho em base de dados, pois geralmente as configurações padrões atendiam bem as nossas necessidades, mas um novo projeto está exigindo muito mais desempenho do SGDB do que o convencional. Chegamos ao ponto de um servidor Xeon Quadcore com 4GB de RAM não aguentar a carga de processamento com pouco menos de 100 máquinas com acessos simultâneo. Mas eu creio que estes testes na base de dados vão exigir mais do que estas ferramentas podem oferecer e vou ter que estudar melhor como fazer uma simulação baseada na aplicação, para conseguir um ajuste fino mais preciso nas variáveis do PostgreSQL. Contudo, algo é certo: essas ferramentas de geração de dados aleatórios são um bom ponto de partida.

FISL10: MySQL com segurança

A última palestra que participei hoje (25/06), foi sobre o desenvolvimento de aplicações mais seguras com MySQL. Foi na sala 41B… Fiquei um pouco incrédulo quando as atendentes disseram que não teria tradução simultânea (“ele vai falar em espanhol, provavelmente”, disseram elas)… Na programação estava tudo em inglês. Tudo bem, encarei assim mesmo.

Realmente foi tudo em inglês, mas no final, a surpresa: o palestrante falava bem o português, mas disse que apresentou em inglês, porque a palestra foi submetida em inglês… Hehehe Fazer, o que né? 

Meu inglês é péssimo, mas deu para “garimpar” algumas coisas da palestra:

- Tente deixar toda sua aplicação dentro do firewall;

- Use e abuse de stored procedures e views (realmente ele sugeriu abusar muito disso, mas eu creio ser muito complicado programar da forma proposta);

- Isole os dados do usuário da aplicação;

- A credencial do administrador do banco de dados deve ser diferente da credencial do usuário da aplicação. Aliás, o usuário da aplicação deve ter direitos mínimos. Em uma aplicação web, por exemplo, o usuário da aplicação pode ter direito de acessar os dados apenas na máquina local;

- Cuidado com os direitos dos arquivos: exemplo, um arquivo em php que acessa a base de dados, nunca deve ter direito de escrita para os usuários web. Ele sugeriu que o dono do arquivo tenha apenas acesso de escrita (sem acesso de execução) e os outros usuários (no caso, usuário web) tenha apenas acesso de leitura e execução;

- Procurar não transmitir dados no formato texto-puro. Tentar encriptar tudo (quero ver convencer os desenvolvedores a não usar mais o ftp, mas vou tentar, hehehe);

- Não grave senhas em formato texto-puro no filesystem (isso eu achei muito paranôico e muito difícil de implementar isso em uma aplicação web – descriptografar em tempo de boot e armazenar em uma variável, algo assim);

- Ter auditória do sistema (logs de acessos, etc);

- Ter certeza que você pode recuperar seus dados em caso de falha: backup, replicação, etc; ser capaz de refazer todos os passos, se necessário;

FISL10: Desenvolvimento de Geradores com PHP

A primeira palestra que participei hoje foi sobre frameworks com PHP, com Marcelino Leal. Fiquei um pouco decepcionado, pois pensei que seria um comparativo de soluções, mas no fim foi mais sobre Zend Code Generator (http://pt.wikipedia.org/wiki/Zend_Framework).

O palestrante até chegou a citar outras soluções, como Cake e Symphony, mas não fez nenhum tipo de comparativo, tão pouco citou as características destes outros. Já vi várias soluções nesse sentido, não apenas de PHP, mas no fim, cada um prega as suas “ideologias” e é muito difícil, para quem não está envolvido nisso, determinar qual é o melhor para a sua necessidade.

Mas algo interessante abordado é sobre os riscos de se criar dependência em um gerador de código. Suponhamos que ele seja descontinuado ou algo assim. Com certeza, não seria uma boa notícia para alguém que estivesse mantendo um sistema.

Resumindo: cuidado com suas escolhas!