Um tempo atrás eu percebi que estava praticamente viciado em checar email. Eu estava programando com o Eclipse aberto ou coisa assim e a cada 2 ou 3 minutos eu abria rapidinho o Firefox e dava uma olhada no Gmail, passava pelo Thunderbird e verificava meu email da universidade, e daí voltava a programar. Na grande maioria das vezes nem tinha email pra mim, e na realidade eu nem tenho certeza de que acontecia alguma mudança de contexto no meu cérebro, já que eu continuava pensando no que estava programando. Era praticamente um reflexo automático e involuntário.

Bom, vicio é uma coisa muito difícil de se contornar. Quando você está realmente viciado, não tem como sair dessa facilmente. Principalmente se você não vê nenhuma conseqüência negativa muito grande no seu vicio. Então eu resolvi que o unico jeito seria gerenciar um pouco o vicio, torná-lo mais leve.

A minha solução foi instalar um daqueles ícones de painel que fica checando email periodicamente e muda de cor quando tem algo na caixa. Dessa forma, ao invés de ter o trabalho de abrir varias janelas, eu só dou uma batida de olho no canto da tela e pronto. Eu sei que isso não resolve meu vicio, mas certamente ameniza.

Eu sou usuário Linux há uns bons 10 anos, então vou falar dos leitores de email que achei interessante nessa plataforma, mas com certeza existem boas opções em Mac ou Windows, já que é um tipo de aplicação bem fácil de fazer (e existem há anos). Eu quase sempre usei KDE, mas depois de sofrer com KDE4 por 1 mês eu resolvi que não aguentava mais e mudei pro Xfce, com o qual estou mais que satisfeito. No painel do xfce, eu instalei o xfce4-mailwatch-plugin. É um plugin beeeem simples, que suporta vários protocolos e te avisa se chegou algum email. Apesar dele também suportar Gmail, eu preferi instalar o checkgmail, que não é especifico de xfce. É um leitor bem legal, que aproveita a API do Gmail pra te deixar ler o começo do email e executar algumas funções básicas, como marcar como lido, deletar, arquivar, etc. É muito bom, pois se eu vejo que o que recebi é lixo, eu simplesmente deleto ali, sem nem ir pro browser.

Bom, tem ainda o vicio do Google Reader que não tem solução simples. Mas pelo menos nesse eu não to tão viciado, já que tem tanta informação que eu reservo um horário do dia pra ler o que apareceu por lá. E em geral não é algo que eu quero saber imediatamente, como os emails.

Eu me considero um macmaníaco, sou fã dos produtos da Apple e de forma geral adoro brinquedinhos tecnológicos. Na lista de gadgets que gostaria de ter um dia, o iPhone ocupa um lugar de destaque. Mas sinceramente, não consigo entender esse pessoal que vira noites e noites em filas monstruosas apenas para estar entre os primeiros a possuir um desses sonhos de consumo.

Primeiro porque tempo é algo precioso. Sabendo a correria que é o dia-a-dia, mesmo tendo flexibilidade de horários, não me passa pela cabeça perder horas valiosas apenas esperando. O máximo que já fiquei numa fila foi 5h, para comprar ingresso do Cirque du Soleil e já foi muito. Aliás, eu até concebo que pessoas fiquem em filas para  shows e eventos, uma vez que os lugares são limitados e muitas vezes é uma chance única de ver sua banda favorita. No caso de produtos eletrônicos, apesar de não serem infinitos, as quantidades são muito maiores.

Mas o que mais me estarrece é ver que as pessoas realmente não aprendem com o passado. Todos repetem os mesmos erros, e ainda por cima reclamam disso. Explico: por mais que empresas tenham processos de qualidade avançadíssimos, os melhores testes são o uso cotidiano por parte do público.

No caso da Apple, é normal que bugs apareçam nas primeiras semanas de uso, patches sejam liberados, novas versões produzidas. Isso aconteceu com os Macs Intel, com o primeiro iPhone e com muitos outros produtos da empresa do tio Jobs. Além do mais, é comúm o reajuste dos preços (geralmente pra baixo) depois de um certo tempo. Quando comprei meu MacBookPro, paguei 1000 reais a menos por uma configuração superior, cerca de 6 meses após o lançamento. Com o iPhone 1, foi assim também.

Mas mesmo assim o filme se repete. Filas gigantescas para adquirir o iPhone, e poucas horas após seu lançamento mundial, as primeiras reclamações já eram publicadas na mídia: processo de ativação lento e/ou inoperante, travamento das funções do celular, etc, etc, etc…

Deve ser fetiche. Só pode ser.

E agora me lembro de duas frases que meu pai adora: “O que é do gosto regala a vida” e “Apressado ou come crú ou queima a língua”.

Eu estava quase passando despercebido por uma notícia da semana retrasada. Parecia até uma notícia não muito relevante, mas pensando bem, achei que valia a pena comentar, já que este foi um assunto já discutido antes aqui neste blog.

Fiquei sabendo pelo blog do Doug Schaefer, principal mantenedor do CDT, que a Nokia tinha adquirido controle total sobre a Symbian. Em princípio a notícia não é muito impactante porque a Nokia já era uma das principais acionistas da Symbian. E era obvio que a Nokia tinha interesse direto no Symbian, que é um dos sistemas operacionais muito usados em SmartPhones. So far, so good.

Mas, como está no anúncio da Nokia, o propósito não é apenas controlar a Symbian. O objetivo final é abrir o código-fonte do Symbian OS sob licença EPL (Eclipse Public License), criando a Symbian Foundation. Com isto, a Nokia, que é a maior fabricante de celulares e de plataformas móveis atualmente, faz frente ao anúncio do Android feito pelo Google e da Open Handset Alliance o ano passado.

O mais interessante, no entanto, é observar o que vai acontecer daqui para a frente. O Android, até onde eu sei, é apenas a descrição de um padrão. Ele pode ter várias implementações. E apesar de a Nokia não fazer parte da Open Handset Alliance, muitas das outras empresas que junto com ela estão promovendo a abertura do código do Symbian fazem. Para a Nokia, como detentora do posto de líder de mercado, o importante era fazer um movimento dizendo que ela não está a revelia dos últimos acontecimentos em relação à criação de padrões abertos no mercado de celulares. Resta saber o que ela e seus parceiros no Symbian OS vao querer fazer com o Symbian OS de código-aberto: continuar com ele  sendo algo separado do Android ou torná-lo um sistema compatível com o padrão da Open Handset Alliance.

Tem uma coisa que o Raphael vira e mexe fala que me dá arrepios: “FOSS não funciona como estímulo para a inovação”. A última vez que eu me lembro que ele falou isso foi aqui. E pelo jeito não sou o único que tem estes arrepios como se pode ver pelo comentário do Carlos Costa neste mesmo post do Raphael.

E eu não sinto arrepios porque sou um defensor inveterado do software livre. Na verdade eu acho que existem coisas boas tanto do lado do software livre como do lado do software proprietário e acho que tem espaço para todo mundo. Sinto arrepios porque realmente acho que software livre tem muita inovação de verdade. O problema é que eu ainda não consegui achar um contra-exemplo cabal para você, Raphael. Pelo menos não para o sentido de inovação que eu acho que você quer dar à sua frase.

De certa forma eu concordo parcialmente que os conceitos implementados em software livre já foram testados no mercado. Isso é verdade muitas vezes. Mas eu acho que este ponto de vista é limitado. No fundo eu acho que os conceitos implementados em software livres são maduros o suficiente, tendo sido ou não implementados pelo mercado. Isto porque quando você se envolve em uma comunidade de pessoas, em geral a tendência é aceitar apenas coisas que já estejam maduras o suficiente e que portanto, irão muito provavelmente gerar código de qualidade.

Não me entendam mal: não acho que software livre não tenha inovação por completo. Se olharmos de perto o GCC, ou o Eclipse ou vários outros projetos open source veremos que eles tem sim uma grande dose de inovação. Mas eu diria que, na visão macro, eles são mais inovadores na forma de fazerem coisas que já existem do que na forma de criarem coisas novas. O que não impede, é claro, que muitos testes e invenções estejam sendo feitas na visão micro destes softwares. Eu diria que eles são mais parecidos com o que a Apple anda fazendo nos últimos anos(copiando conceitos já existentes e dando uma roupagem diferente a eles, inventando uma coisinha aqui e outra ali) do que com o que a Intel ou a IBM fazem no campo de processadores por exemplo (efetivamente pesquisando novas tecnologias e tentando aplicá-las no mundo real).

Aonde eu quero chegar com isso? Para mim o principal problema na frase do Raphael é o mal uso da palavra inovação.

O que é inovação? Quando eu vejo alguma coisa como “FOSS não funciona como estímulo à inovação” eu interpreto mais como “FOSS não funciona como estímulo para a invenção”. Até pouco tempo atrás eu achava muito sútil e muitas vezes inexistente a diferença entre invenção e inovação. Mas a cada dia eu venho me atentando mais para a diferença entre estas palavras. Invenção é realmente inventar coisas novas, fazer algo que nunca foi feito antes. Inovar não é necessariamente inventar: inovar é muitas vezes pegar algo que já existe e, com uma roupagem nova, criar algo que tenha um apelo ou uma utilidade ainda maior do que aquilo que existia antes. Ainda que eu não goste muito da frase, como diria Jean Paul Jacob, “Inovação é o enlace entre invenção e a visão do valor desta invenção”. É exatamente isto que a Apple anda fazendo muito bem nos últimos anos: efetivamente não inventando nada de novo, mas habilmente dando um novo valor e uma nova visão a produtos que já existiam.

Sob esta ótica eu acho que software livre é extremamente inovador. Inovador no modelo de desenvolvimento. Inovador nas idéias implementadas. E, algumas vezes, inovador ao inventar novas coisas e novos conceitos também. Como eu disse antes, ainda não achei um exemplo cabal de um produto completo de software livre que seja totalmente novo (e talvez aí esteja a falha na minha argumentação contra a frase do Raphael… alguém pode me ajudar?). E acho até que isto é apenas um reflexo da economia de mercado: se você inventou algo que acha bom, porque não ganhar dinheiro com isso? Software livre é muito usado em partes já comoditizadas de sistemas (o que não exclui inovação) e a parte de maior valor agregado tende a ser proprietária justamente para gerar mais lucro. Mesmo assim eu poderia citar diversas funcionalidades que foram implementadas antes em software livre (algumas até mesmo no projeto em que eu trabalho) e que nunca tinham sido feitas antes por nenhum outro software. Quer um exemplo? Suporte em sistema operacional, compiladores e debuggers a plataformas híbridas: processadores que possuem núcleos de diferenças arquiteturas no mesmo chip. Isso é totalmente novo. E apareceu primeiro em plataformas de código aberto. Se isto não é inovação, o que é então?

Dizem por aí que  uma boa premissa para se criar um produto novo é partir de uma necessidade pessoal. Eu já devo ter mencionado isso em algum lugar neste blog. No caso do Job4Dev, foi assim. Na verdade, mais do que uma  necessidade, o Job4Dev teve como ponto de partida uma frustração: os sites de empregos brasileiros de empregos voltado para o mundo TI eram um amontoado de mais do mesmo.

O exercício é simples: entre nos 3 principais sites de empregos, e conte a porcentagem de vagas oferecidas por consultorias de TI, na maioria sem nome, sem projetos definido, sem plano de carreira, sem grandes desafios, cujo único objetivo é fazer outsourcing de recursos de programação. São a grande maioria.

Nada contra este tipo de trabalho. Existe a demanda, e existe gente que se interessa em desenvolver. Ótimo. O problema é que quando olhava estes sites, tinha a nítida impressão de que o mercado brasileiro se resumia a isso. E olhando à minha volta, percebia que meus colegas e outros profissionais bons em geral não passavam nem perto destes  sites, preferindo usar listas de emails, contatos pessoais e o bom e velho networking.

Job4Dev foi desenvolvido tendo como objetivo de oferecer alternativas, captando vagas de várias fontes, filtrando o material e disponibilizando apenas aquilo que julgamos interessante.

E devo confessar que, depois de alguns meses no ar, o retorno e o resultado me surpreendeu. O site ainda tem muito a crescer, mas temos conseguido um fluxo regular de vagas, feedbacks muito bons de usuários e empresas. Isso me confirma uma coisa: o mercado brasileiro talves esteja longe do ideal, mas existem sim boas opções de empresas que procuram profissionais diferenciados, que desenvolvem projetos interessantes. E estas empresas estão carentes de espaços adequados de divulgação.

A frase do título foi imortalizada por Pedro Bial no horroroso Big Brother Brasil (que, confesso, assisti assiduamente nos primeiros anos).

Fato é que o ser humano é curioso, voyeur por natureza. O ser computeiro mais ainda. E a dúvida que bate na cabeça de muitos de nós é “Quanto ganha um engenheiro de SW numa empresa top como Google, Apple ou Microsoft?”

Bem, o site GlassDoor.com tem como proposta amenizar esta dúvida cruel, trazendo informações de funcionários anônimos das próprias empresas como salários por posição, opiniões sobre CEOs e nível de satisfação. Fico só imaginando o funcionário chegando no site, com sua voz de pato e a cara quadriculada…

Ja é possível dar uma espiadinha em empresas como Google, M$ e Yahoo.

Um tempo atrás eu descrevi minhas impressões sobre a Discovery’08 e prometi continuar sobre mais uma palestra e o painel que assisti. Demorou um pouco mais do que esperado, mas felizmente eu consegui achar onde tinha deixado minhas anotações e lembrar dos pontos que queria comentar. Mas melhor do que isso, eu descobri que os organizadores fizeram podcasts de algumas palestras e discussões e colocaram à disposição no site. Então, quem quiser pegar o conteúdo na integra é só baixar os podcasts (estão em inglês).

Primeiro vamos à palestra do ministro da pesquisa e inovação de Ontario, Honorable John Wilkinson. Ele falou durante o almoço, o que não é muito agradável, mas a minha primeira impressão foi: como os políticos sabem falar bem! Não que os outros palestrantes não soubessem falar ou tivessem problemas no palco, mas o políticos são especialistas em falar as coisas de um jeito que parece até que eles realmente estão entendendo detalhes de todos os assuntos, mesmo que seja somente um texto escrito pelo assessor.

Mas falando do conteúdo, duas coisas me chamaram muito a atenção. Primeiro foi que o evento contava com enviados das embaixadas da China e da Índia. Nisso eu fiquei pensando: onde estaria o representante brasileiro? O governo brasileiro envia representantes para eventos os mais esdrúxulos possíveis, mas será que ninguém da embaixada em Ottawa ou do consulado em Toronto sabia desse evento e/ou se interessou por ele? Qual seria o motivo da missão brasileira no Canadá, somente dar suporte à cidadãos brasileiros, ou participar mais ativamente em parcerias que podem trazer benefícios enormes para o país? O Canadá não tem uma economia comparável, em tamanho, à dos EUA ou da Europa, mas é não é de se desprezar, como nossos concorrentes chineses e indianos sabem muito bem. Segundo o ministro, Ontario é o distrito do G8 (e possivelmente do mundo) com maior densidade de graduados em universidades (distritos seriam estados ou províncias, já que provavelmente existem focos menores com maior densidade). Isso significa um grande potencial de crescimento na região, já que conta com muita mão de obra qualificada (e um governo que, apesar de todos os problemas, tenta ajudar).

O segundo ponto interessante tem relação com os incentivos do governo provincial para a criação de novos negócios. Existem inúmeros projetos, mas dois chamam a atenção. Primeiro, o governo tem um projeto com um fundo de alguns bilhões de dólares pra investir em empresas de tecnologia. O interessante é que, se você tem um projeto e aplica para conseguir fundos, o governo garante que responde em 45 dias. Isso é realmente impressionante, pois avaliar um projeto desses sempre requer contatos com especialistas e outras milhões de burocracias atrapalhando. Segundo o ministro, o governo quer ser um “parceiro” que anda na “velocidade da nova economia”. Segundo, novas empresas que são baseadas em tecnologia própria tem 10 anos de isenção fiscal. Isso é o governo trabalhando pra ajudar as empresas, não pra chupar o sangue delas! Na minha última ida ao Brasil eu conversei com um amigo que abriu uma empresa de tecnologia. Ele me disse que cerca de 40% dos gastos da empresa eram impostos, desde taxas diretas da venda até encargos para os empregados. Se o governo cortasse esses impostos para empresas recém criadas, ele teria 40% mais investimento pra crescer! E depois o governo poderia reter 20% de impostos de um bolo muito maior. É claro que tem-se que tomar muito cuidado com essas medidas, senão vão surgir milhares de empresas se recriando a cada dois anos pra ficar sempre na categoria de “novas empresas”, mas eu imagino que algo bem pensado nessa direção seja muito proveitoso.

Bem, vamos ao painel então. O título era “Failures on the Road to Success” (literalmente, fracassos no caminho do sucesso). A proposta era basicamente discutir como fracassos fazem parte da busca por sucesso, principalmente em áreas muito imprevisíveis (veja no último texto sobre os Black Swans). Os palestrantes não entraram muito em conflito e todos eles defendiam a tese de que fracassos anteriores são considerados positivamente no vale do silício por analistas de investimento. Isto é, quando alguém vai analisar se vai pôr dinheiro na sua idéia, você ter feito uma besteira anterior é positivo, pois você ganhou experiência, talvez perdeu dinheiro (dos outros), mas tem mais chance de dar certo agora. Infelizmente, e isso eu achei o ponto fraco da discussão, nenhum dos palestrantes admitiu realmente ter fracassado feio. Somente um deles contou um caso em que o fracasso inicial no fim se transformou num sucesso (ele apostou na moeda errada, mas depois de alguns anos ela se tornou a certa). Ou seja, não sei até que ponto é só glamour essa idéia de glorificar o fracasso passado.

Mas outras duas mensagens curtas do painel também foram legais. Primeiro, eles pisaram e falaram mal de venture capitalists. Disseram que eles não estão nem aí para o seu negócio, tudo que querem é retorno do investimento, etc, tudo aquilo que a gente já sabe, mas é sempre bom repetir: no melhor dos mundos, cresça o quanto der, até sua empresa ter o máximo possível de valor de mercado antes de procurar investidores. Segundo, eles disseram nua e cruamente: cientistas da computação não sabem fazer negócios. Isso não significa que não existam computeiros que possam ser ótimos homens de negócios, mas simplesmente que o tipo de treinamento e skills necessários pra ser um bom manager, para negociar com clientes, etc, não é exatamente o que é ensinado em um curso de computação. A dica é, se você entende muito de tecnologia e sabe muito bem como desenvolver produtos, se concentre nessa área e se associe com uma pessoa que é especialista em vender a sua tecnologia e o seus produtos. Mais uma que a gente já sabia!

Venho trabalhado nos meus projetos pessoais com Python há um certo tempo e estou bem satisfeito. Esta linguagem tem sido um fator importantíssimo na minha produtividade, e tem me permitido por minhas idéias no ar de forma estruturada e com qualidade em tempos recordes.

Mas acho importante identificar pontos falhos que possam ser melhorados. Ter uma visão crítica de uma linguagem não a desmerece e não me faz ser menos entusiasta. Foi assim com Java, é assim com Python.

Até agora, a única caracteristica de Python que realmente me incomodava era o fato de variáveis locais não terem escopo de bloco. Ou seja: uma variável criada dentro de um if existe após ele. Muitos consideram isso como um ponto que pode gerar vários erros bestas (e de fato pode), mas se bem utilizado, pode ser bem poderoso. Resumindo: requer cuidado, mas pode ser útil. Ninguém é perfeito…

Mas existem alguns limites…e hoje descobri uma característica que me incomoda. Não a ponto de eu deixar a linguagem, porque ainda acho que os benefícios dela são gigantescos. Mas incomoda. E fico feliz de ter descoberto isso antes de ter passado horas e horas quebrando a cabeça com comportamentos bizarros.

Chega de preâmbulos, vamos ao ponto:

def f(item, lista=[]):

     lista.append(item)

     print lista

Se executarmos a a função uma primeira vez, passando apenas um argumento, o resultado é o esperado: f(1) imprime [1] na tela. Mas se executarmos uma segunda vez, em vez de imprimir [2], a função f imprime [1,2]. Eu custei a acreditar nisso, e tive que confirmar pessoalmente.

Fazendo uma busca no Google, descobri na documentação oficial (http://docs.python.org/ref/function.html) que isto realmente é uma característica mapeada da linguagem:

Default parameter values are evaluated when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that that same “pre-computed” value is used for each call. This is especially important to understand when a default parameter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function […]

Ok, pelo menos está mapeado. Mas a frase texto acima merece “This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function” merece destaque. Afinal, logo após a documentação descrever a funcionalidade, ela reconhece que o efeito é indesejado (afinal, parâmetro de função tem escopo local), e ainda por cima descreve a Solução Rápida de Eficiência Duvidosa, a famosa Gambiarra (ou workaround, no jargão técnico). Ou seja, o problema poderia ser resolvido na fonte e as funções de Python poderiam ter o mesmo comportamento das funções de outras linguagens.

Infelizmente, acabei de dar uma olhada na doc do futuro Python 3.0, e a feature permanece……

Hoje de manhã li uma notícia sobre o Twitter que gerou várias discussões interessantes com várias pessoas sobre vários temas que considero relevantes. Achei que seria interessante repassar os pontos discutidos aqui.

Tudo começou com uma discussão sobre as causas da instabilidade que vem assombrando o Twitter nos últimos dias. Fenômeno da internet, o microblog parece estar sofrendo dos altos índices de popularidade e tem passado mais tempo fora do ar do que dentro dele (aliás, neste momento em que vos falo, o dito cujo nem responde com a tradicional tela de erro).

Quem acabou levando a culpa foi o também famoso Ruby On Rails, que serve de base para o funcionamento do site. Foi noticiado que eles estariam com problemas de escalabilidade (ah… a escalabilidade… suspiros), e que a equipe de desenvolvimento estaria considerando migrar para PHP ou Java. Obviamente os advogados de Java de plantão se uniram e começaram a malhar o Rails. Afinal, como todos sabemos, “só Jesus salva, e só Java escala.”

Neste momento, cabe um comentário: programo em Java desde 96, adoro a linguagem e inclusive ganho o meu pão de cada dia com ela. Mas esse mito da escalabilidade única de Java me dá calafrios…

E ainda cabe outro comentário: a dúvida entre PHP e Java é pouco lisonjeadora pra esta última….

Voltando: eu não conheço RoR, não conheço Ruby, não sou fã da sintaxe da linguagem, e sinceramente não tenho motivos pra defender ou atacar nenhum dos dois. Mas, como diria meu colega Raphael: linguagem não escala, quem escala é a arquitetura do sistema, e parecia óbvio que havia um problema de arquitetura e infraestrutura por trás.

E não deu outra. No final de maio, o próprio blog do Twitter publicou uma entrevista comentando os problemas que eles vem enfrentando e ficou claro que no caso deles, o buraco é bem mais embaixo:

Q: Is it true that you only have a single master MySQL server running replication to two slaves, and the architecture doesn’t auto-switch to a hot backup when the master goes down?
A: We currently use one database for writes with multiple slaves for read queries. As many know, replication of MySQL is no easy task, so we’ve brought in MySQL experts to help us with that immediately. We’ve also ordered new machines and failover infrastructure to handle emergencies.

Resumindo: o Twitter tem como base 3 computadores!!! Provavelmente eles são adeptos da famosa frase do Knuth que diz que otimização prematura é fonte de problemas. Eu também concordo com isso, mas com ressalvas. Acho que existem otimizações maduras que são necessárias e sempre bem vindas.

Mais pra frente, existe um outro ponto que achei interessante: Segundo o artigo, eles contrataram alguns ex-engenheiros do Google, que irão trabalhar na escalabilidade do sistema, e em particular, irão migrar para um sistema de armazenamento de dados baseado em sistema de arquivo, substituindo o sistema de base de dados.

Você sabia que o Google não usa base de dados para o seu incrível sistema de buscas? Pois é, tudo se baseia no BigTable, uma espécie de mega-arquivo distribuído que entre outras coisas não permite operações de joins, por questões de escalabilidade e velocidade.

E isso suscitou uma outra discussão com um colega de trabalho: hoje em dia, pensou em persistência, pensou em sistema de base de dados. Mesmo que isso não seja realmente necessário.

Sistemas de base de dados são ferramentas extremamente úteis, eficientes e importantes no dia a dia da computação, sobretudo quando falamos de sistemas web. Mas é sempre bom lembrar que as vezes um simples arquivo em disco resolve muito bem. Quando? Quando não precisamos de operações como buscas, joins, filtros, histórico….

Exemplo: no job4dev, o sistema de envios de mensagens para o Twitter é assíncrono. Ou seja, a vaga é adicionada no sistema, e de tempos em tempos uma tarefa cron (sim, o bom e velho crontab do linux que funciona perfeitamente) pega o título e url das vagas e envia para o microblog. Para simplificar minha vida, eu salvo as informações que eu quero enviar em um arquivo (cada vaga é gravada em um arquivo diferente) em um diretório pré-determinado, que a tarefa cron lê. Simples, eficiente. E aposto que 95% das pessoas que fizessem isso pensariam de cara em salvar num BD, só para ter que fazer um select depois.

Outro exemplo de uso de BD que eu achava inútil: durante muito tempo eu trabalhei em uma empresa que desenvolve soluções para análise de dados biológicos. Um dos nossos sistemas era um visualizador de lotes de seqüências genéticas. Obviamente, todos estes dados estavam armazenados em uma linda base de dados normalizada. Para carregar um lote, era necessário sempre fazer uma enorme quantidade de joins e selects. O detalhe é que NUNCA o sistema fazia buscas nestas sequências, NUNCA o sistema filtrava apenas alguns dados do lotes, e SEMPRE o lote era carregado de uma vez e salvo de uma vez, em um sistema Desktop onde o gerenciamento de dados em memória é bem simples. E ainda assim, os meus apelos para usarmos arquivos em disco foram inúteis.

O que eu gostaria de deixar como ponto importante deste post que as vezes é bom pensar fora da caixa, procurar novas abordagens para resolução de problemas, sair um pouco da rede de proteção que algumas ferramentas já bem estabelecidas supostamente oferecem. Estas ferramentas são boas, não tem como negar isso e dizer que elas não servem pra nada. Elas servem, e muito.

Mas o status quo não leva a evoluções. Se você dissesse hoje que iria fazer um sistema de buscas de páginas sem usar BD, provavelmente muitos diriam que você é louco.

No começo do mês o Miguel perguntou: podcast? Eu não venho aqui com a resposta pronta (apesar do título ser uma exclamação), mas esse post é um pouco pra reavivar a discussão.

Ultimamente tenho ido diariamente de bicicleta pro trabalho, o que leva em média uns 30 minutos, mais uns 10 minutos entre descer no elevador, destravar a bicicleta, travar de novo no trabalho e ir até o chuveiro. Isso faz com que eu tenha 80 minutos “livres” por dia, praticamente sem pensar em computação! Como bom computeiro, eu não podia deixar essa situação perdurar, então comecei a gravar podcasts no iPod e ir ouvindo no caminho. Por enquanto os assuntos não foram absorventes o suficiente pra me tirar a concentração no transito, e eu ainda não me matei…

Atualmente eu estou ouvindo as entrevistas do Markus Voelter na Software Engineering Radio (se-radio). Tem bastante coisa interessante por lá e eu to achando uma boa pra ter uma noção por cima de assuntos diversos. Eu acho que um podcast não é a mídia ideal pra passar os detalhes, mas você sempre pode correr atrás de saber mais sobre os assuntos que te interessaram mais.

A primeira pesquisa do post é : Que outros podcasts interessantes vocês conhecem, além do stackoverflow que foi mencionado no post anterior?

Naquele post foi discutida também a idéia de criar um podcast do log4dev (pod4dev ou cast4dev, quem sabe até podcast4dev). Eu particularmente acho que seria muuuito trabalho e acho que algumas características teriam que ser muito bem pensadas, como:

• Assuntos: que tipo de assuntos seriam tratados no podcast? Se o intuito é somente dar a opinião sobre algum assunto, porque não usar o log4dev mesmo? Quero dizer, pra agregar valor, o podcast tem que aproveitar o seu diferencial, que é o som, então o conteúdo provavelmente tem que ser diferente do log4dev.
• Duração: qual vai ser a duração média de uma transmissão? O Lucas comentou no post anterior que o ideal seria 25 minutos, pois não fica cansativo. Os podcasts da se-radio são entre 40 e 50 minutos, o que é OK pra mim, mas não funcionaria pra todos. Apesar das entrevistas dele não ficarem cansativas, eu acredito que se eu não tivesse tanto tempo “disponível”, eu não iria parar o meu trabalho pra ficar ouvindo (e olhando pra onde?). É claro que a duração também é muito influenciada pelo assunto: uma entrevista de 25 minutos é muito curta, principalmente quando o entrevistado é bem interessante, mas 50 minutos falando em monólogo sobre algum assunto qualquer fica maçante.
• Equipamentos: que equipamentos teriam que ser adquiridos? Como o Evandro disse, não adianta fazer um podcast com um som porcaria, pois isso só iria irritar quem está tentando ouvir. Logo, alguns equipamentos de áudio teriam que ser adquiridos de alguma forma. Na se-radio, depois de um bom tempo com o som ruim, eles compraram um equipamento melhor, e depois conseguiram algumas doações e sponsors pra manter a radio funcionando, mas eu não acho que essa seja uma possibilidade realista.
• Periodicidade: com qual periodicidade seria publicado o podcast? De novo, o se-radio garante que publica a cada 10 dias. Vale a pena o editor-chefe definir uma garantia dessas? Com certeza essas garantias agradam ao público, pois eles sabem o que esperar. O difícil é honrar o compromisso….

Esses são alguns pontos em que eu estive pensando e com certeza existem outros mais. A minha análise é obviamente muito baseada no se-radio que é o podcast com o qual eu tenho mais contato. Por isso mesmo a opinião de gente com mais experiência é muito importante.

Há dias que eu fico impressionado com a minha capacidade de perder tempo na internet. Dê-me um domingo de chuva e uma boa conexão, eu sou capaz de alcançar o fim da internet umas duas vezes.

Infelizmente, em minhas andanças, eu encontro pouquíssimos:

• Vídeos com close-ups da Jennifer Connely.
• Blogs de tecnologia escritos em português que me deixem com o tal Orgulho de Ser Brasileiro.

Talvez eu esteja sendo exigente demais em relação aos vídeos da Jennifer Connely. Há vídeos por aí, é verdade. É que, como direi?, you just can’t get enough of her blue eyes.

Mas eu acho que não estou pedindo muito em relação aos blogueiros brasileiros. Quer queira, quer não, nosso país tem uma presença online muito forte. Mas essa presença não se traduz em números correspondentes em material online em português. E a assombrosa maioria do que está por aí são blogs que estão muito mais preocupados em armar arapucas para levantar alguma grana com anúncios do que oferecer material relevante.

Um dos problemas dos blogs (na verdade, de qualquer serviço que mede seu sucesso baseado na audiência) é que é eles acabam se importando mais em conseguir a sua atenção do que a sua edificação. Produzir qualquer peça de informação relevante é difícil e dá muito mais trabalho do que pegar meia dúzia de links e fazer uma colagem. Logo, teremos mais blogs fazendo reciclagem de material alheio do que blogs produzindo material genuinamente novo.

Deixa eu ser direto: o que eu gostaria de ver é gente escrevendo material que seja mais do que uma simples câmara de eco dos anúncios e opiniões emitidos pelos grandes players do mercado. Gente que seja capaz de observar o que se passa e fazer uma análise própria. Mas quanto mais eu procurava, mais eu ficava com a sensação que o Log4Dev estava isolado. Pra ser sincero, esse tipo de idéia me deixa até assustado - não é possível que um grupo de quatro (Cinco agora, né, Bart?) computeiros ainda jovens fossem tão bons a ponto de conseguir fazer algo tão diferente, inédito.

Surgiram algumas hipóteses para tentar explicar isso:

1. O pessoal realmente bom não tem tempo para ficar de papo-furado em blogs, ou seu campo de atuação é tão complexo que o formato do blog dificulta a transmissão de idéias.
2. Os caras realmente bons estão escrevendo apenas em inglês, pois estão sendo vistos e entrando em conversa direta com gente do mundo todo.
3. Os tubos de ar-condicionado dos laboratórios de Computação da Unicamp contém um micro-organismo que, quando ingerido, causam megalomania e estupidez. Entre os sintomas dessa infecção estaria o fato da vítima começar a escrever periodicamente na internet e achar que os outros teriam algum motivo para parar as suas vidas e ler tais bobagens. Alunos da Unicamp Ec99 e EC98 seriam especialmente suscetíveis a esse organismo maligno.

Acho que só a hipótese (1) é válida. Tem muita gente boa por aí, sim. Mas ou é gente que está em projetos open source (Marcelo Tosatti, anyone? Os caras que desenvolveram o Windowmaker?) ou é gente muito mais experiente com anos de estrada em mercados como o de eletrônica embarcada, redes de telefonia, VLSI… mercados que não estão tão próximos da internet, por exemplo.

A hipótese (2) é furada. Ainda que o inglês seja a língua franca da internet, os blogs de brasileiros que eu encontro por aí não são muito melhores que os escritos em português.

A hipótese (3) também me parece falha. Não pela nossa megalomania e imodéstia, que certamente existem. Acho que essa hipótese é falha por que estamos vendo nosso tráfego crescer constantemente, e estamos até começando a fazer escola. Não somos os únicos buscando fomentar um grupo aberto para criar novas coisas e tentar trazer um pouco de personalidade para um campo tão “quadrado” como o de tecnologia e computação.

Enfim, esse post é só pra tentar saber por onde estão os profissionais de computação que tem talento, competência e que conseguem expor algumas idéias e opiniões relacionados ao mercado de TI no Brasil. Gente, por exemplo, como o Bruno Pereira, que foi uma grata surpresa que encontrei na semana passada. Tenho certeza que não é o único exemplo, mas pergunto: onde eles estão?

Nas últimas semanas tenho trabalhado em um projeto de integração entre um sistema em C e um sistema em Java: o sistema original, legado, é completamente em C, e a equipe na qual eu trabalho está reescrevendo algumas partes em Java, e eu tenho que fazer o sistema antigo conversar com o novo. O sistema em C utiliza um sistema de comunicação interna que consiste basicamente em serializar bytes e mandar via UDP. Isso torna o processo bem rápido e eficiente, mas torna a comunicação entre plataformas bem complicada, por causa de problemas como alinhamento de bytes, padding, little endian, big endian, ponto flutuante, e por aí vai.

Por isso tive que rever vários conceitos, além de relembrar várias coisas em C. Não trabalhava com C desde 2002, quando participei do projeto AURORA, organizado pelo CenPRA. O objetivo do Aurora era de construir um dirigível capaz de voar sozinho, usando dados de sensores, GPS e de câmeras de vídeo. Minha missão dentro do projeto foi de desenvolver a infraestrutura para captação de imagens através de barramento IEEE 1394 (firewire), processamento e extração de certos parâmetros em tempo real e envio de alguns frames para uma estação de controle em terra. Foi C na veia, e ainda tive que estudar IEEE1394, drivers para linux, formatos de vídeo, processamento de imagens, envio de pacotes via UDP, e muitos outros conceitos básicos. Me diverti muito nesta época.

Voltando ao projeto atual, uma das tarefas necessárias era de receber um fluxo de bytes e extrair informações seguindo um descritor da mensagem. Como meus campos de informação dentro do fluxo de bytes tinham posições e tamanhos pouco convencionais (12 bits, 3 bits começando no bit 4 do byte 2, e por aí vai), não consegui encontrar nenhuma lib que resolvesse meu problema de forma adequada (em particular, nenhuma lib de extração de dados trabalha corretamente com campos de bits). Por isso resolvi extrair os bits na mão, escrevendo algumas operações binárias: o resultado final ficou bastante bom e conciso. Mas várias pessoas me perguntaram porque eu fiz a loucura de implementar isso na mão. Segundo eles, deveria ter pesquisado mais, porque provavelmente algum engenheiro da Sun havia feito algo melhor e mais robusto.

Concordo que seja possível que eu não tenha procurado o suficiente. Mas escrever algumas poucas linhas de operações binárias não me parece ser tarefa do outro mundo. Talvez eu seja arrogante o suficiente para me achar melhor do que os engenheiros da Sun (ou pelo menos tão competente quanto). Mas talvez também os programadores estejam criando tabus em relação a alguns tópicos de computação, chamados por muitos de baixarias.

A evolução na computação se faz por meio de criação de camadas de abstração, que nos permitem trabalhar sem nos preocuparmos com certos problemas. Hoje em dia, quem programa em Java, Python, Ruby e outras linguagens similares não se preocupa mais em gerenciar memória, em perder ponteiros. ORMs permitem que a base de dados seja vista como um conjunto de objetos. RMI e RPC enviam objetos e estruturas de dados de uma máquina para a outra. E acreditem: eu adoro estas abstrações! Adoro trabalhar com dicionários, listas e tuplas em Python, adoro não ter que gerenciar ponteiros em Java. Mas duas ressalvas precisam ser feitas.

A primeira já foi feita pelo Joel, no artigo The Law of Leaky Abstractions: estas abstrações são ótimas, mas não são perfeitas e muitas vezes falham. E quando falham, é preciso conhecer os fundamentos daquilo que está por baixo. Quando sistemas de ORM retornam resultados esdrúxulos, é preciso entender que o sistema subjacente não trabalha com objetos, mas com tabelas. Quando struts não da conta de tratar uma requisição, é preciso entender que no fundo no fundo, um form é uma string de requisição HTTP. Pode parecer bobo, mas é incrível perceber a quantidade de programadores que simplesmente não entendem o que se passa por debaixo do pano. Tudo é mágico.

A segunda ressalva é o ponto que eu quero ressaltar neste texto: estas camadas de abstração criam tabus. Hoje as pessoas tem receio de escovar bits, ou processar um UDP na mão. Muito em breve, SQL será algo de outro mundo, uma vez que Hibernate, RoR e Django permitem que objetos sejam criados de forma direta. HTTP e CGI já são conceitos do passado: hoje temos forms, event handlers e componentes. Para tudo, se busca um framework, uma lib. Para tudo, se acha que o que é feito pelos engenheiros da Sun é melhor. Eu tive esta nítida impressão conversando com um colega de trabalho que já tem muiiiiitos anos de estrada. Ele tem uma boa experiência em programação de microcontroladores, e ele é da época em que C era novidade no mercado. E segundo ele, mexer com bits era algo trivial e corriqueiro naquela época.

Que fique bem claro: eu adoro não ter que mexer nestas coisas. Mas sei que problemas deste tipo podem aparecer na nossa frente de vez em quando, e quando aparecerem nós temos que poder resolve-los. E para isso, não podemos ter medo de passar por cima das abstrações. Por isso, eu defendo que todo programador deveria mexer em algum projetinho em C de tempos em tempos (um ou dois meses a cada 5 anos por exemplo). Isso já seria suficiente para lembrar que o mundo computacional não é tão alto nível quando gostaríamos. E o prazer de voltar para nossas caixas pretas é incomensurável.

Um comentário interessante sobre o meu texto falando do sistemas distribuídos de versão foi do Bruno, que falou que tal arranjo não funcionaria em uma empresa estruturada de forma mais tradicional, onde as responsabilidades são (em teoria) divididas pela hierarquia, experiência anterior, etc.

De certa forma, ele está certo. Tecnicamente, até podemos utilizar uma ferramenta que tem uma arquitetura distribuída e usá-la de uma forma degenerada: bastaria deixar um dos repositórios como o repositório “oficial”, e passaríamos a ter um esquema mais parecido com a organização atual.

Mas uma mudança dessa natureza levaria justamente à perda do que eu considero como a feature mais importante do DVCS, que é permitir a troca de trabalho entre os indivíduos livremente, sem termos que passar pelo crivo de algum processo. O trabalho deixaria de ocorrer exclusivamente nas folhas e teria que passar por alguns nós acima. Acho que é isso que ele quis dizer quando comentou que “claramente não funcionaria em uma empresa tradicional”.

O que me deixa pensando, entretanto, é o seguinte: não seria a hora das empresas começarem a perceber que o esquema delas pode estar errado? Toda a noção de hierarquia e experiência anterior como parâmetro de confiança em um profissional é uma medida indireta, no melhor caso. No pior caso, é apenas uma desculpa para termos uma instituição regida não pelos mais competentes, mas pelos que são melhores em política corporativa.

Instituições

O problema, creio eu, está na crescente obsolescência das Instituições. E as empresas serão as primeiras a sofrer com isso.

Instituições surgiram justamente para dar as pessoas confiança em relações entre as pessoas que não se conhecem. Eu posso apresentar o meu RG para um total estranho em um bar, e ele vai aceitar o documento como prova de que eu tenho permissão para beber. Eu posso pegar o meu diploma de engenheiro, passar no CREA, e de uma hora para a outra as pessoas aceitam a idéia de que eu sou apto a construir uma casa. Se eu chegar em um restaurante sem dinheiro e falar que vou pagar depois, rirão da minha cara. Entretanto, um cartão de crédito funciona da mesma forma: é uma instituição que está garantindo que eu vou, sim, pagar depois.

Se fosse esse o único papel das Instituições, não teríamos problema. O problema é que, ao deixarmos que uma Instituição defina o limite inferior de confiança que podemos ter em desconhecidos, ela acaba implicitamente estabelecendo os termos de um contrato e remove a opção de um dos indivíduos usar o seu bom senso. Por exemplo, um dono de bar pode vetar a venda de bebida para um menor de idade - por mais responsável que o menor possa vir a ser - mas não pode vetar a venda de bebida para um alcoólatra ou para alguém que parece ter passado da conta e pode provocar uma briga. Se eu for um bom falsificador de dinheiro, eu poderia comer de graça em qualquer lugar do país.

A Internet mudou esse jogo de uma forma extraordinária. Quando as pessoas passam a ter um meio de comunicar outras formas diretamente, sem precisar passar por intermediários que digam qual é a forma que o relacionamento entre as pessoas deve se dar, elas mesmas passam a criar o seu círculo de confiança. E com isso elas podem, elas mesmas, definirem com quem e de que forma se dará o seu relacionamento profissional, afetivo, pessoal, comercial… as Instituições ficam obsoletas.

Evolução

Romper com a tradição é difícil. As empresas não vão passar a adotar de uma hora pra outra uma técnica nova. Ainda mais quando uma mudança de técnica implica numa mudança do seu próprio sistema de valores. Elas só tomarão consciência que essa mudança é necessária quando alguém menor, que não tenha nada a perder em adotar essa nova técnica, superá-las no seu próprio jogo.

É assim que se dá a evolução. Muitos mantêm a idéia de que é possível uma entidade já desenvolvida “evoluir”, mudando a sua forma e sua natureza. Essa é uma idéia errada, baseada nos conceitos de Lamarck. A evolução nos moldes de Darwin fala em variabilidade de atributos e “sobrevivência dos mais aptos” ao ambiente. E hoje, parece-me que o ambiente está cada vez mais favorável àqueles que estão largando sua dependência das Instituições e buscando estabelecer seus canais de relacionamento diretamente com as partes envolvidas.

De uma forma ou de outra, são as pessoas que importam. Não a Corporação. Se a Corporação não entender isso, azar o dela.