Divirta-se com “The Humans Are Dead”:

Se a legenda não aparecer, clique no botão CC no canto inferior direito do vídeo e escolha o idioma.

Acontece que esta cidade especificamente não possuía um sinal 3G de qualidade, aliás às vezes não possuía nenhum tipo de sinal. Então tive de passar 3 dias com uma conexão pior que as antigas conexões discada. A comunicação com a equipe foi obviamente prejudicada, já que usamos Skype na maior parte do tempo. Até mesmo acessar uma simples página na internet se tornou um doloroso exercício de paciência, nem mesmo o Campfire era possível de se utilizar. Depois de pouco tempo, simplesmente abandonei o modem e passei a trabalhar 100% desconectado, por três dias, mantendo contato com a empresa apenas pelo telefone quando um assunto era questão de vida ou morte.

Sem Serviço

Já ouvi muitas vezes frases como: “A tecnologia está tornando cada vez mais fácil a colaboração”. Pois eu posso dizer, agora com a máxima convicção, que você pode trocar a palavra colaboração por interrupção na frase acima sem pensar duas vezes. Cada vez mais produtos e serviços visam nos deixar online por mais tempo, alegando que a possibilidade de ser encontrado e poder encontrar qualquer membro da sua equipe, não importa onde ele esteja (no escritório, no carro, no supermercado ou em casa) pode tornar seu time muito mais produtivo. Eu já acreditei nesta estória, mas agora eu vejo as coisas por um ângulo diferente.

Durante estes três dias eu me mantive desconectado, incomunicável e isolado. Mas também foi um período de alta produtividade e foco para mim. O motivo? Eu estava isolado, por isto não podia ser interrompido. Consegui concluir neste tempo muitas tarefas que estavam pendentes por semanas e a cada dia ao terminar o trabalho sentia aquela boa sensação de dever cumprido.

Ser produtivo não é algo que simplesmente acontece. Não basta apenas se sentar e sair produzindo. Entrar na zona de produtividade leva tempo. Às vezes pode levar 15 minutos, em outras ocasiões meia hora, ou uma hora ou até mais para entrarmos neste estado de concentração. Mas basta um simples telefonema, e-mail ou mensagem para lhe colocar novamente no inicio do ciclo.

Agora, toda vez que vejo algum site ou revista comentando sobre a nova ferramenta colaborativa da vez, em minha mente só consigo pensar que não passa de mais uma forma de conseguirem me interromper. E interrupção é o pior inimigo da produtividade. Pode soar estranho dizer isto, mas uma dose saudável de isolamento social e virtual pode fazer um bem extraordinário para sua alma. Se você desejar ser realmente produtivo, precisa de mais tempo sozinho.

@carlosbrando

As respostas que recebi apenas confirmaram o que eu já imaginava.

@tapajos

@flaviogranero

O motivo da pesquisa é que recentemente eu estava lendo um artigo onde o autor argumentava que o ideal seria criarmos classes somente com métodos públicos, evitando ao máximo métodos privados ou protegidos. E entre outros argumentos, um dos motivos para se fazer isto era simplificar a criação de testes.

Uma coisa que me preocupa no Ruby é que é muito comum encontrar programadores que não estão nem um pouco preocupados se os seus métodos são públicos, protegidos ou privados. Pior ainda, quando tomam decisões apoiando-se em argumentos como o acima.

Um clássico exemplo são os métodos de callback de validações do Active Record, que em praticamente 99% dos casos deveriam ser privados ou protegidos, mas é normal encontrá-los entre os métodos públicos de um modelo na maioria dos projetos Rails. Acredito que isto aconteça porque programadores iniciantes entusiasmados com as facilidades do Active Record apenas saem incluindo seus códigos sem pensar muito no que estão fazendo.

Eu também não tenho o hábito de testar métodos privados, pelas mesmas razões mencionadas pelos amigos do Twitter. Mas no Ruby, se você realmente desejar, é trivial realizar uma chamada em um método privado de um objeto. Uma das técnicas mais usadas por “testadores de métodos privados” é se valer das características dinâmicas da linguagem para transformar todos os métodos privados de uma classe em métodos públicos durante os testes. Diferente de outras linguagens, como C# por exemplo, onde você tem uma barreira formal para impedi-lo de acessar métodos privados, no Ruby é ridiculamente simples ultrapassar esta barreira.

Pensando desta maneira, definir um método como privado no Ruby pode não significar muita coisa, já que outro programador pode alterar esta característica com facilidade. Mas ainda assim, definir um método como privado é como dizer aos outros programadores que aquele método faz parte do funcionamento interno daquela classe e que o programador original quer se manter no direito de realizar qualquer tipo de alteração necessária sem se preocupar se alguém está usando ou não aquele método. Isto tem tudo a ver com encapsulamento, e pode fazer toda a diferença quando surgir a necessidade de alterar algum comportamento do objeto.

Toda vez que você constrói um novo objeto, você está construindo uma nova API. Cabe a você então decidir o que deve ser exposto e o que faz parte dos mecanismos internos deste objeto. Desta forma, quando surgir a necessidade de alterar alguma coisa, você não precisará se preocupar tanto com quantas classes serão afetadas pela mudança. Ao marcar um método como privado, você está se resguardando e garantindo que não causará danos ao restante do sistema, já que você está dentro da fronteira do encapsulamento, podendo assim refatorar seu código sem dor na consciência.

Por favor, não saia simplesmente injetando código em suas classes. Pense!

Quanto cobrar por seus produtos na internet?

Mattijs perguntou:

Estou desenvolvendo um produto para a internet e está chegando a hora em que será necessário criar uma tabela de preços para este produto. Problema: Não sei nem por onde começar! Fiz algumas pesquisas que mostraram uma ampla gama de produtos semelhantes com regimes de preços totalmente diferentes. Quando a 37signals estava desenvolvendo o Basecamp, como é que vocês definiram os seus preços?

Quando sentamos para decidir os preços do Basecamp pela primeira vez em fevereiro de 2004, decidimos usar os seguintes preços: $9, $19, $39 e $59. Não houve muita ciência por trás disso. Simplesmente perguntamos a nós mesmos:

1. Quanto eu pagaria?
2. Estes números soam bem?

Quanto eu pagaria?

Penso que esta é a pergunta mais importante. Se você está projetando um produto que você vai usar, então é justo perguntar quanto você aceitaria pagar se você fosse comprá-lo de alguém. Os números que surgiram pareciam justos e razoável. 9 dólares era um bom preço inicial enquanto 59 dólares parecia um ótimo preço para o plano mais caro. Já mudamos estes preços, mas esses números funcionaram bem para um produto que ainda era desconhecido no mercado.

Esta linha de pensamento acabou mudando um pouco nosso conceito quando estávamos decidindo os preços de nosso outro produto, o Campfire. Originalmente o preço seria de 5 dólares por chat no Campfire. A ideia era que as pessoas pudessem criar uma sala temporária no Campfire para coincidir com uma reunião ou conferência telefônica. Sentimos que cobrar $5/reunião/ligação seria um preço interessante.

Mas então pensamos um pouco mais sobre isso. Perguntamos a nós mesmos se realmente pegaríamos o cartão de crédito para pagar $5 por algo que usaríamos somente por alguns minutos? Nós decidimos que provavelmente não faríamos isso. Isso mudou todo o foco do produto. A ideia de chats temporários se foi e surgiu então a ideia de uma sala de chat persistente que nunca se fecharia. Então, nós adotamos uma tabela de preços similar a do Basecamp, com o sistema de mensalidades. Estamos confiantes de que tomamos a melhor decisão.

Estes números soam bem?

Há um grande lado psicológico e emocional quando falamos de preços. Um amigo que trabalhava no Wal-Mart, uma vez me disse que lá um preço nunca terminava com um 9. Eles sempre terminavam em 8 (ou 6 ou 4) ou qualquer outro diferente de 9. Eles querem que o cliente saiba que o Wal-Mart está sempre trabalhando duro para diminuir nem que seja um centavo do preço dos produtos – daí o incomum 8 no lugar do familiar 9.

Não adotamos nenhuma regra para decidir nossos preços. Talvez devêssemos adotar uma, mas não fizemos. Nossa linha de preços no Basecamp é de $12, $24, $49, $99 e $149. Estamos mantendo esses preços em vigor por alguns anos e gostamos da combinação. Eles soam bem. Cada nível é praticamente o dobro do nível anterior, mas nós entregamos mais do que o dobro em benefícios.

Por exemplo, no Basecamp Basic ($24/mês), o cliente pode criar até 15 projetos e tem 3GB para armazenamento de arquivos. No Basecamp Plus ($49/mês), o cliente pode criar até 35 projetos (mais do dobro do nível básico) e tem 10GB para armazenamento de arquivos (mais de três vezes o nível básico). Portanto, o preço é o dobro, mas os benefícios são mais do que o dobro. Este padrão persiste em todos os nossos planos de preços.

Você pode mudar os preços, se precisar

Lembre-se que se você decidiu por um preço errado, você pode fazer correções ocasionalmente. Nós fizemos uma grande alteração nos preços do Basecamp e uma alteração menor nos preços do Backpack. Os preços do Backpack mudaram quando lançamos a versão multi-usuário. Reduzimos principalmente os preços dos planos maiores e diminuímos a diferença entre o preço do primeiro nível para o segundo nível (que costumava ser de $5 -> $9, mas foi alterado para $5 -> $7).

A alteração do preço pode ser um pouco dolorosa no curto prazo, mas se você fizer a sua parte, aumentando os benefícios junto com o preço, alertando seus clientes com bastante antecedência sobre o aumento (uns 90 dias, vamos dizer), considerar a possibilidade de manter os preços anteriores para os clientes mais antigos e manter o seu preço justo, a alteração de acontecer sem maiores problemas.

Reembalagem é o segredo do sucesso

Ganhar dinheiro com a internet hoje em dia não é uma coisa muito difícil. Eu mesmo já andei ganhando uma graninha com a venda do meu último livro, que não passava de uma compilação dos textos deste blog traduzidos para o inglês. Não ganhei muita coisa, mas esta também nunca foi a intenção, mas tem muita gente ganhando dinheiro com seus blogs, principalmente fora do Brasil.

Se você cria um conteúdo de qualidade, não é difícil ganhar dinheiro com ele, desde que você não tenha vergonha de fazer dinheiro. Mas o mais impressionante é que algumas pessoas conseguem ganhar dinheiro mais de uma vez com o mesmo conteúdo.

Não é de hoje que expresso minha admiração pela 37signals, e os caras realmente a merecem. Você muito provavelmente já ouviu falar do livro Getting Real (Caia na Real), onde eles documentam alguns de seus insight sobre a forma como eles criam e vendem produtos na web. O mais interessante é que tudo começou com uma série de artigos publicados no seu blog Signal vs Noise. Veja a seguir como eles ganharam dinheiro 4 vezes com o mesmo conteúdo.

Ganhando dinheiro pela primeira vez

Durante muito tempo eles escreveram, baseados em suas experiências, artigos muito originais sobre o processo de construção de um produto para a internet em seu blog. Estes artigos obviamente geravam muito tráfego e desta forma eles conseguiram alguns milhares de dólares com anúncios na barra lateral do site.

Ganhando dinheiro pela segunda vez

Quando já estavam com um número bem vasto de artigos sobre a sua filosofia de desenvolvimento publicados no blog, eles decidiram compilar os melhores posts no formato de um ebook. Nasceu assim o Getting Real, e cada cópia em PDF era vendida por 19 dólares. Desta forma eles conseguiram angariar aproximadamente 100 mil dólares.

Ganhando dinheiro pela terceira vez

Depois de um tempo, ele pegaram o Getting Real em PDF e transformaram-no em um livro impresso através do site Lulu.com. Cada livro era vendido por 25 dólares e eles conseguiram mais alguns milhares de dólares apenas no primeiro mês. O livro ainda encontra-se a venda no site e até pouco tempo atrás estava classificado como o quarto livro mais vendido.

Ganhando dinheiro pela quarta vez

Por último, eles pegaram o conteúdo do livro e produziram uma série de conferencias sobre a filosofia que eles criaram. Eles ganham em média $50 mil por conferencia e já realizaram mais de 5 delas.

Somando os resultados

Bom, vamos calcular quanto eles conseguiram ganhar com o mesmo conteúdo. Com anúncios eles conseguiram por volta de 100 mil dólares (é importante considerar que eles utilizam o The Deck como seu principal sistema de anúncios, e eles são sócios fundadores da empresa, então provavelmente devem receber um pouco mais do que o normal por anúncio). Com o livro em formato PDF eles ganharam por volta de 350 mil dólares e com o livro impresso eles conseguiram mais ou menos 65 mil. E por último eles já conseguiram 250 mil com as conferencias.

Isto dá um ganho total de 765.000 dólares ao longo de alguns anos, explorando o mesmo conteúdo, insight e idéias sobre como eles executam o seus negócios. Artigos publicados no blog, PDF, livro impresso e conferencias.

É claro que provavelmente eles também devem ter ganho mais algum dinheiro com negócios indiretos conseguidos através do sucesso do livro, como novas oportunidades para a empresa. Mas somente com o conteúdo criado eles chegaram a quase 1 milhão de dólares. Muito bom para um conteúdo que foi originalmente publicada de graça em um blog, não?

Se você ainda não leu o Getting Real, caia na real e trate de lê-lo agora. Temos até mesmo uma versão em português, totalmente gratuita, traduzida pela comunidade Rails brasileira.

Lendo o excelente livro StartUp de Jessica Livingston, notei que mesmo o mais confiante empreendedor tem seus temores. Medo de que uma empresa com mais mais recursos produza um software igual ao seu e que consiga levar seus clientes. Mas o que se percebe é que na maioria dos casos, mesmo que o software da concorrência pareça melhor ou tenha sido construído por uma equipe com mais experiencia, normalmente vence a equipe mais apaixonada.

Está revelado o segredo. Para montar uma equipe vencedora, não procure o melhor profissional, procure o profissional mais motivado. Mas não basta somente contratar alguém apaixonado, é preciso manter acesso está paixão. Como?

Salário?

O salário parece ser sempre o principal motivo de descontentamento em uma empresa. É claro que quando estamos falamos de dinheiro, quanto mais melhor. Mas é um fato que bons programadores não levam o dinheiro tão a sério assim. Pessoalmente, eu conheço muitos bons profissionais que mesmo achando que poderiam estar ganhando mais dinheiro em outra empresa, se “sacrificam” para permanecer em um ambiente de trabalho que lhe agrade, onde ele talvez considere que está aprendendo coisas novas ou adicionando algo de valor ao universo.

Eu mesmo passei por uma experiencia parecida há um tempo atrás. Já estava há dois anos trabalhando em um mesmo projeto e havia perdido o interesse naquilo já fazia um bom tempo quando recebi uma proposta de emprego para receber pouco mais do que eu ganhava naquela empresa. Ao avisar que estava saindo, recebi a tentadora proposta de ficar e dobrar o meu salário. Não aceitei, porque não tinha mais a ver com dinheiro e sim com paixão e motivação.

Se quer resultados, desafie

Em meu trabalho com pessoas surdas, certa vez eu acompanhei um amigo em uma aula. Este meu amigo é uma pessoa de natureza séria, e como tal costuma tratar seus alunos com seriedade, embora seja um excelente professor e tenha um profundo conhecimento da língua de sinais (visivelmente maior do que o meu). Mas ele tinha um problema, seus alunos estavam com sérias dificuldades para entender algumas coisas muito simples. Diferente dele, eu costumo ser um pouco mais brincalhão em minhas aulas e me aproximo mais dos alunos. Neste dia, brincando com as crianças eu disse que quem errasse uma pergunta levaria um cascudo na cabeça, mas para cada pergunta certa eu daria um beliscão no professor deles. Adivinhem, tivemos um excelente aproveitamento da aula e não precisei dar cascudo em nenhuma criança.

O ser humano precisa ser desafiado. Pagar bem para um profissional fazer um trabalho desinteressante e sem valor não desperta paixão em ninguém. É por isto que uma startup, mesmo com uma equipe menor (e com salários menores também) muitas vezes conseguem competir com grandes corporações. É o desafio que motiva as pessoas a fazerem coisas grandiosas.

Programadores precisam ser desafiados

Não existe ninguém que goste mais de desafios que os programadores. Pegue um código escrito por alguém, e sem avisá-lo altere para deixá-lo mais rápido ou mais elegante, e você com certeza estará ganhando um inimigo mortal. Acho que os quadrinhos abaixo ilustram isto muito bem:

Alguns anos atrás eu trabalhei em um projeto onde havia um programador na equipe que já estava trabalhando para o mesmo cliente por algum tempo e já possuía um excelente domínio dos negócios daquele cliente. Sendo assim, ele assumiu a responsabilidade de escrever um código que envolvia uma regra de negócio um pouco mais complicada. Lembro que quando vi o código, pela primeira vez depois de pronto, levei um susto tremendo. O código era macarrônico e tinha quase 1.000 linhas. Era simplesmente incompreensível.

Por profundo respeito ao amigo, não comentei nada sobre o código na hora. Depois de algumas semanas houve uma mudança em uma regra que envolvia realizar uma alteração em algum ponto daquele emaranhado de código. Um outro programador da equipe assumiu o desafio. Horas depois ele desistiu. Como o pai da criança estava presente, ele acabou assumindo e resolvendo o problema.

Pressentindo que aquele código poderia se tornar um problema no futuro, o gerente do projeto solicitou ao programador que ele refatorasse o código afim de deixá-lo mais intuitivo e fácil manutenção. Embora ele tenha melhorado um pouco o código, não posso dizer que o resultado era o esperado.

Passaram-se mais alguns dias e mais uma vez tornou-se necessário alterar algo naquele maldito código. Desta vez, outro programador foi designado para fazer isto. Depois de um tempo tentando entender o que aquele código fazia ele também se cansou e após mostrar o código para o gerente do projeto e receber sua aprovação, ele começou a refazer o código de uma forma que todos pudessem entende-lo. Mas como o dia já estava chegando ao fim, ele deixou para terminar o trabalho no dia seguinte.

A surpresa foi que no dia seguinte ao chegar na empresa o programador original do código já havia refeito todo o código de uma forma muito mais inteligente. De alguma maneira ele soube que seu código seria refeito por outro programador, e ao invés de ir para casa ele passou a noite em claro refazendo todo o código. Somente após se sentir desafiado é que aquele profissional se motivou para fazer seu trabalho da maneira certa, e confesso que ele realmente conseguiu acertar.

Claro que existem formas mais elegantes de se desafiar um profissional, mas eu considero interessante analisar o efeito do desafio na vida de uma pessoa. No caso acima, o programador se privou do sono e do seu merecido descanso, afim de encarar um desafio.

Como motivar um programador? Eu acredito seriamente que o segredo está em dar um propósito a ele, incumbi-lo de um trabalho que tenha um verdadeiro valor, que acrescente algo de importante em nosso mundo. Eu quero deixar a minha marca no universo, quero ser desafiado, quero mostrar porque estou aqui. Me dê um desafio a altura e eu te mostrarei o que é paixão.

ruby user_test.rb

Mas se sua intenção é executar apenas um teste especifico dentro do caso de teste, você também pode fazer assim:

ruby user_test.rb --name test_should_require_login

Para armazenar todo este conteúdo que não pode simplesmente ficar perdido pela internet, criei um novo site associado a este blog, o Nome do Jogo – Vídeos!

http://videos.nomedojogo.com

Até o momento cadastrei somente os vídeos que já foram postados por aqui, mas estou abrindo o espaço para todo e qualquer material sobre Ruby, Rails ou qualquer outra tecnologia que vocês estiverem utilizando e que pode ser interessante para outros programadores. Se você conhece algum material legal que pode ser publicado no site envie o link com o vídeo e se possível alguma informação sobre quem o produziu/palestrou através da página de contato deste blog.

Vale qualquer tipo de material, mesmo sobre outras linguagens de programação. Espero que gostem desta novidade e que possam me ajudar a tornar este novo site uma excelente fonte de recursos para nós programadores.

E não esqueçam de divulgar o endereço do site em seus blogs e twitters: http://videos.nomedojogo.com.

Assumir responsabilidades é um dos pilares da profissão de programador. Mas tão importante quanto assumir responsabilidades, é também assumir seus erros. Seja honesto consigo mesmo, todos somos suscetíveis a falhas.

Em um antigo emprego já tive a oportunidade de liderar uma equipe com excelentes programadores, 100% de cobertura de testes, uma boa documentação e mesmo assim as coisas deram errado. Somos seres humanos e cometemos erros. A forma como lidamos com estas situações é que mostra o quão profissionais somos.

Ser arrogante não significa esconder seus erros. Eu valorizo pessoas que assumem suas ignorâncias e seus erros, e mais ainda os que se esforçam para aprender com eles.

É uma pena que tantas pessoas em cargos de responsabilidade congelem suas carreiras no meio da subida. Porque na minha visão, ter a coragem e a honestidade de assumir seus erros é um passo importante antes de chegar ao topo.

Inicialmente estipulei que os vídeos deveriam ter no máximo um minuto e meio de duração, mas foi bem difícil conseguir isto. Este vídeo tem 3 minutos, o que ainda é bem pouco. Então ao invés de definir um tempo especifico, vou fazer de tudo para gravar episódios com o máximo de conteúdo no menor tempo possível e pronto!

Neste primeiro episódio eu mostro apenas uma curiosidade sobre o nome das classes no Ruby, teremos uma continuação em breve sobre este mesmo tema. Para dar continuidade com esta série preciso da ajuda de vocês, deixem comentários com sugestões sobre o tema ou me enviem ideias para novos episódios usando a página de contato deste blog.

Espero que gostem!

P.S.: Todos os vídeos serão publicados em um canal do YouTube: http://videos.nomedojogo.com