vuejs

Exprimentando Vue.js – aplicando no /dev/All

Recentemente comecei a buscar frameworks JavaScript para serem aplicados em nossos projetos na itexto. Publiquei algum tempo atrás minha experiência de aprendizado envolvendo o Angular.js: chegou a hora de falar sobre o Vue.js.

Como fui parar no Angular.js

 

angular-js_600x400

Aprender Angular foi uma experiência muito enriquecedora para mim pois me pos em contato mais profundo com diversas ferramentas usadas no ambiente JavaScript, tais como o Gulp e o NPM.

O que mais gosto no Angular é a ideia de templates renderizados do lado cliente. Apesar de na esmagadora maioria dos nossos projetos boa parte da renderização ser realizada do lado servidor (diversas razões para isto, o que, por si só, já daria um post), em alguns casos a renderização do lado cliente nos parece a solução ideal.

Um dos nossos projetos em que os templates do Angular cairam como uma luva foi o /dev/All que, até a versão 1.8 usava este framework do lado cliente.  Não conhece o site? Abaixo você pode ver um print do mesmo:

devall_vue

Com o passar do tempo a arquitetura do /dev/All foi sofrendo algumas modificações, dentre elas a criação de uma API na qual estamos trabalhando aos poucos. Entre as chamadas desta API está a nossa busca, que é usada atualmente na interface do site com o usuário final.

A primeira versão do /dev/All era 100% renderizada do lado servidor. Com isto, sempre que o usuário paginava os posts ou realizava uma busca, todo o conteúdo da página era carregado novamente (ignorando os cacheamentos de JavaScript e CSS).

Este problema foi a razão pela qual na versão 1.8 do /dev/All passamos a usar o Angular na confecção da nossa interface gráfica. O resultado foi muito bom: os usuários agora baixavam uma única vez o código da página e em todas as chamadas subsequentes o Angular fazia o trabalho de atualização da interface.

Como encontrei o Vue.js

vuejs

Tivemos esta experiência bem sucedida com o Angular mas fiquei com a impressão de que ele era uma solução muito complicada para as nossas necessidades. A curva de aprendizado do Angular é muito íngreme: são muitos conceitos para que você comece a se tornar produtivo: controladores, módulos, injeção de dependências, inversão de controle, diretrizes. Minha única preocupação era a view: eu só queria um template que fosse renderizado do lado cliente e que tirasse proveito da nossa API.

Eu também queria algo com o qual pudesse reaproveitar conhecimentos que já dominava, como o jQuery: misturar Angular e jQuery é complicado para dizer o mínimo (sei que é possível, mas mesmo assim é mais complexo que o necessário).

Nisto passei por algumas soluções interessantes: Mustache, Rivets, Tangular (apenas 2Kb!) e mais algumas alternativas, dentre as quais estava o Vue.js, cujo primeiro contato foi feito totalmente por acaso através de um vídeo do Vedovelli.

Resolvi experimentar o Vue.js: o primeiro passo foi ler o seu guia para desenvolvedoresA leitura do guia me fez esquecer o Angular. Achei a documentação do Vue.js uma das melhores que já li: rápida, direta e curta. Terminada sua leitura você já consegue criar coisas interessantes com o framework.

(o guia do Vue.js devia ser usado como exemplo de documentação bem feita: virei fã)

A impressão que tive do Vue.js foi a de se tratar de um “Angular” fácil de aprender. Em aproximadamente três horas de estudo você já consegue criar aplicações com o Vue.js: no caso do Angular levou pelo menos uma semana para começar.  Vi esta experiência de aprendizado se repetir com Lucas, nosso estagiário na itexto.

A versão 1.9 do /dev/All, publicada no dia 19/6/2016 substituiu o Angular pelo Vue.js (usamos a versão 1.0). Quantas linhas de código JavaScript precisamos escrever para criar toda a interface do site? 30 (!), incluindo o boiler plate padrão do jQuery ($(document).ready).

O jQuery faz as chamadas ao servidor e o Vue.js renderiza o resultado para nós. É simples assim. :)

Outras coisas que gostei no Vue.js

Além da excelente documentação e facilidade de ser usado com outras bibliotecas (jQuery), houve outras razões pelas quais este framework me ganhou.

API fácil

A API do Vue.js é muito simples: essencialmente você só precisa conhecer o construtor Vue. E não só o guia é fácil de ler: a documentação da API também é excelente!

Levou um tempo até que eu me habituasse com o modo como a injeção de dependências é realizada no Angular (especialmente os problemas que podem surgir durante a minificação e “uglyficação” do código). No caso do Vue, como é focado apenas na view e não há controladores, tudo fica muito mais fácil.

Tem o que gostei no Angular

A sintaxe dos templates do Vue é muito parecida com a do Angular. Tanto é que não precisei reescrevê-los ao migrar para o Vue.js: a grosso modo bastou trocar as diretrizes “ng-*” por “v-*”.  A mesma sintaxe “mustache” se mantém.

Também há diretrizes, como o Angular, assim como filtros. A diferença está na facilidade de aprendizado.

Outra similaridade importante: também implementa o data binding bidirecional. Este recurso é muito interessante, especialmente quando se quer construir interfaces de cadastro mais complexas como, por exemplo, formulários do tipo mestre-detalhe ou mesmo simulação de planilhas (para estes dois casos já estamos projetando soluções baseadas no Vue.js na itexto).

Por falar em data binding, o modo como lida com formulários é também essencialmente o mesmo que temos no Angular.

Criação fácil de componentes

Assim como o Angular, o Vue.js também te permite criar componentes. No caso, o Vue é muito inspirado na spec Web Components do W3C. Note que é inspirado e não uma implementação desta spec.

A vantagem é que você pode escrever sua biblioteca de componentes reaproveitáveis com o Vue e, caso deseje abandoná-lo no futuro, o trabalho de reescrita (em teoria) deve ser bem menor.

Concluindo

Para situações nas quais só me interessa a renderização do lado cliente e a aplicação não é muito complexa (como o /dev/All), creio que Vue.js seja uma solução mais interessante que o Angular.

Se você ainda não o conhece, sugiro que leia seu guia e brinque um pouco com ele: é uma experiência muito interessante.  Na excelente documentação oficial há uma seção interessante na qual o comparam com outros frameworks, recomendo sua leitura, apesar de naturalmente se tratar de um texto tendencioso.

Creio que, apesar de ter preferindo o Vue, estudar Angular é essencial: tenho certeza de que boa parte da facilidade que tivemos em aprendê-lo (Vue) se deve aos conceitos que precisamos aprender em nosso estudo do Angular.

Se você gosta de vídeos, o Fabio Vedovelli tem uma série a respeito que vale muito à pena assistir (como tudo o que ele faz).

comentario_agradavel

Quando o comentário realmente documenta o código

Como alguém que lida com muito código fonte que não é de minha autoria, neste post vou listar algumas dicas para tornar seus comentários no código realmente úteis. São hábitos simples que, se bem seguidos, tornam a vida de quem manterá aquele sistema mais fácil e, portanto, aumentam a produtividade de toda a equipe.

Naturalmente, não irei incluir aqui todas as dicas possíveis, razão pela qual no final deste post irei citar algumas boas dicas de leitura sobre este assunto.

Não vou falar do óbvio: “o comentário deve dizer o que aquele método ou classe faz” ou “comentar o óbvio é bobagem” ou “comente apenas o necessário” pois, convenhamos, é chover no molhado ou mero “preenchimento de linguiça”.

Tudo é história

Todo software é gerado dentro de um contexto: a situação da equipe no momento em que foi criado, quem o escreveu, assim como seus conhecimentos naquela época, quais as tecnologias estavam em voga, etc.

Conhecer este contexto é muito importante para compreender as razões pelas quais o código se encontra em sua situação atual. Infelizmente, na esmagadora maioria das vezes em que encontramos o código pela primeira vez só temos conhecimento do seu estado atual se ignorarmos seu histórico no sistema de controle de versões (seja sincero, quantas vezes já percorreu aquele histórico ao ter seu primeiro contato com uma base de código pré-existente?).

Lidando com o passado – reconstruindo o histórico perdido

 

Comentários podem ajudar e muito aqui. Neste momento entra a primeira dica: use um sistema de controle de issues e replique informações deste sistema nos seus comentários. Como fazer isto? Basta mencionar o número da issue em seu comentário. Seguem alguns exemplos:


/*
Classe responsável pelo envio de e-mails no sistema /* (isto é óbvio) */
Issue na qual se encontra documentado o requisito que deu origem ao
requisito: http://meusistemadeissues/issue/825
*/
class EmissorEmail {

É bastante simples: com isto seus comentários não ficam imensos e quem estiver dando manutenção no sistema poderá entender melhor o contexto no qual aquele código foi criado. Um excelente local para se incluir este tipo de comentários é em código no qual você esteja corrigindo um bug, tal como no exemplo abaixo:

int diasEntreDatas(Date dataInicial, Date dataFinal) {
/*
Havia um erro no código abaixo que não considerava sábados e domingos,
gerando resultados inválidos.
Issue: http://seusistemadeversoes/issue/847
Alterado por Henrique Lobo - 1/3/2016 - 14:20
*/
}

Entra a segunda dica: assine seus comentários. Com isto, caso alguém encontre problemas no código que você alterou, poderá lhe procurar para obter maiores informações a respeito daquela situação que, talvez, não se encontrem documentadas no seu sistema de issues ou qualquer outra fonte de documentação.

Mais do que assinar os comentários, creio que também seja muito importante incluir a data e hora no mesmo. Isto contribuí para entender o contexto histórico daquela alteração e muitas vezes agiliza ao extremo a compreensão do problema e aplicação da solução. Esta portanto é minha terceira dica: date seus comentários.

Três dicas simples relacionadas ao histórico que, se aplicadas em conjunto, facilitarão demais a vida de todos:

  • Use um sistema de issues e o referencie em seus comentários
  • Assine seus comentários para que as pessoas possam lhe procurar (quem não tem culpa no cartório não se esconde)
  • Sempre inclua uma data nos seus comentários para saber quando a alteração foi realizada

Lidando com o passado recente

Há também aquelas situações nas quais você fez uma alteração no código mas não se sente 100% seguro a seu respeito, mesmo que tenha escrito testes para validar o comportamento esperado. É normal e te entendo perfeitamente. Nestes casos, não há problema algum em deixar comentada a versão anterior do código apenas para comparação com o que você fez, tal como no exemplo a seguir:


int soma(int x, int y) {
return x + y;
/*
Acho a versão anterior pura frescura, por isto substituí pela
minha alterantiva melhor otimizada e que não usa ifs!
Issue: http://www.meusistemadeissues.com/issue/13
Henrique Lobo - 2/2/2012 - 13:13
return (x > Integer.MAX_VALUE || y > Integer.MAX_VALUE) ? -1 : x + y;
*/
}

Lidando com o futuro (usando lembretes)

Muitas vezes a pressão do dia a dia faz com que precisemos incluir débitos técnicos em nossos sistemas. É normal: no futuro você vai resolver estas questões (se se lembrar delas).

A maior parte das IDEs hoje, além de sistemas de análise estática de código como o SonarQube oferecem suporte a um tipo especial de comentário: o “TODO”. Nunca o viu? É simples: vamos a um exemplo rápido e completamente fora da realidade.


boolean autenticar(String login, String senha) {

/*
TODO: meu gerente me obrigou a isto para o release 1.0.0 do sistema
Henrique Lobo - 12/3/2004 12:00
Issue: http://www.meusistemadeissues.com.br/issues/666
*/
if (login == "dede") {
return true;
}
}

Comentários do tipo TODO mostram pontos a serem melhorados no sistema. Na imagem abaixo podemos ver um exemplo do uso deste tipo de comentário no Eclipse (práticamente todas as IDEs possuem este recurso atualmente):

todo_eclipse

Mesmo que você não se lembre de ter feito o que estava no comentário, alguém do futuro saberá a respeito e poderá fazer algo a respeito.

Refatorando comentários?

Se você usa um sistema de controle de issues e assina e data seus comentários, passado algum tempo você talvez precise refatorá-los. Como assim?

De duas maneiras: você pode excluir aqueles comentários que envolvam código antigo (pois o tempo já mostrou que as alterações realizadas funcionaram) ou você pode simplesmente remover aqueles comentários que não agregam coisa alguma.

Resumindo: de tempos em tempos é uma boa prática apagar os comentários inúteis. Lembre que você tem o sistema de controle de versões e nele já está presente todo o histórico de alterações.

Não divulgue segredos

Parece estranho o que vou dizer, mas seu comentário pode expor segredos relativos à sua empresa ou contratante. Apesar de ter mencionado no início deste post que não iria mencionar o óbvio, me assusta a quantidade de informações sigilosas que programadores publicam em seus comentários. Alguns exemplos:

  • Credenciais de acesso a serviços ou servidores
  • “Recados” a outros membros da equipe – “Kico, resolva isto depois, ok?”
  • Críticas ao empregador ou outros membros da equipe
  • Críticas à natureza do próprio código fonte (isto você documenta como débito técnico no sistema de issues normalmente)

Quer um bom exemplo histórico? Algum tempo atrás vazou o código fonte do Windows 2000. Que tal ler o que a mídia da época comentou a respeito?

Lembre que remover commits do sistema de controle de versões não é uma tarefa trivial.

Boas leituras

Há dois livros muito bons que possuem capítulos dedicados aos comentários em código fonte:

Code Complete – Steve McConnell – Editora Microsoft (diga-se de passagem, o melhor livro que já li sobre programação em geral, leitura obrigatória) – Traduzido para o português pela editora Bookman

Clean Code – Robert C. Martin – Editora Prentice Hall – Traduzido para o português pela editora Alta Books

As duas traduções são muito boas e ambos são leitura obrigatória apesar da minha preferência pelo primeiro.

Concluindo

Não creio naquela história de que “a documentação do meu sistema é meu código”, no entanto, se for o caso, pelo menos bons comentários irão lhe ajudar na manutenção futura deste sistema.

Sobre minhas críticas ao “código como única documentação”, provávelmente será meu próximo post neste blog (ou quando encontrar uma forma mais polida de lidar com este assunto). :)

logo_freehand_pequeno

Melhorando os Guias da itexto

Na itexto, além do Groovy e Grails Brasil e do /dev/All há um terceiro projeto ao qual me dedico já faz algum tempo: os nossos guias.

São ebooks gratuitos que escrevemos e disponibilizamos gratuitamente para a comunidade: por enquanto há apenas três: Injeção de Dependências com Spring, Usando Git e Usando Jenv. Há m ais alguns a caminho: conforme progrido nos meus estudos sobre Docker, acabei iniciando a escrita de mais este texto e, em um futuro ainda mais próximo, devo publicar outro sobre o uso do Spring Security com Grails.

Hoje lançamos a versão nova do site (pra variar, odiava a antiga). Está com um visual melhor (similar ao do /dev/All), e trás duas novidades interessantes: a primeira é a criação da mailing list para que possamos informar nossos leitores a respeito das novidades.

A segunda é que agora todos os textos terão seu “código fonte” publicado no GitHub da itexto, assim vocês poderão acompanhar o desenvolvimento deste trabalho também.

E o link? http://www.itexto.com.br/guias

Me digam o que acharam, ok? Críticas são bem vindas!

 

IBMS360-1

“Legado” é um termo maldito

O termo “legado”, quando aplicado a software sempre me incomodou: tanto que algum tempo atrás busquei uma melhor definição para esta palavra dentro do nosso contexto de TI. Hoje volto ao assunto para dizer que não uso mais a palavra “legado” com meus clientes e colegas e explico minhas razões.

O termo que todo mundo busca a definição (inclusive eu)

Fui um dos palestrantes da trilha de legados da QCon Rio 2015 e, para minha sorte (ou azar), fui o último a falar, o que me permitiu assistir a todas as apresentações sobre o assunto. O que achei interessante é que quase todos (inclusive eu) apresentaram seu próprio conceito de legado.

(e neste texto ainda apresento mais definições sobre legado, o que mostra ser um fenômeno global, e não uma particularidade daquele evento)

Claramente há algo errado aqui: se dentro de um contexto bem definido (ou ao menos aparentemente) há tantas definições para uma mesma palavra, surgem duas possibilidades:

a) A palavra não possuí um significado real
b) Devíamos ou categorizar este termo ou mesmo buscar outras palavras

A  má impressão criada pela nossa indústria

Diversas vezes um cliente chega para nós pedindo que executemos manutenções ou evolução em seus sistemas com frases do tipo: “temos este sistema legado, que me disseram ser velho e ultrapassado, mas não tenho dinheiro para reescrever do zero”.

Lendo o código fonte observo que foram usadas tecnologias como Spring BootGrailsPHP, JavaScript, JSF ou qualquer outra que é ativamente desenvolvida hoje. Pior ainda: o sistema tem no máximo 5 anos de idade. Não poderia ser categorizado como “velho”, e levando-se em conta que normalmente está em uso, muito menos “ultrapassado” ou “obsoleto”, pois claramente está satisfazendo objetivos de negócio ali.

Fato é que muitas consultorias e profissionais normalmente ao invés de venderem a evolução do sistema preferem a reescrita por dizerem dar menos trabalho e sair mais barato (o que normalmente  é uma grande mentira e ainda escreverei sobre isto, mas enquanto isto, pode ler este excelente texto do Joel Spolsky).

A situação é ainda pior: já vi apresentações sobre “legados” na qual o palestrante usa o termo “evolução” e apresenta uma completa reescrita como resultado (atualmente uma das formas que esta reescrita vêm disfarçada é como micro-serviços).

Resultado: o termo “legado”, que deveria ter uma conotação positiva (conhecimento e experiência adquirida ao longo do tempo, conquista, satisfação por ter construído algo que é passado pra frente) passa a ser visto por muitos como um defeito.

(não creio que a maior parte dos profissionais e consultorias que vendam a reescrita imediata sejam mal intencionados. Na minha opinião o problema surge da nossa formação. Um dia ainda escreverei sobre isto)

Que termo uso agora

O mais óbvio e tedioso:  “software que você já tem” ou “software pré-existente” ou, ainda “software que não escrevi” ou algo similar pelas seguintes razões:

a) O cliente (que é quem realmente importa) entende o que estou dizendo imediatamente
b) Muitos clientes nunca ouviram o termo “legado”, o que evita a necessidade de explicar uma palavra que creio ser tão mal empregada em nosso idioma
c) Me fornece (e à indústria) um ponto inicial que possibilite uma melhor criação de sub-categorias que auxiliam na definição de estratégias

Sobre categorização

O termo “software que você já tem” é elementar: não consigo pensar em uma categoria superior a este (“software”, talvez :D) , mas consigo pensar em “tipos de software que você tem”. Segue uma pequena lista:

  • Aquele que temos o código fonte
  • Aquele que não temos o código fonte (sim, acontece e muito)
  • Aquele que é parte de sua infraestrutura (SGBD, Sistema Operacional, protocolos de rede)
  • Ou outra categorização qualquer que represente o nível de posse do cliente sobre um software

E esta categorização nos ajuda a pensar melhor o “seu software“. Ao analisar a situação do cliente (a mais importante), a comunicação fica mais simples e direta. É curioso que nas apresentações que vejo sobre legados só escuto sobre a primeira categoria: “aquele que temos o código fonte”. Aonde ele é executado? Como é o ambiente que o rodeia?

(é interessante notar que as pessoas confundem “legado” e refatoração, e esta é minha prinicpal crítica ao livro do Feathers – legado não é só o código)

A partir do momento em que um termo mais simples é usado na conversa, tudo flui, impressionante.

Minha antiga definição de “legado” não era uma definição

Ano passado busquei uma definição de legado e eis a que cheguei:

Sistema legado é aquele cujo controle foi perdido por seus principais stakeholders. – Definição Lobo Weissmanniana

Leia atentamente o que acabei de escrever: isto é uma definição? Hoje creio que não, pois não defini um termo, mas sim o problema fundamental do seu software.

O que é legado? Em português (e pensando no contexto brasileiro) é um termo que causa mais confusão que o necessário, haja visto os pontos que expus. Sendo assim, não irei mais me preocupar com a sua definição ou mesmo seu uso.

(ainda escrevo sobre um possível hype envolvendo este assunto (hype este que não se desenvolverá de forma saudável devido às falhas em nossa formação que comentei em parênteses anteriores))

angular-js_600x400

Aprendendo AngularJS – minhas leituras

Chegou aquele momento em que não dava mais pra fugir dele: finalmente me vi forçado a aprender AngularJS. Neste post vou listar o que usei para meus estudos e também as minhas primeiras impressões sobre o assunto. Levem em consideração que estou apenas começando!

O AngularJS: primeiras impressões

Apesar de já estar na versão 1.5, meus estudos estão focados na versão 1.4.2, dado que estou lidando com um projeto legado. Pouco a pouco vou me atualizar com as novas versões, já sabendo que a 2.0 é, pelo que pude ver, radicalmente diferente.

Mecanismo de templates

Como mecanismo de templates, achei fantástico (o mínimo que eu esperava). De imediato o vejo como uma excelente ferramenta para se escrever relatórios quando os dados são obtidos via REST no formato JSON. Alguns experimentos que fiz durante os estudos iniciais foram muito promissores.

Interações de usuário

Como framework usado para se escrever as interações do usuário, também achei bastante interessante. Me lembrou bastante o modelo de desenvolvimento que temos ao desenvolver aplicações desktop.

Escrever aplicações cuja interface no formato tabela usando o binding de duas vias do AngularJS se mostrou uma tarefa trivial com o AngularJS. E escrever filtros com ele (em tabelas) também é ridiculamente simples (quase aposenta o Datatables).

Roteamento

Ainda não me desceu bem o modelo de roteamento apresentado pelo AngularJS, mas creio que seja por enquanto apenas o resultado do meu contato inicial com o framework. Ainda tenho minha cabeça presa ao modelo de desenvolvimento AJAX tradicional (com muito jQuery), o que tem me dificultado um pouco a compreensão.

Saudades do jQuery

Adoro jQuery, o que me atrapalha um pouco no aprendizado do AngularJS. Em diversos momentos me via pensando em como faria a mesma coisa com minha biblioteca favorita. No entanto, conforme o tempo vai passando, este “vício” vai se reduzindo.

Confesso que me deu um certo alívio ver que o modo como fazemos requisições Ajax com AngularJS é muito parecido com o que conhecia no jQuery. :)

O que li

Angular Basics – http://www.angularjsbook.com/

Escrito por Chris Smith, é um pequeno livro online interativo no qual você pode experimentar o código fonte de uma forma muito interessante. Sem sombra de dúvidas foi o melhor material que encontrei sobre o assunto.

A linguagem adotada é muito simples e muito direta ao ponto. O autor se preocupa bastante em tratar apenas do que é essencial para que você possa começar a dar os primeiros passos, o que é excelente, pois alguns materiais que encontrei achei muito complicados para quem está iniciando.

Ao ler este livro, tinha ao lado um editor de textos e um navegador que usava para fazer alguns experimentos baseados no texto. Me ajudou bastante. Importante lembrar que o livro cobre a versão 1.4.2 do Angular, e não a 1.5.5 ou 2.

Algo bacana neste texto são as referências feitas pelo autor. Dá para o leitor que não tem muita vivência com JavaScript se aprofundar em diversos temas sobre a linguagem.

Resumindo: leitura fantástica!

Tutorial oficial do AngularJS – https://docs.angularjs.org/tutorial

Não gostei quando li na época em que o AngularJS foi lançado e continuei não gostando hoje.

Meu principal problema com este texto é que ele afoga quem está chegando em informações e terminologias que deviam ser apresentadas de uma forma mais suave.

Além disto, o código fonte já vêm pronto de cara em um repositório Git. Confesso que prefiro quando o próprio leitor vai gerando este código, tal como fiz lendo o “Angular Basics”.

Desconfio que este meu atraso no AngularJS se deve à antipatia que sempre senti por este tutorial (não vou negar).

Guia do desenvolvedor – https://docs.angularjs.org/guide

Se você quer conhecer a fundo o conceitual por trás do AngularJS, este é o texto. Não é algo que deve ser lido sequencialmente, mas sim como leitura complementar.

É muito bem escrito, e tem o nível de profundidade que se espera ao buscarmos uma melhor compreensão a respeito dos conceitos envolvidos na construção do framework e, ainda mais importante, das motivações que justificam o AngularJS ter a forma que possuí.

Não creio que seja um bom ponto de partida para se aprender o framework, mas como leitura complementar, foi fundamental para mim.

Curso gratuito da CodeSchool – http://campus.codeschool.com/courses/shaping-up-with-angular-js/intro

Feliz demais pro meu gosto: me deu vergonha alheia e acabei pulando.

Ferramenta legal: AngularJS Batarang

Trata-se de uma extensão do Chrome que nos permite depurar código escrito em AngularJS. Você a instala e, na sequência, será criada uma nova aba nas ferramentas de desenvolvimento.

Por lá você poderá ver o escopo do seu módulo, informações sobre desempenho, interceptadores e tudo mais. É muito bacana para se ter uma visão melhor sobre o que estamos escrevendo com o AngularJS.

Concluindo

Apesar de atrasado, o processo de aprendizado do AngularJS tem sido uma experiência muito enriquecedora para mim. Confesso que não tanto pelo Angular, mas sim pelas referências que vou pegando no caminho que, acidentalmente, tem aumentado muito meu conhecimento sobre JavaScript.

Estou apenas começando no framework, apanhado bastante em alguns pontos, mas, no geral, gostado do que tenho visto. Aproveitando, você tem alguma boa indicação de leitura para me passar? Toda dica é bem vinda!

capa

Novo guia da itexto: usando Jenv!

Se existe uma ferramenta que me ajuda HORRORES no dia a dia é o Jenv: trata-se de um gerenciador de ferramentas baseadas em Java e que ofereçam interfaces de linha de comando, tais como Grails, Groovy, Maven, JDK, Ant, Spring Boot e muitas outras.

No meu caso, como lido com diversos projetos baseados em Grails, com versões que variam da 1.1 a 3.1.4, é uma mão (ou melhor, duas!) na roda. Se a coisa parece chata, imagine que também lido com diferentes versões do JDK (do 1.3 a 1.8!). :)

Este é um guia rápido para que você possa começar a trabalhar com a ferramenta imediatamente. Exponho apenas o essencial, mas também alguns hacks que você pode aplicar na ferramenta e, claro, sua comparação com o SDKMan, que é outra opção bastante interessante.

Trata-se de uma ferramenta que sempre indico para nossos clientes de consultoria e alunos. Acabo de publicar então o terceiro guia da itexto, que você pode baixar neste link.

Espero que goste e que o Jenv lhe seja tão útil quanto é para nós!