Recebi o convite do brother Abstractj para entrar na brincadeira, aí vai:

Máquina/Sistema Operacional

Minha máquina tanto de trabalho quanto de casa já há algum tempo é o meu mazelado Vostro 1000 que já se pagou com gosto. Comprei um MacPro 15″ que deve tá chegando por aí. Em casa uso um monitor de 24″ e no trabalho um apenas de 19″.

Uso linux já há alguns anos e ultimamente nos últimos 3 ou 4 exclusivamente Ubuntu, no momento estou com o 10.10. Próxima semana provavelmente começarei a xingar o MacOSX no twitter.

Editor e IDE

Bem, eu notei agora que estou ficando velho, quando comecei a trabalhar com Java lá em 1999 eu usava o Visual J++ que era muito superior a tudo que existia, depois usamos o Visual Café por pouco tempo até que descobrimos o Visual Age que de longe tinha o Editor ideal para a época, ou pelo menos é do que me lembro. Desde essa época do Visual Age que minha IDE para Java sempre foi Eclipse, tentei algumas vezes Netbeans, mas para Java não dá, só Eclipse mesmo. Meu Eclipse por muito tempo sempre foi o MyEclipse, acho que desde 2005, não sei como conseguem desenvolver em Java sem ele.

Para web em geral o Aptana é uma boa pedida, as vezes uso também.

Para Ruby eu uso quando posso o RubyMine (tenho uma licença) até quando falta a paciência dele consumir toda a memória do meu velho Vostro, de resto vai de Gedit ou Emacs. Quando chegar meu méqui eu vou usar só RubyMine.

Terminal

Uso sempre o Bash com algumas modificações.

Browser

Para navegar eu tenho usado o Chrome, mas para desenvolver é sempre com Firefox e os plugins Firebug (e seus complementos YSlow, Firefinder e o fantástico Illumination que encontrei há pouco tempo),  JSONView e Delicious Bookmarks (para consultar as fontes).

Software

Basicamente skype, OpenOffice e utilitários de video/musica comuns em qualquer Debian-like.

Source Code

Conta pública e privada no Github. Alguns repositórios internos em clientes no CVS, SVN e GIT. Temos uma meta de substituir tudo pelo Git em todos os clientes, até de graça.

Música

No cliente atual tentamos fazer sempre Pair Programming o tempo todo, então basicamente não dá para ouvir música nessas condições, quando estou sozinho é com o meu N95 + 3g Vivo no Last.FM em algumas rádio que gosto usando o Mobbler.

Vou repassar a brincadeira agora para o @rponte, @rodrigodealer e o @mauriciojr.

Posted in Linux, Sistemas Operacionais, Software Livre, Web Development ~ 1 Comment

Dica rápida para não caírem feito um pato como eu caí.  Hoje fui pesquisar um link do meu próprio blog pelo google e descobri que meu site “/tech” inteiro havia sido removido. Pior, o cache do google apontava para um lance estranho.

Conferi na ferramenta para webmaster do google e verifiquei que o Googlebot era redirecionado para um endereço “bablo .me .uk” e as vezes esse endereço se camuflava em outros.

Usando  ”curl -v -A Googlebot http://www.milfont.org/tech” eu recebia a mensagem:

...
* HTTP 1.0, assume close after body
< HTTP/1.0 301 Moved Permanently
< Date: Thu, 19 Aug 2010 23:55:13 GMT
< Server: Apache
< Location: http://bablo .me .uk/#....
...


Só depois de muita surra procurando nos .htaccess e .php da vida que encontrei nesse link o comentário que me salvou.

Procurando com find -name “*.php” | xargs grep -E “eval” eu encontrei escondido no wp-config.php, pior, estava com muitos espaços para a direita dificultando a visualização:


./wp-config.php:                                                eval(base64_decode('ZXJ....


Sei lá quanto tempo procurando essa desgraça, fica a dica se passarem pelo menos tormento. Revisei todas as permissões e atualizei o wordpress, coisa que deveria ter feito há tempos, mas o preguiçoso trabalha mais do que o esperto.

Posted in PHP, seguranca, Software Livre ~ 1 Comment

Eu participei como desenvolvedor de 4 projetos em Java nos últimos 12 meses, 3 deles tinham algo em comum: tinham uma arquitetura de referência, mais de 4 anos, baseados no struts 1.x, framework caseiro desenvolvido em cima do struts, modicações caseiras em APIs conhecidas sem contribuição com o projeto original [fork antigo ainda por cima], código altamente acoplado e sem coesão, arquitetura baseada em BOLOVO e principalmente sem testes [o último até que estava com uma tentativa de testes de aceitação com o Selenium mas com grandes dificuldades por conta de todos os problemas].

Em projetos antigos é comum encontrarmos esse tipo de situação, eu mesmo já criei meu framework caseiro em coisa por volta de 6 anos atrás, mas hoje em dia isso não só é algo abominável como um desrespeito pelos profissionais, ainda mais após tanta evolução nos últimos 10 anos.

Conversando com um amigo que trabalha em uma grande empresa de planos de saúde, ele me falou que o “arquiteto java” dessa empresa [conhecido por sua fama de criador de "Framearras"] convenceu a diretoria sobre um projeto recente que se baseia no desenvolvimento de um framework específico para a empresa [eles já possuem um framework caseiro que é um terror e bem conhecido por grande parte dos desenvolvedores locais].

É impressionante como não acaba essa tara de desenvolvimento de frameworks caseiros, qual a necessidade de uma empresa que tem TI como meio [e não como fim] de desenvolver um framework para desenvolvimento de software?

Olha que não é de hoje que eu falo sobre os perigos de frameworks caseiros, mas parece que os defensores desse tipo de abominação se reproduzem como coelhos.

Engraçado que no último projeto que participei eu recebi um treinamento de um dos criadores do framework caseiro que deveríamos usar na construção, alias na continuação de um sistema que está há 5 anos em desenvolvimento sem sinal de algo ir para a produção.

Os argumentos que ele usou foram os seguintes [anotei a frase para não esquecer]:

“Amigos, é importante um framework criado pela propria empresa para padronizarmos o desenvolvimento, diminuindo a curva de aprendizado e ganharmos na produtividade, utilizando padrões consagrados, obtendo reuso nos componentes de negócio e garantindo a manutenibilidade pela fácil criação de código, principalmente CRUD.”

Segredo do fracasso

Vou expor algumas considerações sobre essa frase dele:

Curva de aprendizado

Se algo é complexo de entender por quem conhece os padrões daquilo que se deseja desenvolver, é porque não serve mesmo. Não há como comparar um software opensource consagrado no mercado onde centenas de milhares de desenvolvedores já aperfeiçoaram com algo feito em casa.

Ganho na produtividade

A desculpa número um de todo framework caseiro é a famosa produtividade, sendo que voce sempre perde produtividade porque insere algo fora da normalidade no cotidiano do desenvolvedor. Além do que é insano voce ter uma produtividade no inicio – se fosse o caso, já que não é – comprometendo todo o ciclo de vida restante da aplicação por conta disso.

Porque é isso que acontece, todos esses frameworks caseiros são pensados e desenvolvidos para facilitarem a construção de CRUDs no inicio da aplicação e você tem que sacrificar todo o resto para satisfazer esse capricho que pode ser automatizado facilmente com tecnologias atuais.

Utilização de padrões

Ninguem pode saber que padrão utilizar antes de saber qual o problema, isso é impossível. Ou vai usar um martelo para furar uma parede ou uma furadeira para pregar um prego.

Reuso de componentes

Não existe reuso de objetos de negócios, nenhum processo é semelhante nem que seja na mesma organização ainda mais tentando reusar código por meio ide interface gráfica comum em projetos com dificuldade incial até de separação de pacotes.

Uma alternativa geralmente usada é se comunicar via API ou uma estrutura de serviço como WS, JMS, whatever e não aproveitando uma tela em um sistema distinto.

Aumento da manutenibilidade

Sistema como Frameworks caseiros sempre são dificeis de manutenção por que falta documentação, gente que conheça realmente [além dos próprios criadores], código sempre acoplado, falta de testes, maturidade, e principalmente propósito real [como não haver um existente no mesmo segmento].

Em todos os frameworks caseiros que trabalhei e não foram poucos, a manutenção é algo punitivo porque temos que satisfazer o framework e não o negócio.

Garantia da qualidade

Não há qualidade alguma em frameworks caseiros, pelo contrário, pelo conjunto de más práticas já expostas, o que acontece na realidade é que os sitemas desenvolvidos com esse tipo de ferramenta apresentam uma qualidade baixíssima.

Fork em frameworks do mercado

Problema em fazer um merge no futuro, voce não terá tempo e recurso suficiente para isso. Melhor solução seria submeter patch e codigo para o framework original e acompanhar o desenvolvimento deste. Deixa o desenvolvimento preso a versões antigas.

Associado a cascata.

Quase impossível você encontrar um framework caseiro em uma equipe ágeil, até porque isso fere vários dos valores e princípios.

Menos codificação

Na verdade duplica a codificação para satisfazer o framework.

Extensão de classes genericas

Acoplamento, referencia cíclica, etc… dá até preguiça de escrever.

CRUD Driven Design

Quebra o principio do XP que é fazer o mais importante e crucial primeiro, CRUD nunca é o mais importante. Se voce faz o CRUD primeiro, cria a regra de negócio e refaz todo o CRUD depois.

Geração de codigo sempre reescreve as informações, merge manual.

Frameworks caseiros são #ESFM. Vão complementando com as más práticas…

Posted in Design Patterns, Engenharia de Software, Frameworks, Java, Melhores práticas, Software Livre ~ 14 Comments