Vinicius Ebersol

Estava agora olhando meu Twitter e vendo o que as pessoas que eu sigo têm postado de dicas interessantes. Eu vi uma indicação do Nando Vieira para um post que ele deve ter escrito hoje, sobre relacionamento Has And Belongs To Many, o famoso HABTM. Fui ler, numa boa, uma dica excelente por sinal. No entanto, enquanto eu lia acendeu uma luzinha na minha cabeça: por que diabos todo exemplo de Rails tem modelos do tipo post, comments, users no meio?

Eu me imaginei na seguinte situação: nunca ouvi falar do bendito Ruby on Rails, vou me informar sobre. Aí eu googlar sobre o assunto e vou me deparar com os cabeções de rails no Brasil e até mesmo o famoso screencast “Creating a weblog in 15 minutes” do site oficial do Rails. Simplesmente todo exemplo referente ao Rails tem algo de um blog, o que leva a pessoa – no caso eu – que está apenas dando uma olhada nesse framework a pensar que ela serve basicamente para desenvolver blogs.

Claro que esta hipótese é tão idiota quanto o imbecil que escreveu ela, mas fiquem atentos, não estou descartando a hipótese. Tampouco estou criticando a postura do Nando ao utilizar esta analogia. Ele tem todo o meu respeito e admiração. O ponto é que tudo relacionado ao Rails acaba caindo no velho exemplo do Blog. E a dúvida que fica, é tão mais fácil explicar as coisas baseadas em um blog que bloqueiam as pessoas a criar dicas utilizando outros modelos?

Acabei de ler na lista de e-mails Rails-br um e-mail do Fábio Akita anunciando que o repositório do Rails irá migrar do Subversion para o Git. Isto tem um significado muito importante, pode significar o fim de uma era onde o subversion era dominante. Posso estar exagerando afirmando isto tão cedo, pois não sou vidente, mas hoje é o Rails, amanhã quem sabe o que será?

Aproveitando o post vou indicar também aos leitores e colegas que estão começando no Git este Micro tutorial de Git que o Fábio Akita, de novo ele, escreveu.

Recentemente fizemos a migração do Trac para o Redmine, justamente porque tem suporte a Git. No post anterior eu fiz uma pergunta a qual não respondi, pois precisaria testar a aplicação em produção. A pergunta de que o Redmine seria um trac perfeito no post anterior já pode ser respondida. Não é perfeito, é QUASE PERFEITO! Já pusemos ele em produção em um novo projeto e migramos um projeto que estava no Restrospectiva pra ele.

O relato do Everton J. Carpes é algo que sintetiza bem o que o Redmine significou para nós:

Perfeito soh o tempo dirá, porém excelente, certamente.

O Sistema realmente me surpreendeu. Entre as muitíssimas features interessantes, uma me chamou MUITO a atenção: “controle de workflow”.

O Redmine tem um mecanismo que permite ao administrador dele controlar o que eles chamam (comercialmente) de workflow, mas eu (geek) prefiro chamar de “máquina de estados”.

Através deste controle você consegue estabelecer como o tracker permitirá as alterações de estados de um ticket, e o mais maravilhoso, POR ROLE!!!

Isso simplesmente abre horizontes em termos de gerência, pois permite a você estabelecer padrões onde gerentes possam realizar tarefas X, desenvolvedores tarefas Y e por aí vai… Isso é uma forma clara de estabelecer os padrões de gerência de seu time de desenvolvimento sem complicar para ninguém.

Alem disso, claro as centenas de vantagens em features muito interessantes (como o suporte ao GIT como SCM!!! ).

Uma outra coisa maravilhosa sobre o Redmine eh que ele REALMENTE é uma aplicação Rails e segue suas convenções e práticas. Eu que estava já “de cara” com o Retrospectiva por ele não me dar suporte a outro mecanismo de e-mail que o smtp padrão, fiquei extremamente feliz de poder voltar a usar o msmtp.

Buenas, puxações de saco a parte, vamos agora aproveitar a ferramenta, contribuir se possível e procurar sempre por melhorias.

Mesmo assim, estamos muito atarefados, pois o Brasil começou a funcionar em abril, e de quebra eu estou na fase de redação da minha monografia.

Off-topic nem tão off assim

O trânsito é realmente um ambiente muito fértil para pensar na vida. Durante o tempo em que estava dirigindo pela cidade e recordando os problemas que estamos passando, pensei em várias dicas que poderia dar em relação à nossa experiência como Startup.

1. Nunca conte com um cliente antes dele efetuar o primeiro depósito;
2. Utilize sempre o mesmo software e a mesma identação, identações distintas acabam com os diff’s;
3. Nunca se comprometa produzir a quantidade que não pode cumprir, a sua improdutividade afeta a produtividade dos membros da outra equipe;
4. Sempre ponha um prazo de validade nos contratos, contratos antigos, com orçamentos antigos podem afetar o andamento das atividades atuais;
5. E finalmente, por último, aprenda com os erros alheios para não repeti-los.

E como diria Leonardo Monasterio, meu orientador:

“Dado bom é o dado que a gente tem.”

Eis meus dados (Eu não queria perder a piada):