Jeveaux's Weblog
Tudo certo e nada resolvido
Tudo certo e nada resolvido
29 jun
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.
O passo essencial é trocar a visualização de Projetos para Working Sets, isso é bem simples. Veja a imagem a seguir:
No próximo passo você deverá criar as suas working sets e associar cada uma delas com os projetos que quiser.
Crie, modifique ou remova qualquer working set.
Trabalho feito, agora basta escolher em qual working set quer trabalhar e pronto, paz e sossego.
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.
11 jun
Recentemente participei de algumas discussões nas listas que participo que abordaram ambiente de desenvolvimento e, consequentemente, editores e IDEs. A escolha do editor ou da IDE é algo completamente particular e extremamente pessoal, e depois que alguém adota alguma ferramenta, não adianta alfinetar ou empalar com uma lança, as opiniões dificilmente mudarão, não importa quais ou quantos argumentos forem usados. Até mesmo por isso não quero falar sobre melhor ou pior aqui.
Numa dessas discussões, inevitavelmente começaram a falar sobre o VIM e num determinado momento alguém exclamou que o VIM era tão ruim que nem Syntax Highlighting fazia. Mas oras, é claro que faz. Uma dica rápida.
Durante a edição de um arquivo, você pode ativar ou desativar a Syntax Highlighting quando quiser. Para ativar:
:syntax on
E para desativar:
:syntax off
Se você quiser, pode deixar que o VIM faça isso automaticamente sempre que possível. Pra isso edite o arquivo vimrc e adicione o trecho abaixo. No Linux esse arquivo geralmente fica em /etc/vim/vimrc, enquanto no Mac OS X você o encontrará em /usr/share/vim/vimrc.
if has("syntax")
syntax on
endif
E é isso. Feche e abra o próprio arquivo vimrc e veja as diferenças. No meu caso ele ficou assim:
Os arquivos de syntax ficam no diretório syntax dentro do diretório de instalação do vim, pro caso de você querer mudar alguma coisa.
8 mai
Eu demorei, mas aprendi que criticar diretamente não é a melhor forma para se cativar as pessoas, ainda estou tentando praticar de forma mais eficaz, é difícil, muito difícil, mas funciona. Contudo, existem situações onde a crítica é inevitável, infelizmente existem e nós precisamos estar sempre preparados para elas – tanto para criticar quanto para receber uma crítica. Mas fazer uma crítica sem motivo ou razão e, principalmente, sem um conhecimento sólido que dê credibilidade à esta crítica é, no melhor dos casos, desprezível.
O pior é que ultimamente com tanta mídia gratuita por aí eu tenho notado muita gente se empolgando e embarcando na onda de “crítico matador”, e simplesmente querendo fazer o papel do grande sábio e conhecedor de todos os assuntos, criticando a tudo e a todos sem o menor pudor – e na maioria das vezes, sem a menor autoridade para tal.
Alguns pensam que girando a metralhadora e disparando críticas para todos os lados serão mais respeitados, ou sair logo criticando com todas as forças algo novo e recém lançado é um grande negócio para auto-promoção e até mesmo que a crítica é a melhor forma de “falar que sabe tudo do assunto”.
Mas assim como a síndrome do seniorismo, onde muita gente se tornou consultor senior de negócios após 1 ano de estágio, a síndrome do criticismo está se alastrando rapidamente. Hoje em dia todo mundo acha bonito criticar, todo mundo acha bonito fala mal, chamar o código alheio de porcaria (adoraram fazer isso com o twitter, recentemente) e por aí vai. E o pior, o que está alimentando essa nova síndrome é o comportamento da maioria que tem respeitado e tem até sentido uma pontinha de medo de quem adora criticar tanto.
É muito fácil criticar, aliás, qualquer idiota pode criticar, condenar e queixar-se – e a maioria dos idiotas faz isso. Por vezes é muito mais simples e não requer esforço e nem conhecimento, basta disparar qualquer asneira e pronto. HEI! Pessoal, acordem!
Já do outro lado nem é preciso ser conhecedor do assunto criticado para entender a crítica, afinal, célebres frases como: “- Odeio o framework X”, “- A API de fulano é horrível, deplorável” e “- O serviço do João é cheio de bugs”, são muito fáceis de serem compreendidas e são ótimas para causar uma má interpretação do assunto. Mas eu me pergunto, por que a pessoa odeia o tal framework, será por algum motivo que justifique a crítica ou seria apenas porque antes da síndrome do criticismo esta pessoa já passou pela síndrome do seniorismo e agora além de não saber a ferramenta ainda a crítica. Ou por que a API do fulano de tal é tão ruim, não seria por que a API é REST e o crítico só sabe fazer integrações usando stored procedures? Ou quais seriam os tais bugs no serviço do João, será que existem de fato?
Eu não quero que este post seja visto como uma crítica aos críticos, não é. De certa forma estou usando este espaço e escrevendo sobre isso exatamente aqui no meu blog pois tenho visto que muitos amigos e pessoas próximas que mantenho contato estão sofrendo de tal síndrome do criticismo. E isso é muito mais do que simplesmente chato, é frustrante.
A intenção é dar uma dica: estudem; estudem, ESTUDEM SEMPRE! Saibam ser humildes, tenham respeito pelo próximo e aprendam a admirar o trabalhos dos outros. Você será verdadeiramente respeitado e admirado ao dizer “- Parabéns pela sua implementação, sua idéia para resolver aquele problema foi ótima” do que criticando sem conhecer por pura falta de vontade e empenho em aprender, criticar de forma irresponsável somente vai trazer respeito e admiração de outros irresponsáveis e alienados.
Um exemplo simples e clássico
Eu estudei por muitos anos (há muito tempo atrás) seguidos e tive cerca de 4 anos de experiência profissional com Struts 1.x e até hoje penso duas vezes antes de formular uma crítica a este velho conhecido e tão calejado framework. Tenho consciência que não sei sobre todos os detalhes do Struts e que posso ter compreendido ou até utilizado de forma errada um ou outro recurso, por isso sempre penso se sou a pessoa mais adequada para aquilo, principalmente quando estou inserido num cenário que sei que a minha opinião, por exemplo, poderá repercutir ou influenciar a opinião de outras pessoas. É preciso ter humildade para reconhecer que não se sabe tudo e responsabilidade para criticar.
Mas mesmo assim eu escuto/leio muita coisa ruim do Struts que vem de pessoas que estão começando a aprender JSF sem nunca ter tido qualquer experiência com outra ferramenta/framework antes, que credibilidade dar a pessoas assim? Que credibilidade dar a uma pessoa que desdenha do código alheio sem nunca te-lo visto?
Responsabilidade, humildade e maturidade devem estar sempre juntas para te ajudar a manter-se em seu lugar e saber quando e como expor a sua opinião.
7 abr
Há alguns dias fui convidado a participar de um seminário na FAESA com uma apresentação sobre Extreme Programming – XP. A apresentação foi realizada ontem, tudo correu muito bem e agora estou disponibilizando a apresentação no meu slideshare.
28 mar
Segurança sempre soa como uma falácia na maioria dos projetos de software. É como aquele pessoal que não gosta ou não sabe testar: eles sabem que a coisa existe e que é preciso ou muito recomendável a usar, mas no fim das contas dão de ombros e se funcionar funcionou.
Isso acontece muito quando o âmbito é segurança. Qual cliente ou usuário não se preocupa com segurança? Ao menos um controle de acesso com autenticação através de usuário e senha eles sempre exigem. E qualquer desenvolvedor que se preze se preocupa com isso.
Quando pensamos em segurança em aplicações Java temos que conhecer bem como funciona a arquitetura de segurança da plataforma Java, que é bem completa a útil. A divisão se dá em três “áreas” distintas, que são: JCA - Java Cryptography Architecture – Define classes e interfaces que são responsáveis por trabalhar com criptografia e descriptografia de dados e informações; JSSE - Java Secure Socket Extension – Usa a JCA para criar conexões seguras para troca de dados e informações; e JAAS - Java Authentication and Authorization Service – Responsável por autenticação e autorização nas aplicações Java. Neste post vou abordar somente um pouco do JSSE, para saber mais sobre JAAS veja no arquivo do blog.
O SSL (Secure Socket Layer) e o TLS (Transport Layer Security) são protocolos criptográficos usados para garantir a comunicação segura entre serviços de internet. Não vou entrar em detalhes sobre os protocolos e nem nas suas diferenças, para maiores informações sugiro esta leitura.
A necessidade fundamental de uma implementação com SSL é garantir a privacidade e integridade dos dados trafegados entre as aplicações que estão se comunicando. E isso é realizado através da autenticação das aplicações e da utilização de algoritmo criptográfico nos dados que estão sendo trafegados.
Dizer isso é meio bonitinho mas ninguém consegue compreender como isso ocorre de verdade, o que acontece por “por baixo dos panos”. Vamos imaginar um cliente utilizando um browser qualquer para acessar uma aplicação instalada num servidor JBoss, com certificado SSL implantado. Quando a comunicação entre eles é iniciada o servidor envia uma chave pública ao browser, que usa esta chave para criar uma chave privada temporária que é enviada de volta ao servidor. Desta forma as duas partes, servidor e browser, usarão estas chaves para estabelecer uma comunicação segura. Para saber mais sobre chaves públicas, privadas, criptografia simétrica e assimétrica veja a minha apresentação sobre certificação digital.
Vamos então por a mão na massa e configurar a aplicação.
Últimos Comentários