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:

• @leohackin
• @makotovh
• @wbotelhos
• @franciscosouza
• @m3nd3s
• @tagliati
• @bt1

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!

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.

O 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

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

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.

Mas há um grande dilema: Como consigo o feedback sincero dos membros do meu time?

A resposta parece simples, afinal, não bastaria apenas perguntar? Bom, é quase por aí, mas deve-se tomar muito cuidado com o tipo de pergunta a se fazer.

A primeira regra que deve-se ter consciência é que nunca será possível conseguir feedback sincero com perguntas idiotas. Uma pergunta idiota geralmente é uma pergunta da qual você não quer ouvir a resposta, ou uma pergunta que você espera ouvir aquilo que você quer ou, até mesmo, uma pergunta cuja resposta é óbvia.

Pergunta idiota: No meio de um jogo de futebol, pergunta-se para a árbitro: Você está ocupado?

Qualquer ser vivo pensante saberá a resposta do árbitro. Se a pergunta é idiota a resposta é tola.

Isso não significa que a pessoa não queira te dar feedback, mas que há outras maneiras mais eficazes de se conseguir feedback. Não faça uma solicitação em forma de ordem pergunta direta.

Lembre-se sempre destas palavras pois elas serão a chave para o seu sucesso como líder de qualquer time em qualquer área ou empresa, especialmente para se obter feedback sincero e colaboração das pessoas. Estas são as palavras mais poderosas que existem para obter cooperação: “Eu preciso de”. Essas simples palavras são capazes de mágicas e feitos surpreendentes.

Pedir feedback não significa que você irá consegui-lo, especialmente se o pedido começar com “eu quero”. Quando você diz a alguém de seu time que você “quer” algo, a primeira coisa que essa pessoa pensa é: “ah, claro, todos queremos algo que não podemos ter”. Mas se você começa com “Eu preciso de”, significa que você pensou sobre o que é necessário para alcançar o que você está pedindo e, para tal, precisa da ajuda desta pessoa. É incrível como as pessoas adoram sentir-se necessárias, saber que podem ajudar com algo, isso faz toda a diferença entre escutar uma resposta tola e conseguir um feedback sincero.

Aprendendo a obter feedback: Preciso de feedback específico sobre meu plano para que a próxima iteração dê certo.

Simples e indolor, certamente você terá muito a ouvir e aprender.

Um líder é qualquer pessoa que possa lhe dar apoio e orientação necessárias para alcançar seu objetivo. Às vezes o seu maior desafio como líder é saber onde e quando cada pessoa do seu time executará este papel, e cabe a você conseguir obter o feedback necessário destas pessoas.

Não estou aqui criticando HTML e CSS, eu entendo perfeitamente a importância de tudo isso, mas não posso negar que nunca me dediquei muito para aprende-las, até porque nunca tive a necessidade de ser o responsável por esse trabalho. Exatamente por isso eu aprendi algo babacamente simples esses dias, porém extremamente eficiente.

Imagine mudar o CSS, subir pra produção e o cliente simplesmente ver o seu site totalmente quebrado? Pior, mudar uma imagem (um banner ou qualquer outra imagem) e o cliente continuar recebendo a imagem antiga. Quem trabalha com sistemas web e nunca passou por isso?

É muito comum alterarmos qualquer coisa estática como CSS, imagens e até JavaScript e essas alterações não serem interpretadas pelo navegador. O jeito é limpar (ou desligar) o cache do navegador, dar uns 3 ou mais refreshs ou apelar pro CTRL+F5, isso é o que fazemos desenvolvendo. Mas e quando isso acontece em produção, vamos dizer pro usuário/cliente ‘limpar o cache’? Claro que não, temos que dar um jeito então do navegador do cliente reconhecer as alterações logo na primeira visita.

Isso ocorre pois o navegador faz cache local destes recursos e os utiliza quando julga ser a melhor opção. A mesma coisa ocorre com proxy de redes, que também podem fazer cache. O jeito para descartar esse cache é fazer algum malabarismo no servidor web, mas nem sempre isso é possível, então precisamos recorrer à aplicação, onde – geralmente – temos maior domínio.

O cache no navegador tem uma regra básica super simples: o nome do recurso estático. Se mudarmos o nome de um arquivo CSS ou imagem, por exemplo, não teremos problema algum com cache. Se você puder fazer isso na sua aplicação, ótimo, problema resolvido.

Mas se não puder, temos outra opção simples e eficiente, podemos anexar algum parâmetro falso no nome do recurso, por exemplo:

Ao atualizar propriedades desta folha de estilo as alterações não serão perceptíveis no navegador enquanto o cache (do navegador) não for atualizado. E isso ou o cliente faz explicitamente ou nós faremos por ele. Então, vamos fazer a nossa parte, vejam:

O simples parâmetro ?1 cuida disso pra nós. O navegador vai encarar que se trata de uma nova folha de estilos e fará o download do servidor, utilizando esta nova versão no lugar da que ele tem em cache, na próxima visita o ?1 não vai fazer mais nada, já que o navegador já tem a folha de estilo com o ?1 em cache. O parâmetro ?1 pode ser atualizado toda vez que for preciso fazer alguma alteração na folha de estilo, desta forma o cliente terá sempre a versão correta toda vez que ela for atualizada.

Outra saída é usar um parâmetro que nunca será o mesmo, por exemplo: usar a data completa (dia, mês, ano, hora, minuto e segundo). Só que isso fará com que o cliente faça o download do recurso no servidor toda vez que acessar o site, o que pode causar um grande tráfego no servidor, impactando diretamente na performance da sua aplicação. Num captcha faz sentido, mas em outros casos é bom pensar bastante antes.

É isso, dica simples e fácil (e talvez boba), mas que me salvou um dia desses.

O evento estava bem cheio, muita gente acordou sábado cedinho para não perder às apresentações do Bruno Pereira, sobre como se tornar um desenvolvedor web melhor e mais produtivo, do Régis Melo para aprender como desenvolver e entregar aplicativos para o mundo inteiro, e do Victor Oliveira para desmistificar algumas lendas sobre times ágeis de desenvolvimento.

De tarde tivemos a retaliação apresentação do Rafael Ponte e Tarso Bessa sobre os 10 maus hábitos dos desenvolvedores JSF, uma excelente explanação do Rodrigo Yoshima sobre a falta de conhecimento das pessoas que gostam de se dizer ágeis e uma verdadeira aula de TDD com o Paulo Silveira.

E a minha apresentação também foi na parte da tarde. Nesta apresentação falei sobre o Lucene e sobre o Solr e Hibernate Search, duas ferramentas baseadas no Lucene, porém com propósitos bastante distintos.

Além dos slides acima também foram apresentados três exemplos: com Lucene, com Solr e com Hibernate Search. Os exemplos são bem simples e a intenção é apenas mostrar o funcionamento básico das ferramentas. Todos os códigos estão disponíveis no meu github: aprendendo-lucene, aprendendo-solr e aprendendo-hibernatesearch.

E claro, como eu já estava em Fortaleza não poderia perder a oportunidade para passear e conhecer um pouco mais da cultura e pontos turísticos desta maravilhosa cidade.

Aproveitei bastante a praia do Futuro, caranguejos, peixe frito, muita cerveja gelada e até uma festa chamada Forró no Sítio, onde o pé de valsa Paulo Silveira mandou muito bem. Esta viagem foi 10, espero voltar em breve e por muitas e muitas vezes.

A Giran é uma empresa nova, jovem, descontraída e muito, muito comprometida com seus objetivos. Trabalhamos de forma ágil, usamos Scrum internamente e nos projetos dos clientes, além de várias práticas de Extreme Programming, inclusive TDD e programação em pares. Aversão à estas práticas não é um bom diferencial :)

Neste processo de seleção nós não estamos procurando especialistas e nem donos da verdade, aqui na Giran nós usamos de tudo um pouco. Cada profissional tem uma especialidade ou ‘sabor preferido’, nós também temos as nossas e sabemos valoriza-las, mas estamos interessados especialmente em profissionais multi-disciplinares, que sejam capazes de desenvolver, analisar, testar e arquitetar com diferentes linguagens e tecnologias, ou que ao menos estejam dispostos a trabalhar desta forma. Como trabalhamos com Internet, conhecimentos em Javascript, CSS, XHTML, mashups com APIs de terceiros, etc, serão um bom diferencial.

É importante que o candidato saiba que prezamos muito pela qualidade do que fazemos, nós estudamos os códigos um dos outros e nos respeitamos por isso, aprendemos muito assim. Nosso principal objetivo é a qualidade máxima, nós não viramos noite trabalhando e mesmo assim entregamos software no prazo, testado e funcionando muito bem, obrigado! Por isso estamos procurando pessoas com esse perfil: comprometidas, organizadas, que saibam trabalhar muito bem em equipe e que prezem pela qualidade do que fazem.

Por último, e talvez mais importante: todos nós somos nerds, geeks, apaixonados por tecnologia e super atualizados com as últimas novidades da Internet e do mercado. Nossa equipe é jovem, irreverente, descontraída e em constante evolução. São pessoas com esse perfil que estamos procurando.

A empresa oferece contratação com salário de mercado (não o do mercado capixaba), plano de benefícios e outros incentivos como cursos e treinamentos (especialmente aulas de inglês), um iMac ou Macbook (sim, gostamos da maçã por aqui) exclusivo para você, e claro vaga garantida nas partidas de xbox360. Estamos localizados em Jardim da Penha, Vitória-ES.

Se você acha que se enquadra, mande um email para mim (contato at giran.com.br) com seu currículo e os nomes dos 3 últimos livros técnicos que você leu. Diga se você sabe quem é o Taurin e qual sua ocupação, afinal de contas você está indo para Giran Castle Town.

Não pense que estamos procurando apenas profissionais experientes e de altíssimo nível: se você é estudante e tem pouca ou nenhuma experiência mas gosta de ler e aprender sobre coisas novas você não está fora! Escreva pra gente.

No meu macbook, que uso para trabalhar, eu controle tudo via a variável de ambiente $JAVA_HOME, é bem tranquilo. Quando quero compilar ou rodar alguma coisa com outro JDK/JVM é só mudar o $JAVA_HOME e pimba!

Quando eu usava Ubuntu sempre tive problemas para instalar mais de um JDK através do apt-get. A instalação era uma maravilha, como sempre no apt-get, mas por algum motivo o JDK e JVM padrões sempre ficavam com a versão mais alta. Eu tentava ‘corrigir’ usando a solução do $JAVA_HOME e incluindo o $JAVA_HOME/bin no $PATH, mas isso só funcionava enquanto eu estivesse no bash ou em aplicações que não fizessem referência direta ao /usr/bin/java.

Recentemente assumimos alguns servidores aqui na Giran e estamos migrando todos para Ubuntu Server. Não vou entrar no mérito dos porquês desta escolha para não criar uma guerra santa. Mas o que importa é que nestes servidores nós queríamos usar o apt-get para gerenciar todos os pacotes, afinal não temos paciência tempo para cuidar de tantos detalhes pequenos em tantos servidores.

Ao instalar um JDK, qualquer versão, através do apt-get, vários comandos estarão disponíveis no $PATH, dentre eles o java, javac, javap, jar, etc. Estes comandos estão sempre /usr/bin, mas são um link simbólico para os comandos em /etc/alternatives, que por sua vez são um link simbólico para o arquivo executável de verdade. Após instalar mais um JDK aí a coisa complica, qual deles será o padrão!? A cadeia de links simbólicos continua a mesma e mudar todos (mais de 15) manualmente não é muito indolor.

As instalações ficam sempre em /usr/lib/jvm/java-$versão, que é exatamente onde vão bater os links simbólicos de /etc/alternatives. No meu caso, por exemplo, tenho estas duas instalações: /usr/lib/jvm/java-6-sun e /usr/lib/jvm/java-1.5.0-sun. Se eu quiser alternar entre elas como padrão para todo o sistema, posso simplesmente usar o comando “update-alternatives” ao invés de sofrer reconfigurando um monte de link simbólico.

Então vamos lá:

spock@vulcan:~$ sudo update-alternatives --config java
There are 2 alternatives which provide `java'.
Selection    Alternative
-----------------------------------------------
+        1    /usr/lib/jvm/java-6-sun/jre/bin/java
*        2    /usr/lib/jvm/java-1.5.0-sun/jre/bin/java

Press enter to keep the default[*], or type selection number: 2
Using '/usr/lib/jvm/java-1.5.0-sun/jre/bin/java' to provide 'java'.

E pronto, simples assim. O item com o sinal de + (mais) é a opção default e o item com o sinal de * (asterisco) é a opção atual.