Posts da tag Desenvolvimento

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.

Não peça feedback, obtenha-o

Todo grande líder sabe que o feedback sincero daqueles que estão à sua volta é uma das principais ferramentas para melhoria e evolução de seu trabalho e de seu papel como líder. Receber e saber processar as críticas é fundamental para aprender e melhorar como líder, quando o feedback é um elogio é ainda melhor, nada mais gostoso do que ter a certeza que você está no caminho certo.

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.

Evitando o cache no cliente

HTML e CSS nunca foram meu forte, eu sei o que preciso saber para sobreviver, já que trabalho com desenvolvimento web. Não da pra esperar que eu consiga montar uma apresentação fantástica usando HTML5 e CSS3 e ainda por cima pensando fortemente em semântica, organização e melhores práticas, fato!

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:

1
<link rel="stylesheet" type="text/css" href="/css/estilo.css" />

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:

1
<link rel="stylesheet" type="text/css" href="/css/estilo.css?1" />

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.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes