Com o advento e crescimento dos projetos Open Source, se intensificou o conceito de que em última instância a melhor documentação de um projeto é o seu próprio código fonte. Concordo plenamente com isso! Em projetos ativos, manter uma documentação sobre arquitetura completamente atualizada é uma tarefa ingrata (sobretudo se seguirmos os moldes de artefatos exigidos pelas metodologias waterfall), e documentação errada é a pior coisa que pode existir.

Em projetos Open Source, onde os recursos são muitas vezes escassos e não se pode dar o luxo de manter uma pessoa apenas para manter tudo atualizado, a necessidade de uma documentação simplificada impera. E a necessidade de um código organizado também.

O problema é que muita gente levou ao pé da letra esse conceito, e chegou-se à conclusão de que comentários são supérfluos, afinal o próprio CÓDIGO é a documentação. Resultado: tenho cada vez mais visto toneladas de linhas de código sem um puto de um comentário.

Ah, mas com nomes incrivelmente sugestivos: apagaORegistroDoUsuarioEMandeMensagemdeDesolePraEle.

Senhores e Senhoras, o código fluente!

Plagiando um exemplo que eu peguei no iMasters:

Vendedor.deNome("Abreu").
                 vende().
                 paraCliente("Rafael").
                 oProduto("Mouse Verde").
                 oProduto("Teclado de Pano").
                 comDescontoDe(20).
                 mostrandoDetalhes();

Não posso dizer que não entendo o que este código faz! Até minha avó de 92 anos entenderia. Lindo.

O problema é que por mais que se empacote todas as funções com nomes extremamente sugestivos, que se crie DSLs para se esconder a complexidade,  que as variáveis sejam extremamente bem nomeadas, alguma hora os detalhes sórdidos do código vão começar a aparecer: bases de dados, queries, estruturas de dados, rede, integrações com outra bibliotecas, etc…

(Aaaaaaaaa, você não trabalha com bibliotecas, nem com BD, nem com rede, e apenas integra código fluente? Meus pêsames, o mundo da computação é bem mais interessante e divertido do que isso. Próximo…)

E na hora que chegamos aos detalhes sórdidos, por mais que o nome do método explique o que está se fazendo, pode ficar a dúvida: porque o método faz isso desta forma? E entender o porque das coisas é essencial se você está tendo que corrigir/modificar/aprimorar/integrar/analisar código legado. Sim, porque o que torna o código legado tão infernal de se mexer é justamente entender O QUE SE PASSAVA PELA CABEÇA DO DESGRAÇADO QUE ESCREVEU AQUILO!

Exercício: pegue um código que você escreveu há 6 meses atrás, de um projeto do qual você não participa mais, e tente entender todas as minúcias….foi sofrido? Imagino que sim. Agora imagine o pobre coitado do estagiário que está tendo que resolver um bug que ocorre naquele trecho!

Muito se fala por aí que código tem que ser escrito para ser lido por seres humanos e não por máquinas. Uma máquina apenas interpreta aquilo que escrevemos, e não está nem aí se faz sentido ou não. Ao contrário de seres humanos. Todos ficamos muito felizes quando entramos no javadoc da Sun, e encontramos alguns detalhes de implementação interessantes de métodos cujos nomes muitas vezes são bem explicitos. Como por exemplo o remove(String key) de uma Collection. Ninguém tem dúvidas do que ele faz, mas o que acontece se eu passar um valor nulo? Ou se passar um objeto que não existe?

Comentários são uma ferramenta muito útil, presente em qualquer linguagem, e que fazem parte do código.  Devem ser utilizados com inteligência, para facilitar a vida de todo mundo, tornar o código realmente uma documentação completa e inteligente e poupar horas, cabelos e neurônios de desenvolvedores cansados, estressados ou que simplesmente não querem passar horas decifrando a mente alheia.

Eu já escrevi uma boa quantidade de linhas de código na minha vida. Talvez 100k, talvez mais. Não faço idéia. Com certeza este número diminuiu muito depois de eu ter começado a programar em Python .

E quando releio alguns destes códigos, considero que na média a qualidade é boa (e pelos feedbacks de colegas, outras pessoas devem concordar com isso). Mas se me perguntarem o que me incomoda no meu estilo de codificar (sim, porque codificar é muito parecido com escrever livros: requer prática, cultura geral, leitura de outros textos, etc…) eu responderei na lata: a minha total falta de padronização da língua utilizada na nomenclatura de classes, métodos, atributos. Até hoje eu não me decido por escrever 100% em inglês, ou 100% em português. E faço isso sem perceber.

Em tempos de internet, globalização, software livre e colaboração, me agrada a idéia de existir uma língua universal para desenvolvimento de código. Facilita o intercâmbio de informações com pessoas de outros países, permite que se entre em mundos diferentes, quebrando a barreira da língua.

E inglês é a língua ideal para isso, simplesmente porque ela é a lingua internacional de fato (talvez um dia tenhamos que codificar em mandarin, mas isso é tema pra outra conversa). Além disso, boa parte das linguagens hoje (perto de 100% eu diria) utilizam primitivas e bibliotecas em inglês, para não se falar dos padrões e codificação. Por exemplo, em Java é padrão usar getters e setters para se ter acesso à informações internas a um objeto. Fica razoavelmente ridículo escrever getMinhaVariavel…mas ainda assim, eu faço isso com certa frequência.

Isto porque,  pior do que ter um código não universal (escrito em português por exemplo) é ter um código escrito em inglês errado. Eu com certeza já escrevi vários métodos que soariam ridículos para um falante nativo, e já li uma tonelada que soavam ridículo até pra mim. O problema é que, apesar de ler constantemente textos de computação em inglês e me virar bastante bem na língua do Tio Sam, na hora do cansaço ou da necessidade de termos mais rebuscados, as vezes o cérebro pede arrego. E aí vai em português mesmo. Já tive casos de precisar codificar conceitos ligados ao plantio de eucaliptos para produçao de papel, e fui atrás de termos em inglês para colheita, plantio, talhão, gleba….o resultado foi bom, mas tomou um bom tempo.

Ou seja: tenho que aprimorar meu inglês.

Em tempo: recentemente dei uma folheada em um livro sobre SCRUM, escrito em português por um brasileiro, e desisti de comprar o dito cujo quando vi um “printar” no meio de uma frase. Parece que do mesmo jeito que as vezes eu tenho preguiça de procurar termos em inglês, certas pessoas tem preguiça de escrever direito em português.

Last, but not least: a questão de escrever em inglês entrou em pauta várias vezes no Log4Dev. Temos pelo menos um expert no assunto, Lullis, tradutor nas horas vagas. Com certeza, mudar de língua tornaria nosso blog internacional, e fama e riqueza bateriam às nossas portas. Mas, por modéstia, vontade de manter uma vida calma e anônima, e falta de proficiência absoluta, decidimos manter os textos em português. Antes uma idéia bem transmitida para poucos do que mal escritas para a humanidade.

Dia desses estava eu resmungando pra minha namorada o quanto a minha pesquisa empaca quando meus colegas (principalmente meu orientador) estão muito ocupados e eu não recebo feedback. Como a gente gosta de fazer sudoku juntos, eu comecei a fazer uma analogia entre os problemas atacados em pesquisa acadêmica e sudoku pra explicar meus resmungos. Achei a analogia curiosa, então aqui vão os dois pontos principais, quem sabe alguém acha mais.

Antigamente, isso desde a idade antiga até mais ou menos a 2a guerra mundial, os pesquisadores eram aqueles seres mitológicos, geralmente um pouco malucos, excêntricos e isolados. Eles resolviam seus problemas separadamente, ficando muitas vezes anos escondendo o jogo até conseguir resultados interessantes. Por isso vemos várias vezes na história casos de descoberta simultânea por pesquisadores isolados. O grande problema desse modelo é que muitas vezes você fica empacado. É isso que acontece comigo quando eu faço sudoku sozinho, sem minha namorada. As vezes tem uma solução óbvia pra uma célula, bem na cara, e eu simplesmente não vejo (obviamente isso acontece com ela também, quando ela faz sozinha). E é exatamente assim que me sinto quando falta colaboração na minha pesquisa: eu as vezes encontro problemas que me travam ou, pior ainda, perco um bom tempo num caminho errado, o que poderia ser evitado se alguém com um “fresh look” no problema me desse um toque. Colaboração se tornou essencial em pesquisa principalmente a partir da 2a guerra, quando a complexidade dos problemas (e o preço das soluções!) começou a ficar grande demais pra um pesquisador solitário (ou um até um país sozinho, vide CERN). E com os meios de comunicação atuais, isso só está acelerando. Um bom exemplo é o My Experiment, um portal em que pesquisadores contribuem a metodologia de experimentos pra facilitar replicação.

Outro aspecto em que sudoku se parece com um problema de pesquisa é no seu lifecycle, ou ciclo de vida. Quando surge um novo problema de pesquisa, ou até uma nova área, é como um jogo de sudoku recém começado. As primeiras células são bem fáceis de serem preenchidas, assim como é bem fácil fazer progresso no problema. Você ataca antes as chamadas “low hanging fruits”, ou seja, faz antes o que é mais fácil de ser feito. Daí surgem aquelas lendas, e essa eu ouvi diretamente da boca do Alan Kay, de cientistas da computação conseguindo PhD em uma semana (nos anos 50, 60) por um algoritmo para alguma coisa que ninguém tinha feito antes (não me lembro exatamente pra que). Um outro exemplo é a invenção dos compiladores, provavelmente o desenvolvimento na área de computação que teve o maior impacto na produtividade, impacto que dificilmente vai ter equivalente no futuro. O ponto é que é mais fácil quando ninguém fez nada na área ainda. Depois a coisa começa a empacar, e tem-se uma fase de progresso incremental, em que problemas difíceis são resolvidos um a um, cada um merecendo um PhD. Depois, quando o tabuleiro já está mais cheio, fica mais fácil de completar. É nessa hora que os pesquisadores perdem o interesse na área, e geralmente os problemas que faltam sobram pra indústria. E é nessa hora que eu perco o interesse, viro pro lado e deixo minha namorada terminar o sudoku em paz!

Eu ando meio ausente deste blog. Percebo que a atividade de escrever requer tempo, e sobretudo, ócio criativo. Raramente consigo escrever um texto entre uma atividade e outra, menos quando são textos com notícias breves, como este sobre o Job4Dev no UOL. E o leitor há de se perguntar: “o que toma tanto o tempo deste pobre rapaz?”.

Respondo: o SigaSeuTime, startup que vem crescendo de forma animadora e que me tem tomado todo o tempo livre fora do horário comercial (sim, porque no horário comercial eu brinco de desenvolver sistemas de controle de tráfego aéreo, que ainda é a minha fonte de renda principal…e única).

Mas, acreditem, não passa um dia sequer sem que eu pense que deveria me dedicar mais a este espaço. E não passa um dia sequer sem que eu leve sermão do Raphael por não meter mais a mão no Job4Dev (assumi o papel de captador de vagas…). Mas isto é assunto pra outro dia.

Vou aproveitar o momento de inspiração para relatar uma experiência que tive recentemente trabalhando com o SigaSeuTime, que me parece interessante.

O ditado “A grama do vizinho é sempre mais verde” se aplica a quase todas as áreas do comportamento humano: nós temos uma tendência a achar que o que os outros têm é melhor. Em termos de linguagem de programação, o fanatismo de certos grupos tende a contrariar este ditado: é muito raro algum fã de uma linguagem admitir falhas, e ver outras opções como sendo mais eficientes, modernas, seguras…

Eu já comentei em algum outro texto que o conjunto Python/Django funcionou como um catalizador da minha capacidade produtiva/criativa. Sempre tive várias idéias (não forçosamente boas) mas tinha uma grande dificuldade de colocá-las em prática em Java (que é a minha linguagem de atuação profissional), e Python me permitiu concretizar algumas de forma rápida e eficiente.

Hoje, depois de uma boa quantidade de linhas de código escritas nesta linguagem, das quais a grande maioria em produção de forma estável  no SigaSeuTime e no Job4Dev, me pego pensando em algumas características presentes em linguagens como Java que eu sinto falta. Na verdade, existe uma principal: tipagem de parâmetros de funções e métodos. Apesar dos amantes de Python me dizerem por meio de comentários que eu preciso mudar minha forma de pensar, ainda acho que tipagem de parâmetros facilita a leitura de códigos alheios, e que sobrecarga de métodos é um recurso bastante elegante e útil.

Por vários motivos, incorporei um subsistema em Java dentro do SigaSeuTime, que implementa uma das plataformas. Este subsistema foi desenvolvido por um programador freelancer, e recentemente tive que mexer no código para fazer algumas adaptações. E foi um ótimo estudo comparativo de ambientes: Java/Eclipse vs Python/Emacs (já testei Python/Eclipse, e não vi grandes vantagens…). Cheguei à conclusão de que, no quadro da minha startup, entre a rede de proteção gigantesca oferecida por Java e a rapidez de desenvolvimento oferecida por Python, eu ainda prefiro a segunda opção.

Não trabalhei em projetos com muitos desenvolvedores em Python (no máximo, eu e mais um ou dois), e tenho certeza de que a rede de proteção de Java evita muitos problemas potenciais de gente mexendo onde não devia, chamadas erradas, etc… Mas como eu sempre trabalhei com pessoas de alto nível no SigaSeuTime e no Job4Dev, a eficiência do ciclo de desenvolvimento/deploy do Python (e das linguagens de script dinâmicas em geral) me parece ser muito vantajosa em um projeto onde o importante é desenvolver rápido para colocar em produção rápido.

E quando eu digo rápido, significa eventualmente resolver um bug no código em produção, através de um Vi ou Emacs rodando em um terminal SSH. Sim, eu já fiz isso mais de uma vez, para o desespero de muitos dos leitores deste blog e defensores de CMMIs da vida.

Grandes empresas precisam implementar processos e mecanismos de controle para organizar o crescimento (muitas vezes desordenado) de pessoas, muitas vezes acompanhado pela redução da qualidade média dos desenvolvedores.

Em ambientes pequenos de startup, onde é possível imaginar uma equipe apenas composta por boas pessoas, os controles e processos são desnecessários e muitas vezes indesejáveis. Neste contexto, todas aquelas preocupações enterprise padrões devem ser deixadas de lado, e os participantes do projeto devem focar suas energias em apenas duas coisas: tornar o projeto uma realidade e trabalhar para que ele seja viável economicamente. O resto é resto…

Estava relendo algumas notas antigas que eu faço para mim mesmo sobre comentários que as pessoas leitoras (e, eventualmente, editoras) deste blog fazem…

Na outra ponta, poderíamos pensar o seguinte: que tal se, ao invés de ter uma equipe de 12 pessoas em um projeto, o que levaria ter 12 pessoas que tenham familiaridade com um conjunto de ferramentas (e aí, obviamente, nos levando a escolher um framework), que tal diminuir a equipe para 3 ou 4 que sejam (a) mais experientes/produtivos e (b) capazes de utilizar ferramentas mais poderosas?

Com a ajuda de uma ferramenta de busca não foi difícil achar que este foi um comentário do Rapahel neste post aqui. Longe de querer reavivar aquela discussão, o que me veio à cabeça foi uma resposta, para mim simples, à pergunta, extremamente importante e sobre a qual já refleti diversas vezes, do Raphael.

Eu diria que o principal problema que eu vejo para não ter uma equipe de 12 pessoas medianas que tenham familiaridade com um conjunto de ferramentas e, no lugar disso, ter uma equipe de 3 ou 4 pessoas mais experientes e produtivas, capazes de utilizar ferramentas mais poderosas é porque é muito difícil contratar estas 3 ou 4 pessoas.

Já coordenei e participei como entrevistador em diversos processos de seleção e às vezes fico horrorizado com alguns currículos recebidos ou pessoas entrevistadas. Além disso, a quantidade de pára-quedistas que aparecem em processos seletivos é enorme. Pessoas que simplesmente não tem nada a ver com a vaga (e chegam a dizer isto explicitamente no currículo) mas que mesmo assim se candidatam a ela.

Por ser tão difícil de achar estes 3 ou 4, pelo fato de os projetos geralmente terem prazos apertados que não possibilitam perder muito tempo formando (ou contratando) uma equipe e, talvez, pelo preço de estes 3 ou 4 ser muito alto quando comparado com os 12 medianos, eu diria que provavelmente eu preferiria me manter com os 12 medianos se eles fossem capazes de entregar o projeto pronto do que gastar tempo e dinheiro buscando profissionais que talvez não apareçam, impactando, no fim das contas, o bom andamento do projeto que, no fundo no fundo, não precisava de pessoas qualificadas para ser entregue em um nível bom (mas não ótimo).

Agora, sinceramente, o que mais me preocupa não é está minha “equação” pragmática. O que mais me preocupa é realmente a dificuldade de se achar pessoas realmente boas. E isso eu acho que é culpa da formação e do interesse geral das pessoas naquilo que elas fazem. Coisa difícil de mudar num curto prazo.

Outro dia, num almoço com outros alunos de pós-graduação do Instituto de Computação da Unicamp, estávamos conversando sobre ferramentas de busca e o que elas fazem bem ou mal para nós.

Na verdade a conversa começou porque uma professora tinha pedido a mim para procurar o número de artigos que referenciavam três artigos que eu estava estudando. Esta é uma métrica bastante utilizada no meio científico para ver quão bom um artigo é. Quanto mais referências um artigo tem em um menor espaço de tempo indica quão mais importante para o meio acadêmico de uma forma geral são as idéias defendidas naquele artigo.

Para fazer esta busca, a professora sugeriu que utilizássemos uma ferramenta de busca desenvolvida especificamente para este propósito: o Citeseer. Basicamente o que esta ferramenta faz é buscar numa base de dados as informações sobre um artigo e as referências cruzadas que outros artigos catalogados na mesma base de dados tem com este artigo buscado. Fiz uma busca para os três artigos que eram meu foco e… nada. Não me lembro exatamente dos resultados, mas acho que um nem foi encontrado e os outros dois, apesar de terem sido encontrados, não eram referenciados por ninguém.

O problema, neste caso, era que eu estava trabalhando com artigos muito novos, publicados no final do ano passado. Como o Citeseer, se não me engano, nem utiliza uma base de dados própria, não havia tido tempo suficiente para esta base de dados, que é alimentada com dados de algumas das principais organizações de pesquisa do mundo (no caso de computação, por exemplo, ACM e IEEE), fosse devidamente atualizada pelos diversos intermediários até chegar ao pessoal do Citeseer.

Tentei, então, o CiteseerX, uma versão nova da engine do Citeseer que ainda está na versão beta. Sem sucesso também.

A minha última tentativa foi, então, o Google Scholar. Bom, ele pelo menos conseguiu identificar os meus artigos (provando mais uma vez que o Google realmente consegue indexar algumas coisas bem rápido). Mas ainda assim meus artigos não eram referenciados. Tudo bem. Eles eram novos e isso era de se esperar.

Mas ai, no meio disto tudo, veio à tona três perguntas interessantes: você já usou outra ferramenta de busca que não o Google? Se sim, quando e porque você mudou para o Google? Será que um dia vamos parar de usar o Google?

Muita gente que eu conheço sempre usou o Google. Acho que estas pessoas teriam ainda mais dificuldades de mudar de ferramenta de busca um dia, eventualmente, se isto acontecesse.

Bem, este não é o meu caso. E toda esta conversa que tivemos me fez lembrar de quando comecei a usar a Internet. Este ano faz quinze anos (nem eu imaginava que já era tanto tempo). Em 1994, a World Wide Web estava engatinhando ainda. As ferramentas de busca, idem.

Na verdade, em 1994 não existia nenhuma ferramenta de busca que merecesse este nome para falar a verdade. Naquela época, eu e muitos outros colecionávamos os endereços que achávamos mais interessantes. Eu tinha uma planilha que chegou a ter cerca de 200 endereços catalogados e divididos em categorias. Nesta época eu já via a necessidade de ter uma ferramenta de busca (que fosse uma busca na minha planilha), mas eu não tinha conhecimento técnico para fazer isto — infezlimente; se tivesse, talvez eu estaria milhionário hoje.

O fato é que, naquela época, agrupar endereços em diretórios era tudo o que dava para ser feito. Foi assim que nasceu, também em 1994, o “Jerry and David’s Guide to the World Wide Web”, que, ainda naquele ano passou a se chamar “Yet Another Hierarchical Officious Oracle” ou, simplesmente, Yahoo!. Mais da história inicial do Yahoo! pode ser encontrada aqui.

Eu não tive o prazer de acessar o site inicial de Jerry and David pelo meu navegador Mosaic (primeiro navegador existente e predecessor do Netscape 1.0). Mas a versão inicial do Yahoo! eu usei. Era o melhor que se tinha na época. Andei procurando no Internet Archive uma versão do site inicial do Yahoo!, onde só existia a estrutura de diretórios e nenhuma ferramenta de busca ainda. Mas nem mesmo o Internet Archive indexava páginas há tanto tempo atrás. A primeira home page do Yahoo! que existe lá é de outrubro 1996. Clique aqui para dar uma olhada (até os links funcionam! ). Nela existe a famosa estrutura de diretórios do início do Yahoo! (que deve existir até hoje) e uma ferramenta de busca (talvez a primeira da qual eu me lembre).

Eu parei de usar o Yahoo!, se não me engano, pouco antes de entrar na faculdade, em 1999. Naquela época já existia uma ferramenta de busca chamada AltaVista que conseguia atingir diversos sites que, aparentemente, não eram visitados ou corretamente classificados pelo Yahoo!. Como dizia o próprio slogan do AltaVista, ele era “The most powerful and useful guide to the Net”. O AltaVista ainda existe. Hoje ele é parte do Yahoo!, que, se não me falha a memória, em um determinado ponto no tempo comprou a engine do AltaVista para utilizar em suas próprias buscas. Eu, no entanto, não voltei a usar o Yahoo! como ferramenta de busca.

Até que, já lá para o meio do meu tempo de faculdade, muitas pessoas vinham me falar do Google. Com o tempo, as buscas que eu fazia no AltaVista já não pareciam tanto satisfatórias. E, quando eu, insatisfeito, ia até o Google e repetia a mesma busca, ele me retornava resultados melhores. Com o tempo, fui largando o AltaVista e passei a usar somente o Google.

Como já comecei a usar o Google quando ele era uma ferramenta estável, usei o Internet Archive para buscar as primeiras versões da página do Google. É interessante notar que a primeira página registrada para o Google no Internet Archive (que, neste caso, deve ser a primeira página deles mesmo) não era tão diferente da atual e o nome Google aparecia com um ponto de exclamação no final  (“Google!”)… será que isto tinha alguma coisa a ver com o então maior site de busca do momento “Yahoo!”? Yahoo!, inclusive, para o qual o engine criado por Larry Page e  Sergey Brin (fundadores do Google) foi oferecido e rejeitado, o que levou à criação do Google. Mas isto é outra história…

Bom, o fato é que o tempo foi passando e hoje o Google, para mim, está agregado em rotinas automáticas no meu computador. Para falar a verdade, não acesso mais a ferramenta de busca pela página web do Google já faz muito tempo. Uso apenas o plug-in de busca para o Firefox ou o Google Desktop para fazer isso. Com isto, fica cada vez mais difícil a mudança para outra ferramenta de busca, na minha opinião, pois tudo já está pronto e funcionando assim.

No entanto, isto não quer dizer que não existam outras opções. Ano passado foi lançado o Cuil (leia-se “cool”), um site de busca criado por ex-funcionários do Google. O grande diferencial do Cuil seria a não utilização da popularidade de uma página como item preponderante no cálculo de relevância da página, o que pode ser bem interessante em alguns casos, especialmente quando se busca conhecimento e não simplesmente popularidade. No entanto, eles mesmo adimitiam na época que não era necessário apenas uma boa ferramenta de busca: o maior trabalho estaria em quebrar a inércia dos usuários (a minha, por exemplo, como descrevi no parágrafo anterior, é bem alta).

Outra que sempre tentou desbancar o Google foi a Microsoft. Ano passado ela tentou comprar o Yahoo!. Não deu certo. Este ano ela lançou o Bing, sua nova ferramenta de busca. Apesar do visual mais bacana que o do Google (na minha opinião) e de ele vir embutido em vários produtos da Microsoft, isto não foi suficiente para mudar a inércia do usuário.

Sinceramente, eu acho que a única maneira de quebrar esta inércia do usuário em relação às ferramentas de busca que ele usa é criar algo que o Google ainda não oferece (não me pergunte o que… se eu soubesse não estaria escrevendo este post, mas sim implementando esta idéia ). Ou fornecer ferramentas de busca que retornem resultados mais aprimorados que os do Google em campos nos quais o Google talvez não seja satisfatório. Eu listaria como dois campos em que o Google está longe de ser satisfatório em relação às buscas, na minha opinião, as buscas por imagens e por vídeos. O “Santo Graal” nestas áreas, por mim, seria conseguir fazer busca não pelos textos das páginas em que as figuras ou os vídeos aparecem, mas sim fazer busca pelo significado das imagens e dos vídeos mesmo. Algo que eu acho que a computação ainda está um pouco longe de conseguir fazer de forma automática e eficiente.

Vários assuntos polêmicos rondam minha mente, mas a comunicação com o teclado anda complicada ultimamente. Por isso, vou comentar uma tira que acabei de ver no meu Reader, e que me lembra muito algo que acontece de forma recorrente comigo.

Minha esposa vira e mexe fica chateada comigo, quando me pede para que eu a ensine a fazer certas ações no computador, e eu digo que eu só sei fazer FAZENDO.Ela acha que eu tenho preguiça de explicar, e prefiro fazer sozinho para terminar rápido e voltar para o meu mundinho. A imagem acima define perfeitamente como nossa cabeça funciona: não sabemos fazer, mas sabemos como fuçar.

E fuçar computador é algo que assusta muita gente.

Me lembrei de um fato interessante. Logo no meu primeiro semestre da universidade, estava naquela empolgação de bixo que quer abraçar o mundo. Uma das coisas que me interessavam na época era participar da empresa júnior, por achar que me daria uma vivência computacional interessante. Em termos de empresa, nunca deu. Mas eu participei de alguns projetos ditos do terceiro setor divertidos. Um deles consistia em dar um curso de computação básica para comunidades carentes de Campinas.

O curso em questão era organizado por uma associação, e a primeira turma era de um bairro looooooooooonge pra burro. O laboratório foi montado (e bastante bem montado, diga se de passagem) em um mezanino de uma igreja do bairro em questão, com 10 máquinas doadas. A turma era bem heterogênea: ia desde crianças e adolescentes até donas de casa. Eu e uma colega íamos duas vezes por semana, por duas horas, ensinar Word e Excel básico.

Neste momento, uma pausa: quem me conhece sabe que eu sou um zero à esquerda de Word e Excel. Vivo dizendo que se meu emprego depender de pacote Office, eu estou ferrado. Mas como o curso era bem básico, achei que daria conta numa boa. E de fato, foi bem tranquilo.

Boa parte do conteúdo eu conhecia. Outra parte, eu decorava da apostila. Mas sempre, SEMPRE, alguém vinha me perguntar qual era a funcionalidade de algum menu bisonho escondido, que  eu nunca havia visto, e que não aparecia em nenhum lugar da maldita apostila. Minha reação era sempre a mesma: fazia uma cara de entendido, apertava o botão, e rapidamente deduzia sua funcionalidade:  isto funcionava em 99% do casos (nos outros 1%, eu dizia que não fazia idéia) e resolvia o problema do aluno.

Eu não aprendi muita coisa de pacote Office na época, e não sei se eles aprenderam. Mas com certeza foi uma experiência de vida e de contato com a realidade muito boa.

O Twitter já foi tema de alguns posts aqui no log4dev. E, é claro que, como um bom blog de tecnologia que pretendemos ser (um dia a gente chega lá), não podíamos deixar de falar deste fenômeno da famigerada “rede mundial de computadores, a Internet” (como diria o William Bonner no Jornal Nacional). Ainda mais considerando que esta é a rede social que mais rapidamente cresce na Internet. Dá uma olhada neste gráfico gerado pela comScore:

Passar de menos de 2 milhões de usuários no começo do ano passado para mais e 30 milhões este ano é algo realmente surpreendente. É um crescimento maior que o Facebook, a rede social mais famosa ultimamente fora do Brasil (aqui o Orkut ainda reina).

O editor-chefe deste blog, sempre atento às novidades no mundo da tecnlogia, não ficou para trás. O log4dev também tem twitter: http://twitter.com/log4dev.

Mas eu, sinceramente, ainda continuava me perguntando para que servia esta ferramenta. O Twitter se diz ser uma ferramenta de micro-blog cujo principal propósito é dizer o que você está fazendo agora. Pois bem. Para mim, com uma ferramenta de blog normal eu também consigo fazer micro-blog (é só não ser tão prolixo quanto eu costumo ser). Mas, tudo bem, a integração com SMS (que até onde eu sei não funciona com nenhuma operadora de celular no Brasil) pode parecer algo que chame a atenção. Agora… dizer o que eu estou fazendo agora? Para que? Mas, enfim, eu sempre parecia um peixe fora d’água, velho e não antenado com as novidades.

Há pouco tempo fiquei até mais feliz quando li um artigo que dizia que o Twitter ainda buscava seu foco como algo realmente útil e que, aparentemente, ele não estava sendo tão bem aceito como ferramenta para jornalismo (alguns jornais nos EUA estavam lançando títulos de reportagens no Twitter mas parece que isso não chamou a atenção de muitas pessoas). Ao que parecia, segundo o artigo, ele vinha tendo muito mais sucesso como uma ferramenta publicitária. Aliás, sempre achei que este poderia ser um foco mais interessante para o Twitter. Mas eu ainda não conseguia decifrar a maior parte do tráfego do Twitter: as milhões de pessoas que entram lá para, realmente, dizer o que estão fazendo.

Até que recebi este vídeo de um amigo meu que conseguiu externalizar tudo o que eu sempre pensei sobre o Twitter mas nunca soube como falar:

Ou seja, o Twitter, tirando estas outras utilidades que eu citei e que provavelmente não correspondem a quase nada do tráfego deles, nada mais é do que uma ferramenta para aliviar a carência de indivíduos que não tem nada de mais útil para fazer além de achar que sua vida sem graça tem algum sentido para os outros.

Se isso é bom ou ruim? Para a humanidade eu acho isso ruim porque as pessoas tendem a ficar cada vez mais superficiais (já existem estudos falando que as gerações mais jovens não conseguem se concentrar de maneira satisfatória em torno de um texto muito grande ou muito complexo porque está ficando acostumada a interagir apenas com texto rápidos e, em geral, superficiais). Para o indivíduo… bom, sei lá! Depende de cada um. O importante é ser feliz!

P.S.: Desculpem-me pelas falhas de referências no texto… não me lembro onde li o artigo que falava que jornais estão tendo menos sucesso no Twitter que empresas de publicidade e o outro que falava que os jovens estão com cada vez mais dificuldades para ater grandes quantidades de informações estruturadas. É que, apesar de eu não usar Twitter, eu sou um leitor assíduo, inverterado e completamente ad hoc de artigos e coisas do gênero que são rápidas de ler na Internet. E lembro vagamente de onde li estas coisas. Imagina se eu usasse o Twitter!

Ah! Antes que eu me esqueça. Eu tenho um Twitter: http://twitter.com/laggarcia. Tenho 14 seguidores. Que nunca tiveram o prazer de ver eu escrever nada lá!

Citando frase do Chef Francês Alain Poleto, em entrevista para o especial Brasil-França da Revista Carta Capital:

Com técnica, você entende o que está fazendo. Um bom chef não aprende receitas, mas bases, e depois cresce.

Nota do Editor: Alegoria, segundo a Wikipedia

Uma alegoria (do grego αλλος, allos, “outro”, e αγορευειν, agoreuein, “falar em público”) é uma representação figurativa carnavalesca que transmite um outro significado que o da simples adição ao literal. É geralmente tratada como uma figura da retórica.

Outro dia eu tive que ir ao banco. Isto já é um negócio que eu não gosto muito. Porque em geral o atendimento é demorado e não é muito bom.

O pior é que desta vez o atendimento foi pior ainda. Se é que é possível. Simplesmente porque enquanto me atendia a mocinha insistia em continuar suas conversas (provavelmente pessoais) no MSN!!! Ou seja, entre uma e outra coisa que ela fazia para mim no computador, ela interrompia o processo e digitava um pouco no MSN ou lia as respostas de suas conversas! Fiquei indignado.

Eu sou totalmente contra empresas que bloqueiam o acesso à Internet para seus funcionários. Eu acho a rede uma ferramenta de trabalho muito poderosa. E sou contra também bloquear programas de mensagens instantâneas porque acho que eles podem ajudar muito no dia-a-dia do trabalho. Eu mesmo sou um usuário deste tipo de aplicativo. Mas as pessoas tem que ser mais conscientes. Depois elas ficam por ai reclamando que sua empresa proíbe o uso de mensagens instantâneas… O fato é que todos os funcionários acabam pagando por causa de algumas pessoas, como a mocinha que me atendeu, que não têm consciência e utilizam os recursos de maneira equivocada.

E para aqueles que acham que não dá pra saber o que você anda fazendo na Internet do trabalho, saibam que hoje em dia é extremamente comum (e fácil) monitorar o que os funcionários fazem na rede. E, mais ainda, não é ilegal para uma empresa fazer este tipo de monitoramento e até usá-lo para punir seus funcionários. Afinal de contas ela pagou pelo seu tempo (e seu trabalho) e ela te forneceu os equipamentos para acesso à rede.

Uso consciente, de qualquer coisa, sempre faz bem!