Viagens, opiniões e afins

Esse é daqueles posts que escrevo para não esquecer algumas coisas.  Nessa semana precisei colocar um job no cron do meu sistema para que ele apagasse todos os arquivos que foram criados a mais de X minutos. Esse job deveria rodar de 10 em 10 minutos.  A linha ficou assim:

Essa linha pega todos os arquivos dentro de uma pasta e joga seus nomes numa lista. Essa lista é lida no loop e o comando de remove é feito.  Uma coisa interessante nessa lista é que só pega arquivos regulares, tudo isso graças a opção -type f. Você pode ver mais  opções digitando

Outro detalhe legal dessa linha é como você define o intervalo de tempo para execução de algo no cron. No cron, funciona da seguinte forma: A B C D E onde cada um é:

• A – o minuto no qual quer que seu job execute. Ex: 0 ou 30
• B – hora
• C – dia
• D – mes
• E – ano

Se caso queira fazer algo como intervalo de tempo (quero que algo rode a cada 10 minutos) você pode usar */10(intervalo de tempo).

Existe ainda a opção de usar alias especiais do tipo @daily. Para mais informação, peça ajuda ao google ou ao man na sua linha de comando.

Uma última coisa é que estou jogando a saída da execução para o dev/null (para o limbo – lugar nenhum). Assim eu não fico com alertas e saidas indesejadas.

Se você é um leitor assíduo do meu blog, já deve ter percebido o quanto gosto de testes automatizados. Não só gosto como acredito neles e no retorno que eles proporcionam. Sempre que tenho a oportunidade procuro “vender esse peixe”. O interessante é que com isso acabei escutando alguns exageros que chegam a ser engraçados.  Um exemplo foi após uma conversa em que até rolou uma  sessão de codificação em par com a pessoa, no final, ela soltou a seguinte pérola :”Agora então não preciso mais do pessoal de teste“.  Opa! Devagar com o andor que o santo é de barro, meu amigo.

Antes que concorde com isso,  deixa eu mostra meu ponto de vista.  Teste automatizados ajudam muito e realmente tornam a vida do desenvolvedor e do cliente melhores.  Torna a vida do desenvolvedor mais fácil quando permite que ele faça seus testes rapidamente e detecte um erro o mais cedo o possível.  Para o cliente significa que a automação mais testes podem ser executados num tempo menor e com isso mais qualidade com menor custo.  Mas e a história do cara de teste, onde entra? Calma.  Para automatizar os testes devemos fazer algumas considerações e escolhas.  Para facilitar o que quero ilustrar, imagine um portal. Portais são aplicações webs muito interessantes, pois a cada acesso o seu comportamento pode mudar e isso não é necessariamente um erro.  Por isso, testes automatizados, em ambientes como estes são bem complicados de serem feitos e levam a gente a fazer algumas “adaptações”. Com isso,  os teste acabam validando parte das coisas e logo, ainda temos a necessidade de uma pessoa testando.  Entretanto, agora, essa pessoa não precisa estar testando tudo e qualquer coisa. Ele pode focar um pouco mais, realizando apenas verificações pontuais.

Outra frase que sempre escuto é a questão do recurso e gastos.  Geralmente quando converso com os gerentes sobre testes – principalmente os ditos PMI – eles quase que instantaneamente dizem que isto é inviável e trabalhoso. Bom, primeiro devemos definir o contexto:  se imaginarmos os famosos “cowboys“, rapaziada que desenvolve a culhão e não teste se o objeto que eles estão pegando é nulo, realmente testes automatizados são trabalhosos, pois não fazem nenhum.  Para aqueles que pretendem o mínimo de qualidade, dá para dizer que, realmente, NO INÍCIO,  testes automatizados demandam mais tempos, mais se olharmos ao longo da linha tempo esse custo se dilui e tende a zero. Isso porque, após todos os casos criados, o trabalho será de executá-los e mantê-los atualizados.  Fora que, imagine o custo de pessoas, máquinas, tempo,  para que a cada alteração que um desenvolvedor fizesse na aplicação, toda ela fosse retestada.

Enfim,  caso ainda não acredite em mim quando digo que ferramentas de testes são legais e estão aí para nos ajudar,  experimente e tire suas próprias conclusões. Duvido, sendo você empresário, gerente pmi, coordenador, desenvolvedor, cliente, etc no final não ficará pelo menos tentado a usar algum no seu próximo projeto.

Uma das coisa que me incomondam bastante é toda vez que vou iniciar um projeto, e tenho que montar um ambiente de desenvolvimento, perco horas e mais horas para completar a tarefa. Tudo porque, na maioria das empresas para as quais trabalhei, trabalho e trabalharei,  nunca tem um processo automatizado e padronizado de montagem de ambiente.  Sei que isso pode soar um tanto burocrático e o pessoal que odeia qualquer coisa que possa virar papel vai dizer que isso é uma heresia, mas acredito que é um mal necessário.
Para a grande parte das pessoas que começam numa nova empresa, projeto, etc, a rotina sempre a mesma :  horas baixando instaladores,  horas instalando tudo (pior se for em windows, pois as vezes tem que dar reboot na máquina), mais um monte de outras horas para configurar, criar usuários, baixar código, entender como funciona o build, e por aí se vão dias de trabalho gerando zero de valor agregado para o cliente.  O mais esquisito, que mesmo sendo isso um mega prejuízo para o projeto – uma pessoa consumindo horas do projeto sem fazer “nada” , não existe nenhum movimento para mudar essa realidade.
Não estou falando de processos ultra-automatizados que lê mentes e pelo jeito que você diz bom dia monta a sua máquina,  estou falando de coisas simples, como padronizar, repositórios internos de instalações e bibliotecas, uso de produtos que automatizem build e tarefas repetitivas, etc.  Estou falando também de, no caso de empresa maiores,  uma imagem de ambiente (backup) padronizada para que quando um novo desenvolvedor chegue, basta comprar um novo computador, baixar a imagem e configurar.
Não faltam ferramentas, produtos e soluções no mercado que podem ajudar a qualquer um a resolver isso. Em aplicações java, temos o maven (maven.apache.org) que pode cobrir muito bem quase toda o problema:  ele pode montar o projeto, instalá-lo, baixar as bibliotecas, configurar ambiente, compilar e fazer build, etc; além dele existe a opção de escrever em ant (ant.apache.org)  diversos scripts para automatizar build de aplicação, montagem de ambiente, etc. Em Ruby,  aqui não muito minha praia, acredito que existe o gems e o rake que facilitam bem esse trabalho.  Para os passo não cobertos por essas ferramentas, existem outras.  Em última instancia, pode ser colocado como uma história do sprint ( ou uma tarefa de backlog) e assim criar um programa que faça isso (bash, bat, cmd ,etc).
A questão mais importante é que exista algo padronizado e de preferencia automatizado, fazendo que se perca o mínimo de tempo possível com tarefas que não agregam valor ao cliente que está pagando.  A ideia é exatamente de não perder tempo com coisas que não geram retorno: atividades repetitivas, processos  que podem ser automatizados e outras coisas, maximizando o foco na funcionalidade.

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.