Archive for the 'leitura' Category

Resenha: A Cauda Longa

Há quinze anos atrás, se eu quisesse escutar algum programa de notícias ou entrevistas poderia usar um rádio para escolher dentre algumas dezenas de opções no máximo. A maioria delas seria inevitavelmente sobre política, impostos ou gente famosa. Esses assuntos interessam a basicamente todo mundo e os limites físicos dos canais de distribuição da época forçavam os produtores a apostar apenas nos programas que pudessem atrair a maior quantidade possível de ouvintes — e, por conseqüência, anunciantes. Há somente tantas freqüências FM disponíveis e o dia só tem 24 horas. Se eu quisesse escutar um programa sobre interesses um pouco mais específicos (como carpintaria ou eletrônica, por exemplo), teria que me contentar com algum horário de madrugada ou desistir da busca. O famigerado “horário nobre” estava sempre ocupado com os mesmos assuntos que interessavam a todo mundo.

Ao avançar para o século XXI nos deparamos com um cenário completamente diferente. Agora já não é mais tão difícil encontrar um podcast sobre qualquer assunto na face da terra — incluindo carpintaria e eletrônica. Melhor ainda: posso armazenar meus programas favoritos em um tocador portátil e escutar na hora que quiser. Posso até mesmo descobrir um novo programa hoje e baixar todo o conteúdo arquivado dos últimos dois anos. Enfim, posso ter uma rádio regulada especificamente para meus interesses fornecendo conteúdo num fluxo contínuo e sem fim. Isso é bom tanto para os consumidores, que têm acesso a conteúdo interessante de maneira personalizada, como para os produtores, que não precisam abordar sempre os mesmos assuntos repetidos. Eles podem ser tão especializados quanto quiserem que vão encontrar pelo menos uma dezena de ouvintes interessados em um assunto de nicho.

No fundo, A Cauda Longa de Chris Anderson é um livro sobre prateleiras e como elas evoluíram para tornarem-se virtualmente infinitas. Quando se tem limites físicos para a exposição dos produtos — como nas prateleiras de um super-mercado ou no espectro de tempo de uma rádio FM, faz sentido apostar apenas nas opções mais populares, nos campões de vendas. Você precisa garantir que o espaço será bem aproveitado e não tem muita folga para arriscar. Esse modelo de distribuição acaba criando um círculo vicioso: as pessoas só consomem o que está disponível e os distribuidores só disponibilizam o que as pessoas consomem.

Mas se as prateleiras fossem infinitas, poderíamos exibir todos os produtos e deixar o público escolher. Obviamente ainda haveriam grandes campeões de vendas, mas com uma diferença: eles seriam medidos, não induzidos. Seriam escolhidos pelo público, não por uma aposta dos distribuidores.

Acontece que é exatamente isto que vem acontecendo nas últimas décadas. As lojas online e os meios de distribuição modernos estão tornando as prateleiras virtualmente infinitas. Não há quantidade máxima de livros que cabem numa livraria na web. Não há músicas demais que não caibam na loja do iTunes. Não há DVDs demais para a Netflix. Os distribuidores modernos podem trabalhar com o todo o espectro de produtos, ao invés de serem obrigados se concentrarem somente nos grandes sucessos. Como nos mercados de cauda longa o custo de distribuir um campeão de bilheteria é o mesmo de um produto de nicho, não há necessidade de tentar adivinhar quais serão os grandes sucessos. Há tantas ou mais oportunidades nos produtos de nicho — milhares de produtos que individualmente atraem algumas dezenas de pessoas — quanto nos grandes sucessos — algumas dezenas de produtos que sozinhos arrastam multidões.

Anderson identifica três forças principais que possibilitam esses mercados de cauda longa. A primeira é a democratização das ferramentas de produção, o que torna qualquer pessoa com um computador um produtor de conteúdo em potencial. A segunda é a democratização da distribuição, que permite aos produtores oferecerem seu conteúdo a um público realmente interessado nele. A terceira força são os filtros de distribuição. Eles ajudam a conectar os produtores ao público interessado no seu trabalho e vão desde os recursos de “itens relacionados” em sites como Amazon, Submarino e Youtube até a boa e velha propaganda boca-a-boca. Sem eles, toda essa oferta de produtos de nicho não passaria de uma grande fonte de ruído e ninguém acharia o que procura. Afinal de contas, meus interesses de nicho são diferentes dos seus interesses de nicho. Por isso são chamados de interesses de nicho, ora bolas!

A diferença entre a propaganda boca-a-boca de hoje e a de quinze anos atrás é o fato da Internet ter colocado um megafone na mão de cada pessoa. Agora é muito mais fácil indicar conteúdo e produtos a pessoas com interesses parecidos. Se você não viu o vídeo do “cara que não tá legal não”, por exemplo, você não é o público-alvo dele (ou então talvez você seja, e acabou de descobrí-lo). E não é preciso nem ter um blog para ter esse tipo de poder: todo mundo está indicando produtos para pessoas com interesses similares quando compra um produto em qualquer loja online.

Há uma citação de David Foster Wallace no capítulo sobre televisão e distribuição de vídeo que resume muito bem o espírito da cauda longa:

A televisão é como é simplesmente porque as pessoas tendem a ser extremamente semelhantes em seus interesses vulgares, lúbricos e parvos, e muitíssimo diferentes em seus interesses refinados, estéticos e nobres.

As coisas que são medianamente interessantes para você também o são para muitas pessoas. É disso que são feitos os grandes sucessos: fórmulas comuns que atraem muita gente mas não com tanta força. Por isso novelas fazem sucesso. Por isso todas novelas parecem ser iguais. A diferença nas coisas altamente interessantes é só serem altamente interessantes para poucas pessoas. Os assuntos mais atraentes para uma pessoa são verdadeiras chatices para a próxima. Os assuntos pelos quais somos realmente apaixonados atraem pouca gente, mas com muita força. É disso que é feita a cauda longa.

Tradução: A outra metade de “Artistas publicam”

Não costumo fazer traduções porque em geral não gosto delas: a maioria parece um arremedo do original e quando prestam você está no máximo lendo o texto do tradutor e não o do autor. Mas o texto “The other half of ‘Artists ship'” do Paul Graham é tão bom que não consegui me segurar. Tecnicamente o que vem aí abaixo é mais uma versão do que uma tradução (o original, por exemplo, não tinha nenhuma referência nem tantas ênfases em itálico): uma versão minha para o que o autor disse que pode inclusive não ter nada a ver com o que ele quis dizer. Então o que você vai ler aqui não é exatamente o que o Graham escreveu originalmente. Portanto, se você se sente à vontade para ler textos em inglês, vá em frente, clique no link acima e esqueça a minha versão. Caso contrário, corra para aprender inglês — todo programador que se preza sabe ao menos ler inglês — e contente-se com minha versão ridiculamente patética neste meio-tempo.

Uma das muitas diferenças entre as empresas grandes e as pequenas é que as grandes tendem a desenvolver procedimentos de auto-proteção contra erros. Uma empresa que está iniciando anda mais ou menos como um bebê: esbarra nas coisas e cai o tempo todo. Empresas grandes são mais ponderadas.

O acúmulo gradual de verificações em uma organização é um tipo de aprendizado baseado nos desastres que aconteceram com ela mesma ou com organizações parecidas. Depois de assinar um contrato com um fornecedor que declara falência e não entrega o que deveria, por exemplo, uma empresa pode passar a exigir que todos os fornecedores provem sua solidez antes de fazerem uma oferta.

À medida que as empresas crescem elas invariavelmente desenvolvem mais dessas verificações, seja em resposta a desastres que sofreram ou, provavelmente com mais freqüência, por contratar pessoal oriundo de empresas ainda maiores que trazem consigo seus dispositivos de proteção contra tipos de desastres novos.

É natural que as organizações aprendam com seus erros. O problema é que quem propõe novas verificações quase nunca considera que a verificação em si tem um custo.

Toda verificação tem um custo. Considere, por exemplo, o caso de exigir que os fornecedores comprovem solidez. Parece mera prudência, não? Mas na realidade pode ter custos significativos. Existe obviamente o custo direto de tempo de gente dos dois lados para fornecer e verificar provas de solidez. Mas os custos que realmente importam são os que nunca chegamos a conhecer. Como, por exemplo, a empresa que seria a melhor fornecedora, mas não se candidata porque não pode se dar ao luxo de despender o esforço necessário para ser verificada. Ou a empresa que seria a melhor fornecedora, mas fica logo abaixo do limite considerado para a solidez — que obviamente foi puxado para cima, já que não há nenhum custo aparente para aumentá-lo.

Sempre que alguém em uma organização propusesse uma nova verificação, deveria ter que explicar não só o benefício mas também o custo. Não importa quanto o trabalho de análise fosse ruim, esta meta-verificação iria ao menos lembrar a todos que deve haver um custo e fazê-los procurar por ele.

Se as empresas começassem a fazer isso, encontrariam algumas surpresas. Joel Spolsky palestrou recentemente na Y Combinator sobre venda de software para clientes corporativos. Ele disse que na maioria das empresas software que custe até aproximadamente $1.000 dólares pode ser adquirido pelos gerentes sem necessidade de aprovações adicionais. Acima desse limite as aquisições de software geralmente precisam ser aprovadas por um comitê. Mas bajular esse processo é tão custoso para os fornecedores de software que não faz sentido cobrar abaixo de $50.000 dólares. O que significa que se alguém produz algum produto pelo qual normalmente cobraria $5000, acaba sendo obrigado a vender por $50.000.

O propósito do comitê presumivelmente é garantir que a empresa não desperdice dinheiro. Apesar disso, o resultado é que eles acabam gastando dez vezes mais.

Verificações de aquisição vão sempre ser caras, porque quanto mais difícil for fazer você comprar algo, mais o preço vai aumentar. E não necessariamente linearmente. Se for suficientemente difícil lhe vender algo, quem for o melhor em fazer as coisas simplesmente não vai querer perder tempo. Os únicos que vão vender para você são as empresas especializadas em vender para você. Quando chega a este ponto você já está afundado em um nível inteiramente novo de ineficiência. Os mecanismos de mercado normais não vão lhe proteger, porque os bons fornecedores nem estão mais no mercado.

Essas coisas acontecem o tempo todo nas maiores de todas as organizações: governos. Mas verificações estabelecidas por governos podem causar problemas bem piores do que superfaturamento. Verificações estabelecidas por governos podem aleijar toda a economia de um país. Até mais ou menos 1400, a China era mais rica e tecnologicamente mais avançada que a Europa. Uma das razões para a Europa ter conseguido ultrapassar foi que o governo chinês restringiu viagens de comércio longas. Com isso só sobraram os europeus para explorar e eventualmente dominar o resto do mundo. Incluindo a China.

Mais recentemente, a lei Sarbanes-Oxley praticamente destruiu o mercado americano de ofertas públicas. Essa não foi a intenção dos legisladores que a escreveram, eles simplesmente queriam acrescentar algumas verificações sobre empresas públicas. Mas esqueceram de considerar o custo. Esqueceram que empresas na iminência da abertura geralmente estão com os cintos bem apertados, e que o peso de algumas verificações a mais pode ser fácil para a General Electric enfrentar mas são o que basta para evitar que empresas mais jovens sequer considerem uma oferta pública inicial.

Quando você começa a pensar no custo das verificações, começa a fazer outras perguntas interessantes. O custo está aumentando ou diminuindo? É mais alto em algumas áreas do que em outras? Onde ele cresce de forma descontínua? Se grandes organizações começassem a fazer perguntas desse tipo, descobririam algumas coisas bem assustadoras.

Eu acredito que o custo das verificações está na verdade aumentando. O motivo é que o software ocupa uma posição importante nas empresas, e que as pessoas que escrevem software são atingidas de um modo peculiar pelas verificações.

Programadores são um tipo de trabalhador diferente na medida em que os melhores preferem trabalhar duro. Este não parece ser o caso na maior parte das ocupações. Quando trabalhei com fast food, nós não preferíamos os tempos atarefados. E quando aparava gramados, eu definitivamente não preferia quando a grama estava alta depois de uma semana de chuva.

Programadores, no entanto, gostam quando escrevem mais código. Ou, mais precisamente, quando publicam mais código. Programadores gostam de fazer a diferença. Os bons, pelo menos.

Para os bons programadores, um dos melhores aspectos de trabalhar para uma empresa pequena é que há poucas verificações para publicação. Em empresas iniciantes, não há nenhuma verificação externa. Se você tiver uma idéia para um recurso novo pela manhã, pode escrevê-lo e enviar para os servidores de produção antes do almoço. E quando pode fazer isso, você acaba tendo mais idéias.

Em empresas grandes, o software precisa atravessar várias aprovações antes de poder ser liberado. E o custo de fazer isso pode ser enorme. Eu estava conversando recentemente com um grupo de três programadores cuja empresa havia sido adquirida há alguns anos por uma empresa grande. Quando eram independentes, eles podiam liberar modificações instantaneamente. Agora, eles disseram, o mais rápido que poderiam disponibilizar o código nos servidores de produção é em duas semanas.

Isto não os tornou simplesmente menos produtivos. Fez com que odiassem trabalhar para o comprador.

Aqui vai uma evidência do quanto os programadores gostam de poder trabalhar duro: esses caras pagariam para poder publicar código de imediato do jeito que estavam acostumados. Perguntei se eles trocariam 10% do preço de aquisição pela habilidade de publicar código de imediato e todos os três instantaneamente disseram que sim. Então perguntei qual seria a percentagem máxima do preço de aquisição que trocariam. Eles disseram que preferiam não pensar nisso, pois não queriam descobrir o quão alto iriam, mas tive a impressão que seria mais ou menos a metade.

Esse pessoal teria sacrificado centenas de milhares de dólares — talvez milhões — só para poder disponibilizar mais software para os usuários. E sabe de uma coisa? Seria perfeitamente seguro permitir que o fizessem. Na verdade, o comprador estaria bem melhor; não somente esses caras não quebrariam nada, eles teriam conseguido fazer muito mais. No fim das contas o comprador está tendo performance mais baixa a custo mais alto. Do mesmo jeito que o comitê que aprova aquisições de software.

Assim como o maior perigo de ser difícil de ser convencido a comprar não é pagar superfaturado, mas o fato dos melhores fornecedores nem mesmo quererem vender para você; o maior perigo de aplicar verificações demais a seus programadores não é torná-los improdutivos, mas fazer que os bons programadores nem mesmo queiram trabalhar para você.

A famosa máxima de Steve Jobs “artistas publicam” é aplicável nos dois sentidos. Artistas não são somente capazes de publicar. Eles insistem nisso. Assim, se você não deixar as pessoas publicarem, não terá nenhum artista.

Resenha: Por que as pessoas de negócios falam como idiotas?

Num mundo onde o jargão e o palavreado vazio são a regra, expressar-se claramente e com objetividade pode ser um tremendo diferencial. Quando todos se esforçam para parecer iguais, ser a exceção garante um lugar de destaque e “Por que as pessoas de negócios…” é um livro que convence a aproveitar-se dessa situação.

O livro é estruturado em quatro partes, cada uma dedicada a uma das armadilhas: obscuridade, anonimato, venda agressiva e tédio. Na maioria das vezes as pessoas querem ser claras, mas o ambiente corporativo que as cerca não é exatamente um meio que as incentiva para isso. Na verdade, o caminho mais natural neste mundinho parece ser exatamente o contrário. Por isso o texto fala de armadilhas, são coisas que nos capturam sem que notemos e das quais ninguém se aproxima de propósito.

Acontece com todo mundo. Tem o gerente que quer parecer mais inteligente que os outros usando algumas palavras difíceis, como “aculturamento”, “objetivar” e “endereçamento”, mas que no fim das contas só deixa de ser compreendido. Qual o problema com “endereço”, afinal?

Tem também o programador sempre ligado na evolução da computação mundo afora que de tanto ler em inglês começa a escrever como se seus textos em português tivessem passado por um tradutor automático dos mais fraquinhos. Parece que o português está ficando obsoleto (ou seria “depreciado”?). O negócio agora é dificultar a compreensão falando portuglês através de expressões como “sistema irresponsivo” ao invés de “sem resposta” ou “comer a própria comida de cachorro” ao invés de “provar do próprio remédio”. Ou até perpetuar traduções tortas como “aplicativo de missão crítica”, que já vem da expressão completamente desprovida de significado “mission critical application” e deveria ser “aplicativo crítico para a missão”.

Muita gente deixa a personalidade em casa quando sai na segunda-feira de manhã e veste um manto de obscuridade disfarçado de profissionalismo junto com a roupa do trabalho. Por causa do ambiente esterilizado da vida corporativa, pensam que precisam deixar aquela pessoa engraçada bem longe e tornarem-se uma versão pausterizada de si mesmos oito horas por dia, cinco dias por semana.

O livro tenta mostrar sempre com muito bom humor quais são as armadilhas mais comuns do discurso corporativo e insiste no argumento de que são exatamente isso: armadilhas. As pessoas não se esforçam para parecer evasivas e vazias de propósito. É bem verdade que às vezes elas querem realmente sair de alguma saia justa, mas isso não acontece todo dia. Portanto, da próxima vez que vir alguém se perdendo com termos esquisitos como “governança” e “missão crítica”, controle a raiva e não ataque ninguém. Ao invés disso, alerte a pessoa para o fato de que talvez os outros não a estejam entendendo muito bem e que talvez seja interessante mudar um pouco o estilo de comunicação.

Por falar nisso, se isso acontecer aqui neste blog, por favor não hesite em avisar. Eu não vou achar que você está sendo implicante nem chato. Prometo.

Blog novo

Quem costuma acompanhar este blog já deve ter notado que de vez em quando cito Ruby em um exemplo ou outro e às vezes analiso algum aspecto da linguagem. Porém nunca dediquei muito tempo à linguagem, bibliotecas associadas e nem a frameworks interessantes. Nunca escrevi nenhum tutorial, fiz resenha de nenhuma biblioteca nem publiquei novidades sobre Ruby por aqui.

Para estas e outras coisas relacionadas a Ruby vai servir o Minerama. Este novo blog foi uma idéia do João Paulo Lins e estou entrando junto com ele nessa com o objetivo de criar mais um ambiente colaborativo para aprendizado de Ruby (como se já não houvesse milhares). Por “colaborativo” quero dizer que vamos aceitar textos assinados por outros autores. Este é um blog verdadeiramente multi-autor e espero conseguir algumas colaborações bastante interessantes. Por enquanto só há um texto introduzindo os objetivos do projeto, mas não vai demorar para começar a aparecer novidades.

Por fim, não, eu não abandonei nem pretendo abandonar o Mergulhando tão cedo. Apesar de um mês e meio ser um bocado de tempo sem textos novos, pretendo voltar a publicar dentro de uma semana no máximo. Quem preferir pode “ficar no aguardo”, mas fico feliz se você só esperar um pouco. (Notaram como ninguém mais “aguarda” ou “espera”? Todo mundo agora só “fica no aguardo.” Parece que o corporativês vai dominar o mundo mesmo.)

Resenha: The Pragmatic Programmer

Acabei de ler um dos clássicos da literatura de desenvolvimento de software: The Pragmatic Programmer, de Andy Hunt e Dave Thomas. Os nomes na capa não são esses, mas os caras já são figuras tão carimbadas que todo mundo já conhece os apelidos.

Este livro deve ser um dos maiores culpados pela disseminação — e posterior perda de significado — do termo “pragmático”. A essa altura a palavra já percorreu todo o caminho rumo à terra perdida dos termos de efeito. Talvez a intenção original dos autores tenha sido boa, mas a decisão de usar o termo como um tipo de marca registrada (Pragmatic Press, Pragmatic Unit Testing, etc.) com certeza não ajudou a preservar o significado original.

Não é à toa que o livro é indicado pelos melhores programadores que conheço e virou um clássico moderno. A desvirtuação do termo muito provavelmente foi conseqüência disso: muita gente talentosa comentando e muita gente não tão talentosa assim lendo somente o prefácio. Os capítulos são auto-contidos e parecem muito com textos de blogs (e digo isso como elogio). O estilo é bem informal, gostoso de ler e sempre abarrotado de referências relevantes — tanto internas quanto externas (uma das piores coisas do mundo é gente que só faz referência ao próprio trabalho).

As páginas estão repletas de conselhos sábios de dois dos mais geniais praticantes da arte da programação. Lá pode-se encontrar as práticas óbvias que sempre são ignoradas como usar controle de versão para tudo, preferir formatos de texto puro e dominar um ambiente de linha de comando. Além disso há discussões sobre como organizar equipes, sobre linguagens específicas de domínio e, claro, o mundialmente famoso princípio DRY. Não se vê citações de institutos de pesquisa obscuros para provar nenhum argumento. Ao invés disso, tudo é muito bem argumentado com bastante lógica, sensatez e experiência.

O texto é digerível para os novatos sem se tornar entediante para os veteranos. Às vezes é necessário dar um desconto para o tom fundamentalista do texto (o que é um certo paradoxo para algo com o termo “pragmático” no título), mas em geral a relevância dos conselhos é das mais altas. Este certamente é um daqueles livros que todo programador deveria ler e reler periodicamente.

Blogday 2007

O José Oliveira indicou este blog (junto com outros quatro) em um texto publicado como parte da iniciativa BlogDay 2007. Ele não especificou se isto é algum tipo de meme, mas tem todas as características de um. Parece que estou meio atrasado, já que o tal dia foi na última sexta-feira (dia 31), mas vou usar isto como desculpa para indicar cinco blogs que acompanho de qualquer modo (em nenhuma ordem em particular):

Motor curiosidade — Novo blog do Marcos Pereira sobre desenvolvimento de software e essa vida de programador. Promete ser extremamente interessante, a julgar pela qualidade dos dois primeiros textos e pelos textos dele no blog antigo.

Coding Horror — Talvez um dos blogs mais discutidos no pequeno círculo dos programadores. Jeff Atwood costuma abordar com acidez e bom humor assuntos relacionados a tecnologia que vão desde a relevância dos jardins gradeados na internet até como montar uma máquina silenciosa.

Danilo Sato — Para quem quer estar por dentro das últimas novidades em matéria de agilidade e sempre de olho no mundo acadêmico. Danilo costuma freqüentar conferências ágeis (e também algumas não tão ágeis assim) e relata as experiências neste blog, junto com muitos pensamentos úteis.

Thinking Parallel — Mesmo para quem acha que este barulho todo sobre paralelização é só mais uma onda, não custa nada acompanhar o blog do Michael Suess. Apesar dele ser um pós-doutorando, seus textos passam longe do academiquês e costumam ser dos mais digeríveis sobre o assunto.

{ | one, step, back | } — Jim Weirich não é tão conhecido (e forçadamente controverso) quanto David Hansson, mas é uma das figuras mais relevantes quando o assunto é Ruby. Se você programa em Ruby, mesmo que ainda não tenha ouvido falar no cara, já deve ter usado rake ou builder, duas ferramentas criadas por ele.

Twitter, eu me rendo

Twitter é um serviço para publicação de mensagens curtas. As pessoas usam todo tipo de aparelho eletrônico para responder a famigerada pergunta “O que você está fazendo?”. As mensagens precisam caber em 140 caracteres. Isso, além de possibilitar mensagens rápidas enviadas de aparelhos celulares, faz com que todo mundo se concentre em dar o recado com poucas palavras.

Quando tomei conhecimento do Twitter, minha reação inicial foi questionar porque diabos alguém iria querer saber o que eu estou fazendo. Eu definitivamente não estou nem aí para o que milhares de anônimos com acesso à Internet estão fazendo agora. Afinal de contas, esse é mais ou menos o mesmo propósito de um blog-diário, só que mais instantâneo.

Mas eu estou muito interessado em aprender com eles. Não importa quem sejam, se eles podem falar algo sobre um assunto que me interesse, quero pelo menos tentar escutar.

Eu tenho o hábito de compartilhar pensamentos rápidos com as pessoas através de mensagens curtas. Todo mundo que está na minha lista de contatos em alguma rede de mensagens instantâneas já deve ter recebido uma dessas (geralmente acompanhadas de um link). Este meio é muito bom para compartilhar estes estalos, momentos eureka e pequenas descobertas. Porém estas mensagens simplesmente querem ser públicas e não gostam de ficar confinadas entre duas pessoas apenas. Uma das maiores evidências que tenho disso é o fato das minhas mensagens nunca serem enviadas para uma pessoa só. Ao invés disso, quase todo mundo que está on-line no momento recebe uma cópia. Além disso, muitas vezes também tenho vontade de publicar as mensagens neste blog aqui, só não acho que seja a mídia mais apropriada.

Assim como aconteceu com os blogs, eu deixei minha impressão inicial de lado e descobri que um serviço de mensagens públicas não precisa ser usado para futilidades e pode ser muito útil para compartilhar estes pensamentos breves. Faz muito sentido tornar público aquilo que não se tem certeza a exatamente quem pode interessar. Assim as pessoas podem escolher por si mesmas o que ler. Por cima disso tudo, como uma cobertura especial, está o robô de mensagens instantâneas que me permite manter a mesma forma de publicação que usava antes. Ou seja, eu não preciso entrar em algum site especial para publicar minhas mensagens, posso usar meu serviço de mensagens instantâneas favorito como sempre fiz. Só que agora ao invés de mandar uma mensagem para uma ou duas pessoas que eu escolher, posso “falar” apenas com o robô e as pessoas podem escolher me dar um segundo da sua atenção ou não.

Portanto, quem quiser acompanhar alguns devaneios mais curtos do que normalmente encontra aqui neste blog, é só seguir para http://twitter.com/thiagoarrais e quem recebia minhas mensagens de vez em quando só vai ser importunado se quiser. Lá ninguém vai encontrar muita coisa sobre o que eu estou fazendo agora, mas pode ter uma idéia do que estou pensando.

P.S.: Não consegui achar um artigo na wikipedia em português sobre a palavra “Eureka”. Será que alguém tomaria o tempo para começar um?

Blogs-diário, blogs-opinião e minha tentativa como entrevistador

Tem um tipo de blog pelo qual tenho uma ojeriza tremenda: o blog-diário. Acho que eles já pararam de fazer isso (porque migraram para os sites de relacionamento), mas sabe aqueles blogs de adolescentes cujos artigos costumam ser sobre a festinha de ontem ou a bronca que o professor passou na turma hoje mais cedo? Sabe aqueles blogs cujos artigos mais elaborados são aqueles que têm uma letra de música qualquer que o autor e seus amiguinhos estavam escutando no dia (e mais nada)?

Este tipo de coisa não acontece somente com garotos e garotas de 14 anos, alguns blogueiros na área de tecnologia também estão infectados com a mesma doença. Neste caso os assuntos mudam um pouco. Passam a ser sobre o último release dos seus projetos, as conferências mais badaladas e os encontros de grupos de usuários locais. Eles podem não notar, mas estão agindo do mesmo modo que os adolescentes. Estão somente publicando um diário de bordo.

Acho que blogs deveriam ser um meio para publicar opiniões e vê-las serem destrinchadas, atacadas e testadas. Se estivéssemos em uma revista semanal, os blogs deveriam ser mais como uma coluna ou um editorial do que como o resumo da semana. Os leitores não querem saber o quanto o autor é inteligente, produtivo ou como tem sucesso em tudo que resolve fazer. Ao invés disso, um blog deve ser um espaço para o autor ajudar os leitores a se tornarem mais inteligentes, produtivos e a terem mais sucesso em tudo que resolverem fazer.

Apesar disso tudo, acabei caindo nesta armadilha em conseqüência da correria nossa de cada dia. Se você consultar os históricos aqui do blog, vai ver que os dois últimos artigos anteriores a este se encaixam perfeitamente no que eu descrevi como artigos de blog-diário. O último é só um anúncio de reunião de grupo de usuários e o penúltimo uma bela de uma babada em meu próprio trabalho juntamente com o anúncio da publicação do Motiro (não consegui resistir a mais um link). Mas o sinal mais alarmante de que eu estou usando meu blog como um diário é que este mesmo artigo que você está lendo agora também é só mais uma anotação de diário.

Sim, eu publiquei toda esta introspecção e fiz você ler até aqui somente para anunciar que participei da entrevista que o Eduardo Fiorezi fez com o Vitor Pamplona. Foi bastante gratificante receber um segundo convite para o programa do Eduardo, principalmente por ter sido surpreendido com uma posição de entrevistador ao invés de entrevistado e pela estrela do programa ser uma figura tão relevante.

Espero que com estes três últimos artigos eu não tenha perdido metade da minha audiência, mas prometo que vou fazer de tudo para que o próximo revele algum pensamento interessante sobre tecnologia.

Por enquanto, um anúncio de entrevista disfarçado de reflexão é tudo que tenho a oferecer.