As regras do Pomodoro são simples:

• Priorize suas tarefas logo no inicio do dia;
• Você vai ter um intervalo de 25 minutos para resolver todas as tarefas, após esse tempo você descansa 5 minutos. Após 4 pomodoros (Que são 30 minutos – 25 da tarefa e 5 do descanso) você deve descansar por mais tempo, por 20 minutos;
• Ao final de cada pomodoro, marque com um x ao lado da tarefa, ao concluir risque-a da lista.

Claro que não entrei em detalhes nas regras, mas basicamente é isso. Sem mistério, simples e direto ao ponto. O único material que você precisa é de uma caneta e de um contador regressivo programável (25, 5 e 20 minutos) que tenha alarme.

Se você trabalha direto no computador, você pode usar algum software para controlar o tempo. Para Mac existe o Pomodoro e em Air, que funciona em qualquer S.O., você pode usar o PomoDo.

O principal ponto que eu notei sobre o pomodoro é que eu sei quanto tempo eu gasto por cada tarefa. Contando as horas que eu trabalho por dia isso é muito importante, se aplicarmos o mesmo principio do gerenciamento financeiro, você não sabe que tem um problema até que você comece a contabilizar o quanto é o tamanho do seu problema.

Usar o pomodoro me fez ter algumas estatísticas interessantes, por exemplo, no período da manhã é o horário onde eu gasto menos pomodoros (Isso quer dizer menos produtividade). O período da tarde é o que eu mais faço pomodoros, mas não muitos, variam entre 4 a 6. Eu sei que da pra fazer até 8 pomodoros.

Em casa é o ambiente onde eu tenho o maior número de distrações. No trabalho eu tenho bem menos distrações, mas tenho o maior número de pomodoros interrrompidos.

E por último outra coisa legal, você começa a identificar as tarefas comuns e começa a medir a quantidade de pomodoros para completar uma tarefa, isso faz com que você possa se organizar melhor (Se você sabe que tem apenas 2 pomodoros disponíveis, você então faz uma tarefa que vá levar 2 pomodoros).

Eu realmente indico o pomodoro para quem não tem noção nenhuma de onde você gasta suas horas. Recomendo que você leia todo o livro antes, mas não precisa para começar a usar. Ler sobre as interrupções é importante, saber lidar com ela é muito importante.

No Oxente Rails, evento realizado em Natal – RN, eu, Cleiton, Weldys e Cyrus começamos uma aplicação por brincadeira e zoação, nós criamos um livestream, foram 2 dias de muito trabalho e pouco descanço.

Na volta pra casa nós discutimos bastante sobre os rumos do livestream mas não chegamos a nenhum ponto. Logo no mês seguinte participamos do Rails For Kids, e mais uma vez estávamos com nosso Livestream, e dois dias depois nós cobrimos o Dev In Rio.

A cada novo evento nos surgiam mais e mais idéias, surgiram mais e mais feedback nesse tempo todo e resolvemos que iríamos fazer uma aplicação, bem estilo web x.0 e bem cara de Rails.

Daí surgiu a idéia do TrendTi.me, que é um stream ao vivo do que acontece sobre um determinado assunto em vários canais da mídia. Inicialmente estamos cobrindo tudo que acontece no twitter, flickr e youtube.

Nós marcamos a estréia do TrendTi.me no maior evento de Rails do Brasil, o Rails Summit (Veja aqui o TrendTi.me).

A cada dia nós temos mais e mais idéias, estamos anotando tudo para implementar! Estamos com um bom roadmap, a equipe ta ótima e o desenvolvimento melhor ainda!

Em breve terei mais novidades sobre o TrendTi.me!

Existem duas formas de você utilizar os documentos, uma é fazendo dele como um documento real, e armazenar todas as informações possíveis dentro dele. A segunda forma é fazer referência à um outro documento. Existe uma diversidade da “melhor prática” no CouchDB, onde cada um dos desenvolvedores tem uma visão diferente. O J. Chris, por exemplo, desencoraja o uso, a não ser que seja realmente um caso onde não tem como não se usar vários documentos.

Quem usa Ruby, tem nas suas mãos várias ferramentas para trabalhar com CouchDB. Eu uso o CouchRest, que é uma biblioteca feita em Ruby pelos criadores do CouchDB. Ela é simples e bem fácil de usar. Com ela você pode definir modelos para sua aplicação:

COUCHDB = CouchRest.new
COUCHDB_SERVER.default_database = "your_database"

class Article < CouchRest::ExtendedDocument
  use_database COUCHDB_SERVER.default_database
end

Você não precisa definir nenhuma regra, a única coisa que vai ser inserida nesse documento é o couchrest-type. Onde ele define o tipo de documento:

>> article = Article.create(:title => "A melhor banda")
=> {"title"=>"A melhor banda", "_rev"=>"1-2513717810", "_id"=>"69d8dac29a0b112707b280eec4374a59", "couchrest-type"=>"Article"}
>> article['title']
=> "A melhor banda"

Quando você define no modelo o método property, ele adiciona automagicamente os gets/sets para a propriedade:

class Article < CouchRest::ExtendedDocument
  use_database COUCHDB_SERVER.default_database

  property :title
  property :author
end

>> article = Article.create(:title => "A melhor banda", :author => "Cairo Noleto")
=> {"title"=>"A melhor banda", "_rev"=>"1-3604901785", "_id"=>"2fe349c08d7d3150968b8de7b719d5d1", "author"=>"Cairo Noleto", "couchrest-type"=>"Article"}
>> article.title
=> "A melhor banda"
>> article.author
=> "Cairo Noleto"

O CouchRest possui uma forma de declarar vários documentos em um só:

COUCHDB = CouchRest.new
COUCHDB_SERVER.default_database = "your_database"

class Article < CouchRest::ExtendedDocument
  use_database COUCHDB_SERVER.default_database

  property :title
  property :authors, :cast_as => ["Author"]
end

Assim, quando você armazenar esse documento via CouchRest, ele vai colocar todas as propriedades desse documento dentro do mesmo documento:

>> a = Article.create(:title => "A melhor banda do mundo!", :authors => [Author.create(:name => "Cairo Noleto")])
=> {"title"=>"A melhor banda do mundo!", "_rev"=>"1-2417824677", "_id"=>"bfeaa06ad41bd8bdda50290ef10cbc5d",
  "authors"=>[{"name"=>"Cairo Noleto", "_id"=>"f80f56083917f8b651495f2a445b4df0", "_rev"=>"1-2108444623",
  "couchrest-type"=>"Author"}], "couchrest-type"=>"Article"}
>> a.authors.first['name']
=> "Cairo Noleto"
>> a.authors.first.class
=> Author

Uma outra forma de se fazer isso é armazenar apenas a referência do documento nesse documento e usar uma view pra recuperar todos os documentos:

COUCHDB = CouchRest.new
COUCHDB_SERVER.default_database = "your_database"

class Article < CouchRest::ExtendedDocument
  use_database COUCHDB_SERVER.default_database

  property :title
  property :authors, :cast_as => ["String"]
end

>> a = Article.create(:title => "Ben 10 - Como funciona", :authors => [Author.create(:name => "Cairo Noleto").id])
=> {"title"=>"Ben 10 - Como funciona", "_rev"=>"1-3102640010", "_id"=>"e7e6085ca37e7fe1da80273e0dea6fe0",
  "authors"=>["a7fbb1522fc613a0a54da3c9c075ca04"], "couchrest-type"=>"Article"}
>> a.authors.first.class
=> String
>> a.authors.first
=> "a7fbb1522fc613a0a54da3c9c075ca04"

Para recuperar todos os documentos nesse caso, iremos fazer uma view:

COUCHDB = CouchRest.new
COUCHDB_SERVER.default_database = "your_database"

class Article < CouchRest::ExtendedDocument
  use_database COUCHDB_SERVER.default_database

  property :title
  property :authors, :cast_as => ["String"]

  view_by :all_documents,
    :map => "
    function(doc) {
      if (doc['couchrest-type'] == 'Article') {
        for (var i in doc['authors']) {
          emit(doc['authors'][i], null);
        }
      } else if (doc['couchrest-type'] == 'Author') {
        emit(doc['_id'], null);
      }
    }"
end

>> Article.by_all_documents
=> [{"title"=>"Artigo: 0.290891879003595", "_id"=>"2c4680c3772b984195d18043f45ca574", "_rev"=>"1-1057019809",
  "authors"=>["97cc55b7c6124c54b1a2b1b111285294"], "couchrest-type"=>"Article"}, {"name"=>"Nome 0.807179829913082",
  "_id"=>"97cc55b7c6124c54b1a2b1b111285294", "_rev"=>"1-1103209569", "couchrest-type"=>"Author"}]

Assim você pode recuperar todos os documentos, sendo artigos ou autores. A diferença é que ele leva em consideração todos os documentos, ele realmente traz do CouchDB todos os documentos, já no CouchRest não, ele traz apenas o documento, os documentos aninhados são instanciados, eles não foram recuperados de seus documentos reais.

Assim, o CouchRest não lida com os documentos que mudaram de revisão, por quê ele cria as instâncias dos documentos aninhados a partir do documento. Do ponto de vista do CouchDB, ele não está trazendo os documentos aninhados com a ultima revisão, por quê ele não está pegando esses outros documentos.

O CouchRest trabalha da forma como o J. Chris desenhou o CouchDB, com um documento apenas. A necessidade de relação em documentos pode existir quando nesses casos, você precisa desses documentos em outros locais da sua aplicação. Se você quiser continuar da forma “CouchRest” você tem que preparar para que sua aplicação trabalhe de forma que ela sempre mantenha todos as revisão nas mais atuais (Ou talvez você nem precise dessa informação atualizada!).

De um jeito ou de outro, você vai ter que aprender como funciona as views e map-reduce. Você sempre vai ter que fazer alguma coisa nesse sentido dentro do CouchDB.

O XP possui práticas e dentre elas a que eu acho mais vantajosa é a Programação em Par, que é a atividade onde dois programadores usam um computador e eles codificam juntos. Eu, quando comecei minha vida no desenvolvimento, não colocava muita fé nesse tipo de desenvolvimento. Cheguei a espalhar para outros programadores que duas pessoas em um computador não funcionava, e que seriam melhor um programador por computador.

Esse é o pensamento Taylor de desenvolvimento de software ainda presente em várias empresas no mundo onde duas pessoas, cada um fazendo o seu trabalho, são mais eficientes do que as duas em um único computador. Quem tem mais experiência com desenvolvimento de software sabe que isso é uma afirmação falsa. Pode sim duas pessoas em um computador ser melhor do que uma.

O fato é que duas pessoas se motivam para desenvolver. Como estão em par, ver email, olhar os twitts, ler feeds, não entra nesse tipo de desenvolvimento. Em par, as distrações são menores porquê quem está desenvolvendo está preocupado apenas no código, e fica um dando pilha para o outro.

O design da solução se torna melhor e mais consistente. Aquele velho ditado popular que diz que duas cabeças pensam melhor do que uma é verdade, dois programadores pensam melhor na solução do problema, discutem mais, avaliam mais os riscos, escrevem melhor os testes.

Na equipe você acaba com ilhas de conhecimento. Programação em par é uma prática que se faz em no máximo algumas horas, então você sempre estará trocando de par e assim estará compartilhando mais rápido o conhecimento do negócio entre a equipe.

“Quem pariu Mateus, que balance o berço“. Uma outra vantagem é o codigo compartilhado, a prática ajuda para que todos saibam o que está sendo feito em cada parte do código, assim faz com que acabe o “Dono do código”, já que toda a equipe fez parte do desenvolvimento.

Ainda assim, alguns programadores não gostam de fazer programação em par, nesses casos não se pode forçar a barra. Faça apenas com que eles saibam que valores eles estarão perdendo. Não o demita só porquê ele não faz programação em par, talvez ela realmente seja bom sozinho. Mas faça com que ele compartilhe o código, que ele não crie ilha de conhecimento e que se comunique ao máximo com a sua equipe.

Mesmo que sua empresa não adote uma metodologia, eu recomendo que você a adote no seu dia a dia . A curto prazo você pode ter a sensação de que não está evoluindo muito, mas a médio e longo prazo, você, sua equipe e sua empresa começarão a ter o retorno mais rápido e a satisfação no desenvolvimento será bem maior.

Se fosse assim, já estaria com o design que eu quero pronto. Mas não, não é tão simples. Falo sinceramente quando uma pessoa que sabe fazer design e é programador é um profissional completo.

Desing é mais complexo do que muitos pensam. Não é apenas colocar alguns formulários e pronto! Não, longe disso. Você tem que entender de cores, de tamanhos, de posição. Depois você tem que entender de usabilidade, saber que botão é melhor para colocar aqui, ou para colocar ali.

Eu tenho noção de usabilidade. Sei que posicionar um botão num lugar errado pode fazer com que os clientes não saibam usar o seu produto. Sei que isso é o que define o seu produto e sinceramente, eu vejo poucas empresas que apostam alto nessa parte que eu considero importante.

Não basta que a coisa seja bonita, ela tem que ser funcional, e o mais importante, o seu cliente tem que saber usar sem precisar de um manual.

Quando um programador, como eu, tento fazer um desing de um produto, eu só consigo pensar nas funcionalidades que eu vou implementar com JavaScript, ou o banco de dados que eu vou usar para armazenar os dados. Eu não consigo imaginar mais, não porquê eu não saiba (Tá, eu não sei, AINDA! ;) mas porquê como programador, eu não prático isso no meu dia-a-dia.

Para um designer é fácil ele fazer isso, é a profissão dele. É a mesma coisa, ele não conhece programação para poder fazer o meu trabalho. Se ele sabe, com certeza, para ele é mais fácil saber o que deve fazer.

Lembro muito bem no livro da 37 Signals, Getting Real, onde eles falam que a melhor coisa que você faz no seu produto é começar pelo mais importante, o que seus clientes irão ver. O mais importante dessa abordagem é que você, como programador, só vai implementar o que é essencial para o produto funcionar. Nem uma linha a mais, nenhuma a menos.

A 37 Signals sabe que isso fará com que seu produto seja o mais simples possível. É verdade, o produto será. Mas por quê você apenas faz o essencial, não mais do que você vê. Para o seu cliente é a melhor abordagem! Em menos tempo ele tem o seu produto funcionando, com todos os recursos possíveis.

Foi nessa filosofia que o Rails foi desenvolvido. Não apenas para ser rápido, mas para está preparado para as mudanças do cliente. Em alguns minutos é possível mudar a forma como os dados estão sendo mostrados no Rails, mais uma vez, não apenas por que ele já é rápido e já vem com várias coisas disponíveis para que você faça a coisa mais rápido, mas por quê ele foi desenhado para que isso seja feito de forma rápida e sem dor, porquê foi essa praticidade que a 37 Signals estava precisando para resolver o seu problema.

Vai começar um novo produto e já escolheu o banco de dados, criou os models mas nem imagina como está as telas?! Peço que você reconsidere todo o seu trabalho, pois tenho certeza que esse seu produto não vai ser tão recompensante do que se você começar pelo design.

Eu gosto muito de ver o filme do Homem de Ferro, gosto muito de ver toda aquela coisa tecnologica funcionando. Acho o máximo quando ele usa o “raio repulsor” e passa da barreira do som!

O mais importante de se tirar dessa história, é como uma equipe motivada pode ser melhor do que meia duzia de ótimos profissionais.

Tony Stark estava entre a vida e a morte, sem recursos e com uma equipe reduzida (Ele e Yin Sen). Yin Sen inventa um aparelho para manter o coração do Tony Stark batendo. Depois disso, Tony Stark inventa uma armadura para libertar os dois dali.

A versão 1.0 da armadura é cheia de bugs e nem se parece com a última versão do filme. Ela não é muito resistente nem tão Ágil, mas é com ela que Tony Stark foge.

Até aqui, a história dele é bem parecida com várias start ups pelo mundo. Pouco recursos, equipe motivada, velocidade para ter um primeiro release, bugs e mais bugs.

Quando ele sai, ele “recebe” investimento. Aprimora sua armadura e torna ela forte, resistente e Ágil.

Esse mesmo estágio acontece com algumas start ups, elas crescem, recebem investimentos ou começam a ter retorno. Geralmente, neste ponto, é que muitas start ups mudam! Aumentam o quadro de funcionários, crescem, mudam de atitude. Outras não, continuam com a mesma equipe, apenas melhoram a motivação, que além de lançar um produto, agora tem um incentivo financeiro.

A 37 Signals sabe, pequenas equipes, mas extremamentes motivadas são melhores do uma “IBM” da vida sem motivação. E isso acontece no filme.

Tony Stark durante o filme tem um concorrente, Obadiah Stane. Ele junta os melhores engenheiros que o dinheiro pode pagar. Esses engenheiros não conseguem reproduzir o mesmo equipamento que Tony Stark possui. Para ter a primeira versão do Monge de Ferro ele tem que roubar o dispositivo do Tony para fazer a máquina dele funcionar.

Isso geralmente acontece em grandes corporações. Empresas como Microsoft, Google, que não tem mais a mesma agilidade que possuiam quando começaram. Elas se tornaram grandes, com milhares de processos e camadas. Para inovar, elas precisam gastar muitos recursos e ter muitos profissionais.

Diferente das pequenas empresas, que com poucos recursos e com muita motivação conseguem fazer produtos de sucesso. Aprender a motivar a sua equipe pode ser mais importante do que fazer um ótimo produto. Sem uma equipe motivada, o melhor dos produtos terá uma péssima execução e assim não terá o retorno esperado. Produtos médios mas com uma ótima execução vão ser muito mais lucrativos.

Fica a dica, tente aprender pensando fora da caixa, existe muito mais valores que você pode detectar em outras coisas que você nem esperava encontrar!

Nesses 4 lugares você pode adicionar configurações para um do environments do rails (production, test e development) ou em todos os environments (config/environment.rb).

Dentro desses arquivos, você pode configurar gems específicas para cada environment, ou para toda a aplicação. Mas uma coisa que muitos fazem é centralizar nesses locais configurações de inicialização de constantes, de conexões com serviços externos, monkey patches entre outros.

Recentemente estou desenvolvendo um projeto e brincando com CouchDB e CouchRest. No CouchRest eu resolvi fazer um monkey patch e na hora de colocar eu não sabia a melhor forma. Depois de um pouco de buscas no google lembrei do config/initializers/.

Nesse lugar é onde você deve colocar as coisas que vão ser inicializadas junto com o Rails. Todos os arquivos serão executados após o carregamento dos plugins.

Por exemplo, você pode inicializar o MemCached, fazer com que ele conecte nos 4 servidores de cache que você tem, limpar a cache e colocar na cache toda a sua aplicação.

Ou você pode fazer um monkey patch.

Assim você mantem seus environments limpos.

Esse ano a instituição escolhida foi a Cotolengo. Sobre o evento, vai contar com os mais importantes Railers do Brasil, vai ser um puta grande evento sobre Rails. Vamos ajudar as crianças e vamos ganhar conhecimento que é o este Brasil esta precisando, principalmente nosso estúpido senado.

O Rails 4 kids acontecerá no dia 12 de setembro, não fique de fora dessa, não perca essa oportunidade de ajudar as crianças e poder contar com um dia inteiro de rails com os melhores do Brasil, faça já sua inscrição.

O que eu vejo é que muito se fala sem ao menos saber do que se trata. Pouca gente percebeu, mas quem leu a lei na íntegra sabe, para ministrar aulas, ou escrever em blogs (Eu sei que é muito, mas podemos interpretar a lei assim) sobre qualquer coisa que seja de domínio de um “Analista de Sistemas” só poderá ser feita por um Analista de Sistemas.

Não somente isso, mas pesquisas e experimentação só poderão ser feitas por Analistas de Sistemas. Ministrar aulas só poderá ser feita por Analistas de Sistemas.

A lei não da direitos as pessoas que são formadas, por exemplo, em Administração, mas com mestrado em Engenharia de Software a ministrar aulas de Engenharia de Software, pois isso só cabe aos formados em Ciências da computação, processamento de dados ou analistas de sistemas.

No twitter, alguns falaram que a maioria é Pessoa Jurídica e como empresa tanto faz a lei. Isso é um engano, a lei é clara, punirá quem estiver trabalhando como Analista de Sistemas e não for registrado no conselho regional de informática (CREI) ou quem facilitará a quem não é registrado e comprovado Analista de Sistemas a exercer a profissão.

Ninguém ainda sabe como ficará profissionais que trabalham em casa para empresas que ficam em outros estados (Como eu já trabalhei no ano passado). “Eu vou ter que me registrar no CREI aqui no Piauí, em São Paulo ou nos dois?! Por quê a sede da empresa é em São Paulo e eu trabalho em casa!”.

E como ficará o trabalho internacional!? Existem pessoas que fazem outsourcing para empresas na America do Norte, Europa e outros lugares do Mundo, como ficarão essas pessoas!?

Ninguém está preocupado com o impacto imediato que esta lei tem, e o pior, ninguém está se preocupando com o impacto dessa lei a daqui 10 anos. Onde o Brasil será mais uma vez uma nação que consumirá apenas a sucata que é criada lá fora, por que essa lei limitará em todos os aspectos o desenvolvimento tecnologico do nosso país.

Mais uma vez o Brasil está nadando contra a maré querendo “inventar” um impedimento do desenvolvimento de conhecimento. Mais uma vez o Brasil afundará com uma medida que não tem lógica. Mais uma vez nosso país está fazendo o contrário do que pensamos e queremos!

Agile, Pair Programming, Espírito Open Source e resolvemos que devíamos trazer esse tipo de ambiente aqui para Teresina! Eu e o Cleiton conversamos com todos os piauienses que foram para o Oxente Rails e ficou certo uma data para realizarmos o primeiro Coding Dojo aqui no Piauí.

Foi um evento FODÁSTICO. Não tínhamos nenhuma experiência sobre como fazer o Coding Dojo ou como nos organizar ou qualquer outra coisa. Para um Dojo “Piloto” nós fomos muito bem!

Partimos para o segundo e foi melhor ainda. Não por que foi ótimo e resolvemos o problema, mas por que tivemos nossa primeira experiência ruim! E como nas metodologias Ágeis, nós aprendemos com os erros! O feedback foi essencial no segundo Coding Dojo.

Para o próximo, que vai acontecer nesta semana, considero que será um dos melhores! Vamos fazer um rodízio melhor!

Se você quiser participar do Coding Dojo, entre no nosso grupo e fique ligado no que vai rolar na lista, ela está sendo super importante para a gente melhorar o Coding Dojo a cada edição!

Eu fico feliz em saber que tem gente fora do nosso estado que está gostando do que nós estamos fazendo aqui no Piauí! Eu acredito que nós podemos nos tornar uma potência em computação! Basta nos esforçarmos! :)