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:

Usando Working Sets no Eclipse

Quem não tem mais de uma workspace do Eclipse que levante a mão. Alguém!? Alguém!? Tenho certeza que todos que trabalham com o Eclipse há algum tempo, por mais organizado que seja já se pegou gerenciando duas, três, quatro ou mais workspaces.

Isso sempre foi um problema pra mim, especialmente pelo modo que o Eclipse gerencia suas configurações, que são particulares para cada workspace. Isso é bom, é um modelo legal e funciona super bem. Não era bom pra mim pois eu estava teimando em usar as workspaces de forma errada, então eu sempre tive um sério problema com as configurações, pois elas estavam sempre diferentes entre cada workspace.

Eu sempre tentei separar os projetos por clientes, por área de interesse ou por atividade. Uma workspace de projetos open source, outra do cliente ABC, outra do cliente XPTO, outra de projetos que eu estava estudando o código e assim por diante. Os problemas na hora de trabalhar eram vários, por exemplo: um repositório criado numa workspace era só dela, um atalho configurado na outra ficava só lá, um bookmark também, ou templates de código também. Resumindo, a bagunça ficava gigante e a redundância de configurações então nem se fala.

Então resolvi jogar tudo pra uma workspace só. Problema resolvido!? O das configurações sim, mas de brinde ganhei um novo: performance. Outro hábito não muito bom que eu tenho é o de manter todos os projetos abertos. São tantos projetos (141 atualmente) que só pra abrir o Eclipse demorava muito tempo. Depois, pra abrir/buscar um tipo (CMD+SHFIT+T), por exemplo, demorava de mais para indexar, limpar a workspace então nem pensar. A solução que eu encontrei foram as Working Sets, um recurso que sempre esteve ali presente e eu nunca dei bola.

As Working Sets são grupos de trabalho que podem concentrar um ou mais projetos e funcionam como se fossem várias workspaces. No meu caso as working sets caíram como uma luva para a minha antiga distribuição de workspaces. Ao invés de usar várias workspaces por clientes, agora mantenho uma única workspace com várias working sets, algumas de clientes, outras de estudo, etc. Isso resolveu o meu problema de configurações completamente e com as working sets eu posso escolher em que vou trabalhar num determinado momento e ver somente aqueles projetos, resolvendo também o problema de performance.

E para quem quiser usar as working sets, seguem algumas dicas.

Ativando a visualização por working sets

O passo essencial é trocar a visualização de Projetos para Working Sets, isso é bem simples. Veja a imagem a seguir:

eclipse_ativar_working_sets

Gerenciando suas working sets

No próximo passo você deverá criar as suas working sets e associar cada uma delas com os projetos que quiser.

eclipse_visualizando_working_sets

Crie, modifique ou remova qualquer working set.

eclipse_gerenciando_working_sets

Trabalho feito, agora basta escolher em qual working set quer trabalhar e pronto, paz e sossego.

eclipse_go_into_working_set

Lembre-se que você pode optar por fechar ou abrir todos os projetos de uma working set bem como “ir e voltar” para qualquer uma delas.

Um exemplo completo com JAAS

Devido ao um dos últimos posts deste blog, sobre utilização de JAAS com JDBC Realm e a grande procura por exemplos mais completos, com login e logout, por exemplo, resolvi melhorar um pouco a aplicação e disponibiliza-la para download.

Desta vez a aplicação está no meu github, junto com a aplicação do primeiro post sobre JAAS. São elas:

As aplicações possuem um README e alguma explicação, qualquer dúvida fiquem a vontade para lançar perguntas nos comentários, as duas aplicações foram feitas de forma a simplificar o máximo possível a utilização e configuração dos recursos de JAAS.

Autenticação e Autorização: JAAS com JDBC Realm

Recentemente ministrei um curso sobre Segurança em aplicações JavaEE, onde, grande parte do treinamento é a utilização e configuração do JAAS (Java Authentication and Authorization Service) abordando Basic e Form Authentication usando os realms: File, JDBC e LDAP.

Aproveitando o embalo do treinamento e principalmente pela empolgação dos alunos da turma quando viram quão simples e fácil é usar o JAAS, vou mostrar a configuração de autenticação e autorização em uma aplicação JavaEE usando Basic Authentication e JDBC Realm.

O JAAS (Java Authentication and Authorization Service) é a API padrão do Java para controle de acesso e autorização em aplicações JavaEE. Com JAAS é possível autenticar e validar usuários e certificados, bem como controlar a possibilidade de acesso e/ou utilização de recursos na aplicação (arquivos, diretórios, URLs, conteúdo, etc). Resumidamente o JAAS cuida de:

  • Autenticação: deve verificar se um usuário é ele mesmo através de validação de senhas e/ou certificados.
  • Autorização: com base em um usuário identificado, as regras e controles de permissão e acesso serão aplicadas na aplicação/produto e seus recursos.

O exemplo a seguir foi feito usando o Eclipse, Glassfish_v2 e MySQL, e não há nenhum segredo obscuro, simplesmente criaremos um Dynamic Web Project e usaremos o console do Glassfish para criar o realm.

Continue lendo “Autenticação e Autorização: JAAS com JDBC Realm”

Porque eu não compraria o IntelliJ IDEA

Não é nenhum segredo que eu gosto muito do Eclipse, já andei falando isso aqui no blog por algumas vezes. Também já fiz um retrospecto de como foi uma experiência trabalhando com Netbeans, a qual resultou numa migração para o Eclipse. Desta vez a experiência está sendo com alguns produtos da JetBrains, e como andei falando muito bem do TeamCity, muita gente já me pertubou dizendo que eu fui muito parcial, então agora vou falar um pouco sobre o Intellij IDEA, versão 7.

Eu tenho no meu computador pessoal o Intellij IDEA 8 devidamente licenciado e registrado graças a um programa da Jetbrains que presenteia JUG Learders com licenças de seus produtos. Apesar disso eu nunca dei tanta atenção a esta ferramenta além de um projetinho de brincadeira aqui ou outro ali.

Mas ultimamente estou trabalhando numa equipe onde o Intellij IDEA 7 é a IDE oficial, até então nada de mais, eu pensei: “Vou usar o Eclipse, não tem problema”. Mas esta equipe possui uma certa proximidade com a ferramenta e possuem até plugins desenvolvidos para o IDEA que facilitam o trabalho com os produtos criados e mantidos pela empresa. Então aproveitei para não criar mais empecilhos e topei a experiência.

Já li e ouvi comentários fervorosos sobre o IDEA, pessoas que realmente gostam muito desta ferramenta. Na maioria das vezes sempre elogiam: o editor, as formas diferentes de code completion que podem ser alteradas ao gosto do desenvolvedor, as opções de refactoring, dentre algumas outras.

O primeiro: suporte a code completion. Não achei que fosse um diferencial que pudesse justificar o preço a ser pago na ferramenta. Existem alguns recursos interessantes nesta parte, é fato. Por exemplo poder controlar se o case sensitive será aplicado somente na primeira letra do que estiver sendo digitado, em todas elas ou em nenhuma. Excluir determinados pacotes/classes/métodos do code completion eu também gostei.

No editor, o recurso como ele chama de Virtual Space eu não gostei nem de longe, basicamente o editor permite que o cursor possa ficar em qualquer lugar, mesmo dentro de um espaço de tabulação ou após o final da linha, ou seja, espaços que não existem – virtuais. Este recurso pode ser desabilitado, mas vem ativado por default e eu perdi uns bons dias para descobrir que podia ser desabilitado. Da mesma forma o limite de abas abertas, além de ser pequeno (por default, somente 10) ele não avisa que chegou no limite, simplesmente funciona como uma fila, os mais antigos são descartados em detrimento aos mais novos. Poder abrir os arquivos com apenas um clique também é legal, mas não ter um botão pra fechar a aba e ter que usar o botão direito pra isso não é muito legal.

As opções de refactory são boas, mas ainda sinto um pouco de dificuldade com os nomes diferentes, geralmente onde eu esperava encontrar um “Extract Method”, por exemplo, acabo encontrando um “Introduce Method”. Só que ainda não encontrei “Aquela” opção única de refactory que só exista no IDEA e que fosse muito boa.

Aproveitando que foi o post sobre TeamCity que me fez escrever este post, o plugin de integração entre o IDEA e o TeamCity é legal, mas o melhor recurso que o plugin trás, o Delayed Commit, também pode ser usado com o plugin para Eclipse ou Visual Studio, então, menos um ponto para se prender a uma IDE paga.

A comunidade desenvolvedora de plugins não me pareceu tão grande e ativa quanto a do Eclipse, e isso, pra mim é um grande diferencial. Considero e dou muito mais valor ao “suporte” da comunidade e das pessoas que lidam diariamente com uma ferramenta do que aquele suporte que você compra e paga.

Estou usando o IntelliJ IDEA há cerca de 6 ou 7 semanas, então eu posso ainda não ter descoberto as “maravilhas” que o façam valer o seu preço, mas enquanto não encontrei e ninguém da equipe me mostrou tais maravilhas, continuo pensando que não vale a pena devido ao preço e à altertivas como o Eclipse. Não considero o IntelliJ IDEA uma ferramenta ruim, apenas considero uma estratégia ruim uma empresa gastar seiscentos doláres por licensa numa ferramenta que, ao meu ver, não irá agregar um diferencial que justifique o seu preço.