Faça donwload direto no site oficial
“Ó Deus, cria em mim um coração puro e dá-me uma vontade nova e firme!” Salmos 51:10
Porque eu uso Groovy? # 2
Blog interessante comentando sobre as sub- linguagens JAVA.
Lembrando que temos o Lombok que hoje auxilia muito em código verboso.
Estes dias me perguntaram o por que eu parei de escrever meus programas Java com a linguagem Java e passei a utilizar a linguagem alternativa de Java chamado de Groovy. São vários os motivos, e hoje quero falar de alguns.
Dont Repeat Yourself – DRY
DRY é uma abreviação para o inglês Don’t Repeat Yourself, “Não se Repita”. É o primeiro princípio do desenvolvimento de software mencionado por Andy Hunt e Dave Thomas no clássico livro O Programador Pragmático. O princípio basicamente declara que não se pode fazer coisas repetidas ou duplicadas ao longo do desenvolvimento de software. Isso ocasiona alta manutenção, aumenta a complexidade, reduz a qualidade da solução final e deixa a coisa extremamente chato e cansativo de fazer.
Linguagem Java é repleta de DRY
Se você ainda não reparou, a linguagem Java padrão esta repleta de DRY, obrigando o desenvolver que a usa todos dias fazer…
Ver o post original 620 mais palavras
Pré-processadores: usar ou não usar?
Meus dois centavos sobre a utilização de pré processadores de CSS.
22/07/2013 Seja o primeiro a comentar!
O Miller Medeiros escreveu um ótimo artigo com o nome de The problem with CSS pre-processors. Lá ele cita alguns pontos interessantes, que pra mim já são suficientes para não usar.
Mas como eu disse: sou meio contra. Isso quer dizer que eu admito, sim, que em alguns casos, muito específicos eles podem nos ajudar muito. Eu sempre fico em dúvida em utilizá-los ou não em meus projetos. Um desses casos: eu participo de um projeto onde o usuário pode fazer vários painéis de cores diferentes. Usamos SASS para fazer essa parte de gerenciamento de cores. Se não fosse ele certamente nos perderíamos depois de um tempo.
Pré processadores podem ajudar como também podem maltratar bastante. Basta um escorregão para que seu projeto vire um inferno. Por isso, mesmo que eu seja contra, eu incentivo que você experimente e tire suas próprias conclusões. Nas próximas linhas dou meus dois centavos sobre o assunto.
Curva de aprendizado de novos integrantes
É comum recebermos novos integrantes na equipe. Pessoas vem e vão. Isso é normal em qualquer time. O problema é que sempre que alguém novo chega, esse alguém precisa aprender, de preferência o mais rápido possível, os detalhes do projeto. Pra facilitar essa curva de aprendizado, as equipes podem manter um manual explicando as boas práticas de escrita de código, scrum e tudo isso aí ajudam. Mas não importa quantas reuniões você faça, o cabra só vai conseguir conhecer mesmo o tamanho do projeto quando colocar a mão na massa.
Quando o código foi escrito sem nenhum pré processador, a curva de aprendizado é muito menor. Ele não precisa aprender os costumes da equipe quanto às preferências do uso das features do pré processador escolhido. Se a equipe estiver usando SASS, por exemplo, podem existir uma série de regras de mixins e extends que pode demorar para fazer sentido. Sem comentar o aninhamento (nesting) de seletores para evitar o repetimento de elementos. Já é difícil de entender todas as relações de elementos e suas formatações na maneira normal, imagine usando indentação para hierarquizar os seletores.
Isso pode prejudicar bastante a manutenção, principalmente se a manutenção for feita por um novato no projeto, que por não conhecer os miúdos do código, pode acabar alterando algum valor que é reutilizadao em vários mixins/extends e seus correlatos.
Para evitar problemas assim, a documentação deveria ser muito bem atualizada, apontando todas as relações de mixins, extends, variáveis e etc. E se você já tentou manter uma simples documentação dentro de uma equipe sabe que é quase impossível ter 100% de comprometimento para atualizar os mínimos detalhes. Principalmente detalhes que mudam o tempo inteiro.
Difícil voltar
Quando decidimos usar um pré processador é um caminho sem volta.
Até onde pesquisei, uma vez que seu projeto foi escrito sob as regras de um pré processador, não há como voltar atrás, a não ser que você utilize a versão já processada desse código. Mas aí entramos em outro problema: geralmente pré processadores escrevem mais código do que você escreveria manualmente. Duas opções: corrigir o excesso de código do projeto inteiro na mão ou ignorar e seguir em frente.
Há equipes que se arrependem e decidem que deste ponto em diante escreverão CSS puro, sem utilizar as features do pré processador.
Nunca será como se fosse feito manualmente
Como já citamos, o código gerado pelo pré processador nunca será como o código escrito por você. Nunca vi nada que tente gerar código automaticamente fazer algo que não fosse duvidoso.
Veja um exemplo simples de uso do mixin do SASS:
@mixin alert {
color: red;
border: 2px solid red;
}
.alert-default {
@include alert;
}
.alert-special {
@include alert;
background-color: gray;
}
Resultado:
.alert-default {
color: red;
border: 2px solid red;
}
.alert-special {
color: red;
border: 2px solid red;
background-color: gray;
}
Entende a duplicação código de border e color das duas propriedades? Claro, no exemplo acima seria muito melhor ter usado um extend em vez de mixin. Mas e se um desavisado cometer esse erro?
Com o extend, fica assim:
.alert {
color: red;
border: 2px solid red;
}
.alert-default {
@extend alert;
}
.alert-special {
@extend alert;
background-color: gray;
}
Que já ser compilado para:
.alert, .alert-default, .alert-special {
color: red;
border: 2px solid red;
}
.alert-special {
background-color: gray;
}
Legal, ele agrupou os seletores que tem a mesma formatação. Ficou mais perto do que talvez faríamos na vida real. Mas aí alguém usa isso em trilhões de lugares diferentes.
Lembra que algumas versões IE tem um limite para a quantidade de seletores agrupados?
O código também vai ficar bem complicado de se manter com tantas dependências. Quem vai lembrar de atualizar a documentação, como já havíamos comentado.
Cedo ou tarde o CSS vai amadurecer
O W3C tem trabalhado bastante para oficializar o mais rápido possível as novidades do CSS. Os fabricantes de browsers também tem se esforçado para manter seus navegadores atualizados, trazendo sempre novidades para experimentarmos e usarmos em projetos hoje, agora. Cedo ou tarde o CSS vai ter features como as dos pré processadores para nos ajudar com a manutenção e economia de código. Não é algo imediato, claro, mas sabemos que virá.
Com certeza vai ser bem melhor do que temos hoje em vários sentidos. Por isso que eu prefiro esperar pra ver.
Conclusão
Esses são os motivos pelos quais eu ainda não aderi de vez aos pré processadores. Como disse eu uso aqui e ali pra tentar usufruir das vantagens, mas ainda fico com uma sensação de que essas vantagens realmente não valem tanto a pena quanto parecem.
Você já usou ou usa em algum projeto? O que acha?
Angular 2, vale a pena?
O Angular é hoje uma das ferramentas mais largamente utilizada para desenvolvimento front end. Vale a pena migrar para a nova versão?
02/12/2016 2 comentários
O Angular, apesar de ter sido pensado inicialmente para lidar apenas com formulários, é hoje uma das ferramentas mais largamente utilizada para desenvolvimento front end, porém, sempre teve seus problemas, dentre eles, os problemas de performance. E é esse um dos principais motivos que levou a equipe do Angular a desenvolver, do zero, a sua versão 2.
O rangle.io listou as principais diferenças entre o Angular 1 e o 2:
“_Transitional Architecture_” se refere ao estilo de programação no Angular 1 de forma a se aproximar o máximo possível do Angular 2, mas com Controllers e _Diretivas,_ ao invés de classes TypeScript.
Mas e aí, vale ou não a pena?
Adoção
A preocupação da maioria das pessoas é simplesmente não saber se Angular 2 vai realmente “vingar”, e acabam ficando com receio de migrar. Fazendo uma simples pesquisa no Google Trends, é possível comparar a popularidade do termo Angular 2, comparado a VueJS e ReactJS, as ferramentas que estão mais em alta atualmente.
Mobile
Se você pretende desenvolver aplicativos híbridos, cá está mais um excelente motivo para usar Angular 2, a equipe do Ionic está finalizando o desenvolvimento da sua segunda versão, que é totalmente escrita em Angular 2.
TypeScript
Uma vez que a maioria dos navegadores não estão habilitados para rodar ES6 e ES7, surgiram alguns pré-compiladores, que geram todo o código para o JavaScript “entendível” pelo navegador. Mas o Typescript vai um pouco mais longe.
O TypeScript, criado pela Microsoft (isso mesmo), é um “_superset_” do JavaScript, que, além de implementar as funcionalidades do ES6+, traz uma série de “poderes” no desenvolvimento. Uma das coisas que eu gosto bastante, é a capacidade de autocomplete nas IDEs (se você tiver uma que suporte, como o Sublime Text ou VSCode). Mas acredito que o mais interessante é a parte de organização do código. O TypeScript tem uma sintaxe muito mais clara e fácil de entender. Abaixo um mesmo código escrito em TypeScript e JavaScript:
TypeScript:
class HelloWorld {
text: string;
constructor(text: string) {
this.text = text;
}
}
let txt = new HelloWorld("Olá mundo!");
console.log(txt);
JavaScript:
var HelloWorld = (function () {
function HelloWorld(text) {
this.text = text;
}
return HelloWorld;
}());
var txt = new HelloWorld("Olá mundo!");
console.log(txt);
Performance
Um ponto muito importante de destaque é a performance. O Angular 1, de fato, oferece uma experiência de baixa performance devido a excessivas interações com a DOM. O Angular 2 vem pra resolver esse problema de uma vez por todas. O gráfico abaixo, feito pela auth0, mostra, na prática o resultado do benchmark que eles realizaram:
Conclusão
O Angular 2 veio pra ficar, além de ser uma ferramenta que evoluiu, ter uma grande empresa como o Google por trás só ajuda. A adoção deste framework só tende a crescer mais, e, sim, vale muito a pena usar em seus projetos.
Differences Between Angular 1 & 2
Note that “Transitional Architecture” refers to a style of Angular 1 application written in a way that mimics Angular 2’s component style, but with controllers and directives instead of TypeScript classes.
| Old School Angular 1.x | Angular 1.x Best Practices | Transitional Architecture | Angular 2 | |
|---|---|---|---|---|
| Nested scopes (“$scope”, watches) | Used heavily | Avoided | Avoided | Gone |
| Directives vs controllers | Use as alternatives | Used together | Directives as components | Component directives |
| Controller and service implementation | Functions | Functions | ES6 classes | ES6 classes |
| Module system | Angular’s modules | Angular’s modules | ES6 modules | ES6 modules |
| Transpiler required | No | No | TypeScript | TypeScript |
Vamos estudar Angular ?
Angular 2 é um framework que permite desenvolver aplicações web e mobile, mantido pela Google. Apesar de ser a segunda versão do framework, Angular 2 não é a continuação do Angular 1 com melhores e novas funcionalidades, foi reescrito.
Nesse curso vamos aprender como desenvolver com Angular 2.x e 4.x e TypeScript. Você vai aprender os conceitos básicos e intermediários do Angular, desde os primeiros passos até uma aplicação completa com requisições ao servidor e rotas.
Vamos aprender os conceitos de componentes, templates, diretivas, serviços, data-binding, validação de formulários, formulários reativos, roteamento (single page application – SPA) e como conectar ao servidor e trabalhar com RxJS (Observables).
Não é necessário saber Angular 1 para esse curso, já que o Angular v2 foi reescrito. Vamos aprender todos os conceitos do zero, então não se preocupe!
O conteúdo desse curso é aplicado tanto no Angular 2.x quanto no Angular 4.x
Nível: Iniciante ao Intermediário
Curso em andamento – as aulas ainda estão sendo publicadas. O certificado só ficará disponível quando todas as aulas forem publicadas.
Link com o calendário/agenda das aulas: https://github.com/loianetraining/ementas/blob/master/angularjs2.md
EMENTA DO CURSO
| Introdução | |||
| Data binding | |||
| Angular CLI | |||
| Diretivas | |||
| Serviços | |||
| Pipes (Filtros) | |||
| Rotas | |||
| Formulários (Template Driven) |
Concluindo o curso sobre Angular. Do iniciante ao avançado com Loiane.
Com direito a certificado!!
O que é Node.js e saiba os primeiros passos
O que é Node.js?
Node.js é uma plataforma para desenvolvimento de aplicações server-side baseadas em rede utilizando JavaScript e o V8 JavaScript Engine, ou seja, com Node.js podemos criar uma variedade de aplicações Web utilizando apenas código em JavaScript.
Em uma primeira análise essa informação pode não parecer tão interessante, uma vez que existem diversas outras maneiras em que esses tipos de serviços podem ser implementados. Mas se pensarmos um pouco mais sobre as demandas de aplicações na internet e o modo em que o código em JavaScript pode ser estruturado, vamos nos deparar com uma gama de novas possibilidades para desenvolvimento Web, e provavelmente nos juntar à crescente comunidade que tem adotado essa plataforma.
Uma importante diferença está no fato do Node ser single threaded. Embora isso possa parecer uma desvantagem em um primeiro momento, o que percebemos ao desenvolver com Node.js é que isso simplifica extremamente a construção da aplicação, e por Node.js utilizar uma abordagem não obstrutiva, essa diferença vai ser imperceptível na maioria dos casos.
V8 JavaScript Engine
É o interpretador de JavaScript open source implementado pelo Google em C++ e utilizado pelo Chrome. O que sem dúvidas gera uma grande expectativa em relação ao desempenho do Node.js.
Instalando o Node.js
A instalação do Node.js é extremamente simples graças ao fato de o V8 JavaScript Engine ser completamente multi-plataforma, tudo que você precisa fazer é visitar a página oficial do Node.js, clicar em “INSTALL” e seguir as instruções.
Após a instalação, basta executar o seguinte comando no seu terminal para verificar se foi instalado corretamente:
$ node -v > v0.10.26
deve retornar a versão do node que foi instalada, como por exemplo v0.10.26.
O web server ‘Olá mundo!’
Ok, então vamos construir alguma coisa.
Nosso primeiro exemplo é um servidor que retorna a string ‘Olá mundo’ para qualquer requisição. Para fazer isso utilizando Node você vai precisar de criar um arquivo JavaScript que pode ser chamado olanode.js e de três minutos do seu tempo.
Escreva o seguinte código no seu arquivo:
var http = require('http');
http.createServer(function(req,res) {
res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
res.end('Olá mundo!');
}).listen(3000);
console.log('Servidor iniciado em localhost:3000. Ctrl+C para encerrar…');
Para executar o seu programa Node basta o seguinte comando no seu terminal:
$ node olanode.js
Para testar seu servidor você pode acessar localhost:3000 no seu navegador ou utilizar linha de comando com o comando curl (em uma nova instância do terminal) como mostrado a seguir:
$ curl http://0.0.0.0:3000/ > Olá mundo!
Caso você prefira retornar algum html válido para o navegador, basta alterar 'text/plain' para 'text/html' no código acima e utilizar uma tag html legal como <h2>, como foi feito a seguir:
var http = require('http');
http.createServer(function(req,res) {
res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
res.end('<h2> Olá mundo! </h2>');
}).listen(3000);
console.log('Servidor iniciado em localhost:3000. Ctrl+C para encerrar…’);
Agora basta voltar ao seu navegador e ver o resultado.
Orientado a eventos e não obstrutivo
Orientado a eventos
Vamos aproveitar este momento de euforia após a construção do seu primeiro servidor para aprender um pouco mais sobre Node.js.
Quando estamos desenvolvendo com Node.js devemos utilizar uma abordagem orientada a eventos, isso quer dizer que o desenvolvedor precisa conhecer os eventos que serão emitidos em diferentes momentos da execução e também saber como ouvi-los para executar as operações necessárias.
Um bom exemplo de orientação a eventos está na construção de interfaces de usuário. Muitas vezes utilizamos elementos como por exemplo os botões que ao serem clicados emitem um evento do tipo click ao qual podemos ouvir e executar alguma operação.
No nosso exemplo anterior utilizamos esse conceito quando chamamos método listen do objeto do tipo web server e passamos como parâmetro a porta 3000, com isso fizemos que a nossa aplicação ouvisse ao evento que é emitido sempre que alguém faz uma requisição no localhost:3000 e a nossa resposta foi servir a string ou a página html. Este evento é chamado request.
Para ilustrar estes conceitos, podemos escrever o nosso exemplo anterior em uma sintaxe alternativa da seguinte forma:
var http = require('http');
var server = http.createServer();
server.on('request', function(req,res) {
res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
res.end('<h2> Olá mundo! </h2>');
});
server.listen(3000);
console.log('Servidor iniciado em localhost:3000. Ctrl+C para encerrar…’);
Dessa forma podemos ver claramente a maneira em que o Node.js opera para servir a sua página. Utilizamos o método on do nosso objeto server para ouvir ao evento request e fazer as operações. E definimos que estamos servindo na porta 3000.
Não obstrutivo
Todos os recursos presentes no Node.js e também a maioria das bibliotecas feitas para ele adotaram um padrão não obstrutivo de escrever código, isso quer dizer que em Node.js você geralmente vai conseguir estruturar seu código de uma maneira que operações que não dependem de nada que está sendo executado possam ser executadas de forma independente.
Para mostrar um pouco como isso funciona, vamos um programa que escreve duas frases no terminal, porém uma dessas frases precisa ser carregada da memória antes de ser impressa.
var frase;
carregaFrase = function (callback) {
setTimeout(function() {
//Simula leitura da frase no banco de dados.
frase = "Minha frase obstrutiva";
callback();
}, 3000)
}
imprimeFrase = function () {
console.log(frase);
}
carregaFrase(imprimeFrase);
console.log(“Olá");
Nesse exemplo foi criada uma função chamada carregaFrase cujo objetivo é ler uma determinada frase de uma fonte de dados, e uma outra função chamada imprimeFrase que imprime o valor de uma determinada variável no console. Como dependemos da leitura da frase na fonte de dados para imprimir o valor, passamos a função que imprime como parâmetro para a função de leitura para que possamos executar essa função quando a leitura for concluída. Esse tipo de função que é passada como parâmetro dessa maneira é chamada de callback.
Ao executar este exemplo com Node.js ou qualquer mecanismo JavaScript você vai perceber que a frase “Olá” será impressa antes da outra frase mesmo estando posicionada depois no código, isso se deve ao fato de sua execução não depender de nada enquanto a execução da outra frase depende de uma operação que leva 3 segundos.
Este é um exemplo extremamente simples de como criar um código não obstrutivo, portanto use sua imaginação para imaginar cenários em que isso pode ser útil.
Observe que no nosso primeiro exemplo com Node.js tanto a função on quanto a função createServer podem receber uma função de callback.
Conclusão
Espero que este tutorial tenha sido o suficiente para provocar o seu interesse em aprender mais sobre Node.js. Portanto visite a documentação do Node.js para obter mais informações e exemplos de aplicações dessa plataforma e também a página da Joyent, patrocinadora oficial do projeto.
E finalmente, Node.js é um projeto open source, portanto você pode visualizar o código fonte e contribuir no repositório do Node.js no GitHub.
SEND SMS AND MMS MESSAGES IN JAVA
Padrões de Transações Java com Spring Framework
Uma transação é uma seqüência de ações que são tratadas como uma única unidade de trabalho. Essas ações devem ser completas ou não terem nenhum efeito. O gerenciamento de transações é uma parte importante no desenvolvimento de soluções corporativas, sendo que é que deve garantir a integridade e consistência dos dados nas operações. Existem 2 tipos de transações: Locais e Globais.
Transações locais versus globais
As transações locais são específicas para um único recurso transacional, enquanto as transações globais podem abrangem vários recursos transacionais distribuídos.
O gerenciamento local de transações pode ser útil em um ambiente de computação centralizado, onde os componentes e recursos do aplicativo estão localizados em um único lugar, e o gerenciamento de transações envolve apenas um gerenciador de dados local executado em uma única máquina. As transações locais são as mais fáceis de implementar.
O gerenciamento de transações globais é necessário em um ambiente de computação…
Ver o post original 1.055 mais palavras
Feign uma forma simples para consumir serviços
Excelente post sobre webservice.
Dificilmente uma aplicação “vive sozinha” e em algum momento pode surgir a necessidade de integrá-la com outras aplicações.
As necessidades podem ser diversas:
- Consultar dados de um sistema legado
- Retornar endereço a partir de um CEP
- Efetuar pagamento online
- Consultar o custo de envio de determinada mercadoria
- Fazer autenticação através de alguma rede social ou qualquer
Hoje em dia muitas das integrações utilizam o modelo arquitetural REST, e não é uma tarefa muito difícil criar um cliente para consumir um serviço web.
Vamos usar como exemplo via cep, que é uma alternativa para pesquisar um endereço a partir de um CEP.
Para consumir o serviço este basta efetuar uma requisição GET no seguinte formato https://viacep.com.br/ws/NUMERO-DO-CEP/FORMATO. O formato pode ser: json,xml,piped,querty.
Se por exemplo efetuarmos uma requisição GET para https://viacep.com.br/ws/04101300/json, temos o seguinte retorno:
Consumindo Serviço com RestTemplate
Para consumir um Web Service no Spring podemos usar a classe
Ver o post original 633 mais palavras
Marcelo Nobre - Tecnologia Java 