Para quem já programou em C, ou mesmo C++, e em uma linguagem de alto nível tais quais C#, Haskell ou LISP sabe o tamanho do sofrimento que é trabalhar com uma ferramenta tão primitiva. Aos incautos não estou me referindo nem me referindo as vantagens óbvias dessas linguagens como gerenciamento automático de lixo, um sistema de tipos rico ou tipagem ou dinâmica[1].

Quando se programa próximo do metal ter um controle e visão muito clara daquilo que é gerado é muito importante, então coisas como verificações inseridas pelo compilador, não ter controle fino sobre a representação dos dados ou simplesmente não podem burlar o sistema de tipos inviabilizam o uso de uma linguagem – por mais estranho que pareça.

Entretanto usar destes argumentos para defender as relíquias que são C e C++ é temerário. Ambas linguagens foram construídas sob as bases do que era avançado em termos de compiladores nos anos 70 e para a capacidade de processamos do começo dos anos 90. Muita coisa mudou de lá para cá, menos o fato de C++ demorar horrores para compilar.

A primeira grande falha do C, e uma que chama muito a atenção, é o sistema de módulos e compilação separada. Que realmente não existe. Em ambas as linguagens se usa inclusão textual de cabeçalhos com declarações supostamente exportadas por outros módulos do sistema e pronto. O problema disso é óbvio se já tiver trabalhado em projetos grandes. O tempo de compilação individual aumenta sem razão aparente, conflitos com o nome de símbolos ocorrem e, em geral, atrapalham a vida de todos.

Continuando com a questão de processamento de texto. Macros em C provavelmente são o recurso mais importante da linguagem, aquele que a tira da lista de inúteis. É bem freqüente encontrar uma infinidade de truques feitos usando macros para sanar a falta de expressividade da linguagem. Porém tão comum quanto é encontrar gente frustada com a dificuldade de depurar um sistema rico em macros. Ao mesmo tempo, programando um dia com LISP qualquer um enxerga que um grande sistema de macros faz qualquer linguagem medíocre ir muito longe.

Por fim, minha última reclamação é devido ao fato de estar em 2009 e ainda ser obrigado a usar uma linguagem sem inferência de tipos. O artigo do Robin Milner tem quase 31 anos e ainda assim sou obrigado a pagear o compilador com aquilo que ele consegue descobrir sozinho. Inferência de tipos é um recurso ainda mais importante quando falamos de sistemas de tipos mais ricos.

Ainda assim, por algum motivo que me escapa, não existe um substituto usável para C ou C++. Talvez seja pelo fato de tal linguagem não possuir muito acadêmico em termos de papers e PHDs, ou que a enorme parte da comunidade de programadores destas linguagens é cega por achar que são o último biscoito do pacote.

[1]Ou latente, caso tenha um fetiche pelo Fowler.

Os irresponsáveis pelo sistema permitem consultar os dados de um chamado sem qualquer forma de autenticação. Basta acessar essa url e trocar o ZZZ pelo número do chamado. Fosse apenas esse o problema não estaria eu tão assustado, porém se olharmos com cuidado para o problema vamos notar uma série de agravantes.

A página inclui uma enorme quantidade de dados pessoais do usuário, desde endereço a telefone e CPF. Estes são dados mais que suficientes para realizar vários tipos de fraudes. Fosse apenas este o problema não estaria tão assustado, pois seria necessário saber o código da solicitação para ler tais informações.

Vamos então verificar a segurança do código do chamado. Abra dois chamados, um em seguida do outro, e note que se trata de um número seqüencial pequeno sem qualquer forma de verificação ou randomização. Ou seja, é trivial coletar todos chamados com ferramentas simples disponível em qualquer computador pessoal.

Finalmente vem a cartada final, reparem nos dados exibidos na página, eles incluem email e cpf. Até ai tudo bem, até você ir para a página de login do sistema e descobrir que para entrar você deve informar, acredite, seu email e cpf. Ou seja, temos como fazer não só harvesting de dados dos usuários, mas de suas senhas também.

Segurança como essa é inadmissivel para um órgão governamental. Isso é ridículo, é um afronte a nossa privacidade. Os amadores que fizeram esse sistema ignoraram todas regras básicas de segurança que qualquer desenvolvedor safo tem a obrigação de saber. Anatel, corrija isso com urgência e tome as devidas medidas administrativas para esse tipo de desastre não ocorra novamente. Por favor, a todos que lerem este texto, liguem já para a Anatel no 0800 33 2001, registrem uma reclamação formal e divulguem esse problema para o quanto antes ser solucionado.

Basta um pouco de matemática para provar que não é cavando túneis que vamos reduzir o caos do transporte. Vamos pegar o caso de uma cidade com um transporte considerado referencia global. Londres possui 408km de metro para 7,5 milhões de habitantes, ou um quilômetro para cada 18,3mil pessoas. Enquanto isso na região metropolitana de São Paulo sobrevivem 19,2 milhões de pessoa com 68km de metro e 257km de trem, ou seja, 282,3mil se debatendo por quilômetro de metro ou 59mil se espremendo no transporte metroviário da cidade.

Fazendo uma simples regra de três, a cidade precisa de mais 720km de trilhos para ter o mesmo nível de conforto de Londres. Pronto, resolvido, só construir agora. Porém as pessoas esquecem que dois detalhes, custo e prazos. Primeiro aos custos, a linha 4 foi orçada originalmente em 1,25 bilhões de dólares e tem uma extensão de quase 13km, o que significa 155 milhões de reais por quilômetro. Por esse parâmetro, São Paulo precisa de aproximadamente 112 bilhões em investimentos, ou sete vezes mais que os 15,8 destinados a todos programas do PAC para o ano de 2008. Mas vamos esquecer isso, pois dinheiro não é o problema. Sério.

O ponto importante é o tempo de construção. No atual ritmo de quatro quilômetros ao ano as obras ficariam prontas somente em 2188. Mas as coisas vão melhorar e vamos andar na mesma velocidade frenética da construção do metrô chines em Pequim, que é cinco vezes mais rápida. Ainda assim, as obras seriam entregues em 2044, daqui 36 anos.

Ouviram bem, serão trinta e seis anos de espera se, por milagre, passarmos a construir na velocidade maluca dos chineses. Vejamos, daqui todo esse tempo eu vou ter 62 anos e a todos dos leitores desse blog terão bem mais de cinqüenta. Ou seja, vamos estar na terceira idade, próximo de nos aposentarmos. Porém se o ritmo das obras se mantiver, talvez nossos bisnetos assistam a conclusão perto do final de suas vidas.

Eu não quero esperar até minha aposentadoria para ter um transporte urbano que preste na minha cidade. Não podemos esperar mais de três décadas, precisamos disso o mais rápido possível. Precisamos para ontem, não podemos que cada um jogo fora centenas de horas parado em engarrafamentos todo ano.

Dito isso, o quanto a tecnologia mudou nossas vidas nos últimos dez anos? Em especial, vamos refletir na questão organizacional das nossas vidas. Hoje é muito fácil via celular e internet organizar reuniões e grupos – basta um tweet “vamos beber” que em uma horas estão todos no bar certo. Hoje é muito fácil centralizar, catalogar, manipular e consultar informação pertinente a milhões de pessoas em tempo real – basta pensar em coisas como redes sociais, rss e sites de busca. Por fim, hoje a informação possui uma tremenda mobilidade, um celular moderno tem localização via GPS e até 1mb de largura de banda com a internet.

Agora vamos pensar em como opera o transporte público hoje. Temos linhas de ônibus fixas e definidas por engenheiros de tráfego baseados em pesquisar de origem e destino. Nós temos rotas estáticas de transporte, você conseguiria imaginar a internet sem roteamento dinâmico de pacotes? Nós temos rotas otimizadas segundo critérios antigos – o que seria do Google se a busca fosse baseada no conteúdo de um anos atrás apenas? Nós temos itinerários e linhas que não são adaptadas as necessidades dos usuários no momento que usam – imagine usar um navegador com 30 minutos de atraso.

Nosso sistema de transporte não deve ser modernizado, precisa ser recriado, repensado e quebrar todas barreiras convencionais. Porque você precisa pegar um ônibus que passa em lugares e horários pré-definidos? Imagine se bastasse do seu celular informar seu destino que um sistema ajustaria a rota de um veículo para melhor servir você e otimizar o uso das nossas vias? Algo quase como um taxi coletivo a custos de um convencional. Hoje temos todas as peças do quebra cabeça tecnológico para viabilizar isso.

Basta começar a pensar no assunto para centenas de idéias surgirem, a maioria delas muito melhor que as minhas. Basta pensar em um modelo de transporte que seja tão ágil quanto nossa vida moderna é, ou deveria ser.

Minha contribuição, entretanto, não é a sugestão tecnológica. O transporte de São Paulo é um mercado de 8 bilhões de reais ao ano, pelo menos. Muita grana não? Porém existe uma reserva de mercado para novas empresas entrarem e na forma de atuação delas, além de um cartel de empresas controlando o serviço hoje. Todos sabemos dos prejuízos que tais reservas causam ao interesse público, por isso a única solução é abrir o setor ao mercado como um todo e permitir que as empresas decidam como operar modal que irão oferecer. O resto deixem por conta da iniciativa privada, que é mister sua capacidade de inovação em face a livre concorrência.

Todo paulistano tem a obrigação de aproveitar que estamos em ano eleitoral, discutir o assunto, questionar seu candidato e tomar uma decisão informada em novembro. Não vamos mais uma vez deixar políticos nos enganarem com suas promessas vazias. Vamos dessa vez mostrar que não temos sangue de barata e mostrar exatamente aquilo que queremos. Eu estou aqui fazendo a minha, agora você Paulistano vá fazer a sua!

Porém, recentemente notei que existe algo que ao qual ainda não entendo bem, mas tudo indica que os símios dessa nação são ineptos à civilidade e ao respeito ao próximo. Nascer brasileiro significa ser incapaz de viver em comunidade, significa que dar um jeitinho é mais importante que respeitar a lei, a ordem e a decência. Como pode uma pessoa que não entende que vivem em sociedade significa necessariamente ter um apresso aos outros e aceitar que sua vontade não pode se sobrepor aos direitos dos demais.

Minha saga de vítima começou a alguns meses, quando decidi que já era em tempo para exigir meus direitos dos outros. Nada espúrio, apenas o mínimo que qualquer pessoa dotada de suas faculdades mentais diria se tratar de obviedades.

Resolvi começar pela lei 9294 de 1996 que limita os lugares no qual é permitido fumar. Quem me conhece sabe que não fumo e a fumaça me é terrivelmente incômoda. Comecei por lembrar as pessoas da lei quando se tratava de um lugar proibido. Resultado, fui na maioria das fezes muito hostilizados pelos fumantes perto de mim, mesmo de estranhos que ouviram a conversa de longe vieram se intrometer para serem rudes e grosseiros comigo.

Não perdoei nem meus amigos, eles sabem quanto os perturbei. Mas eles, ao menos, se tomaram pela vergonha do desrespeito ao próximo e costumam fumar do lado de fora de restaurantes sem área para fumante. Poderia eu dizer vitória?

Minha segunda tentativa de exigir meus direitos foi o novo código brasileiro de trânsito. Este que regulamenta o uso de bicicletas na rua e ciclovias. Desta vez eu queria apenas poder andar em paz nas ruas de São Paulo e contar que o motoristas iriam ao menos me respeitar e não me matar. Não quis nem exigir o meu direito de ciclista de ter a preferencial sobre carros pois não sou muito fã de ossos quebrados.

Antes de continuar, vou aproveitar para transmitir um pouco de conhecimento. Saibam todos que uma ciclovia existe para o trânsito de bicicletas, ouviram bem? De novo, bicicletas! Bicicletas! Uma ciclovia cuja finalidade não é se deslocar dentro da cidade também admite outros modais como patins ou crianças aprendendo. Mais uma vez eu estou falando do óbvio ao que tudo parece. Mas não, definitivamente isso é muito longe da realidade de muitos freqüentadores de parques da minha cidade.

Hoje não fui eu a vítima do desrespeito, mas sim minha esposa. Estamos a andar no parque do Ibirapuera quando uma mulher resolveu usar a ciclovia toda para passear com o cachorrinho dela. Eu consegui frear, minha mulher passou 6 horas no hospital e terminou com um braço engessado. Tudo isso por conta de gente que é incapaz de respeitar o direito alheio. Esta mulher não se prestou ao menos a ver o que aconteceu com minha mulher, simplesmente virou as costas nos xingando pois quase acertamos o bichinho dela – na ciclovia caso tenha esquecidos.

Decidi então que é hora de tomar uma atitude e educar freqüentadores do parque que não respeitam a ciclovia. A partir de hoje, caso o seu cachorro se encontrar na ciclovia e não for capaz de me matar, ele será atropelado. Se possível espero também deslocar o ombro do lado que estiver segurando a coleira. Dito isso, preciso ir pois tenho sangue futuro a limpar da minha bicicleta.

Quem nunca passou horas atoa esperando até um operador te atender? Bom, eu já e não gosto nenhum pouco, ao ponto que definitivamente pagaria por um serviço que me entregasse direto uma ligação com um operador. Acho apenas curioso como pode um negócio existir meramente devido ao descaso e incompetência de outras empresas ao atender seus clientes.

A regra de escopo que torna classloading um enorme inferno, principalmente pela sutileza que acontece e te morde. De acordo com o Daniel, o classloader acionado não é necessariamente aquele que resolve o tipo, isso acontece devido a delegação. O mecanismo de delegação funciona muito bem quando somente um classloader da hierarquia é capaz de carregar uma dada classe e não existe dependências entre classes no sentido inverso da hierarquia existente entre eles.

Explicando melhor esses dois pontos; primeiro, somente um classloader da hierarquia deve ser capaz de carregar uma dada classe, isso se faz necessário senão acabamos com problemas de esquizofrenia de tipos, quando uma classe é carregada por dois classloaders e passa a existir como dois tipos distintos e gera vários ClassCastException sem razão aparente.

Por exemplo, dado o código a seguir e a existência de dois classloaders: João e José. Imaginemos a situação na qual a tanto José quanto João carregam a classe Exemplo, cada um definindo um tipo. Vamos supor agora que a aplicação chame novaCoisa de uma instância de Exemplo criada a partir do tipo definido pelo classloader João e passe como parâmetro de uma chamada a fazCoisa de uma instância vinda de José. Por mais curioso que seja, o resultado vai ser um ClassCastException e “nome da classe: Exemplo” escrito no console. Legal, não?


class Exemplo{
public void fazCoisa(Object obj) {
System.out.println("nome da classe: "+obj.getClass());
Exemplo ex= (Exemplo)obj;
ex.toString();
}

public Object novaCoisa() {
return new Exemplo();
}
}


O problema anterior é causado por falta de isolamento, objetos de classloaders no mesmo nível hierárquico jamaisdevem se comunicar, a aplicação deve garantir essa separação. Caso seja realmente necessária esta comunicação, ela deve ser feita via call-by-value, ou seja, serializando os objetos nas bordas.

O outro problema é o do espelho de duas direções, no qual uma classe enxerga a outra mas a recíproca é falsa. Isso ocorre quando uma classe carregada por um classloader mais próximo da raiz depende de uma classe que pode ser carregada apenas por um classloader mais distante. Como exemplo, dada as classes a seguir e dois classloader, Pai e Filho, vamos ver como isso acontece:


class VimDoPai {
public void print() {
System.out.println(new VimDoFilho());
}
}

class VimDoFilho {
public void print() {
System.out.println(new VimDoPai());
}
}


Vamos supor que o classloader Filho delega para Pai a carga de classes. Supondo que Filho carregue a classe VimDoFilho e Pai carregue VimDoPai, quando VimDoFilho.print() for chamado, o classloader Filho delega para Pai e consegue uma referencia para a classe VimDoPai, porém quando VimDoPai.print() é chamado, o classloader Pai não encontrará a classe VimDoFilho e um ClassNotFoundError irá acontecer.

No exemplo anterior podemos notar o motivo pelo quando o escopo do classloading é um problema difícil de decifrar. Quando uma classe é carregada por um dado classloader, todas suas dependências serão resolvidas através dele. Tratá-se de uma imposição draconiana, pois abre espaço para uma enorme gama de problemas, como o visto anteriormente. Mais grave é o fato de acabarmos com um sistema no qual objetos que interagem entre sí possuem visões divergentes dos tipos existentes. Infelizmente esta é uma limitação necessária para criar um sistema de tipos sonoro e seguro.

Classloading é um mecanismo muito interessante do Java, pois permite criar coisas fabulosas como o container OSGi, porém não deixa de ser a parte mais dolorosa da plataforma quando ocorrem problemas. Java não possui suporte a realmente isolar um classloader de outro, como outras plataformas possuem, e quando precisamos violar o mecanismo de delegação uma enorme quantidade de problemas podem acontecer.

Os preços são estúpidamente caros para ligações internacionais, as tarifas chegam a ser 4x mais caras que do skype! Para ligações nacionais e locais é melhor que as teles tradicionais, só que isso é o mínimo a se esperar de uma solução voip!

A qualidade da ligação ocila com frenqüência e o serviço fica fora do ar mais vezes que a internet, além disso espere um modem que trava 2x por semana. No geral é melhor que um telefone tradicional, não que isso seja um grande diferencial.

Guardei para o final a melhor parte: o sistema de billing da embratel! O pessoal é tão incompente que me cobraram as mesmas ligações nas contas de janeiro, fevereiro e março! Segundo a atendente deles, isso está acontecendo muito – o que está longe de ser confortante. Os caras colocaram dois estágiarios deficientes para desenvolver toda parte de billing e esperam que os clientes sejam compreensivos o suficiente.

Minha percepção do produto e veredito final é se tratar tão somente de um substituto do telefone fixo caso você faça apenas ligações para celular dele e pretende usar algo como o skype para as ligações caras. Não que faça algum sentido isso, mas com preços não competitivos, qualidade mediana e um back-office medíocre, não posso senão recomendar que todos fujam desse produto.

Senso comum é um ótimo exemplo de aversão a mudanças. Ele surge porque alguém disse que viu outros fazendo e pareceu legal. Só ver que assim que se fala em usar EJB a maioria já pensa nos DTOs que vão precisar escrever, ou melhor, VOs, para sermos fieis às origens.

Alguém já usou, já fez, já falou do assunto. Muito já ouviram e repetiram. Pronto, já virou senso comum. A partir desse ponto não fazer assim é querer mudar as regras do jogo e para isso precisamos pensar, propor, discutir e confrontar os demais. Para isso acontecer é preciso estar armado de argumentos, razões e motivos, ter uma boa dose de coragem para tirar todos da zona de conforto de uma coisa já formulada e pensada por outros.
O senso comum é nada mais que uma manifestação de um problema ainda maior, o medo que mudanças e suas incertezas carregam. Podem ver, existe muita gente que adora de escorar nisso para justificar ações e medidas descabidas. Inércia de questionamento causa isso, você não se pergunta o por que de algo acontecer por tempo suficiente até assumir que se trata de uma verdade, o famoso concenso por omissão.

Garantir que esse feedback ocorra, e em tempo habil para ser útil, é obrigação do lider do projeto, que deve criar o espaço e habito entre os demais. Tem formas razoaveis de fazer isso, como, por exemplo, instituir semanlmente um code-review das classes que aparecerem mais feias em um relatório de métricas ou pedir que uma pessoa mande o trecho de código mais cabeludo do atual projeto dela para ser sabatinado.

O mais importante nisso tudo é evitar que se crie uma bola de neve de desenvolvedor inexperiente criar aquela obra de arte impossivel de se manter e que é rotulada de legado antes mesmo de ir para o ar.

Espero então que esse post sirva pelo menos para todas as vítimas de programadores júnior – aquelas que tiveram que se aventurar em códigos por eles escritos – entenderem que tem de dividir a culpa.