Sobre Isso!

Hoje mostrarei a utilização básica do Spring Boot CLI.
O Spring Boot CLI é uma ferramenta de linha de comando que auxilia na criação rápida de artefatos Spring escritos em Groovy, facilitando assim a prototipação de suas aplicações.

Instalação

Você pode instala-lo a partir dos binários ou utilizar o GVM que é uma ferramenta multiplataforma utilizada pela comunidade Groovy para gerenciar a instalação de várias ferramentas. O GVM roda em plataformas Linux, Solaris, Mac OSX, BSD, porém no Windows apenas via Cygwin. Se você usa o Windows, aconselho que baixe o Spring Boot CLI diretamente dos binários.

Instale o GVM da seguinte forma:

curl -s get.gvmtool.net | bash

em seguida a instalação do Spring Boot CLI:

gvm install springboot

digitando :

spring --version

para verificar a versão instalada.
Opcionamente você poderá configurar o Command-Line completion para obter sugestões de parâmetros e argumentos durante a utilização.
Adicione em seu arquivo de configurações de ambiente (.bash_profile por exemplo) a linha

source '~/.gvm/springboot/current/shell-completion/bash/spring'

Esse path considera que você usou o GVM, altere se necessário para apontar para pasta onde seu Spring Boot CLI foi instalado.
Na linha de commando experimente:

spring 

grab  help  jar  run  test  version

Opcionamente você poderia usar o instalador disponibilizado pela equipe do Spring:

curl http://start.spring.io/install.sh | sh

Na prática não haverá difenças no resultado, mas a primeira opção constitui um modelo padronizado para gerenciamento desta e demais ferramentas utilizadas.

Crie o arquivo Groovy SampleController.groovy

@RestController
class SampleController {

  @RequestMapping("/")
  String home() {
    "Hello World!"
  }

}

Na linha de comando digite:

spring run SampleController.groovy

Observe que essa é uma classe Groovy e portanto se beneficia da simplicidade que a linguagem oferece. O resultado, mais uma vez será o mesmo observado nos posts anteriores

Semelhante ao Maven, instale o Gradle seguindo essas instruções, opcionalmente utilize a mesma pasta do exemplo anterior e crie o arquivo para o build do gradle: build.gradle :

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:1.1.9.RELEASE")
    }
}

apply plugin: 'java'
apply plugin: 'spring-boot'
apply plugin: 'eclipse'
apply plugin: 'idea'

jar {
    baseName = 'gs-spring-boot'
    version =  '0.1.0'
}

repositories {
    mavenCentral()
}

dependencies {
    compile("org.springframework.boot:spring-boot-starter-web")
    testCompile("junit:junit")
}

task wrapper(type: Wrapper) {
    gradleVersion = '1.11'
}

O Gradle é mais flexível e mais simples, além de usar justamente o grande acervo de bibliotecas disponibilizadas nos repositórios Maven.

O techo

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:1.1.9.RELEASE")
    }
}

orienta o Gradle a encontrar e disponibilizar o plugin spring-boot-gradle-plugin

As linhas:

apply plugin: 'java'
apply plugin: 'spring-boot'
apply plugin: 'eclipse'
apply plugin: 'idea'

disponibilizam tasks especializadas para projetos java, artefatos spring-boot e integração com a IDE Eclipse e Idea, respectivamente.

No terminal digite:

gradle bootRun

e mais uma vez e resultado será idêntico ao mostrado no post anterior.

No próximo post veremos a utilização de mais uma opção: o Spring Boot CLI, uma ferramenta em linha de comando que permite gerar aplicações Spring Boot ainda mais rápido.

No post anterior fiz uma breve introdução ao Spring Boot. Hoje e no próximo post irei demonstrar como executar o mesmo exemplo do post anterior utilizando duas populares ferramentas para automação de compilações: o Maven e o Gradle.

Trabalhando com o Maven

A instalação do Maven é bem simples e você pode utilizar esse guia oficial em caso de dúvidas.
Crie um novo projeto Maven utilizando sua IDE preferida ou no terminal digite:

mvn archetype:generate -DgroupId=hello -DartifactId=hello -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

O resultado será uma estrutura de pasta semelhante a essa:

hello
├── pom.xml
└── src
    ├── main
    │   └── java
    │       └── hello
    │           └── SampleController.java
    └── test
        └── java
            └── hello
                └── AppTest.java

Renomeie a classe App para SampleController e deixe-a com esse conteúdo:

package hello;

import org.springframework.boot.*;
import org.springframework.boot.autoconfigure.*;
import org.springframework.stereotype.*;
import org.springframework.web.bind.annotation.*;

@RestController
@EnableAutoConfiguration
public class SampleController {

    @RequestMapping("/")
    String home() {
        return "Hello World!";
    }

    public static void main(String[] args) throws Exception {
        SpringApplication.run(SampleController.class, args);
    }
}

No terminal digite:

mvn compile exec:java

O resultado será idêntico ao mostrado no post anterior.

No próximo post demonstrarei a utilização do Spring Boot com o Gradle.

Spring Boot é mais uma grande idéia da equipe do Spring para facilitar nossa vida durante a criação de soluções em Java.
Baseado na arquitetura de Microservices, com ele é possível criar facilmente aplicações completas com o mínimo de esforço pois sua filosofia baseada em convenções elimina a necessidade da maior parte das configurações.

Lembro-me que a primeira solução Spring em que trabalhei tinha tantas instruções de configurações que até me perdia e ainda assim era mais simples que trabalhar com os famigerados EBJ’s. De lá prá cá isso mudou muito, hoje por exemplo é totalmente opcional a utilização de xml’s e quando falamos de Spring Boot então as configurações para levantar um aplicativo praticamente não existe. Observe esse código: ¹

package hello;

import org.springframework.boot.*;
import org.springframework.boot.autoconfigure.*;
import org.springframework.stereotype.*;
import org.springframework.web.bind.annotation.*;

@RestController
@EnableAutoConfiguration
public class SampleController {

    @RequestMapping("/")
    String home() {
        return "Hello World!";
    }

    public static void main(String[] args) throws Exception {
        SpringApplication.run(SampleController.class, args);
    }
}

Considerando que as classes importadas estão em seu classpath, ao executar essa classe você terá essa saída em seu terminal:

…e em seu browser:

Observe que apesar de ser um chato “Hello World”, você não precisou fazer nenhum configuração avançada apenas na linha 8 a anotação

@Controller

que informa ao Spring que essa classe terá atributos de um Controlador Web. Na linha 9 temos

@EnableAutoConfiguration

que orienta o Spring a abstrair as dependências de seu projeto e a melhor configuração baseado nos recursos utilizados. Na linha 12 temos a anotação padrão do Spring:

@RequestMapping("/")

que define a url que ao ser interceptada produzirá o retorno desejado.

Nas linhas 17 à 19 temos um simples método Main que informa ao Spring Boot para iniciar a aplicação usando as configurações contidas nela própria. Em resumo você tem um simples executável rodando uma aplicação web.
Apesar de não ter informado um container, o Spring Boot levantou uma versão embarcada do Tomcat automaticamente para você.

Algo que é precioso nesse modelo baseado em convenções é que apesar de toda essa abstração, é possível sobrescrever os padrões propostos por suas próprias configurações.

Num próximo post veremos como utilizar o Maven e o Gradle para gerenciar um projeto Spring Boot.

Nesses últimos dias a equipe do Gradle anunciou o release 1.3. Essa nova versão traz atualizações importantes pois o torna mais estável e otimiza a forma com algumas tarefas são realizadas.
Os usuários de Scala devem comemorar pois foi introduzido a compilação incremental o que garante um grande ganho de velocidade.
Também foi corrigido e otimizado o mecanismo de resolução de dependencias.
Vale a pena conferir.

Já ha algum tempo que uso o Maven como ferramenta de build, mas preciso confessar que sempre tive meus contra-tempos com ele. No último projeto resolvi experimentar novamente o Ant integrado ao Ivy e o resultado foi que acabei com os problemas de dependencias mas ainda permaneceu o inconveniente de trabalhar com um xml e ter que definir todos por menores.
Resolvi então experimentar o Gradle, uma ferramenta de build baseada em Groovy que traz inúmeras vantagens em relação às anteriores citadas.
É possível personalizar toda a estrutura do projeto e também se beneficiar de tasks e comportamentos padronizados.
O fato de ser em groovy permite que seus scripts sejam escritos com muita flexibilidade lançando mão dos recursos de um build associados uma poderosa linguagem.

Instalando

Baixe e descompacte a ultima versão do Gradle em um diretório e em seguida crie em seu ambiente a variável GRADLE_HOME e aponte para a essa pasta. Modifique a variável PATH adicionando $GRADLE_HOME/bin à ela.

Após isso você poderá digitar gradle -version para se certificar que tudo está ok.

Um script

Crie uma nova pasta e dentro dela seu script com o nome de build.gradle

task tarefa1 << {
	println "essa é a tarefa 1"
}

Salve-o e execute ainda nessa pasta: gradle tarefa1
O resultado será parecido com

gradle tarefa1
:tarefa1
essa é a tarefa 1

BUILD SUCCESSFUL

Total time: 2.741 secs

Ao digitar gradle tasks você verá a task “tarefa1” além de outras.
Podemos também definir a task padrão assim:

defaultTasks "tarefa1"

task tarefa1 << {
	println "essa é a tarefa 1"
}

Agora já é possível executar o script apenas com gradle

Algo prático

Você poderá utilizar o Gradle para automatizar várias tarefas, mas compilar e integrar códigos serão as mais rotineiras. Vamos criar uma pasta src/main/java e nela salve o arquivo Project1.java

public class Project1{

	public static void main(String[] args){
		System.out.println("Wello World!");
	}
} 

Altere seu script para:

apply plugin:'java'
apply plugin:'application'


mainClassName = "Project1"

Por fim execute o script gradle run para que sua classe seja executada.

Estou trabalhando num projeto com Springframework mvc onde os serviços rest são transportados em json.
Por padrão, a serialização para json é feita pelo framework Jackson que é muito bom diga-se de passagem, já que é bastante flexivel.
No meu problema de hoje precisei personalizar a serialização dos enums pois por padrão ele retorna o name do enum. É possivel por exemplo, adicionar a anotação @JsonValue para definir qual método retornará o valor desejado. No meu caso porém, eu precisava retornar o enum numa estrutura de pojo e não:


{
"name" : { "first" : "Joe", "last" : "Sixpack" },
"gender" : "MALE",
"verified" : false,
"userImage" : "Rm9vYmFyIQ=="
}


Para isso criei um serializador personalizado:


public class SimpleEnumSerializer extends JsonSerializer> {

com isso o resultado passa para:

{
"name" : { "first" : "Joe", "last" : "Sixpack" },
"gender" {"ordinal":0, "name":"MALE"},
"verified" : false,
"userImage" : "Rm9vYmFyIQ=="
}


Nos últimos dias tenho ouvido muito na mídia sobre ecologia focado em reciclagem. Um assunto tão importante como esse, é tratado aqui no Brasil como se reciclagem fosse algo que já fizéssemos há anos.
Interessante também é observar como aqueles que tentam despertar na população o interesse por esse assunto parecem realmente não considerar questões básicas em suas abordagens.

O Governo por exemplo, sugere que a dona de casa, durante sua árdua tarefa diária, separe todo lixo, cuidando em não misturar orgânicos, metais, papeis, vidros e plásticos. Até parece interessante, até você se perguntar: Como tudo isso vai funcionar? A maioria da população vive em minusculas moradias, será que caberá mais quatro recipientes de lixo numa casa? E o pior: o que adianta separar o lixo se na prática não existe coleta seletiva?

O Governo precisa iniciar projetos envolvendo a população, os condomínios, as empresas responsáveis pela coleta de lixo os sindicatos dos catadores, objetivando fazer menos propaganda e mais ação. É necessário projetar e distribuir gratuitamente um repositório de lixo compacto que seja possível num mesmo repositório, de forma prática armazenar todo tipo de lixo. E mais: é preciso fazer a coleta seletiva nesses bairros.

Algumas redes varejistas têm dado a opção de se adquirir sacolas “retornáveis”. Fico imaginando isso na prática pois à exceção do responsável pelas compras domesticas, a maioria das pessoas, não vão para o supermercado, passam lá. Imagine agora você que foi ao shopping, lembrou que precisava comprar algo mais que estava em falta mas não poderá faze-lo pois não trouxe sua sacola retornável. Se esse algo for muito importante, você poderá adquirir outra sacolinha pelos módicos R$ 4,50.

Soluções como essas nada mais são que tentativas de lançar novos produtos sob o marketing de uma
iniciativa ecologicamente correta.

Por fim não poderia deixar de mencionar a área de tecnologia que a cada dia evolui de tal forma que o mercado lança para o consumo novos produtos em intervalos cada vez menores.
No Brasil, logo teremos mais dispositivos móveis que brasileiros, ainda que esses não estejam proporcionalmente distribuídos, ou seja, não estou dizendo que todos terão um dispositivo.
Todos sabemos que não se deve descartar a baterias desses dispositivos em lixo comum, mas você conhece
algum ponto de coleta? Tipo você foi almoçar e viu a placa: “Descarte suas baterias de celulares Aqui!”.
Você não precisou ligar para nenhuma agência regulamentadora, não precisou ameaçar o gerente de uma revendedora de aparelhos celulares…

É preciso haver compreensão que apenas marketing não é suficiente para haja um despertamento de uma consciência ecológica.

Num post anterior eu mostrei um script genérico para realização dos backups de projetos, mas que é flexível pois permite a personalização das informações que se deseja backupear em cada projeto, a partir de arquivos de configurações.

Neste post faremos algumas pequenas modificações nele e configuraremos o agendamento para que o backup seja feito automaticamente.

As modificações consistem em remover as mensagens e diálogos gerados pelo kdialog e outras simplificações.
O novo script ficará assim:

backup.sh

[as]
#!/bin/bash
############################################
# backup de projetos
# deve ser usado em conjuto com algum arquivo de
# definicoes de backup
# por Paulo Cordeiro (paulo@link3.com.br)
# 02/09/2007
# versao 1.2
############################################

if [ “$#” -eq 0 -o ! -e “$1” ];
then
echo “execute: backup.sh arqConfig.bpk”
exit 2
else
defBackup=$1
fi

projeto=$(cat $defBackup | grep projetoNome | cut -d “=” -f 2)
descricao=$(cat $defBackup | grep descricao | cut -d “=” -f 2)
fonte=$(cat $defBackup | grep fonte | cut -d “=” -f 2)
destino=$(cat $defBackup | grep destino | cut -d “=” -f 2)
pastasPorData=$(cat $defBackup | grep pastasPorData | cut -d “=” -f 2)
data=$(date +%Y%m%d-%H%M%S)
includefile=$(mktemp /tmp/$projeto.in.XXXXXX)
excluirfile=$(mktemp /tmp/$projeto.ex.XXXXXX)

if [ “$pastasPorData” == “sim” ]
then
destino=”$destino/$projeto/$(date +%Y)/$(date +%B)/$(date +%d)”
else
destino=$destino/$projeto
fi
backup_name=$destino/$projeto-$data.tar.gz

cd $fonte

for infile in $(sed ‘/incluir-ini/,/incluir-fim/! d; ‘ $defBackup | sed ‘1d;$d’)
do
echo $infile >> $includefile
done

sed ‘/excluir-ini/,/excluir-fim/! d; ‘ $defBackup | sed ‘1d;$d’ > $excluirfile
mkdir “$destino” -p
tar -cvzf $backup_name –exclude-from=$excluirfile $(cat $includefile) > /dev/null

rm $includefile
rm $excluirfile
echo $backup_name
exit 0
[/as]

crie também esse pequeno script que será usado no agendamento:

agendamento.sh

[as]

#!/bin/bash
############################################
# agendamento de backups
# por Paulo Cordeiro (paulo@link3.com.br)
# 02/09/2007
# versao 1.0
############################################

arqConfig=arqConfiguracao.bkp
servidor=server
usuario=user
pastaRemota=/backups
# gera o backup
backupGerado=$(dpbackupAgendamento $arqConfig)

# tranfere para servidor remoto
scp -p $backupGerado $usuario@$servidor:$pastaRemota

exit 0
[/as]

É importante observar é que o comando scp faz a transferência do arquivo de forma segura por SSH. Para que ele não solicite a senha durante a transferência é preciso que previamente você gere um par de chaves com o ssh-keygen e exporte-a para o servidor. Veja como fazer isso em http://freebsd.ag.com.br/sessao10_7.html

Por fim registre o agendamento no cron. Digite “crontab -e ” e adicione as linhas abaixo:

[as]

# agendamentoBackup
0 13 * * * agendamento.sh

[/as]

Pronto, seu backup será feito todos os dias às 13h00.

Sobre Isso é um espaço que disponibilizo com o objetivo de compartilhar vários assuntos do dia-a-dia de cada um de nós que está de alguma forma ligado à tecnologia. Especialmente na área de programação, falaremos sobre a plataforma Java e eventualmente outras linguagens, sempre que oportuno.

Falarei também de Linux, tentando trazer dicas que poderão facilitar a vida daqueles que por opção ou não, migraram para o mundo do Pinguim.

Outros temas que me parecerem interessantes também serão compartilhados sempre que pertinentes.

até mais.

Paulo Cordeiro