Não é a primeira vez que recorro ao cinema para passar a mensagem.

“I never think about the audience. If someone gives me a marketing report, I throw it away.”

Andrew Stanton, criador de Wall-E

A idéia deste artigo é tentar capturar dicas, conselhos e experiências dos leitores deste blog, para benefício próprio - e quem sabe de outros que talvez tenham o mesmo problema.

Há pouco tive uma conversinha rápida com o Miguel no GTalk, acabamos falando de planos futuros, projetos pessoais, etc e tals. E ele estava descrevendo que estava bastante contente com a concretização de alguns projetos pessoais, como aprender Python, Job4Dev, SigaSeuTime, fotografia, entre outros. Neste instante, comentei que admirava a sua disciplina, pois apesar de ter alguns planos, não conseguia me dedicar à execução dos mesmos se não tivesse alguma obrigação embutida.

Para tornar mais claro, vou dar dois exemplos pessoais que ilustram bem este problema:

1. Estava com o firme propósito de aprender Lisp para fazer desenvolvimento web (curiosidade pessoal gente, não atirem pedras, por favor). Comecei a estudar, brincar um pouco, e “puff”. O plano empacou. Não consegui me dedicar mais ao mesmo
2. decidi que era o momento de aprender estatística - me inscrevi como aluno especial em uma matéria sobre o tema na Esalq, e voilá … estou aprendendo.

Outro problema que sinto também, é balancear vida pessoal com estes objetivos de “desenvolvimento técnico-profissional“. Apesar de gostar muito do que faço, dificilmente troco uma cerveja com os amigos por algumas horas de programação em Lisp; ou então um treino/jogo de handebol pela leitura do artigo sobre MapReduce.

Exposto o problema, fica aqui o pedido de socorro aos leitores:

• O que vocês fazem para desenvolver a disciplina necessária para execução de projetos pessoais de “desenvolvimento técnico-profissional“?
• Como vocês fazem para determinar o equilíbrio entre as vidas pessoal e profissional?

Sintam-se à vontade de contribuir. Espero podermos reunir um bom material, e depois escrever um outro artigo a respeito (se não rolar nenhum churrasco no dia :-D)

Mas tá frio hoje, né?

E o Timão, hein? Vocês viram?

Utilizando a mesma técnica do editor-chefe, de postar milhares de pequenos comentários sobre o que ele lê na internet, só para dizer que é super produtivo, vou compartilhar uma idéia muito interessante que li no blog Signal vs. Noise.

O autor conta que experimentou a sensação de trabalhar em pé, ao invés de sentado em frente ao computador, e segundo ele isto foi extremamente positivo. Segundo ele, quando sentado em sua confortável cadeira, sua postura era ruim, ele se distraía facilmente, e lutava constantemente contra a fadiga.

Trabalhando em pé, ele conta que sua atenção melhorou, assim como a capacidade de se concentrar em um problema por mais tempo.

Não sei se os ganhos de concentração seriam iguais para todos, mas acredito que os ganhos de bem-estar físico seriam ótimos, sem contar que eu não precisaria mais lutar contra o sono de manhã.

Esta idéia não é nova: várias pessoas têm observado esta prática,como Ernest Hemingway, Winston Churchill e Thomas Jefferson. Além disto, uma simples busca no Google sobre o tema irá lhe mostrar várias pessoas endossando a prática.

É claro que você não vai trabalhar em pé na mesa que você tem agora. Você precisará de uma mesa específica para este fim, mas opções não faltam.

Acho que vou tentar isto em casa. Se der certo, quero ver como vou convencer meu chefe a comprar uma mesa dessas pra mim, além de lidar com o fato de ser um estranho no ninho.

“Não existe almoço grátis”, diria Milton Friedman. A máxima tem um fundamento importante: mesmo quando as coisas não vêm com uma etiqueta indicando um preço, não quer dizer que elas deixaram de ter um custo. O software pode ter sido obtido de graça (seja software de código-livre, seja software pirata), mas o desenvolvedor deseja certamente ser recompensado pelo tempo que dedicou ao trabalho.

Essa recompensa pode até não ser monetária. Muitas pessoas trabalham em busca de reconhecimento, ou por desejarem resolver um problema que o incomoda, ou por hobby - um mero passatempo que agrada. Sempre há algum tipo de recompensa desejada em troca.

Entretanto, há uma coisa diferente em software: depois que o produto estiver pronto, ele pode ser infinitamente consumido a um custo irrelevante. Duplicar software tem custo marginal que é zero, se comparado ao custo do desenvolvimento. O mesmo pode ser dito de qualquer produto que possa ser digitalizável: músicas, filmes, informação em geral. Esse é um dos pontos-chave para falarmos da Economia Digital.

Baseado nisso, eu deveria me esticar um pouco para justificar a seguinte afirmação: “a melhor forma de garantir a produção de riquezas em uma sociedade cada vez mais baseada em uma economia digital está em buscar uma forma de fomentar e financiar os criadores, e buscar consumir apenas aquilo que possui um custo marginal de duplicação.”

Mas se eu esticar demais, deixo a coisa complicada. O que eu quero dizer é simples: se arrumarmos um sistema onde as pessoas que produzem tenham um sistema que incentiva a produção ao mesmo tempo que obrigue que o produto final seja livremente copiado, então toda a sociedade se beneficiaria mais do que numa sociedade onde há escassez artificial.

E o que é escassez artificial? Software proprietário. Música com proteção de DRM. Patentes sobre desenvolvimento de remédios. Livros que não podem ser copiados em universidades… qualquer coisa onde a tecnologia (ou a política) é usada para impedir o livre fluxo e consumo de bens e serviços.

Software as a Service

O crescimento e a adoção do modelo de desenvolvimento open source levou a uma reação a algumas das empresas que possuem a propriedade intelectual como pilar estratégico. Essa reação foi simples: “vamos deixar de pensar no software como um produto, e vamos transformar num serviço”. Os consumidores não pagariam um valor grande para comprar o (direito de uso do) software, mas passariam a usar a infra-estrutura dos provedores de serviço em um modelo pay-as-you-go. Ou seja: ao invés de ter que comprar o carro, o consumidor passou a andar de táxi. O consumidor consegue o que quer e o fornecedor arrumou uma maneira de receber uma recompensa pelo seu trabalho. Todos saíram contentes, certo?

Ainda não. Isso pode ser ótimo para quem não quer ter a dor de cabeça de dirigir o carro, mas é péssimo para aqueles que não querem depender do taxista. É péssimo para aqueles que querem um carro para exercer eles mesmos uma outra atividade econômica.

Mesmo que as empresas não estejam mais cobrando pelo produto, ainda falta um mecanismo para permitir a livre duplicação de um produto depois de acabado.

Por que não o Open Source?

Porque não funciona como estímulo para a inovação. Qual é o projeto que você conheça que foi a) desenvolvido desde o começo de forma aberta e b) razoavelmente original em sua concepção e c) capaz de recompensar diretamente o idealizador do projeto apenas?

Linux? Cópia do Unix, feito há mais de 40 anos. Apache? Servidores web já existiam. Pessoas que trabalham em projetos de linguagens de programação abertas fazem isso ou por hobby ou são projetos financiados por terceiros. Android? Não há nada de novo.

Nenhum. O modelo open source é ótimo para implementar idéias que já se provaram, mas não funciona como campo de laboratório. Para idéias realmente inovadoras e para empreendedores, as recompensas possíveis não são maiores do que os riscos envolvidos. E as pessoas só trabalham em coisas arriscadas quando a recompensa é proporcional.

Sem contar que é difícil de engolir o papo de que as empresas que produzem software open source podem viver de suporte. Se o produto for realmente de qualidade, é de se esperar que ele não dê dor de cabeça para o consumidor final. Software de qualidade (just works) e dependência de equipe de suporte são qualidades mutuamente exclusivas.

Uma alternativa: o mercado de futuros

Se você já tentou comprar um imóvel, você deve ter percebido que existe a possibilidade de comprar o imóvel “na planta”. Em miúdos, você fecha um contrato de um imóvel que ainda será construído. Obviamente, quem compra o imóvel na planta acaba pagando um valor menor do que os que compram o mesmo imóvel em etapas posteriores do empreendimento. Isso acontece por que um comprador de imóvel na planta está comprando não só o imóvel, mas está comprando risco. Não há nada que elimine a possibilidade de atrasos na execução, oscilações do mercado e até mesmo que o dono da construtora e sua secretária de 22 anos de idade fujam com o seu dinheirinho para alguma ilha remota do mundo.

Esse risco tem um valor a ser quantificado. Se para o comprador do imóvel o valor do risco é menor do que o desconto, certamente é vantajoso comprar o imóvel na planta. A empreendedora também vê vantagem. Ao ter clientes que compraram o imóvel na planta, ela pode arrumar recursos para iniciar as obras, garantindo a continuidade do empreendimento. Ela pode também não vender algumas das unidades e vender apenas com o imóvel pronto, obtendo assim uma margem de lucro maior.

Não creio ser tão difícil assim emular um modelo parecido para a Economia Digital. Nesse sistema, as pessoas que desejam algum software (ou música, ou livro, ou filme) compram um produto “na planta” daquele que for capaz de oferecer o produto ao menor custo, incluindo o risco. O vendedor, em troca, se comprometeria a disponibilizar livremente o produto do seu trabalho acabado. Dessa forma, temos o melhor dos dois mundos: o produtor só trabalha com a garantia de que será recompensado e o consumidor fica livre para usufruir do que comprou, como quiser.

Há ainda uma óbvia vantagem: se forem várias as pessoas interessadas em um produto similar, elas podem fazer o rateio do custo.

Já existem empresas que tentam levar o modelo adiante. Existe um site chamado Micropledge que atua como um mercado de projetos futuros. Consumidores se comprometem a pagar um pequeno valor em favor de um determinado projeto. Esses compromissos (pledges) são registrados no site e acumulados. Desenvolvedores podem “dar o seu preço” para que trabalhem no projeto. No instante que o valor acumulado em pledges é satisfatório para o desenvolvedor, o trabalho se inicia. O desenvolvedor só pode receber o dinheiro e as pledges só são cobradas depois que o produto é entregue de forma satisfatória pela maioria das pessoas que fizeram o compromisso.

Na teoria e na prática, é um verdadeiro exemplo de como funciona uma economia de mercado. Entretanto, para que funcione, é preciso que acumule uma massa crítica.

É aí que você entra.

Se o editor-chefe resolvesse hospedar este blog usando o Amazon Web Services, o custo mensal de transferência seria de R$0,46.

Há pouco meu caro amigo Miguel escreveu um artigo muito interessante sobre a facilidade que algumas linguagens oferecem ao utilizarmos expressões booleanas. A dica é muito boa, e certamente farei uso dela. No aspecto de legibilidade de código, não vejo problema algum.

No entanto, esta técnica me incomoda no aspecto de parecer anti-natural do ponto de vista da álgebra booleana, onde trabalhamos somente com dois valores (true/false, 0/1). Me parece misturar conversão de tipos de dados, com lógica booleana. Isso somente não me incomodaria, mas me fez pensar: que resultado eu terei de expressões como ( 0 == “”), (”" == null)? Será que ele adota o valor booleano pra comparar? Resolvi testar usando perl, python e javascript, e obtive resultados diferentes:

Perl:
> perl -e ‘ $a=0; print( “” == $a); print “\n”; ‘
> 1

> perl -e ‘ $a=0; print( nil == $a); print “\n” ‘
> 1

Python:
> python -c ‘_a=0; print ( _a == “” )’
> False

> python -c ‘_a=0; print ( _a == None )’
> False

Javascript:
> var a=0; alert( a == “” );
> True

> var a=0; alert( a == null );
> False

Bom, como podemos ver, cada linguagem de programação tem sua forma de tratar este tipo de comparação. Desta forma, fica aqui o toque para se tomar cuidado com esta técnica, levando-se sempre em conta as especificidades da linguagem que você está utilizando.

Há um tempo atrás num post polêmico do Miguel (ando falando demais no passado né? mas tem coisas que não dá pra deixar passar…) o Raphael escreveu um comentário que me incomodou:

Performance? Dane-se! Python é mais lento que Java? Sem dúvida. Mas performance pura não importa hoje em dia. Hardware hoje já é tão barato que pouco importa se eu tenho que ter 1, 2 ou 3 máquinas para rodar o sistema. O que não pode é ter uma plataforma tão lenta que me obrigue a comprar 20 ou 30, que seria o caso do Ruby. Questão de ordem de grandeza.

É claro que eu tenho plena conciência que o Raphael não acredita 100% na afirmação acima e que ele estava envolvido numa discussão (quase) sem sentido com o Bruno… Prova disso é que mais pra frente, em outro comentário ele escreveu:

Eu quero uma stack de protocolo de comunicação SIP que atenda 100 mil usuários simultâneos

Que vai exatamente contra o que ele tinha dito antes! Afinal de contas, neste exemplo desempenho é primordial ou nada funciona. Talvez por isso eu estivesse achando a discussão (quase) sem sentido… Mas… vamos ao que (me) interessa!

O fato é que desempenho importa sim em muitos casos. Em algumas áreas ele é, eu diria, primordial. Mais essencial até que uma boa interface homem computador. Duvida? Pense então em criptografia.

Quase todo mundo hoje em dia sabe o que é criptografia e quase ninguém duvida que ela é essencial para nossa (falsa?) segurança na Internet. O fato que pouca gente sabe é que ainda hoje algoritmos criptográficos são exageradamente pesados. Aliás, para o desespero de alguns, é exatamente aí que está o segredo: não existe, ainda hoje, nenhuma prova formal de que algoritmos criptográficos sejam realmente seguros. O que todo mundo sabe é que é muito difícil quebrá-los com o que se conhece de teoria matemática hoje em dia. E é nessa dificuldade que é baseada boa parte da segurança das comunicações mundiais. Parece frágil isso, não? Definitivamente! E olha que eu nem comecei a falar nas técnicas não-matemáticas para se quebrar um algoritmo criptográfico… Mas isso não é conversa para este post.

Neste post, antes que eu perca o fio da meada de novo, quero falar de desempenho! Como algoritmos criptográficos ainda hoje são muito pesados, é muito comum você achar artigos e artigos na Internet de autores se vangloriando por terem achado um novo método revolucionário de implementar um algoritmo criptográfico que traz um ganho de desempenho de incríveis 5%! Ou ainda pesquisadores gastando meses fazendo testes para descobrir a combinação de flags de otimização a serem usadas no gcc para fornecer um ganho de 3%!

E é ai que eu queria chegar. Estudando um pouco sobre criptografia este semestre eu aprendi com o professor Julio López da Unicamp um método de otimização de código capaz de fazer com que um código rode consideravelmente mais rápido. Pense no seguinte trecho de código, bastante comum em algoritmos criptográficos:

if (a & 0x80)
r ^= b;

Basicamente o que se deseja fazer é testar um bit da variável a. Se este bit for 1 faz-se uma operação de soma em aritmética módulo 2 (um XOR) da variável b sobre um acumulador da resposta r. Este tipo de código, apesar de simples, costuma ser executado de forma muito ineficiente em processadores de propósito geral modernos. Isso porque este processadores são muito rápidos mas não são adivinhos. Para simplificar bastante o assunto, podemos dizer que antes de eles terem idéia do resultado do if eles já estão tentando executar a instrução em seguida (a soma). No entanto, eles podem descobrir alguns ciclos de relógio depois que a soma não deveria ser executada pois o if deu falso. Neste caso eles tem que voltar atrás e desfazer o deslocamento.

Os processadores modernos até tentam adivinhar qual caminho é o certo, mas nem sempre isso dá certo. Descobrir que o que ele estava fazendo estava errado e voltar atrás é algo que penaliza muito o processador. Perde-se às vezes dezenas de ciclos de relógio com isso… Tempo suficiente para executar talvez de 6 a 10 instruções, dependendo do processador. Ou seja, se conseguíssemos eliminar este if do código poderíamos ter um ganho. O código para eliminar o if acima é o seguinte:

r ^= b & (-((a & 0x80) >> 7));

Alguém vai dizer: “Ora bolas, mas agora ao invés de um if, que é em geral uma comparação e um salto condicional, e um XOR eu estou fazendo um XOR, dois AND, um deslocamento e uma inversão de sinal!” Por incrível que pareça isso, muitas vezes, é mais rapido, pois elimina qualquer possibilidade do processador ter que voltar atrás e jogar fora processamento, perdendo dezenas de ciclos de relógio de execução.

É este tipo de truque de programação que muitos pesquisados da área de criptografia passam meses tentando descobrir. Este truque, aliás, é bem conhecido. Ele é muitos outros podem ser vistos no livro Hacker’s Delight. Nunca olhei o livro profundamente mas ele já me foi muito bem recomendado.

E você tem algum truque bacana destes pra nos ensinar?

aos colabadores e leitores assíduos do blog. O mês está encerrando, e o blog passou a marca de 6000 acessos em Outubro.

Pode parecer pouco, mas 200 acessos diários em um blog que se dispõe a buscar um público tão pequeno (desenvolvedores e pessoas que trabalham com tecnologia), que se mantém escrevendo em português, e que não se preocupa em fazer marola, primando a qualidade, é uma marca que impressiona.

Próxima meta: 10 mil acessos.

Cheers.

Tá, tá… você é um computeiro e sua leitura favorita - além do log4dev, claro - se resume a Java Magazine, Info Exame, aquele RSS que traz reportagens sobre o gadget que você tá louco para comprar ou outros textos onde você vai ter assunto para discutir no gtalk com outros geeks como você. Mesmo assim, eu vou te passar uma citação do Seth Godin, um blogger que já foi VP de Marketing do Yahoo. Trocando em miúdos, ele não é o cara que escreve o programa, mas é o cara que escreve a spec:

I don’t know about you, but when I hire someone, or go to the doctor or the architect or an engineer, I could care less about how good they are at memorizing or looking up facts. I want them to be great at synthesizing ideas, the faster and more insightfully, the better.

Eu estou devendo um artigo falando sobre como aprimorar o senso de design. Talvez eu nem devesse escrever, e simplesmente apontar para esse parágrafo. Mas como eu sou um tanto tinhoso e o Miguel me proibiu ficar discutindo sobre linguagens de programação, acho que vai sobrar tempo para escrever mais opiniões não-fundamentadas e equivocadas por aqui.

Ps.: Desejem-me sorte. Espero receber hoje um email um tanto especial.

Uma das coisas mais interessantes quando se tem um blog é o canal de comunicação que se cria com pessoas que compartilham interesses.

O log4dev começou como um blog onde eu guardava algumas soluções e dicas que eu descobria depois de muito fuçar na Internet. O raciocínio era óbvio: se eu tive dificuldade para encontrar resoluções para algum problema que eu tinha, mais gente poderia estar na mesma situação.

Mas já se foram 3 anos, e muita coisa mudou. Os problemas de um profissional desenvolvedor, também. Com a contribuição de outros colegas, começamos a tratar de questões relevantes: processos de engenharia de software, tendências em tecnologia, novos paradigmas que mudam a forma de encarar um computador e nossas atividades. Ser um programador hoje é muito mais que conhecer uma linguagem de programação e uma IDE. Imagino que isso também não aconteceu só para mim.

Esse post é o início de uma conversa com você. Queremos saber mais sobre você, mais sobre as suas necessidades e seus objetivos. Quem é você? Que temas te interessam? Que temas você não tem o mínimo interesse? O log4dev está fazendo censo. Deixe seu comentário!