Um amigo meu me pediu umas dicas de estudo para se tornar um desenvolvedor web produtivo e com boa empregabilidade. O ideal para ele é ter como base a plataforma Java, mas sem ficar restrito a Java. Talvez isso possa ser útil para outras pessoas também, então colocarei as dicas a seguir.
Framework web Java
Considerando o critério empregabilidade, é fundamental conhecer razoavelmente Struts 1.x. Eu creio que poucos projetos hoje em dia sejam iniciados usando o Struts 1.x, mas a quantidade de aplicações em produção com esse framework é enorme, e durante um bom tempo essa realidade ainda se manterá.
Depois do Struts 1.x, nenhum outro framework web Java conseguiu adoção semelhante, então é difícil recomendar uma opção mais moderna que garanta alguma coisa. É provável que a melhor opção “moderna” em termos de empregabilidade seja Java Server Faces, mas não me sinto bem em recomendar que ninguém estude JSF. Se alguém quer seguir na linha do JSF, eu recomendaria o JBoss Seam, do qual ouvi boas avaliações, mas nunca usei.
Dos frameworks web Java mais recentes, o meu preferido é o Spring MVC 2.5.x. O importante da versão 2.5 em diante é que os controllers suportam anotações para configuração, em vez dos XMLs monstros que eram a opção anterior. A maioria dos frameworks web está seguindo numa abordagem RESTful de arquitetura, o que me agrada também. O Spring MVC é um dos que está fazendo isso, e com uma abordagem legal.
Além disso, todos os componentes do Spring acabam te “seduzindo” a usar outros componentes dele, pela conveniência e pela qualidade dos mesmos. Então se você usar o Spring MVC, é muito provável que use a injeção de dependências, o controle transacional, talvez o web flow, entre outras coisas.
Frameworks web da “nova geração”
Qualquer desenvolvedor web hoje em dia TEM OBRIGAÇÃO de olhar pelo menos um entre Django, Grails e Ruby on Rails. O ideal mesmo é avaliar os três e ter um deles como opção principal. Eu já conheço legal o Grails e estou evoluindo rápido com o Django. Em algum momento esse ano eu dedicarei um bom tempo avaliando e fazendo algo relevante com Ruby on Rails também.
Pode parecer que leva um tempo enorme para conhecer os 3, mas isso não é verdade. Os 3 são extremamente produtivos e têm muitas características semelhantes. Quando você começa a utilizar um deles já tendo experiência com outro, a curva de aprendizado fica muito rápida.
Um aspecto muito legal do aprendizado desses frameworks da “nova geração” é que você tem contato com outras formas de fazer software (para quem tem um background Java), outras comunidades, e várias idéias interessantes que te farão um programador melhor em qualquer linguagem ou plataforma. Se você ainda não conhece nenhum dos 3, não perca mais tempo e escolha um para começar. E de preferência conheça os outros em seguida também 
HTML, CSS, Web Standards
Estamos em 2009. Embora ainda vejamos muitos sites bisonhos que só funcionam com o IE, se você é um desenvolvedor que se preza você precisa conhecer bem HTML, CSS e os web standards. Na verdade, fazer o site funcionar no IE 6 por exemplo é secundário. Você precisa aprender primeiro a gerar HTML e CSS válido de acordo com as normas da W3C, que garantem padrões de qualidade e interoperabilidade entre browsers. Leia de cabo a rabo todos os tutoriais referentes a essas coisas no W3Schools. É muito rápido estudar por lá, e é uma ótima referência depois.
Depois que você conhecer isso, um pouco de prática na escola norueguesa de software fará suas aplicações rodarem no IE 6 também
Javascript
Ainda há pessoas que escrevem javascript na unha, mas acho que elas são cada vez mais raras. Temos hoje uma oferta enorme de bibliotecas javascript para resolver todos os problemas comuns dos desenvolvedores web. Eu era um fiasco em javascript antes de conhecer o jQuery, mas há um bom tempo eu gosto MUITO de javascript, e minha produtividade no client-side melhorou absurdamente.
O jQuery tem uma abordagem que eu acho excepcional. Temos 3 aspectos claramente distintos para tratar em uma página web: Estrutura (HTML), Estilo/Visual (CSS) e Comportamento (Javascript). Se você fizer tudo direitinho e usar o jQuery, essas 3 coisas ficam totalmente desamarradas.
Você não precisará colocar nenhuma declaração de estilo na estrutura (leia-se: sem CSS inline). A definição do comportamento fica totalmente por fora da estrutura. A beleza do jQuery está em aplicar todo o comportamento da página de uma maneira não-intrusiva, e com uma abordagem muito limpa. Ah, e o javascript funcionará em todos os browsers sem você ter que tratar disso explicitamente. Um sonho, não é mesmo?
Há várias outras opções, e não estou defendendo a idéia de que se use apenas uma. Eu uso o jQuery para tudo que posso, e até hoje não precisei de outra biblioteca, mas vá em frente e experimente algumas opções até encontrar o que lhe atender melhor.
Plugins legais do Firefox
Firebug
Além do jQuery, outra descoberta que mudou minha opinião e gosto por client-side foi o Firebug. Ele ajuda MUUUUUITO na criação do HTML/CSS das páginas, pois você consegue inspecionar de forma fácil o conteúdo e o estilo, e aplicar mudanças imediatas sobre o que está vendo. Depois de acertar as coisas pelo Firebug, você simplesmente aplica as mudanças no HTML/CSS originais e continua implementando sua página. Além disso, ele te permite debugar javascript e analisar as requisições HTTP detalhadamente. Eu já o utilizo há pouco mais de 1 ano, e ele contribuiu muito para meu amadurecimento no client-side, e me dá muito mais produtividade.
Web Developer
Um companheiro freqüente do Firebug é o Web Developer. Ele te permite inspecionar detalhadamente uma porção de coisas na sua página, como informações de todas as imagens, todos os formulários, estilos, entre outras coisas. Além disso, permite a manipulação de cookies, valida HTML/CSS/Javascript, e tem muitas outras funcionalidades úteis. É indispensável para trabalhar com web, assim como o Firebug.
Screengrab
É muito comum termos que mostrar uma página para outras pessoas, e nem sempre elas têm acesso à nossa máquina. Para facilitar isso, podemos usar o Screengrab, que é semelhante a um Print Screen, mas salva o conteúdo completo da página como uma imagem. Isso é bem melhor do que o Print Screen, pois pega apenas a área útil da página (sem pegar barras do Firefox e barra de tarefas) e pega toda a área útil. As regiões da página que precisam ser “roladas” para visualização também são incluídas na imagem, o que é certamente o desejado.
NoScript
O NoScript é um plugin bem incômodo para uso em geral. Ele bloqueia a maioria dos javascripts e você precisa ficar liberando a execução de scripts toda hora. Quando não estou desenvolvendo eu sempre deixo ele desligado.
Entretanto, para desenvolver ele ajuda em algumas situações. Por exemplo, você pode precisar desabilitar alguns scripts específicos da sua página para testar alguma coisa, ou testar se a página funciona sem scripts. Ou então você pode ter uma situação como uma recente minha.
Eu tive que customizar um plugin do jQuery que faz algumas animações, e aí o HTML da página ficava mudando o tempo todo. Eu precisava customizar o HTML/CSS de vários “instantes” da animação, mas era impossível fazer isso com a animação rodando. Para resolver isso, eu usei o NoScript para interromper os scripts exatamente no trecho da animação que eu precisava mudar o HTML/CSS. Com isso, eu conseguia um HTML estático que eu podia mexer pelo Firebug, e consegui trabalhar tranqüilamente nas customizações que eu precisava fazer.
Conclusão
Deixei algumas opiniões e dicas sobre algumas coisas de desenvolvimento web, mas é óbvio que eu também tenho muita coisa a aprender. Se alguém discordar de alguma opinião minha ou quiser acrescentar sugestões, estejam convidados a participar Além disso, se alguém tiver mais dicas de extensões do Firefox para desenvolvimento web, eu sempre estou interessado.
Dicas muito boas, vou dar uma olhada nesse jQuery fiquei curioso.
Olá Bruno,
Vlw pelas dicas, vou indicar esse post pra uma galerinha novata tbm.
Abraço
Oi Marcelo, você não vai se arrepender. O jQuery é uma das melhores bibliotecas/APIs que eu já vi em qualquer linguagem/plataforma. Muito simples de entender seu funcionamento e começar a usá-lo de forma produtiva.
Além disso, tem uma comunidade ótima em torno dele, gerando diversos plugins excelentes, muito úteis.
Fala Bruno!
Realmente suas dicas são bem valiosas!
O jQuery realmente é sensacional né! Imagina ter que desenvolver aqueles efeitos visuais (slideDown/Up, FadeOut/In, etc…) na unha! E mais…. garantir que funcionem em todos os browsers!
Agora estamos desenvolvendo a nova central de relacionamento da Globo.com e estamos utilizando todos os novos padrões de web2.0, dando uma enorme importância ao conteúdo gerado.
Agora vejo como é importante desenvolver um HTML sem erros, padronizado e hierarquizado.
Saber como os elementos (span, p, div, table, etc…) devem ser utilizados é de extrema importância!
Falando nos plugins do FF…
Depois dá uma olhada no plugin “View Source Chart” (https://addons.mozilla.org/pt-BR/firefox/addon/655).
Sabe quando precisamos dar uma olhada no HTML e nos deparamos com um código todo zoneado e desalinhado? Não conseguimos saber visualmente onde começa e termina uma DIV por exemplo!
Então, ele além de formatar todo o código pra você, ele te dá a opção de comprimir/expandir os blocos de código para que vc deixe apenas uma parte para ser analisada.
Outra feature importante é que ele exibe o HTML gerado por algum javascript (document.write ou innerHTML por exemplo), ficando muito mais fácil decifrar o que de fato algum script está gerando de conteúdo!
Fica a dica!
Show de bola essas dicas!
Ainda não conheço o JQuery, vou dar um estudada, tenho ouvido falar muito sobre ele.
Dicas show!
Já avaliei bem o GRails e o Django e fiquei bastante satisfeito com os dois. Django pela simplicidade e enorme produtividade. GRails também pela produtividade e principalmente pela familiaridade.
Agora é hora do RoR.
@Nelson, realmente o jQuery não tem preço
Daqui a pouco vou postar uma parada bacana que fiz com ele.
Vou dar uma olhada no View Source Chart, eu não conhecia ele ainda. Valeu pela dica. []s
@Loiane, não perca mais tempo e se “apodere” do jQuery
É excepcional. Daqui a pouquinho vou publicar um componente que fiz com ele no meu projeto atual.
@Igo
Bom ver você por aqui. Eu estou num estágio semelhante ao seu. Grails e Django já tô bem familiarizado e consigo utilizar bem em projetos “valendo”. O RoR ainda não consegui dedicar o tempo de estudo, mas farei isso em algum momento esse ano.
[]s
Parabéns pelo post maxo!
Gostei tanto que até bloguei sobre ele!
Faaaaale maxo! Show de bola, obrigado pelos comentários
Legal, boas dicas. Algum motivo específico para você não recomendar JSF?
Para quem trabalha com web services, uma extensão do Firefox que acho útil é o Poster (https://addons.mozilla.org/en-US/firefox/addon/2691).
Para validação de HTML, há a extensão HTML Validator (http://users.skynet.be/mgueury/mozilla/), e o site do W3C tem validadores para HTML (http://validator.w3.org/) e CSS (http://jigsaw.w3.org/css-validator/).
Oi Guilherme, tudo bem? Eu já conhecia o Poster, ele é bem legal mesmo. Eu fiquei um pouco em dúvida se ele se encaixava nesse tópico, aí acabei deixando de fora. Mas acho que ele se encaixa sim, depois vou atualizar aqui.
Sobre os validadores de HTML, o Web Developer tem também
Sobre JSF, eu tenho alguns problemas. O que ele tenta fazer – in a nutshell – é prover o mesmo estilo de desenvolvimento que as antigas IDEs Delphi/VB, mas aplicado para web. Pros fissurados por Drag and Drop, talvez isso faça sentido, mas eu acho que ele atrapalha bem mais que ajuda.
Eu não gosto da maneira como JSF “se mete” no desenvolvimento client-side. O framework atrapalha muito na interação dos desenvolvedores com os designers. Tem muito código sujo no client-side de JSF. Tanto em relação ao CSS como JS. Aqueles componentes bonitinhos podem parecer muito atraentes, mas eles complicam muito na personalização do estilo e comportamento da página.
Além disso, tem uma questão de preferência pessoal nisso. O JSF te provê uma abstração que “tenta não ser web”. Ele tem um modelo de tratamento de eventos e de request/response que quer dar uma forma de trabalho tipo Delphi, abstraindo o modelo “request/response” tradicional. Eu não gosto dessa forma de trabalho, eu prefiro uma abordagem mais RESTFul, vendo claramente as URIs, tratando os Requests e Responses HTTP como eles realmente são.
Há pessoas que se adaptam melhor à forma de trabalho do JSF, então quem preferir, use-o à vontade, não vou condenar. Mas eu definitivamente não gosto, e há muito mais opções do jeito que eu gosto do que o contrário, felizmente
Excelente post Bruno!
Todas as tuas dicas são realmentes válidas, sem dúvida.
Seu post serve de referência para muitos desenvolvedores, principalmente quem está iniciando no mundo web.
Parabéns!
Bruno, os validadores do Web Developer redirecionam para os do W3C. O plugin HTML Validator tem a vantagem de ser executado localmente, o que é muito útil durante o desenvolvimento local, pois, nesta situação, não é possível utilizar o do W3C (somente através de upload da página).
Obrigado pelos esclarecimentos sobre JSF. Concordo com tudo o que você escreveu!
Discordo da sua afirmação sobre Struts. Acredito que estudar Struts seria desperdício de tempo, no caso de se estar à procura de um emprego que exija isso. Existem muitas vagas para JSF, então este deveria ser o framework a se estudar.
No caso de estudar frameworks extras, recomendo fortemente Apache Wicket, além dos que você recomendou. Ou seja, troque o Struts pelo Wicket. Se quer ir na onda do mercado, estude JSF e o que mais estiver disponível, exceto opções descontinuadas (Struts).
[]’s
Bruno
Oi Bruno, sobre o Struts, minha opinião é como falei. Não é uma opção a ser considerada para projetos novos, mas se você considerar o critério empregabilidade, ainda é importante.
Pense em quantas empresas ainda tem aplicações em Struts. Esse legado ainda deve permanecer por um bom tempo. Um profissional que precise se realocar HOJE pode perder algumas vagas por não conhecer Struts. Esse ponto que eu quis destacar.
Sobre o Wicket, eu considero bem mais interessante do que JSF, mas não me adaptei à abordagem de trabalho dele. É um framework muito bem pensado, e você consegue trabalhar em projetos web com um bom modelo OO, com componentes consistentes, etc.
Entretanto, simplesmente não é a abordagem que funciona melhor para mim. Eu prefiro trabalhar com uma abordagem RESTFul, no estilo do Spring MVC. Isso é gosto pessoal meu, portanto quem quiser avaliar e usar o Wicket, go ahead and be happy. Na pior das hipóteses será um aprendizado válido que trará novas idéias.
[]s