Viagens, opiniões e afins

Simplesmente considero que a informática (entenda-se todo desenvolvimento e criação de produtos) ligada a engenharia e industria está andando na contramão do progresso de TI.  É impressionante a quantidade de ambientes, softwares, ferramentas, etc… que se mantém num modelo proprietário de “caixinha” (você tem que pagar a licença pelo aplicativo, licença para usar um recurso, e por ai vai a exploração) . Fora isso, para mim um dos “pecados” mais grave é a questão de muitos não possuírem versões para outros sistemas operacionais que não o Windows. Um exemplo clássico disso é o Autocad, sistemas de supervisório (Factory Link, RSView, etc), sistemas de acesso ao plc (RSLinx), etc.

Dados recentes de censos promovidos, acredito que no Estados Unidos, mostram um crescente número de pessoas que estão usando outros S.O (sistemas operacionais). Dentro estes outros, existe um destaque para o uso de MAC OS (cuja a última versão é o Snow Leopard) .  Isso se deve a fatos como estabilidade maior, menor vulnerabilidade, robustez, menor custo de licença (no caso de distribuições linux elas são de graça), desempenho, entre muitas outras coisas. Hoje entre desenvolvedores (que não usam o .NET  - por motivos meio que óbvios) é quase que um consenso que a melhor plataforma (máquina e SO) para trabalhar são Mac Apple (iMac, Mac Book …)

Porém quem trabalha com automação ou com desenvolvimento de sistemas do tipo MES – supervisórios – tem a dependência de alguns produtos. Se você for desenvolver um ladder precisará de uma ferramenta para conectar ao PLC e fazer o upload e download. Se você for desenvolver um supervisório, precisará de ferramentas para desenvolver, outra para conectar ao PLC e outra para mostrar as telas. Todas estes aplicativos, com raras exceções, são proprietários e só tem versões disponíveis para Windows.

Num mundo onde cada vez mais se discute a questão do software livre, novos modelos de negócio, sistemas multiplataformas, fim de monopólios, esse tipo de comportamento se coloca justamente na contra mão  de toda uma realidade atual. A questão que mais me choca é, estes fabricantes, quando perguntados porque dessa postura nada respondem ou são extremamente evasivos.

Exemplos não faltam e justificava para que não façam também. Posso citar um caso de empresa onde trabalho. Lá temos um fornecedor de PLCs. Gastamos bilhões (isso mesmo) anuais em compra deste equipamentos. Porém, para podermos trabalhar com eles (conectar, alterar o programa ladder, ver estado de bits, etc) temos que ainda pagar milhares (cada licença custa em média mil dólares) por sistemas. Ou seja, a empresa ganha dinheiro com tudo. Além disso, caso queira fazer um sistema seu para fazer oque as ferramentas deles fazem, não tem como pois usam de protocolos proprietários e cada  especificação chega a custar muitas centenas de milhares de dinheiro.

Outro exemplo é o nojento do AutoCad. Hoje todos os desenhos de engenharia são feitos nele (em alguns casos muito especificos usamos outros aplicativos). Ele só tem versão para Windows e cada licença custa uma verdadeira fortuna. A diferença do caso anterior é que pelo menos existem outras opções.

Enfim, quando todos caminham para se libertar de SOs e de modelos retrogrados de licença tipo caixinha, o pessoal da engenharia continua nos tempos da caverna achando que são vanguardistas usando telas coloridas para seus sistemas.

A pouco empo atrás um colega me perguntou como ele poderia fazer para verificar se um dado arquivo texto era igual a outro.  A primeira resposta que me veio a cabeça foi de fazer um programa que comparasse linha a linha. A segunda solução ( esta não foi uma ideia minha) era de utilizar a assinatura MD5 de cada arquivo e comparar.  As duas soluções o atenderiam perfeitamente, onde a primeira iria precisar de um certo desenvolvimento e a segunda, ele poderia usar o md5sum e/ou outros softwares já existentes.

A questão que me surgiu, e uma ideia para uma ferramenta, era o que aconteceria se os dois arquivos tivessem os mesmos dados (textos por exemplo) porém um tivesse uma linha em branco a mais ou se num deles faltasse uma linha ? Possivelmente  a verificação com os métodos acima falharia (apesar de achar que o md5 ignora espaços em branco, imagina se colocasse um comentário a mais). Não seria interessante uma ferramenta que dissesse o quanto dois arquivos são semelhantes? Algo do tipo : “O arquivos A e B possuem 80% de similaridade”

Mas como seria possível fazer isso?

Bem, para aqueles que lêem este blog a um certo tempo (caso não seja seu caso dá uma olhada nos post antigos), sabe que tenho lido e estudo muito a questão de algoritmos de inteligência artificial para processamento de conhecimento coletivo. Num dos livros do assunto, “Programando Inteligência Coletiva” do Toby Segaran, logo nos primeiros capítulos ele ensina algumas técnica para que construa algoritmos de agrupamento de blogs, por exemplo. Tais algoritmos verificam o grau de similaridade das fontes e os agrega por proximidade.

Diante disso, se funciona para Blogs, logo isso funciona também para arquivos, ainda mais arquivos textos ou rtf (doc, odt, etc). Por isso penso, usando as dicas do livro, fazer uma ferramenta que lerá os arquivos e diagnosticará o grau de semelhança.

Prometo que assim que tiver algo coloco no github para a galera mexer, contribuir e usar. Aguardem.

Recentemente li um artigo do Martin Fowler (já tinha lido, mas praticamente o reli com outros olhos)  onde ele discute a questão do design e da análise dentro do mundo ágil, mais precisamente o XP (Extreme Programming).  No artigo, cujo título é “Is Design Dead?”, Fowler discorre sobre vários tópicos e tenta ver se é realmente um fato que com a adoção de  metodologias ágeis, o uso de padrões, análise prévias e design se tornaram práticas mortas

Dentro do times ágeis, existem diversas premissas que devem ser adotadas para que se possa colher todas as vantagens que ele oferece.  Algumas das mais famosas são:

• Faça o justo necessário:  não faça aquém nem além do que deve ser feito na iteração
• Refatoração : sempre que puder melhore o código
• Foco nas tarefas que agregam valor na visão do cliente
• Fazer o simples e depois evoluir o código de acordo com a necessidade.

Fazer o justo necessário é de focar em gerar valor para o cliente. Aqui a principal mensagem está em evitar tarefas que no final não geram retorno. Exemplo: o tme que gasta horas para criar um modelo de dados;  times que gastam considerável soma de tempo para escrever  bibliotecas para fazer algo que não esteja ligada a funcionalidade que o cliente deseja  naquela iteração (api de log, api de para ler o xml de configuração, api para tratar string, etc). Nesta ideia também se encaixa a questão de evitar tarefas que não agregam valor para o produto.

A Refatoração constante do código significa mais que simplesmente rescrever trechos de código e sim, uma busca constante por simplicidade, qualidade e por programas legíveis. Uma coisa que os mais novos sempre erram é de ter uma visão simplória do que venha ser Refatorar : não é simplesmente acerto de escopo de variável,  comentar, etc.  Refatorar, em XP principalmente é “alma do negócio”.

Quando se diz – ” Fazer o simples e evoluir“, você está comunicando ao seu time que é desejável que façam coisas simples. A medida da necessidade do projeto, os modelos, arquiteturas, etc., vão evoluindo e ganhando os recursos necessários para resolver os problemas.  Dentro da refatoração existirá, também, o espaço necessário para a melhora.

Fazer ou não fazer análise em projetos ágeis ?

Diante do que disse antes, principalmente de evitar atividades que não agreguem valor, os mais puristas, diriam que fazer analise ( estudo, diagramas, etc para entender a arquitetura e quais seriam os requisitos técnicos)  é algo que não deve ser feito. Iriam além estes mesmo: afirmaria que tal prática é ultrapassada e que de nada server.

Bom, eu discordo. E se me perguntassem isso, responderia:  - “Depende ! “

Se estamos falando de um sistema simples, cujos os requisitos são extremamente claros,  fazer analise pode ser um passo a mais que poderia ser retirado. Ou então, considerado como um história de documentação que deve ser tratado no backlog ( mas com baixa prioridade de acordo com a visão do cliente). Porém se estamos falando de sistemas cujo o processo a ser gerido é complicado  e/ou com regras de negócios complexas, uma fase, por menos que seja, de análise ajudaria até melhor entender os requisitos. O problema está que muitas equipes de desenvolvimento tornam o resultado de uma analise uma verdade absoluta e imutável.  Bem, isso não pode ser verdade pois o cliente vária vezes nem ter certeza do que quer e ao longo das entregas que começa a desenhar melhor sua necessidade e desejo.

Analisar previamente ajuda a diminuir riscos e a nortear, de certo modo, a visão do time na hora de implementar.

Entretanto, ao realizar uma analise, podemos pensar como um rascunho do Niemeyer de um prédio novo. Serve apenas para ter um impressão inicial não muito clara do que iremos realizar.

Quem usa XP não adota padrões?  Não define arquitetura?

Esta aí outra coisa que não gosto e nem concordo em ouvir.  Bem, os padrões não são ruins, são as pessoas que abusam do direito de usá-los.  Já vi gente fazendo um site para 10 pessoas (coisa interna de uma empresa) cujo o escopo é limitado e quase nunca evolui, colocando milhões de camadas, milhares de DAOs, VOs, etc.

Muitos poderiam dizer, principalmente os defensores mais ferrenhos, que devem sempre fazer as coisas simples.  Minha resposta : no final, caso faça algo descendente, é bem possível que “esbarre” num padrão.

Outra coisa que não concordo é a questão de não se discutir arquitetura… Para um projeto pequeno, você pode se dar ao luxo de não pensar nisso, pelo menos, num primeiro momento, mas para projetos grandes, tem que pensar nos componentes pois isso influirá diretamente na forma que time irá implementar as coisas. Novamente reforço que, quando sugiro usar padrões, não é pegar o livro e fazer tudo que está dizendo ali. Nada nos impede de adaptar a sugestão para nossa realidade.

Rebeldia  e revolução a parte, sempre vou dizer que o melhor caminha continua sendo o do meio. Ficar com o melhor de todos os mundos é o paraíso a ser desejado.

Confesso que não aguento mais, todas a vezes que me reuno com alguns amigos, participar daquelas discussões onde todos falam que tal linguagem é mal, outra boa, tal linguagem é melhor e outra pior. Isso só piora quando resolvem falar do Java. Parece que o salvador da pátria, até pouco tempo atrás, virou o vilão da história.

Me lembro bem que a quase 10 anos atrás, em quase toda empresa que ia, e propunha de fazer algo em Java, era como se tivesse cometido uma heresia. Ninguém aceitava.  Todos eram enfáticos em afirmar que  a linguagem era lenta, pesada demais,  pouco perfomante, e por ai seguiam.  Todos olhavam para o Java e acreditavam que iria morrer logo, pois não tinha como compertir com o Delphi (que dispontava na época), muito menos com o C++. Java estava quase que restrito aos ambientes acadêmicos, ou então, para aquelas empresas que se colocavam como vanguardistas da época.  Eu sou um bom exemplo disso:  meus primeiros contatos como desenvolvedor java foram para projetos acadêmicos.

Eis que então a tal da internet começou a avançar as passos largos, e o que era até então,  uma coisa timida em seu uso, foi tomando corpo.  No começo, ainda me lembro, daqueles sites “toscos”, todos em HTML, não havia nada dinâmico.  O pessoal usava o padrão cgi e codificava em C para tratar os dados que eram preenchidos nos formulários. Javascript, até onde me lembre, não tinha nada.  webmails, eram raros, maioria das coisa eram por meio de programas clientes (quem não lembra daquelas rotinas onde conectavamos, baixavamos os emails e depois lia e respondia. Ao terminar de responder, conectava novamente e enviava e sincronizava novamente).

Portal da UOL em 1996

Bem até que o pessoal da Java, fez os applets. Elas foram, na minha opinião, as verdadeiras responsáveis pelo sucesso que a linguagem tem hoje.  Graças aos applets que Java teve alguma projeção no mercado e seu crescimento não parou mais.  Tal crescimento se deve não somente pelas applets mas  por que eles nunca se contentaram em ser “cantores de uma só canção“. A equipe da Sun investiu pesado em recurso que fizessem do Java cada vez mais a melhor opção para desenvolver sistemas distribuidos, cliente-servidor.

Bom, mas porque escrevi tudo isso? Para mostrar que: primeiro que Java já foi uma tão inovadora e revolucionária, como as linguagens atuais; Java percorreu um longo caminho para ser oque é hoje;  Assim com hoje para algumas tecnologias emergentes, Java enfrentou preconceitos e barreiras ao seu uso; todos diziam que ela não iria sobreviver ao mundo corporativo e que não escalava, assim como alguns linguagens hoje; etc. Por isso, não sou muito fã de  artigos, discursos, o que mais seja, dizendo que Java é o novo Cobol.  A tecnologia conquistou o seu espaço provando ser util para muitas coisas.

Onde está o problema então? As pessoas que abandonaram o Java ou que não o querem estão malucas?

Bem, claro que não. A reclamação, ou melhor, a observação que os desenvolvedores mais revoluionário e vanguardistas tem feito são válidas.  Porém acredito que, alguma delas, são mal direcionadas. A tecnologia, ou como ela se apresenta hoje, a plataforma Java ela em si não é culpado pelo uso que lhe é dado.  Sendo assim, foram os desenvolvedores que tentaram, e ainda tentam, torná-la a bala de prata.  Que vejo hoje, é que a melhor coisa é entendermos que não precisamos somente usar a mesma “ferramenta” para resolver todos os problemas. Podemos mesclar, e usar o melhor de cada linguagem.  Podemos nos aproveitar de todos poder do Java e Python ou  Ruby, etc.

Java não é ruim.  Java não é o novo Cobol.  A questão que penso é :  Os programadores Java, alguns, querem transformar-se em consultores como era o pessoal de Cobol.  O pessoal que usa a tecnologia que está fazendo que ela seja vista de forma negativa.  São as pessoas que  forçam as situações que vemos hoje no mercado.

Além disso, a minha percepção é completamente diferente da de que Java está se fechando e querendo ser a soluçõa unica.   As informações que leio é de trabalhos por parte da Sun de fazer com que sua JVM seja poliglota, ou seja,  seja capaz de trabalhar com diversas linguagens que não somente Java.  A prova e/ou reflexo disso é o JRuby, Groovy, Jython,  Scala , Clojures, etc.

Uma outra coisa é que essas mesmas pessoas que criticam Java, podem num futuro próximo, com uma nova tecnologia ter a mesmo comportamento que criticam hoje: de achar que só a tecnologia que dominam é capaz de resolver todos os problemas.

Para finalizar, Java é bom, desde que saiba usá-lo.  E hoje mais vale ser um programador que conhece diversas tecnologias pois assim poderá escolher a melhor para resolver seu problema.