Por que ainda não temos um Conselho? (ou “O que é isso, Petrobrás?”)

Seja lá qual profissão você exerça, ela exigiu de você aprendizado para que suas tarefas fossem executadas com o mínimo de qualidade. Não interessa se você está construindo uma ponte ou pendurando um quadro na parede: você aprendeu (ou buscou aprender, ao menos), de diferentes formas, como executar suas tarefas da maneira correta.

Usando o exemplo mais grosseiro, não se dá um bisturi a um açougueiro para que ele corte alguém, sob o argumento de que ele ‘entende’ de corte; ele não foi treinado pra fazer um corte desse tipo em alguém (especialmente alguém vivo), e há normas rígidas que definem quem pode e quem não pode sair por aí cortando gente ao deus-dará. Não importa o quão auto-didata você seja, se você não tiver o aval do conselho de classe adequado (no exemplo, o da Medicina), você não poderá fazê-lo, e será severamente punido se o fizer.

E isso vale para toda e qualquer área profissional que exija um conhecimento técnico específico, tal qual o Direito, a Medicina, a Engenharia, etc, certo?
(…)
ERRADO.

Há tempos a comunidade de desenvolvedores brasileiros discute a necessidade (ou não) da criação de um conselho de classe que englobe os profissionais da área. Programadores, Arquitetos e Engenheiros de Software, Testers, Analistas de Infraestrutura, Administradores de Sistemas, entre outros, devem ou não estar protegidos por uma arredoma legislativa, sendo esta capaz de resguardar direitos econômicos e de mercado, mas que também trouxesse garantia e segurança jurídica a quem os contratasse? Essa já é uma prática comum, e realmente necessária (minha opinião, é claro) quando se quer exigir um mínimo de qualidade dos serviços executados ou produtos entregues ao cliente.
Entretanto, nas discussões fóruns de desenvolvedores, há um sem-número de pessoas contra a criação de um conselho de profissionais de TIC e a devida regulamentação da profissão. “Lavagem cerebral das empresas, só pode, pra evitar a criação de um piso salarial decente”, diz um amigo meu num chat durante o dia. Eu tendo a concordar, já que não acho outra informação plausível.

Veio à tona novamente o assunto esta noite, ao ler, perplexo, o edital do concurso da Petrobrás.

Da área de tecnologia, há três atribuições disponíveis (dos que exigem nível superior), todos com cargo “Analista de Sistemas Jr.”: Engenharia de Softaware, Infraestrutura e Processos de Negócio. As atribuições de cada função podem ser conferidas no Edital, mas todos da área já conhecem exatamente o que cada um desses profissionais faz. O que me deixou realmente de boca aberta foram os requisitos dos três cargos (idênticos):

Certificado de conclusão ou diploma, devidamente registrado, de curso de graduação de nível superior, bacharelado ou licenciatura, em Computação e Informática, Administração, Arquitetura, Arquitetura e Urbanismo, Astronomia, Bioquímica, Ciências Atuariais, Ciências Contábeis, Economia, Engenharia, Estatística, Física, Geofísica, Geologia, Matemática, Meteorologia, Oceanografia, Oceanologia ou Química, reconhecido pelo Ministério da Educação, Secretarias ou Conselhos Estaduais de Educação; ou certificado de conclusão ou diploma, devidamente registrado, de Curso Superior de Tecnologia, com carga horária mínima de 2.000 horas, em Análise e Desenvolvimento de Sistemas, Banco de Dados, Gestão da Tecnologia da Informação, Redes de Computadores, Segurança da Informação ou Sistemas para Internet, reconhecido pelo Ministério da Educação, Secretarias ou Conselhos Estaduais de Educação.

Agora, me diga: que garantia de qualidade ou de conhecimento relacionado à TIC teremos de alguém com formação em Geologia, por exemplo? Não vou aqui entrar no mérito de que ele terá que “provar” conhecimento fazendo a prova (que é de múltipla escolha, então nem prova tanto assim), apenas quero aqui deixar claro que ele não foi treinado para as atividades para o qual será designado, se aprovador for.

Agora, vejamos, com relação ao exemplo da Geologia já citado, como é a descrição do cargo de “Geólogo Jr.”:

Certificado de conclusão ou diploma, devidamente registrado, de curso de graduação de nível superior, bacharelado, em Geologia ou em Engenharia Geológica, reconhecido pelo Ministério da Educação, Secretarias ou Conselhos Estaduais de Educação. Registro no respectivo Conselho de Classe.

Perceberam que a lista de profissionais considerados aptos para a função é bem menor? Pois bem, reparem então na frase grifada acima, para saber onde está a diferença. E o salário, pra quem quiser saber, é igualzinho. Dá uma olhadinha no edital, caso duvide. E há várias outras funções, na mesma condição descrita acima, presentes no edital. Advogados, médicos, psicólogos, engenheiros, e por aí vai.

Mas então, por qual motivo, razão ou circunstância um profissional de TIC não pode exercer a função de Geólogo, se eles podem exercer a função de Analistas de TIC?
SIMPLES, profissionais de TIC não foram treinados para isso, não são aptos e não podem (ao menos tentar) garantir que o farão estará correto. E quer saber? Ainda bem! Se nos forçarmos a executar a todo tempo funções que não nos cabem, teremos em todas as empresas a infeliz práticas de grandes orquestras, que tocam de tudo, mas sem qualidade alguma e sem nenhum solista de qualidade.

Então, antes de sair gritando à cantilena que um conselho e/ou regulamentação só trará prejuízo à classe, veja o que o mercado já está fazendo conosco. Analise quanta falta a regulamentação nos faz, e veja o quanto a criação de um conselho pode ser melhor, não só para nós, profissionais, mas para quem faz uso do que é produto de nosso conhecimento.

Bug Eclipse – Erro ao carregar web.xml

Eis que me deparo com essa mensagem ao fazer o checkout do projeto:

An internal error occurred during: “Loading descriptor for <your_project>”.
org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature ‘tablig-location’ not found.
(platform:/resource/<your_project>/src/main/webapp/WEB-INF/web.xml, <line>, <column>)

“Tudo bem, é só jogar a mensagem no google e vou ter uma solução!”

Eis que vejo isso: https://bugs.eclipse.org/bugs/show_bug.cgi?id=198630

Bug fechado pela própria equipe do Eclipse como “não reproduzível”. Fora, claro, uma série de posts inúteis discutindo se era ou não um bug, se devia ou não ser lançada correção durante aquela major version, ou se deveria aguardar a próxima e de quem era a culpa.

Enfim, eu achei a solução. O problema não é com o arquivo, sequer com o Eclipse propriamente dito: é com o XML Editor. (Léo, você quis dizer o XML Validator) – Não, é o XML Editor mesmo. O validador utiliza a mesma engine do editor para validar o conteúdo. Como há um erro na Engine, ANTES de abrir o arquivo (ao fazer o import, no caso), ele corrompe o arquivo.

A solução é cretinamente simples:

  • Copie o conteúdo do arquivo e salve num novo arquivo, algo como web.txt;
  • Exclua o web.xml;
  • Renomeie o arquivo para web.txt para web.xml.

Sorria e seja feliz.

Duas lições, portanto:

  1.  A solução mais simples nem sempre é deselegante, às vezes ela te atende que é uma beleza e você não deve perder mais tempo procurando pêlo em ovo;
  2.  Quando há um bug, problema, incidente, qualquer coisa: FOCO. Atenda o cliente. O Eclipse é open-source, é uma obrigação inclusive minha, que uso, tentar solucionar o problema; mas serve de lição: discutir sexo dos anjos no bugtracker não vai trazer solução alguma.

Manipulando permissões de arquivos em Java

Manipular arquivos em Java é, em geral, uma tarefa simples (a não ser que você tenha que fazer auto-referências de locais: a API Java até hoje não incluiu um método que permitisse buscar a pasta do próprio arquivo automaticamente). Entretanto, muitas vezes nos deparamos com um entrave até meio óbvio: permissões de arquivos.

Para quem trabalha com Linux, alterar permissão de arquivo é dia-a-dia. No Windows, isso já não é tão comum, quase não se mexe nisso, pois o próprio SO controla isso. Como o assunto aqui não é explicar como funciona permissão de arquivos, eu vou deixar um link que conceitua bem o assunto (com relação ao Linux, que trata esse tema de forma mais completa):

http://www.infowester.com/linuxpermissoes.php

Quando precisamos manipular as permissões dos arquivos pelo Java, o que mais se encontra em sistemas por aí é sua manipulação através da classe Runtime, o que tira da aplicação sua portabilidade, já que a linha de comando executada deverá ser diferente para cada sistema operacional.

Assim, utilizar métodos da classe File é, de longe, o mais indicado. No caso, os métodos setReadable, setWritable e setExecutable. Cada um desses métodos contém duas assinaturas: uma, que recebe apenas um boolean, que representa a permissão em si; e outra, que recebe dois booleans, ou seja, um para a permissão e outro que indica se tal permissão deve ser dada apenas ao dono (owner) do arquivo. O conceito de owner pode ser encontrado no link sobre permissões citado acima.

Como em Java não é possível utilizar parâmetros opcionais, a assinatura que possui apenas um boolean como parâmetro é, na realidade, apenas um método de conveniência para o segundo. Entretanto, quando fazemos métodos de conveniência ocultando booleanos, em geral seu padrão é false. Por algum motivo, neste caso, ele tem como padrão o valor true, o que faz com que, em caso de uso, somente o owner do arquivo receba estas permissões.

Portanto, quando você quiser dar permissão a todos os usuários para alteração, leitura e exclusão de um arquivo, você precisará utilizar a segunda assinatura, com o valor false sendo passado como parâmetro, conforme o exemplo abaixo.

File file = new File("arquivo.txt");
file.setReadable(Boolean.TRUE, Boolean.FALSE);
file.setWritable(Boolean.TRUE, Boolean.FALSE);
file.setExecutable(Boolean.TRUE, Boolean.FALSE);

Claro que o Linux permite maior controle das permissões do que apenas as 6 combinações aqui descritas; mas para a grande maioria dos casos, esses métodos atendem, e sem roubar do sistema sua portabilidade.