Arquivos da categoria: Desenvolvimento

Meu ambiente de trabalho em 7 itens

Meu ambiente de trabalho em 7 itens, alguém começou com este meme legalzinho e a minha amiga Loiane falou sobre seu ambiente de trabalho e me indicou para que eu falasse um poquinho sobre meu ambiente de trabalho e desse continuidade ao meme.

1) Mac OS

Macintosh Quadra 605

Minha primeira experiência com o Mac OS foi em 1997 quando ainda era Macintosh e não era nada hype. Conheci um Macintosh Quadra 605, que já era bem velho na época, mas acabei gostando *muito*. Logo depois, em 1998 quando o primeiro iMac foi lançado com o PowerPC G3 eu comprei um pra mim e me tornei o único besta da cidade a ter um Macintosh – não bastasse, antes, ser o único besta a usar Linux. Desde então tenho Macs. Cheguei a ficar alguns períodos sem Mac, mas não mais que 1 ano e pouco.

Obviamente também gosto e uso muito Linux, gosto de qualquer distribuição baseada no Debian, em especial o Ubuntu e detesto qualquer coisa RPM based. Tenho vários servidores que administro com Ubuntu Server e Debian (da Giran e de clientes) e algumas máquinas virtuais no meu macbook pro também com Ubuntu e Ubuntu Server.

Dizer que eu uso o Mac OS porque é bom, estável ou eficiente é chover no molhado. Eu simplesmente uso pois gosto e acho que gosto pois sempre tive Macs. Não é assim com Windows? Pergunte a alguém porque ele(a) usa Windows.

iMac G3 - Meu primeiro Mac

2) Gmail

O gmail é hoje uma das minhas principais ferramentas de trabalho, se não for a principal. Depois que abri a Giran com o Léo Hackin o gmail e o keynote tonaram-se ferramentas indispensáveis e de uso diário – o gmail eu nunca fecho.

Acho que até já sei mais atalhos do gmail do que do Eclipse.

3) Eclipse e TextMate

Ainda trabalho bastante com Java e não pretendo deixar de fazer isso tão cedo, logo, o Eclipse é minha IDE favorita e campeã em todos os aspectos.

Mas não vivo só de Java. Sempre usei o VIM para qualquer outro tipo de trabalho, mas depois que comecei a aprender Ruby e Rails fui aprendendo a usar o TextMate com alguns railers e curti muito. Hoje o VIM acabo usando somente em servidores remotos e pra quase qualquer outro tipo de trabalho uso o TextMate.

4) Git + Github

Eu conheci o git e gitorious em 2008 quando trabalhei na globo.com. Não foi muito fácil entender o funcionamento de um repositório distribuído no começo, mas as confusões e brincadeiras foram legais o suficiente para não desistir: “- Mas você fez commit? – Sim! – Mas não basta, tem que fazer também o pu… ué pull ou push mesmo?”

O git é incrivelmente simples e eficiente e o github fez um trabalho igualmente fantástico ao criar uma ferramenta que simplificou o uso do git em projetos open source e a colaboração entre os desenvolvedores destes projetos.

Dica: quer ter o seu repositório privado e na nuvem (putz, não espacei das buzzwords): Using git + dropbox. Uma combinação matadora.

5) Bash

terminal

Não da pra trabalhar sem um shell. Eu uso o bash e a aplicação do Terminal fica nos meus itens de lançamento automático ao reiniciar o Mac OS (não que isso aconteça muito). Uso o terminal pra tudo, inclusive para o git. Não tenho nada de outro mundo nos meus bash files, apenas alguns alias, cores e auxiliares que me ajudam muito no dia a dia, como, por exemplo, saber em qualquer branch em estou num projeto git.

6) Giran

A Giran não é só a empresa onde trabalho, é o meu item principal de trabalho. Primeiramente eu trabalho na Giran, mas trabalho para levar a Giran adiante e trabalho também com as limitações e qualidades da Giran, além de trabalhar sempre para a Giran, mas, principalmente eu trabalho com às pessoas que hoje, juntas, são a Giran.

Não quero falar muito pra não parecer jabá disfarçado/forçado ou algo do tipo, mas se estou feliz e realizado no trabalho hoje em dia, sem dúvida é culpa desses excepcionais da Giran e da cultura de trabalho que estamos criando juntos por aqui, sem isso não adiantaria 7 ou 70 itens do meu ambiente de trabalho.

7) Monitor externo e o mito da produtividade

Aqui está um ponto delicado da minha rotina de trabalho. Por muito tempo sempre pensei: quanto mais monitor, melhor. Errado! Grande engano e grande mito. Com o passar do tempo os monitores externos só serviam para acumular coisas abertas e simultaneamente visíveis para me tirar a atenção, me atrapalhando a manter o foco em uma coisa de cada vez.

Pra mim, no meu caso, o monitor externo não aumenta em nada a minha produtividade, pelo contrário, se eu der mole até me atrapalha e reduz a minha produtividade. Eu eventualmente uso o monitor externo para ajudar com a visualização ou acompanhamento de logs e consoles ou então durante sessões de programação em par. Fora isso prefiro deixar desligado.

Minha estação de trabalho hoje: monitor externo 21.5 full hd 'de lado' + macbook pro 13'

Sem o monitor externo eu organizo todas as minhas coisas em várias spaces separadas e não permito que o CMD+TAB mude direto para a aplicação selecionada + space em que ela estiver. Pra eu mudar de aplicação tenho que mudar de space mesmo, evitando que eu perca o foco no que eu estou fazendo.

E é isso. Difícil falar tanto sobre itens de desenvolvimento hoje em dia quando às vezes chego a passar um dia inteiro sem desenvolver nada. Mas o gmail tem se mostrado uma boa IDE, por enquanto =P

E pra continuar…

Claro, indicarei alguns amigos para escrever sobre seus respectivos ambientes de trabalho também, pra ficar tudo igual indicarei 7 amigos:

RailsRumble 2010 Review

No último final de semana participei do RailsRumble 2010, uma competição onde um time com no máximo 4 pessoas tem 48 horas para desenvolver uma aplicação usando Ruby on Rails.

Meu time desenvolveu o Mittun, um gerenciador de eventos. Fazendo uma rápida retrospectiva (só do meu ponto vista, não fizemos uma retrospectiva do time ainda):

+ Conseguimos definir em pouco tempo as principais tarefas e funcionalidades do produto. Isso ajudou muito a andarmos com um objetivo claro até o final do projeto
+ Conseguimos preparar nosso ambiente de produção/deployment (Ubuntu, MySQL, Ruby, Rails, Apache e Passenger) em menos de uma hora com deployment automatizado com capistrano. Isso nos tirou uma grande preocupação e nos permitiu focar no desenvolvimento do produto.
+ Voltar a ter um contato forte com Rails foi energizante.
+ Fizemos a busca de eventos com paginação, tudo bonitinho …
… mas esquecemos de coloca-la no produto
Como muitos outros projetos, não conseguimos deixar claro qual o objetivo do produto na sua página principal, quando um novo usuário entra no site ele não consegue saber de cara qual o propósito da ferramenta.
Infelizmente dormimos uma noite, pois é. Trabalhamos 24 horas direto, da sexta-feira a noite até o sábado a noite, direto, sem parar para dormir nenhum minuto. Então dormimos a noite de sábado e voltamos às 12 últimas horas do domingo.
Foi meio chato não ter ficado entre os 20, acho que todos os times devem ter um pouquinho desta sensação, afinal todos se esforçaram muito. Mas esse não era nosso objetivo principal, então vamos em frente.

O Rumble foi extremamente importante pra mim, por muitos motivos e muitas razões. Há todo o desafio de ter que desenvolver uma aplicação em 48 horas, o que, em qualquer linguagem já é um grande desafio. Some ainda o fato de ter que lidar com todas as dificuldades de um projeto real, definir e alinhar objetivos, deixa-los claros e evidentes o tempo todo, priorizar funcionalidades mais importantes, abrir mão de algumas outras e manter o andamento do trabalho visível. E mais um pouco: definir a visão da produto, layout (só dou pitacos nessa parte), comportamentos, funcionalidades e, principalmente, desenvolver o produto. Tudo em 48 horas!

Mas pra mim, pessoalmente, o mais importante foi o que consegui vivendo este projeto, que foi ter de volta um pouco de alegria e motivação para desenvolver novas aplicações e resolver problemas, trabalhar com coisas simples e eficientes, ver os resultados acontecerem, o produto andando e crescendo, isso não tem preço :) Eu estava há algum tempo sem ter um contato forte com Ruby on Rails e o Rumble foi muito legal nesse ponto e me ajudou bastante.

Mas claro, tudo isso só foi possível graças ao meu time (blastoooooooise), que foi formado por pessoas – literalmente – excepcionais: Makoto, Cabral e Roberto Soares, os quais devo muitos agradecimentos. E também ao apoio da Giran, que nos proporcionou um ambiente muito bacana. Enfim, foram as 48 horas mais divertidas e com maior aprendizado dos últimos meses, talvez até deste ano.

E foi isso, muita diversão e aprendizado. Não conseguimos ficar entre os 20 este ano, mas tentaremos de novo no ano que vem! Blastooooooise!

Safari 5 plugin: SaveTo Social Bookmarks

Logo quando o suporte a desenvolvimento de extensões no Safari foi lançado eu corri e fiz um pequeno plugin, muito mais com a finalidade de testar do que qualquer outra coisa. Mas como sempre preciso de alguma coisa eu fiz logo algo que eu estava querendo ter, que era um botão para salvar no Delicious. Foi uma experiência legal e super simples, muito simples.

Entretanto, após usar o plugin eu notei que não estava legal: o comportamento de abrir uma nova aba, salvar o favorito e manter a aba aberta não ficou legal, não estava bom. Mas a sandbox do Safari não me permitia fazer muita coisa, e nem pouca coisa também: window.open e window.close, por exemplo, são duas que não funcionam dentro da sandbox de extensões do Safari.

A solução foi usar a injeção de scripts e estilos do próprio Safari para fazer algumas coisinhas com JavaScript, como abrir ou fechar uma janela. Aproveitei a oportunidade para fazer um novo plugin, diferente e mais afrescalhado completo, esse cara foi o SaveTo.

SaveTo permite enviar a página atual para o Delicious, igual ao plugin anterior, mas ele faz isso abrindo uma nova janela que é fechada automaticamente logo após o favorito ser gravado, as diferenças: 1) agora são necessários dois cliques para salvar o favorito, antes só precisava de um; 2) além do Delicious coloquei os atalhos para outros serviços (que escolhi entre os que eu uso com mais frequência).

Para quem tiver interesse em baixar, a distribuição está disponível aqui. E o código fonte aqui no meu github.

Lembrando que antes de instalar o plugin é preciso ativar as extensões no Safari, siga esses passos:

– Menu: Safari > Preferences

– Guia: Avançado > Mostrar menu de desenvolvedor

– Menu: Desenvolvedor > Ativar Extensões

Plugin do Delicious para Safari

O Safari 5 foi lançado este mês pela Apple (ontem, dia 07/06/2010) e dentre as novidades a que eu mais gostei foi poder desenvolver meus próprios plugins e extensões para o Safari, através do: Safari Developer Program.

Na verdade sempre foi possível fazer plugins para o Safari, é fato, mas não havia um suporte nativo decente, os plugins menos piores precisavam do SIMBL (que eu não gosto de usar) e por aí vai.

O que eu mais sentia falta no Safari era de um mísero botãozinho para salvar páginas no Delicious, não precisava nem mostrar os favoritos ou fazer qualquer outra coisa, eu só queria salvar. Da pra fazer isso facilmente com um atalho na barra de favoritos, o próprio delicious ensina, mas eu sou um cara chato de personalidade difícil (de verdade) e não gosto de deixar a barra de favoritos ativa, de modo a otimizar a área útil de visualização no navegador.

Outra alternativa era o DeliciousSafari, um plugin que faz tudo o que você precisa e o que você também não precisa ou nem imagina que fosse responsabilidade do plugin, algo como o pacote Office da M$. Eu já tentei usar o DeliciousSafari várias vezes, mas, por coincidência ou não, toda vez que eu começava a utiliza-lo o Safari ultrapassava a marca de 1.5Gb de consumo de memória RAM.

Hoje resolvi testar a possibilidade de criar plugins para o Safari5 e me surpreendi, foi muito fácil e indolor. Com menos de 30 minutos consegui deixar o plugin funcional. O mais difícil foi o Tagliati fazer o ícone pra mim (brincadeiras com o ‘designer’)

O plugin é super simples, é somente um botão na toolbar do Safari que salva a página ativa no Delicious, exatamente o que eu tanto queria :) Espero que possa ser útil pra mais alguém. Algumas poucas funcionalidades extras para este plugin já estão em desenvolvimento e outros plugins também, espero poder anuncia-las em breve.

Para quem tiver interesse em baixar, a distribuição está disponível aqui. E o código fonte aqui no meu github.

Antes de instalar o plugin é preciso ativar as extensões no Safari, siga esses passos:

– Menu: Safari > Preferences

– Guia: Avançado > Mostrar menu de desenvolvedor

– Menu: Desenvolvedor > Ativar Extensões

Desenvolvimento ágil de software com SCRUM

Esta semana fui convidado pelo professor Egídio, da Faesa, para falar um pouco para os seus alunos sobre desenvolvimento ágil de software utilizando SCRUM. Eu adoro falar sobre SCRUM e já fiz esta apresentação algumas vezes, mas cada vez é diferente, não tem jeito, então aproveitei a oportunidade para fazer um refactory considerável na apresentação de SCRUM que tinha.

A apresentação em si é básica, fala sobre SCRUM, seus papéis, responsabilidades, atividades e ciclo de vida. Nesta apresentação tento focar na desmistificação de alguns conceitos e idéias simples que, às vezes, as pessoas que ainda não conhecem o SCRUM possam ter formado naquelas conversas de corredor, e claro, mostrar alguns benefícios e problemas reais que a adoção do SCRUM trará para a organização e para as pessoas envolvidas.

A apresentação está disponível aqui no meu slideshare e também no blog. A conversão/compressão do slideshare deixou a apresentação um pouco mais feia, quem quiser faça o download do arquivo que este estará bem melhor.


Dúvidas, críticas e sugestões farão meu dia um pouco melhor, fique a vontade para me procurar.