sexta-feira, 26 de fevereiro de 2010

Entropia de software


Esbarrei no termo esses dias lendo sobre "What Is Time? One Physicist Hunts for the Ultimate Theory", e achei muito interessante a definição. Nunca havia parado para realmente entender o termo, mas é incrível como está conectado sobre várias áreas do cotidiano, inclusive no trabalho de Analista de Sistemas.

Por definição entropia é uma função de não conservação de estado. Ou seja, pouca entropia define que o estado da coisa está pouco alterado, muida entropia define que o estado está bem alterado em relação ao estado inicial. Existe um ponto máximo de entropia, podemos defini-la como "pior que está não fica". Ou seja as coisas tendem para o caos e a desordem automaticamente, aumentam a entropia.

Um exemplo simples é quando deixamos um maço de folhas empilhados sobre a mesa e depois saimos, depois de uma semana, quando voltarmos, muito provavelmente o maço estará desorganizado.

Relacionando com desenvolvimento de softwares, quando começamos um projeto sabemos onde está tudo, o softwaer funciona e a coisa está organizada, dai então entra outro programador, outra equipe, os prazos apertam, etc, e a coisa começa a ficar um pouco mais confusa. Nesse momento estamos aumentando a entropia, as coisas começam a ficar mais desorganizadas ou não documentadas. Com a evolução do software e manutenções corretivas se atinge um estado de entropia máxima, e o sistema não suporta mais "novas funcionalidades" e sequer correções pequenas se tornam uma tortura. Esse é o ponto de reescrever o software ou o módulo.

sexta-feira, 5 de fevereiro de 2010

Seu grande inimigo




Li a frase "(...) and competing with no one but himself,(...) any issue that must be handled was solved first and foremost in a dialogue between him and himself(...)" e não consegui parar de pensar nela.

Parece uma coisas simples, mas perceber que você só tem um único inimigo e que esse inimigo é você mesmo lhe da um novo entendimento das coisas. Se lembra daquela promoção que não te deram mas a deram ao João, ou aquele carro que queria comprar mas acabou optando por um mais barato, ou aquele curso que queria fazer mas não tinha tempo. Quem lhe atrapalhou foi você mesmo, porque não se esforçou mais, porque não juntou dinheiro mais uns messes e porque não reservou um tempo.

Essa filisofia também é nova pra mim, estou aprendendo a encara-la.

sexta-feira, 29 de janeiro de 2010

Copy and Past Hell

Vamos começar assim, estabelecendo uma regra:
  • se um programador efetuar mais que 5 copy and past por dia seus dedos mindinho e indicador serão cortados, dificultando muito faze-lo.

Copy and past é uma coisa do dia a dia, mas no desenvolvimento de sotware acaba gerando um antipattern chamado "Big ball of mud". Dificulta a manutenção do código e pode espalhar bugs.

Recentemente esse tipo de problema tem ficado bem evidente. Estou utilizando o Hudson como ambiente de integração continua e o plugin Violations em conjunto com o Simian(bem, não é mavem, o que posso fazer) para analisar trechos de código iguais no código. Como só implementamos essa ferramenta a pouco tempo e o software já tem um tempo na estrada, não é de se esperar que haja alguns problemas desse tipo. A figura 1 mostra o que estou falando, enquanto a figura 2 mostra porque estou escrevendo(é mole).

Figura 1) Bem, não está tão mal.

Figura 2) 1800? Tá de brincadeira.

Vamos torcer para a coisa melhorar.


terça-feira, 19 de janeiro de 2010

Google-fu


Achei o termo muito interessante e não podia deixar passar em branco a oportunidade de cometa-lo.

"Google-fu é a arte de responder qualquer pergunta feita utilizando recursos de internet, como ferramentas de busca". Já há algumas entradas em dicionários urbanos e na wikipedia para o termo.

A internet é uma verdadeira base de dados viva, que a cada minuto ganha milhares de novas entradas, em qualquer área, saber minera-la pode ser um diferencial.

Ser especialista nessa técnica não está atrelado apenas a informática. A pouco tempo presenciei uma quase "formação em medicina" (rsrs) baseado apenas em google e publicações de medicina com base na internet (sério).

Para a área de informática essa técnica é ainda mais importante, acho que vou preparar um curso sobre isso. Hoje existem vária tecnologias eminentes e o mundo se reinventa a cada seis messes. Mais importante que um certificação é a capacidade de adaptação rápida a novas tendencias, a absorção de nova tecnologia e modelos deve ser rápida senão as chances de sucesso ficam comprometidas.

terça-feira, 22 de dezembro de 2009

Sun Tech Days 2009-2010

Estive novamente no evento da sun esse ano e para falar a verdade as novidades são poucas, pelo menos para quem anda antenado no que está acontecendo la fora através de blogs, sites de noticias e outros.

Uma coisa interessante foi a vinda do James Gosling para promover uma palestra de abertura. O cara é uma lenda na comunidade java, sua apresentação foi muito boa.

Estava esperando para ver alguma novidade sobre a aquisição da Sun pela Oracle mas o único momento que alguém falou sobre isso foi para dizer que não falaria sobre isso(rsrs). A apresentação da Oracle foi feita por Pieter Humphrey, um dos diretores.

Achei interessante uma apresentação sobre o JRockit, uma camada de virtualização que roda sobre o virtualizador, ou seja, a máquina virtual não tem S.O. somente a maquina java para executar o AppServer. Sem problemas de segurança, porque não existe usuário, sistema de arquivo, etc, muito interessante.

sexta-feira, 30 de outubro de 2009

Código Coletivo

Uma das coisas que mais me preocupam nos ambientes de desenvolvimento de software é o aparecimento do "super" programador. Normalmente esse fenomeno se dá quando algum software ou rotina complicada se apresenta e não há, na melhor das palavras, disponibilidade de encarar a tarefa, quando se encara surge o "super" programador.

Várias metodologias modernas de desenvolvimento de software resa por praticas que visam difundir o conhecimento do código, auto documentação e testes. A programação em par é uma dessas técnicas.

Uma técnica também muito útil é a rotatividade de equipe. Um sistema não deve ficar eternamente na mão de um único desenvolvedor, mas a equipe tem que variar, disiminando o conhecimento do sistema pelos desenvolvedores.

Recentemente vi um apresentação do Google IO sobre o míto do programador gênio, bem interessante e faz refletir sobre alguns aspectos comuns nas equipes de desenvolvimento de software.

sexta-feira, 17 de julho de 2009

Segurança na hora de estacionar

Presenciei essa cena há algumas semanas, perceba os dispositívos de segurança adotados na cidade de São Paulo pelos proprietários de veículos zelosos.


Alta tecnologia, não identificou? Veja em detalhes abaixo.















Daqui há alguns dias essa tecnologia chegará também para os carros da cidade.