DEV Community: itexto

Dicas de Grails #2 - acessando o contexto do Spring

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 13:08:16 +0000

Todo projeto Grails na realidade é uma aplicação Spring MVC (mais precisamente, Spring Boot a partir do Grails 3.0). Há momentos nos quais é interessante obter acesso ao contexto do Spring (também conhecido como Application Context) para poder obter os beans que compõem nossa aplicação.

Mas quais seriam estes beans? Essencialmente seus controladores, classes de serviço, bibliotecas de tag ou mesmo aqueles que você possa vir a declarar no arquivo grails-app/conf/spring/resources.groovy (isto fica para uma próxima dica).

Em qualquer classe de domínio, controlador, serviço ou biblioteca de tags, para obter o contexto execute o código abaixo em seus métodos:

grailsApplication.mainContext

Sim, é só isto: o objeto grailsApplication é injetado em todos os artefatos acima mencionados e representa, como o próprio nome já diz, sua aplicação Grails em execução. A partir deste objeto é possível obter diversas informações sobre seu projeto, tais como a lista de classes de domínio, controladores, serviços, etc.

Aplicação rápida da dica

Um dos principais usos do contexto do Spring é validação de código de serviços através do Grails Console (o Grails também injeta um objeto grailsApplication nele!). O exemplo abaixo obtém um serviço e, na sequência, executa um método neste para validar seu funcionamento:

def servicoArquivos = grailsApplication.mainContext.getBean(ServicoArquivos.class)
servicoArquivos.executeMetodo()

Conhece o Grails Console?

Se não conhece o Grails Console, segue uma dica brinde: executando o comando "grails console" em seu projeto. Será iniciada uma aplicação desktop na qual você pode executar código Groovy que tem acesso a todas as suas classes de domínio, serviço, controladores, etc.

Dicas de Grails #1 - como executar código SQL

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 13:04:12 +0000

A partir de agora iremos publicar dicas rápidas de desenvolvimento aqui no site da itexto: então vamos estreiar com uma nova série, Dicas de Grails, na qual iremos expor alguns usos pouco conhecidos do framework. E a dica de hoje é: como executar código SQL de forma segura.

Rápido background: conheça o Hibernate

Se você usa Grails sabe que por padrão o Hibernate é usado como mecanismo de persistência do framework através do GORM. Então, por que não tirar proveito disto? Uma dica que costumo passar a todos os nossos clientes e alunos é: se deseja dominar o GORM, estude o Hibernate.

Este estudo nos possibilita ter um uso muito mais profundo e produtivo do GORM e, consequentemente, acaba evitando uma série de problemas que as pessoas enfrentam quando estão dando seus primeiros passos com o Grails. Quer ver um exemplo bacana? O acesso ao objeto DataSource.

Há dois caminhos para se executar código SQL: um perigoso e outro correto.

Primeiro caminho: o perigoso

Simplesmente injete o bean DataSource em sua classe de domínio, controlador, serviço ou biblioteca de tags, tal como o exemplo abaixo:

class LogicaService {
def dataSource

def metodoDeNegocio() {

def connection = dataSource.getConnection()

}
}

O objeto dataSource é uma implementação interface javax.sql.DataSource. Ele foi injetado pelo Spring como uma dependência ao seu objeto. Portanto você poderá usar aqui tanto a API JDBC padrão do Java ou, se preferir, o suporte do Groovy a bancos de dados relacionais.

(Por trás dos panos quem domina o Grails é o Spring (seu projeto Grails é uma aplicação Spring MVC por baixo dos panos, sabia?). Sendo assim, o conhecimento deste framework lhe trará uma produtividade ordens de magnitude maior ao desenvolver com Grails!)

Qual o problema com esta abordagem? Ao acessarmos o bean dataSource diretamente não há garantia de que a conexão obtida esteja dentro do mesmo contexto transacional que o restante do seu código. E aí as coisas podem se complicar. Use este caminho apenas se tiver muita certeza do que está fazendo.

Segundo caminho: o seguro e correto

Lembra no início do post quando falei que o conhecimento do Hibernate é muito importante? Usando o método withSession, injetado em todas as classes de domínio do Grails podemos ter acesso direto à sessão do Hibernate (JavaDoc). E na sessão há um método chamado doWork, criado justamente para os casos nos quais precisamos executar código SQL nativo.

Este método recebe como parâmetro um objeto que implemente a interface Work , que possuí um único método:

void execute(Connection connection)
      throws SQLException

Como ficaria seu código então? Primeiro uma versão com a cara do Java:

ClasseDeDominio.withSession {session -> // olha a sessão do Hibernate aqui!

session.doWork(
new org.hibernate.jdbc.Work() {
public void execute(Connection connection) throws SQLException {
// seu código SQL usando connection entra aqui
}
}
}

}

Ou, se preferir, pode simplesmente passar um objeto qualquer (ou mesmo um map) que contenha um método cuja assinatura seja equivalente à da interface Work ao método doWork.

PS:

Aos interessados, estamos finalizando (finalmente) a preparação para nossas novas turmas de Groovy e Grails em nosso projeto Formação itexto. Inscreva-se no site para saber mais novidades em breve!

Dicas de Spring #1 – simulando autenticação no Spring Security em testes automatizados

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:56:49 +0000

Estamos iniciando nossa série "Dicas de Spring". Neste primeiro post vamos ver como proceder para simular uma autenticação na escrita dos seus testes unitários ou de integração.

O primeiro passo é incluir a dependência spring-security-test em seu projeto. Se estiver usando Maven, basta incluir este código em seu arquivo pom.xml:

<dependency>
  <groupId>org.springframework.security</groupId>
  <artifactId>spring-security-test</artifactId>
  <version>substitua pelo mesmo número da versão do seu Spring Security!</version>
  <scope>test</scope>
 </dependency>

Gradle? Igualmente fácil, inclua a dependência no seu arquivo build.gradle tal como exposto a seguir:

testCompile "org.springframework.security:spring-security-test:[versão]"

Muita atenção para o escopo da dependência (apenas teste) e o número da versão, que sempre deve ser o mesmo que o da sua instalação do Spring Security.

Feito isto, simular um usuário autenticado é algo incrivelmente fácil: basta que você use a classe TestSecurityContextHolder que vêm na dependência spring-security-test (pacote org.springframework.security.test.context), tal como no exemplo abaixo:

TestSecurityContextHolder
     .getContext()
     .setAuthentication(new JwtUser(account, new ArrayList<GrantedAuthority>()));

A classe JwtUser é uma classe que inventamos e que implementa a interface Authentication do Spring Security que recebe como parâmetro uma lista de permissões e o objeto que representa o usuário autenticado.

E é simples assim. Não é muito difícil imaginar como podemos proceder para simular o mesmo efeito com Grails no plugin Spring Security Core, hein? Quem sabe não será nossa próxima Dica de Grails?

Dicas de Java #1 - muito cuidado com SimpleDateFormat e seu aspecto "lenient"!

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:54:04 +0000

Em Java (e Groovy) é muito comum validarmos uma data digitada usando a classe SimpleDateFormat escrevendo código muito parecido com o exposto a seguir:

String dataInvalida = "45/42/2017"; // mês 42???</code>
SimpleDateFormat formatoData = new 
SimpleDateFormat("dd/MM/yyyy");
try {
  Date dataParseada = formatoData.parse(dataInvalida);
// se parseou, data válida!
  } catch (ParseException ex) {
// data inválida! Não parseou
 }

Por mais estranho que possa parecer, a data acima será considerada válida por SimpleDateFormat. Isto se deve ao aspecto "lenient" de sua implementação: um atributo do tipo boolean cujo valor default é true.

Se está definido como verdadeiro, SimpleDateFormat irá executar eurísticas internas para descobrir qual a data a partir da loucura que você forneceu. No exemplo acima a data encontrada será 15/7/2020 (experimente com o código acima).

Como resolver então? Simples: chamando o método setLenient e passando para este o valor false, tal como no exemplo abaixo:

String dataInvalida = "45/42/2017"; // mês 42???
SimpleDateFormat formatoData = new SimpleDateFormat("dd/MM/yyyy");
formatoData.setLenient(false); // simples!
try {
Date dataParseada = formatoData.parse(dataInvalida);
// se parseou, data válida (de verdade)!
} catch (ParseException ex) {
// data inválida! Não parseou. Bobagem enviada.
}

Problema resolvido, e não, infelizmente você não descobriu um bug na classe SimpleDateFormat. :)

Dicas de WordPress #1 – Melhorando a segurança

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:46:53 +0000

Não uma, mas duas dicas rápidas que irão tornar mais segura a sua instalação do Wordpress.

Localização do arquivo wp-config.php

No arquivo wp-config.php ficam armazenadas as configurações essenciais do Wordpress, dentre as quais o modo como é realizada a conexão com o banco de dados. Por padrão este arquivo fica no diretório raiz da sua instalação do Wordpress, mas sabia que esta não é a única localização possível para este arquivo?

Ele também pode ficar no diretório pai que contém a sua instalação do Wordpress. Sendo assim, se sua instalação fica em /var/www/meu_site, você pode (e deve) armazena-lo em /var/www, tornado com isto muito mais difícil a obtenção deste arquivo através de algum ataque realizado ao seu servidor.

Por padrão o Wordpress sempre busca o arquivo primeiro no diretório de sua instalação e, não o encontrando, um diretório acima.

Prefixo no nome das tabelas

No momento em que o Wordpress é instalado, um dos campos a ser preenchido diz respeito ao prefixo a ser adotado no nome das tabelas.

Muitos acham que a principal razão para este prefixo é diferenciar as tabelas em um banco de dados compartilhado. É: também é pra isto, mas a razão principal é segurança. Se por algum acaso seu site vier a sofrer um ataque de sql injection, o atacante irá ter uma maior dificuldade em descobrir o nome das suas tabelas (lembre que o esquema de tabelas do Wordpress é público e muito difundido). Sendo assim, evite o prefixo padrão "wp_" sempre.

Receita - expondo seu localhost ao mundo com Ngrok

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:39:07 +0000

Em tempos de quarentena esta é uma receita bastante útil. Eis a situação: você desenvolve sua aplicação localmente e gostaria que outras pessoas a acessassem remotamente mas sem a necessidade de implantá-la em um servidor. Como fazer?

Esta receita tem dois ingredientes: Linux e Ngrok, mas você pode substituir o primeiro por Windows ou MacOS se preferir.

O que é o Ngrok?

Trata-se de um serviço gratuito (há limitações, mas para uma demonstração ou implementação de uma integração dá bem pro gasto) que permite ao desenvolvedor abrir um túnel que exporá serviços executados localmente em sua máquina para o mundo. Seu uso é bastante simples.

Inicie o serviço local em sua máquina.
Execute o Ngrok para expor a porta do serviço ao mundo. Será gerada uma URL que você deverá compartilhar com quem deseja acessar seu serviço.
Compartilhe a URL que será gerada para você.

Primeiro passo: instale em seu computador local

Acesse https://ngrok.com e crie uma conta no serviço. Opte pela opção gratuita e, na sequência, se autentique na plataforma. Baixe o cliente de acordo com seu sistema operacional (há versões pra Linux, Windows e MacOS).

O processo de instalação pode variar de acordo com seu sistema operacional. No caso do Linux é um arquivo zipado que você descompacta no diretório de sua preferência.

Descompactado no diretório de sua preferência, execute o comando que irá aparecer, na página de download do cliente Ngrok, tal como na imagem a seguir:

Segundo passo: execute o Ngrok e compartilhe o acesso

O Ngrok pode apresentar ao mundo os protocolos HTTP, HTTPS e TCP executados em sua máquina. Em nossa receita iremos apresentar apenas o protocolo HTTP. Se sua aplicação estiver executando na porta 8080, basta executar o comando a seguir:

./ngrok http 8080

Você verá uma saída similar à apresentada à imagem a seguir:

Tá vendo aquelas URLs de forwarding (notou que uma delas é inclusive HTTPS???)? Compartilhe com quem você quer que acesse seu serviço executado localmente e voilá: seu cliente pode ver o resultado em sua máquina sem a necessidade de um servidor.

Experimente também aquele endereço apresentado como "Web Interface", pode ser uma mão na roda.

Esta receita na versão gratuita do Ngrok manterá a URL gerada por até 8 horas, mas nas versões pagas do serviço este tempo pode ser esticado.

Modos de servir

Ngrok é muito útil não só quando você quer expor a alguém seu trabalho remotamente, mas também quando precisa implementar integrações. Já precisou, por exemplo, integrar com serviços como meios de pagamento que te mandam notificações por HTTP? Com Ngrok este trabalho fica muito mais fácil.

Também é muito útil quando você precisa resolver um bug com seu cliente ou QA e quer reproduzir a situação localmente para resolver o problema.

As deliciosas receitas da itexto

Recentemente começamos a divulgar nossas receitas ao grande público para compartilhar soluções rápidas para problemas comuns. Você pode aprender mais sobre nossa metodologia neste link.

Espero que esta lhes seja útil. Até a próxima!

Receitas - Usando SonarQube em seu projeto Java (Maven) ou JavaScript

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:37:08 +0000

Um hábito que recomendamos a todos os nossos clientes e adotamos em nosso dia a dia é a revisão de código. Esta prática sempre deve ser realizada por humanos, mas toda ajuda adicional é válida. E uma ferramenta que pode agregar bastante é o SonarQube.

Para quem não conhece, o SonarQube (também chamado de "Sonar" por muitos (eu, principalmente :) )) é uma poderosa ferramenta que realiza a análise estática de código fonte. Essencialmente o Sonar possui uma base de dados contendo diversos padrões em muitas linguagens de programação que detectam erros comuns de programação e até mesmo algumas falhas de segurança.

Mais que isto: Sonar deve ser visto também como uma ferramenta pedagógica, que ensina diversas boas práticas à sua equipe. Um caso no qual Sonar agrega bastante é justamente quando estamos aprendendo novas linguagens de programação.

Infelizmente nem todos sabem como configurar seus projetos para serem analisados pelo Sonar. Então segue aqui não uma, mas duas receitas para que você possa usar o Sonar tanto no seu back quanto no seu front-end.

Ingrediente principal: o SonarQube

É necessário que você tenha o Sonar (versão 7.1 ou posterior) em execução em algum lugar para poder prosseguir com estas receitas. Neste post não iremos lhe ensinar a instalá-lo ou usá-lo, mas aqui segue não um, mas dois caminhos possíveis para instalar o Sonar caso não tenha um servidor.

Usando Docker (o mais fácil) - siga este tutorial presente na imagem oficial do Sonar.

Modo tradicional (um pouco mais trabalhoso, mas nem tanto) - siga o que está descrito na documentação oficial neste link.

Mas não termina aí, você também precisará das seguintes informações:

Um usuário no Sonar que possa criar novos projetos (seu login e senha).
A URL de acesso ao seu servidor Sonar

Primeira receita - Java e Maven

Neste momento lhe ensinaremos a proceder com Maven por ser a opção mais popular entre desenvolvedores Java, mas não tenha dúvidas de que lhe mostraremos como proceder também com Gradle, no futuro.

Configuração por projeto

A beleza do Maven está no fato de ser baseado no conceito de convenções sobre configurações, ou seja, um conjunto de convenções são seguidas para que você não precise ficar gerenciando arquivos enormes: só é preciso alterar o que deve ser customizado. No caso do Sonar você só precisa incluir três linhas na tag <properties> do seu arquivo pom.xml. Quais são estas propriedades?

<properties>
   <!-- O endereço que leva à sua instalação do Sonar -->
   <sonar.host.url>http://localhost:9000</sonar.host.url>
   <!-- O login do seu usuário -->
   <sonar.login>admin</sonar.login>
   <!-- a senha de acesso deste usuário -->
   <sonar.password>suasenhasupersecreta</sonar.password>
</properties>

E como fazer daqui pra frente? Para que o Sonar realize sua análise, é necessário existir código compilado. Sendo assim basta executar o comando abaixo:

mvn compile sonar:sonar

Feito isto será criado um novo projeto em seu servidor Sonar, tal como na imagem a seguir. Aí é só seguir suas recomendações de melhoria e ver se algum bug foi detectado.

Configuração global

Sim, acredite: é só isto. Mas e se você não quiser ficar enviando sua senha por aí? E se tiver uma instalação do Sonar compartilhada por toda a sua equipe e quiser ter a configuração centralizada para que não precise ficar alterando seus projetos um a um? Tão fácil quanto! Basta alterar o arquivo settings.xml que estará no diretório conf da sua instalação do Maven. Vamos lá?

Na tag <pluginGroups> inclua o plugin do Sonar, tal como no exemplo a seguir:

<pluginGroups>
   <pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
</pluginGroups>

E você também deverá criar um profile padrão. Isto é fácil. Basta incluir texto similar ao apresentado a seguir na tag <profiles> do seu arquivo settings.xml.

<profiles>
  <profile>
    <id>sonar</id>
    <activation>
       <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <!-- as mesmas que você viu no pom.xml! -->
      <!-- O endereço que leva à sua instalação do Sonar -->
      <sonar.host.url>http://localhost:9000</sonar.host.url>
      <!-- O login do seu usuário -->
      <sonar.login>admin</sonar.login>
      <!-- a senha de acesso deste usuário -->
      <sonar.password>suasenha</sonar.password>
    </properties>
  </profile>
</profiles>

Segunda receita - JavaScript

Um ingrediente importante aqui será o NPM. O primeiro passo consistirá em instalar o sonar-scanner: este componente do Sonar é o responsável por realizar a análise estática do código fonte. A instalação é simples:

npm install -g sonar-scanner

No diretório raiz que contenha o código fonte do seu projeto você deverá agora criar um arquivo chamado sonar-project.properties. Em seu interior serão incluídas configurações no formato chave/valor tal como no exemplo a seguir:

# A identificação do projeto. Nome:versão
sonar.projectKey=nomeDoSeuProjeto:1.0.0
# O nome do projeto
sonar.projectName=Seu lindo projeto
# A partir de que diretório será lido o código fonte.
# Neste exemplo é a partir do mesmo diretório que
# o arquivo criado
sonar.sources=.
# Host do Sonar
sonar.host.url=http://localhost:9000
# Usuário - login
sonar.login=admin
# Senha de acesso
sonar.password=seuSegredoValioso!
# Qual diretório não deve estar na análise.
# Quer ver algo demorar? Inclua a pasta node_modules
# pra ser analisada também. :)
sonar.exclusions=/node_modules/

Notou que as mesmas propriedades que usamos no exemplo com Java se repetem aqui? Sim, elas são padronizadas, mas há algumas novas aqui. Preste atenção nos comentários que foram incluídos no exemplo acima.

Com o arquivo gerado e o sonar-scanner instalado, como você analisa seu projeto? Simples! Executando o coamando abaixo no mesmo diretório em que o arquivo sonar-project.properties se encontra.

sonar-scanner

Incrementando as receitas

Você deve ter notado que algumas das chaves de configuração foram usadas tanto no Maven quanto no JavaScript, certo? É por que são padronizadas. Caso queira ver a lista completa de configurações possíveis, acesse este link.

Naturalmente há outras maneiras de se obter os mesmos resultados, porém o objetivo destas receitas é apenas lhe mostrar um caminho rápido possível pra poder dar seus primeiros passos. Quer incrementar estas receitas? Nos conte suas experiências!

As Deliciosas Receitas da itexto

Resolvemos recentemente abrir nosso livro de receitas que contém soluções rápidas para os principais problemas enfrentados por profissionais de desenvolvimento de software. Há uma metodologia na criação deste livro de receitas, e você pode aprender a escrever o seu conosco lendo este post.

Esperamos que estas duas receitas rápidas lhe ajudem no dia a dia. Pode aguardar que mais receitas já estão a caminho, até lá!

Receita: usar o AWS S3 localmente para desenvolvimento

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:35:16 +0000

O serviço S3 da AWS é uma das melhores, mais baratas e mais populares soluções para armazenamento de arquivos na nuvem. Mas e se em desenvolvimento você precisar trabalhar offline ou, melhor ainda, quiser reduzir o seu custo mensal com a AWS enquanto estiver programando? Esta receita resolve estes problemas.

Ingredientes desta receita

Docker
S3 Ninja - estamos usando aqui seu último release que é o 6.4
Java - mas pode ser substituído pela linguagem de sua preferência
SDK da AWS para o Java - usamos a versão 2.11.2 - mas você pode fazer adaptações fáceis para seu ambiente caso não seja o Java
Linux - mas pode ser substituído por Windows ou MacOS

Ingrediente principal: S3 Ninja

O S3 Ninja implementa as APIs de manutenção de objetos ("arquivos") providas pelo S3, sendo assim você conseguirá facilmente simular nele operações de obtenção, escrita e remoção de objetos.

Atenção: observe que não há aqui suporte para a manutenção de buckets. Para que seu ambiente de desenvolvimento esteja completo será necessário que estes buckets já existam no S3 Ninja. Há duas maneiras de se fazer isto: a primeira é usando a interface web que a ferramenta promove, manualmente, por tanto.

A segunda forma é usando Docker, que é bem melhor e já automatiza esta tarefa pra você, evitando com isto o trabalho manual. Vou te ensinar como fazer isto, é bem simples.

Não envenene seus convidados

Apesar do S3 Ninja funcionar tal como quem emula ele não passa de um mock, e um mock muito limitado. Você só consegue interagir com objetos aqui.

S3 Ninja não é escalável, não não é seguro, não é robusto. É apenas o que se propõe ser: um mock para que você consiga simular o S3 no seu ambiente de desenvolvimento ou testes automatizados. Não use em produção e não conte com ele como um componente de alta qualidade.

Primeiro passo: instalando o S3 Ninja

Eis algo que era muito mais fácil de ser feito no passado, então preste muita atenção a este ponto.

A instalação do S3 Ninja hoje se dá a partir do Docker. Se você clicar no link "Download" do site oficial do projeto, será inclusive direcionado para o Docker Hub.

Infelizmente se você tentar executar a imagem provida no link de download acima mencionado talvez não consiga, tal como pode ser visto no print a seguir:

Por quê? Por quê?? Por quê??? Simples: por que no momento da escrita desta receita não existia uma imagem com a versão "latest". Durante a escrita deste post a última versão era a 6.4. Sendo assim, se você executasse o comando abaixo, funcionaria.

docker pull scireum/s3-ninja:6.4

Mas não basta isto: você também irá querer iniciar o S3 Ninja com todos os buckets já criados, certo? Infelizmente na documentação você não encontrará nada lhe ensinando a fazer isto. Então resolvi te poupar tempo aqui. Segue um arquivo Dockerfile customizado. Modifique as instruções "mkdir" para criar todos os buckets que você precisa.

FROM scireum/s3-ninja:6.4
USER sirius

# Inclua todos os buckets que precisa no comando a seguir

CMD mkdir -p /home/sirius/data/seu_primeiro_bucket && \
    mkdir -p /home/sirius/data/seu_segundo_bucket && \
    /home/sirius/run.sh

# O terceiro ponto irá iniciar o processo do S3 Ninja

Caso não saiba o que fazer com este arquivo Dockerfile, crie um arquivo com este nome em um diretório qualquer em seu computador e, neste diretório, execute o seguinte comando:

docker build --tag=s3ninja-itexto:latest .

Isto irá criar uma imagem chamada s3ninja-itexto. O próximo passo consiste em executar seu container. Caso não saiba como fazê-lo, segue um exemplo:

docker run -p 9444:9000 s3ninja-itexto:latest

Voilá: note que estamos direcionando a saída da porta 9000 (do container) para a 9444 do host. Para testar sua instalação abra seu browser e acesse este endereço: http://localhost:9444/ui . Você verá uma página similar à exposta a seguir:

Observe que o Access Key e Secret Key são criados por padrão e apresentados no painel esquerdo desta interface. Guarde esta informação.

Por esta interface você pode criar novos buckets, incluir arquivos em seu interior e verificar quais endpoints da API do S3 estão implementados no S3 Ninja. Pode ser muito útil!

Quer os arquivos de referência? Criei um repositório no Github contendo inclusive um arquivo do Docker Compose pra você. Basta clicar neste link.

Aplicando em seu código fonte

Aplicável a qualquer ambiente de desenvolvimento

Você precisará de três informações apenas:

Access Key e Secret Key - você o obtém na página pública do S3 Ninja - http://localhost:9444/ui . Boa notícia: estas informações não mudam, então você pode aplicá-las em sua configuração de dev/teste. (não falei que não era seguro o S3 Ninja???)
Endpoint de requisições - a AWS fornece endpoints padrão de requisições para o S3, mas também a possibilidade de você poder usar endpoints alternativos justamente pra situações muito específicas como esta. O endpoint do S3 Ninja contra o qual todas as requisições deverão ser feitas é o http://localhost:9444/s3

O S3 Ninja vai ignorar qualquer região da AWS e também não vai aplicar ACLs tal como o serviço original, leve isto em consideração. Consulte sua ferramenta de desenvolvimento para que possa realizar esta integração.

Exemplo em Java

Se você não programa em Java, leia mesmo assim pois há um detalhe importante ali.

Tudo o que você precisará fazer é customizar o cliente S3 provido pelo SDK provido pela AWS. Em nosso exemplo iremos usar a versão 2.11.2 desta biblioteca. Leve em consideração que esperamos que você já saiba usar esta biblioteca. Vamos expor aqui apenas como usar junto com o S3 Ninja.

Veja o exemplo a seguir escrito em Java no qual instanciamos o cliente S3 usando o SDK da AWS.

import software.amazon.awssdk.auth.credentials.AwsBasicCredentials;
import software.amazon.awssdk.auth.credentials.StaticCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.S3Configuration;


// observe o exemplo com atenção. Se houver a configuração
// do endpoint, é por que estamos usando o S3 Ninja
// claro: pode haver variações, isto é apenas
// um exemplo!

public S3Client getS3Client() {
  String url = "http://localhost:9444/s3");
  S3Client result = S3Client.builder()
               .region(qualquerUma)
               .credentialsProvider(oQueSeAplica)
                // A mágica acontece aqui
               .endpointOverride(URI.create(endpoint))
            // O detalhe da maldade
             serviceConfiguration(
              S3Configuration.builder()
               .chunkedEncodingEnabled(false).build()
               )
               .build();
  return result;
}

O primeiro detalhe é o uso do endpoint customizado. A maldade está no detalhe: a opção "Chunked Encoding". Fizemos isto por que em versões mais antigas do S3 Ninja esta funcionalidade não estava implementada. Sua função consiste em validar o conteúdo recebido pelo S3.

As Deliciosas Receitas da itexto

Esta é mais uma receita do nosso livro que estamos tornando pública. O objetivo é te dar um pontapé inicial para resolver problemas comuns em seu dia a dia no desenvolvimento de software. Claro que há outras alternativas e modos de se resolver o mesmo problema (até melhores!). Caso tenha alguma sugestão, por favor, compartilhe conosco!

Quer escrever seu próprio livro de receitas? Mostramos para você como criamos o nosso e lhe trazemos diversas dicas neste post para te ajudar neste processo. Leia mais clicando aqui!

Tomara que esta receita torne seu dia a dia um pouco melhor. Até a próxima!

Receitas - comandos úteis de rede para devs!

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:32:36 +0000

Se você escreve aplicações web ou precisa interagir com serviços remotos com certeza já passou por alguns dos problemas que vamos mostrar a solução aqui. Usaremos apenas duas ferramentas: os comandos telnet e netstat.

E não daremos apenas uma receita, mas algumas!

Ingredientes

Sistema operacional - usaremos o Linux como exemplo, mas pode substituir por Windows ou MacOS
netstat - nosso canivente suisso, disponível também pra Windows e MacOS
telnet - cujo uso nós vamos subverter aqui. Se estiver usando Windows, uma implementação muito fácil de ser usada é o putty.

Se você usa Linux é quase certo que o comando telnet já está instalado, assim como o netstat. Caso não esteja, consulte a documentação da sua distribuição para aprender como proceder.

No caso do MacOS o netstat já vêm como padrão, mas não o telnet. Aprenda a instalá-lo neste link.

Usaremos o Linux como base e em algumas receitas usamos o comando | (pipe) usado para direcionar a saída de um comando para que seja a entrada de outro. Se não conhece este recurso, leia este texto (seção 12.5) antes.

As receitas do dia

Use o telnet para verificar se um serviço de rede é acessível a partir da sua máquina

O telnet é um protocolo de rede que te permite se conectar a outros serviços usando o modo texto no formato pergunta/resposta. Essencialmente você envia comandos, a outra ponta os recebe e te responde na sequência. Como boa parte dos protocolos da internet estão neste formato, você pode usá-lo para interagir com boa parte destes serviços.

Mas você também pode subverter seu uso se quiser apenas verificar se um serviço está online. Imagine que você queira verificar se sua máquina é capaz de acessar um servidor MySQL, por exemplo, cuja porta de comunicação é a 3306 e nesta máquina local não exista um cliente MySQL. Como você faz? Simples: use o modo "raw" do telnet com a sintaxe abaixo:

telnet [endereço/IP] [porta]

Vamos a um exemplo: quero ver se o MySQL está executando em minha máquina. Executo então o comando "telnet localhost 3306". Olha o resultado no meu console:

O MySQL usa um protocolo binário, por isto esta resposta com caracteres estranhos. Se você ver esta resposta é sinal de que o serviço é acessível. Se eu quiser acessar um serviço que não está acessível, veja como seria a saída: no caso, supondo que a porta 1234 estivesse aberta no Google.

E você nunca terá uma resposta pois nada está escutando nesta porta (1234) no endereço google.com. Digite Ctrl-C para terminar a conexão. Você também pode obter uma resposta similar à exposta a seguir:

Verificar quais as portas ativas no seu computador com netstat

Já tentou subir um servidor na sua máquina e topou com mensagens de erro dizendo que a porta já está em uso? Esta receita com netstat te mostra como. Basta executar um comando:

netstat -tnlp

Você terá uma saída similar a esta:

Descobrir qual processo está usando uma porta com netstat

E agora vamos resolver aquele problema do "não foi possível iniciar seu servidor por que a porta está em uso"? Precisamos saber qual o processo. Imagine que nosso desejo seja saber que processo está usando a porta 8080. Como fazer isto?

netstat -tulpn | grep 8080

Ali ela ó!

Ao final da linha você vê o código do processo e qual programa está executando a porta.

O que quer dizer este "-tunlp"?

t - lista apenas as conexões TCP
n - mostra os endereços no formato numérico
l - lista apenas os sockets que estão esperando conexões
p - expõe o nome do processo e seu identificador
u - expõe as conexões UDP caso deseje também

Como saber quantas conexões estão ativas em uma porta com netstat

A receita final: você quer saber quantas conexões estão ocorrendo contra uma porta em seu servidor. Vamos ao comando mágico usando como exemplo a porta 443?

netstat -anp | grep :443 | wc -l

O parâmetro -a representa conexões ativas. Na sequência filtramos todas as conexões na porta 443 e, finalmente, o filtro final, usando o comando "wc -l" do Linux, que nos retorna o número de linhas da saída.

Quer ver um exemplo?

Ali: 33 conexões ativas usando a porta 443 deste servidor. Esta receita é muito útil quando você precisa, por exemplo, verificar se há conexões com o banco de dados, se estão acessando seu site, etc.

As deliciosas receitas da itexto

Estas receitas tem como objetivo te dar um pontapé inicial para que possa resolver rapidamente seus problemas mais comuns. Naturalmente há muitas outras soluções para estes mesmos problemas e estas não são as melhores soluções. Tem sugestões? Mande pra nós!

Esta receita faz parte do Livro de Receitas da itexto que abrimos recentemente para todos. Toda semana publicamos ao menos duas de nossas receitas aqui. Acreditamos que o Livro de Receitas seja uma importante ferramenta para aumentar a produtividade da sua equipe. Quer aprender a escrever o seu? Te contamos como fazer neste post, clique aqui!

Até as próximas receitas!

Testes integrados com Arquillian e Java

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:21:53 +0000

As Ferramentas da itexto

Este post inicia uma nova série de posts aqui em nosso blog: "As Ferramentas da itexto", na qual iremos esporadicamente apresentar aqui ferramentas que podem fazer toda a diferença no dia a dia do desenvolvedor e que muitas vezes são ignoradas pelo público.

Todas as ferramentas aqui listadas são usadas em nosso dia a dia: sendo assim podemos contar a vocês as principais vantagens e, principalmente, desvantagens de cada uma delas.

Naturalmente estes posts irão gerar mais receitas para que vocês possam tirar máximo proveito das mesmas. Sendo assim vamos lá!

O problema: testar aplicações Java EE ou Servlet based - especialmente projetos pré-existentes

Se você desenvolve aplicações Java que são implantadas em servidores de aplicação ou servlet containers você tem um problema: como realizar seus testes de integração de uma forma que seja o mais próxima possível do ambiente no qual seu projeto será executado?

A solução mais comum consiste na implementação de mocks ou tirando máximo proveito das ferramentas oferecidas pelo seu framework (o Spring, por exemplo, oferece um suporte a testes que é muito rico). Outra alternativa interessante é o uso de bibliotecas como Mockito.

O problema das duas soluções é que elas se aproximam do ambiente no qual a aplicação será executada, mas não são este ambiente. Não raro em diversas aplicações o servidor de aplicações contém uma série de configurações que influenciam na execução do projeto:

Datasources configurados por JNDI.
Filas JMS.
Bibliotecas compartilhadas.
A configuração dos próprios.
Mecanismos de autenticação configurados por JAAS.
Configuração de clusters
E todos os recursos que seu servidor de aplicações pode oferecer.
Bundles no caso de containers OSGi.

Pra complicar um pouco mais a vida, talvez você tenha um produto que precise ser implantado em diferentes servidores de aplicação e containers e precise validar todas estas variações. Mocks ajudam, mas não testam a coisa em si ainda. Aliás, olha que interessante o que tá escrito no site oficial do Arquillian:

Projetos legados

Talvez você tenha pego um projeto pré-existente para evoluir. Não são raros os casos nos quais a execução encontra-se intrinsecamente dependente do servidor de aplicações nos quais o projeto é executado. Pra estes casos Arquillian é uma solução bem interessante a ser levada em consideração.

O Arquillian

Uma solução para os problemas que mencionei acima é o Arquillian: um projeto inicialmente desenvolvido pela JBoss (agora Red Hat). No site do projeto deixam bem claro seu objetivo: escrever testes integrados. E é exatamente isto que ele consegue fazer.

No caso do Arquillian os testes integrados necessariamente envolvem o carregamento do servidor de aplicações (daqui pra frente quando usar o termo servidor de aplicações entenda que ele embarca também servlet containers). Ele automatiza a execução dos seus testes usando toda (ou quase) a infraestrutura do servidor que executará seu projeto:

Os mesmos datasources.
As filas pré-configuradas.
Usará as mesmas bibliotecas compartilhadas.
Se quiser, pode executar inclusive a mesma versão da JVM.
Enfim: o mesmo ambiente.

O Arquillian cuidará das seguintes ações para você:

Inicialização e finalização do servidor de aplicações.
Inicialização dos frameworks necessários.
Enriquecer os testes permitindo a injeção de beans nos mesmos.
Execução do seu código como cliente (excelente pra testar endpoints JAX-RS, por exemplo)

Sua execução é bastante simples e pode ser resumida nos passos a seguir:

Inicie o container.
Empacote o código que será testado e, na sequência, implante-o no container.
Injete o que for necessário nos testes (os beans) e execute-os.

Pra melhor entender o Arquillian você precisa de alguns conceitos.

Conceitos essenciais

O conceito fundamental do Arquillian é que você escreva seus testes contra o ambiente no qual a aplicação é executada, ou seja, com a aplicação já implantada no container.

Sendo assim o que o Arquillian faz essencialmente é empacotar nosso projeto, implantá-lo neste servidor e, na sequência, executar nossos testes contra este ambiente.

ShrinkWrap

Este é o processo de empacotamento do nosso código. Um dos componentes do Arquillian é o ShrinkWrap, que é o módulo responsável por gerar o pacote que contém o código a ser verificado e o implanta no servidor. Todos os formatos padrão do Java EE são suportados: WAR, EAR e JAR.

O ShrinkWrap é muito rápido: a velocidade na geração deste pacote chega a ser surpreendente. Em nossos testes com sistemas legados costumamos gerar o pacote completo (todas as libs, classes, recursos) para os testes integrados e este processo não costuma levar mais que alguns (realmente alguns) segundos.

No entanto ele não é feito para que você crie um pacote completo, mas sim um que contenha apenas o que realmente é necessário para a execução dos seus testes. É possível gerar um pacote JAR, por exemplo, contendo um único bean (um único arquivo).

Container

Consiste no servidor de aplicações ou Servlet Container responsável por executar nossa aplicação. Por padrão o Arquillian não virá com um container pré-definido (ele não tem). Você terá de incluir o container necessário como uma dependência de testes em seu projeto.

Esta "dependência" tem um nome: "container adapter". Você pode ver a lista completa de adaptadores neste link: mas já adiantando, há adaptadores para o Tomcat, Jetty, Websphere, Wildfly, Weblogic, JBoss, Glassfish e mais alguns outros.

O container no Arquillian se divide em três categorias:

Embarcado.
Gerenciado (managed).
Remoto.

Quando embarcado, o container será iniciado na mesma JVM que nossos testes. É o ideal para ambientes de integração contínua.

O gerenciado requer que a distribuição do container esteja no mesmo computador que o nosso código fonte. Será criado um novo processo para a JVM que será responsável por iniciar o container, implantar nosso código e, finalmente, executar nossos testes.

Externo ou remoto implica no container em execução em outra máquina (ou na mesma máquina, porém em um processo diferente). Todo o acesso a este container será feito a partir de chamadas de rede.

A diferença entre o gerenciado e o externo é sutil: o gerenciado é aquele que pode ser iniciado ou finalizado pelo nosso código de teste.

Executor

O Arquillian não é dependente de um framework de teste específico. Atualmente oferece suporte a JUnit e TestNG. Sendo assim você mantém todo o seu conhecimento na escrita dos seus testes usando seu framework favorito.

Requisitos para usar o Arquillian

Ok, você agora tem uma ideia sobre o que o Arquillian pode fazer e quais problemas ele resolve. Do que você precisa para adotá-lo em seus projetos?

Ferramenta de build

O Arquillian pode ser usado com qualquer ferramenta de build que tenha gestão de dependências. A documentação oficial está focada em Maven, mas você pode usar o Gradle também se quiser.

Se você estiver na situação em que precise testar sua aplicação contra diferentes containers, recomendo uma ferramenta de build que possua o recurso de perfis (profiles), tal como o Maven. Isto lhe permitirá carregar as dependências necessárias para cada situação de acordo com a configuração desejada.

JDK

Há suporte para a versão 1.6 ou posterior do Java. Lembra quando disse que é uma ferramenta excelente para se aplicar a sistemas legados? Na página de módulos do Arquillian que lista os container adapters você verá alguns containers bem antigos (Tomcat 5, por exemplo).

Framework de testes

Tal como mencionado acima, você pode usar tanto JUnit quanto TestNG.

O Container a ser gerenciado

Finalmente, você precisará ter acesso ao container que será o responsável pela execução dos seus testes. Caso não tenha acesso ao container em si, verifique as opções de container embarcados disponíveis no site oficial do projeto neste link.

Vantagens e desvantagens

Será que o Arquillian se aplica ao seu projeto? É importante primeiro entender a natureza do mesmo.

Vantagens

A principal vantagem do Arquillian é o fato de termos nossos testes executados contra o ambiente real no qual o sistema será implantado. Isto permite à equipe compreender muito melhor as entranhas destes ambientes de execução.

Outra vantagem muito interessante é o fato de não haver mudanças significativas no seu fluxo de trabalho: você continuará usando sua IDE de preferência tal como faz hoje. É possível depurar seus testes tal como faz hoje: não muda coisa alguma, a não ser algumas anotações que você aprenderá em posts futuros.

A velocidade na execução também é surpreendente: a primeira coisa que você pensa ao ser apresentado ao Arquillian é que consiste em uma ferramenta lenta pelo trabalho que realiza. Não é o caso.

No caso de projetos legados baseados em Java eu diria que seu uso no primeiro momento pode ser essencial, dado que o tempo que você gastaria levantando mocks pode ser proibitivo. Especialmente em casos nos quais exista o uso pesado de JNDI para obter recursos do sistema, tal como datasources e fontes externas de autenticação baseada em JAAS.

Desvantagens

Servidores de aplicação e Servlet Containers pouco a pouco estão perdendo a relevância no desenvolvimento de novos projetos. Cada vez usa-se menos os recursos disponibilizados por estas ferramentas, tais como os datasources obtidos por JNDI, por exemplo.

Sendo assim, se for para pensar em adotar o Arquillian, deve-se ter a certeza de que seu projeto será aplicado neste tipo de ambiente. Sinceramente não vemos muito sentido em sua adoção em projetos que fujam deste perfil neste momento.

Outro fator a ser levado em consideração é o fato do projeto ter perdido o gás nos últimos anos. No momento da escrita deste post o último post em seu blog é de junho de 2018 (estamos em maio de 2020).

Isto não quer dizer que o projeto esteja morto, apenas que não é mais tão vibrante quanto antes. Os últimos commits até a escrita deste blog no módulo Core, do projeto, por exemplo, são de 20 de abril no GitHub.

Sua aplicação em projetos também pode ser um pouco mais trabalhosa que o esperado. Isto em parte se deve à própria documentação do Arquillian.

Para saber mais

Este é o nosso primeiro post sobre o Arquillian aqui no site da itexto. Em breve publicaremos também algumas receitas ensinando a aplicá-lo em seus projetos e a como executar tarefas importantes com ele. Esperamos que este conhecimento lhes seja útil.

Mas enquanto isto, você pode aprender mais sobre o projeto nestes links:

Site oficial - http://arquillian.org (notou que não é HTTPS?)
Os guias oficiais - siga do início ao fim para aprender direito seu uso - http://arquillian.org/guides/
A lista de módulos que contém extensões ao Arquillian e também a lista de container adapters - http://arquillian.org/modules/
A nova documentação oficial - http://arquillian.org/arquillian-core/

Até os próximos posts!

Como ter janelas em seu terminal usando tmux

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:19:04 +0000

Muitas vezes você lida com ambientes que possuem apenas uma interface de linha de comandos e precisa executar mais de uma ação ao mesmo tempo. Como resolver esta necessidade tendo uma única sessão/janela? Nesta receita apresentamos o tmux.

Esta receita lhe fornecerá o essencial para que possa dar os primeiros passos com esta super ferramenta de produtividade que não é tão conhecida como deveria por usuários Linux.

Ingredientes

Linux (mas você pode substituir pelo WSL no Windows ou mesmo pelo macOS).
tmux.
Habilidade e memória manual mínima.
Um pouco de paciência e persistência pois o primeiro contato pode não ser tão fácil assim.

Ingrediente principal: tmux

A melhor maneira de entender o problema é vendo-o em ação, sendo assim vamos a um caso real. Preciso iniciar dois processos, acompanhar seus logs de saída e editar um arquivo ao mesmo tempo. Consigo pensar em três soluções imediatas para o problema (há mais, a criatividade é infinita).

Abro três janelas no meu desktop:

Ou crio três abas na interface do meu terminal (também se estou em uma solução gráfica):

que é uma solução bem ruim, pois não vejo todos os logs ao mesmo tempo. Ou... uso tmux.

As vantagens são nítidas:

Não preciso de uma interface gráfica: o que é excelente quando vou lidar com servidores, por exemplo. Pense em você implantando a solução e acompanhando os logs ao mesmo tempo.
Tenho acesso a todas as informações que preciso ao mesmo tempo diante dos meus olhos.
Se estou em uma interface gráfica, são n janelas a menos com as quais preciso me preocupar.

Mas o tmux não é uma ferramenta que você irá dominar de imediato. Leva tempo e, principalmente, habilidade e memória manual, mas depois das dores iniciais ele é um forte candidato a aumentar exponencialmente sua produtividade no terminal. Então é importante ter três conceitos em mente.

Os conceitos

Tmux é um multiplexador de terminais (que termo "elegante"!), traduzindo: é um software capaz de a partir de uma única sessão do usuário com a interface de linha de comando, simular várias. Pense como o análogo ao conceito de multitarefa que temos em interfaces gráficas.

E por sessão, estou falando de sessão mesmo, ou seja, um único processo de autenticação no computador, exatamente como você faz quando inicia seu Windows, macOS ou Linux: você fornece seu login e senha e na sequência inicia vários programas ao mesmo tempo com estas mesmas credenciais. Se achou esta descrição muito ruim, tem esta na Wikipedia que talvez você prefira.

Para que eu tenha minhas "janelas" na linha de comando o tmux usa os conceitos de sessão (session), janela (window) e painel (pane). Nesta receita lidaremos mais com janelas e painéis para simplificar, mas sou obrigado a falar um pouco sobre sessões também.

A sessão é um conjunto de janelas (sério?). Pense nele como os desktops virtuais com os quais você já tenha experiência no ambiente gráfico do seu sistema operacional. É possível ter várias sessões ativas do tmux em paralelo inclusive, o que vai ser muito útil quando você tiver se empolgado e criado inúmeras janelas.

Já a janela é um agregador de painéis. Fica difícil descrever textualmente, sendo assim observe a imagem a seguir: cada retângulo é um painel independente, todos contidos em uma mesma janela.

Gravei minha interação entre janelas no tmux para que você possa ter uma ideia sobre o que estou falando. Note que parto de uma janela já com três painéis, crio uma nova e, na sequência, navego entre as diferentes janelas do sistema:

Acho que com base nisto já podemos colocar a mão na massa.

Instalando o tmux

Talvez você já o tenha instalado em seu computador. Sendo assim, para testar, execute o comando tmux em seu terminal e veja se já não está presente.

Se não estiver presente, na esmagadora maioria das distribuições Linux que usam o APT este é um pacote que já se encontra presente, você pode instalá-lo com o comando a seguir:

apt-get install tmux

Caso o comando acima não te atenda, neste link do site oficial do projeto há instruções que poderão resolver seu problema. Usa Windows, pelo WSL você consegue ter o mesmo resultado. MacOS? Não fique triste, há tutoriais sobre como executar a instalação neste e neste link.

Iniciando tmux e vendo as sessões

Iniciar o tmux é simples: te mostrei ali em cima, mas só pra recordar, vamos lá. No seu shell execute o comando a seguir:

tmux

O tmux por padrão estará criando uma nova sessão sempre que executar este comando, que é um sinônimo do comando tmux new.

Talvez acidentalmente você tenha fechado a janela do seu terminal e queria voltar para a sua sessão: o que você faz? Primeiro execute o comando a seguir para listar todas as sessões do tmux:

tmux ls

E uma saída similar à exposta a seguir será exposta:

Para entrar de novo na sessão que saiu, execute o comando a seguir:

tmux attach-session -t [identificador da sessão]
Exemplo indo para a sessão 5 acima listada:
tmux attach-session -t 5

Ok, até aqui nada de novo, agora vamos ao que interessa: panes e windows.

Entenda os comandos

Para que o tmux seja produtivo você deve ter muito bem gravado em sua mente o conceito de "comando" no tmux. Se já usou o Emacs este não será um problema, mas se não usou, vai doer um pouquinho no início. Um comando no tmux é uma sequência de teclas.

Esta sequência de teclas segue o seguinte padrão:

Ctrl + b [Comando]

Calma agora. Comando é qualquer outra tecla do seu teclado após o "Ctrl + b". E lembra quando disse que é importante ter habilidade e memória manual mínimas? Agora você vai entender.

Não é pra pressionar todas as teclas ao mesmo tempo. É um procedimento composto por dois passos:

Pressione Ctrl + b (minúsculo mesmo, nem precisa ficar com os dois pressionados o tempo todo, apenas digite na sequência)
Libere Ctrl + b
Pressione a tecla que representa o comando

Vamos a um exemplo: você já iniciou o tmux e quer dividir sua janela em dois painéis horizontais, tal como na imagem a seguir: o comando é Ctrl b "

Pressione Ctrl + B
Digite " (é, aspas duplas, eu sei que é chato no início)

Pronto, resultado obtido. Minha sugestão é que você pratique por um minuto pra poder ficar bom mesmo na coisa. Então segue a lista dos comandos que mais uso no tmux.

Comandos essenciais

Aqui seguem os comandos mais úteis para um uso simples do tmux.

Gestão de painéis (os que mais uso sem sombra de dúvidas):

Comando	Efeito
Ctrl b "	Cria uma novo painel horizontal
Ctrl b %	Cria um novo painel vertical
Ctrl b o	Navega entre os paineis no sentido horário
Ctrl b (seta)	Navega para o painel que está acima, abaixo, à esquerda ou à direita do atual
Ctrl b x	Mata o painel corrente
Ctrl b espaço	Muda o layout dos painéis. Você zoneou a sua janela e quer tentar salvá-la? Este é o comando.

Dica: scroll! Você muitas vezes precisará fazer scroll no conteúdo que um painel está expondo a você. É possível configurar o tmux para aceitar eventos de mouse, mas há uma solução mais simples usando apenas o teclado (convenhamos, o ideal aqui é usar só o teclado mesmo). Siga este procedimento:

Execute o comando Ctrl b [
Agora você pode navegar usando setas ou as teclas Page Up e Page Down
Para sair do modo scroll digite q

Gestão de janelas

Quando tiver se empolgado e criado uma infinidade de paineis você irá desejar criar o caos em outra janela. Sendo assim, segue uma pequena lista.

Ctrl b w	Lista as janelas abertas para que você possa navegar entre elas de um modo "quase gráfico"
Ctrl b c	Cria uma nova janela
Ctrl b [número]	O número representa o identificador da janela de 0 a 9. Serve para que você possa trocar de janelas de uma forma mais ágil (quando sabe o identificador da mesma)
Ctrl b n	Vai pra próxima janela
Ctrl b p	Vai pra janela anterior
Ctrl b &	Fecha a janela atual

Gestão de sessões

Depois de ter criado o caos entre suas janelas, você o transfere para as sessões. :)

Ctrl b s	Lista as sessões abertas e te permite navegar entre as sessões
Ctrl b (	Muda para a sessão anterior
Ctrl b )	Muda para a próxima sessão
Ctrl b d	Sai da sessão atual

Você pode encontrar diversos outros comandos do tmux neste link. São tantos que criaram até um site pra isto. O objetivo desta receita é apenas te dar o essencial para que possa dar seus primeiros passos por conta própria.

As deliciosas receitas da itexto

Esta é apenas mais uma receita da itexto. Nosso objetivo não é nestes posts lhe fornecer todo o aprofundamento para que domine um assunto, mas sim dar aquele pontapé inicial para que você possa dar seus primeiros passos neste.

É importante lembrar que o tmux não é a única solução para este problema: há diversas outras, como o GNU Screen ou Byobu. Talvez a grande vantagem do tmux seja sua popularidade, mas sem dúvidas não é a melhor solução. Até a próxima receita!

Não conhece as nossas receitas? Esta é uma metodologia que ensinamos a nossos clientes com o objetivo de facilitar a divulgação de conhecimento para o público interno ou externo, como neste post. Aprenda a ter seu livro de receitas neste link.

A linguagem de programação Groovy - Radar da itexto

Henrique Lobo Weissmann (Kico) — Wed, 16 Jun 2021 12:14:28 +0000

Este post inicia a série "Radar da itexto" na qual apresentamos à comunidade as tecnologias que usamos e recomendamos. Nosso objetivo é responder a questões essenciais que deveriam nortear a escolha de qualquer tecnologia: o que é? onde aplicar? tem passado e futuro?

O que é Groovy?

Uma linguagem de programação desenvolvida e pensada para a plataforma Java. Por "plataforma Java", entenda "executada pela e na JVM". Mas o que "mais esta linguagem" pra JVM trás pro jogo?

Ter como alicerces a JVM e a linguagem Java

Groovy convive muito bem com código Java pré-existente. Você pode executar código Java a partir do Groovy e vice-versa. Groovy, assim como Java, gera bytecode que é executado pela JVM de forma indiscriminada.

Mas mais do que isto: Groovy respeita a estrutura de tipos e modelo de execução adotado pela linguagem Java, o que torna esta integração no nível mais baixo da linguagem (bytecode) um processo totalmente transparente.

Como nota histórica, a linguagem aparece pela primeira vez em um post do blog de James Strachan (seu criador) em 2003: o objetivo era ter uma linguagem dinâmica na plataforma Java que surgisse tendo a JVM em seu centro, ao contrário das linguagens Jython e JRuby que, na época, não tinham atingido com pleno sucesso este objetivo.

Surge assim Groovy: "uma linguagem dinâmica para a plataforma Java", mas com um diferencial importantíssimo: sintaxe muito próxima à do Java, o que reduz significativamente a curva de aprendizado.

Uma linguagem dinâmica (mas só se você quiser)

É importante entender um dos principais fatores de venda do Groovy que é o fato desta ser "uma linguagem dinâmica". Groovy é muito influenciado por Ruby e Python que também são linguagens dinâmicas.

Em essência uma linguagem dinâmica permite que você modifique o comportamento do seu código em tempo de execução. Soa estranho em um primeiro momento: se você já colocou seu código em produção, pra que incluir novos comportamentos neste? Qual o sentido?

A primeira forma como encontramos o aspecto dinâmico de linguagens diz respeito à tipagem. Uma linguagem possui tipagem dinâmica quando descobrimos seu tipo (inteiro, texto, booleano...) em tempo de execução e não de compilação.

Há aqui um tradeoff entre desempenho e produtividade. Não raro do ponto de vista do desenvolvedor o tipo não é tão importante quanto parece. Pense em uma hierarquia de classes na qual precisemos da existência de um conjunto de comportamentos (métodos). Em uma linguagem estática criamos uma hierarquia ou estrutura de interfaces que identifiquem estes comportamentos. Em uma linguagem dinâmica só precisamos que o método exista: é o que chamamos de duck typing.

Mas nem só de tipagem dinâmica vivem estas linguagens: você também pode incluir novos métodos e atributos em classes existentes ou mesmo interceptar a invocação de métodos usando recursos nativos da linguagem ao invés de frameworks como Spring ou AspectJ.

No frigir dos ovos, entretanto, é importante salientar que estes recursos são usados mais por quem desenvolve código de infraestrutura (frameworks) que a esmagadora maioria dos desenvolvedores.

Um aspecto importante a ser levado em consideração no caso do Groovy é que os aspectos dinâmicos da linguagem são opcionais: se quiser, você pode desenvolver com tipagem estática sem problema algum e com isto obter algum ganho de desempenho (não é tão significativo assim).

Um "Java++"?

Observamos em nosso time e de diversos clientes que a adoção do Groovy pode aumentar significativamente a produtividade da equipe devido aos pontos que trataremos aqui.

Uma consequência interessante de estarmos lidando com uma linguagem dinâmica é que a equipe responsável pelo desenvolvimento do Groovy acabou evoluindo a própria API do Java.

Como podemos incluir novos métodos em classes já existentes, Groovy acabou por adicionar uma pletora de novas funcionalidades na API padrão do Java, aumentando significativamente a produtividade do desenvolvedor. É o que chamamos de GDK (Groovy Development Kit). Observe os métodos incluídos na classe String, por exemplo: inúmeras funcionalidades que você sempre quis mas precisava antes de outras bibliotecas encontram-se ali.

Mas os ganhos não estão apenas no enriquecimento das bibliotecas padrão: a sintaxe também possui diversas melhorias. Como mencionado, você pode dar seus primeiros passos na linguagem usando o que já conhece do Java, mas pouco a pouco ir experimentando novas features, tais como:

Sobrecarga de operadores.
Operadores para lidar com Collections, tais como "[]" para lidar com listas ao invés da classe java.util.List (e implementações) e "[:]" para lidar com mapas ao invés de java.util.Map (e implementações).
Interpolação de valores em strings.
Uma sintaxe que pode ser muito mais limpa por remover atributos que poderiam ser opcionais (";" ao final de cada comando quando há um único por linha, parênteses opcionais, expressão "return" opcional, método "main" opcional, e muitos outros).

E esta é uma lista bem pequena. Anos atrás (Windows Vista!) gravei um vídeo de quase uma hora só expondo estas funcionalidades que pode ser visto neste link: https://youtu.be/eEUKRhPoJAY

Com sua sintaxe menos burocrática e o enriquecimento da API padrão do Java, Groovy trás para o universo Java uma experiência muito próxima da que desenvolvedores Python e Ruby tem em seu dia a dia.

Indo além, acreditamos que temos aqui o que chamamos de "tecnologia ponte": Groovy fornece aos menos experientes uma introdução suave a conceitos e bibliotecas mais complexas do ecossistema Java (incluindo Java EE).

Construa suas próprias linguagens (DSLs) com Groovy

A sintaxe do Groovy unida aos seus aspectos dinâmicos e a inclusão de funcionalidades como builders e outros o tornam a ferramenta ideal para a construção de linguagens específicas de contexto (DSLs - Domain Specific Language).

Há alguns projetos de sucesso hoje que são essencialmente DSLs escritas com Groovy, sendo o mais famoso provavelmente o Gradle, seguido do Spock.

DSLs são uma poderosa estratégia: permitem à equipe de desenvolvimento focar na construção de uma plataforma essencial que é enriquecida pelos seus usuários finais, responsáveis por implementar em uma linguagem próxima ao seu contexto regras de negócio que lhes atendam no dia a dia.

Em nossa experiência já implementamos, por exemplo, linguagens específicas de contexto para os setores de engenharia, e-commerce, comunicações e outros. Caso queira ler mais sobre Groovy para a construção de linguagens específicas de contexto, leia este link de sua documentação oficial ou leia este livro.

Aplicações

Groovy é uma linguagem de uso geral: pode portanto ser usada, em teoria, para qualquer coisa, entretanto há usos para os quais esta se mostra uma alternativa interessante, e são estas que traremos aqui. Naturalmente há outras, entretanto estes são os usos que consideramos mais populares.

Um problema que a linguagem enfrenta é o fato de na maior parte das vezes ter seu nome vinculado ao do framework Grails, o que limita bastante a sua percepção pelo público.

Complementando o Java

Como linguagem embarcada

É possível embarcar Groovy em projetos Java de uma forma relativamente simples, o que possibilita a construção de plataformas que possam ser estendidas em tempo de execução por seus usuários através da inclusão, edição e remoção de scripts Groovy a serem executados por esta.

Em uma plataforma de vendas, por exemplo, é possível termos scripts que validem promoções em tempo de execução, podemos pensar também em fórmulas e cálculos definidos pelo usuário, algoritmos de processamento sinais e muitas outras funcionalidades cujo conhecimento está nas mãos dos usuários e não da equipe de desenvolvimento. Uma opção muito mais fácil de ser implantada que a adoção de motores de regras complexos como Drools, por exemplo.

A equipe de desenvolvimento passa portanto aqui a atuar como responsável pela evolução de uma plataforma a ser enriquecida por seus usuários finais, sem a necessidade de realizar complexos procedimentos de manutenção de código e implantação. Bateu aquela curiosidade pra saber como isto pode ser feito? Aqui segue um vídeo em que explico como proceder: https://youtu.be/_njSd-efuCo

Como ferramenta de automatização/integração com scripts

Código Groovy pode ser executado sob a forma de scripts. E dado que o acesso a código Java é direto, abrem-se aqui possibilidades de automatização bastante interessantes.

É possível, por exemplo, incluir suas bibliotecas de negócio (arquivos JAR) ou de infraestrutura (como frameworks de persistência ou biblitoecas utilitárias) no classpath dos seus scripts e executar nativamente as funcionalidades ali implementadas.

Um uso muito comum é a execução de tarefas agendadas de manutenção como, por exemplo, usando as regras de negócio distribuídas como arquivos JAR, invalidar registros, executar relatórios, etc através de agendamentos simples de sistema operacional (CRON).

Você pode, por exemplo, tirando proveito das melhorias introduzidas pelo GDK inclusive executar ações como raspagem de dados, implementação de crawlers, processamento em massa de dados e muitas outras atividades que normalmente são implementadas como scripts simples.

Como ferramenta de onboarding de novos membros na equipe

Uma das maiores dificuldades de equipes que precisam contratar profissionais Java é encontrá-los. Então por que não usar Groovy como uma ponte para desenvolvedores Python, Ruby ou JavaScript?

Esta é uma possibilidade real: muitas vezes profissionais habituados a estas linguagens possuem forte resistência ao ecossistema Java devido à linguagem (Java). Como Groovy apresenta uma sintaxe muito próxima do Python/Ruby, estes programadores tendem a sentirem-se mais confiáveis usando Groovy e, pouco a pouco, começam a se habituar ao ecossistema Java a partir desta ponte.

Desenvolvimento web

Desenvolvimento web com Groovy vai muito além do Grails (em breve um texto aqui sobre este assunto). Sou obrigado a citá-lo, mas é fundamental que você saiba que há várias outras alternativas que também são de altíssima produtividade:

Grails - de longe a opção mais popular da linguagem, sendo fortemente inspirado em Ruby on Rails - https://grails.org
Micronaut - desenvolvido pela equipe que desenvolveu o Grails, uma solução interessantíssima para o desenvolvimento de microserviços. - https://micronaut.io
Spring Boot - é possível com pouquíssimo código Groovy escrever microserviços com este framework, sabia?
Ratpack - uma opção extremamente produtiva para a escrita de aplicações web no estilo de microserviços - https://ratpack.io/
Groovy Servlets - quer um desenvolvimento mais raíz? Que tal implementar seus próprios servlets com o mínimo de código? Aprenda mais aqui.

Desenvolvimento desktop

Quem disse que o desenvolvimento desktop acabou? Groovy é uma opção muito interessante nesta área. Duas alternativas bastante interessantes:

Griffon

Pense no Griffon como se fosse um Grails/Ruby on Rails/Django para o desenvolvimento desktop. Os mesmos princípios de convenção sobre configuração e não se repita (DRY - Don't Repeat Yourself) se aplicam aqui.

Saiba mais neste link.

Swing Builder

Em sua biblioteca padrão Groovy trás um recurso muito interessante que é o Swing Builder. Com ele é possível desenvolver aplicações desktop na plataforma Java usando um ambiente que desenvolvedores JavaFX (especialmente em sua primeira versão) acharão bastante familiar ;)

Adoção e futuro

Uso no mercado

Por muitos anos Groovy foi a segunda linguagem mais popular na plataforma Java (atrás do próprio Java). Com a adoção do Kotlin no desenvolvimento Android a situação mudou e esta não é mais a realidade.

No índice TIOBE de novembro/2020, a linguagem quase chega ao TOP 10 global, encontrando-se na décima primeira posição, tal como pode ser visto neste link. Este crescimento vêm sendo observado pela mídia internacional nos últimos meses, tal como pode ser visto neste, neste e neste link.

Entretanto popularidade não deve ser levada em consideração na adoção de uma tecnologia, especialmente o índice TIOBE, que mede apenas menções a tecnologias na web (e fora do Brasil). Há muito hype que deve ser filtrado, o que realmente interessa são outras métricas em relação ao futuro do projeto:

Atividade do repositório: bastante ativa como pode ser vista no Github.
Frequência na liberação de releases: há pelo menos uns dois ou três por ano, tal como pode ser visto neste link.
Adoção em outros projetos: são realmente muitos, tais como pode ser visto neste (Awesome Opensource) e neste link (Github).
Comunidade - a comunidade Slack do Groovy é bastante ativa e há muita movimentação no StackOverflow também, como pode ser visto aqui. Entretanto é importante salientar que temos aqui comunidades difusas, dado que estas se distribuem entre os diferentes projetos que se baseiam na linguagem (Gradle, Grails, Jenkins, etc.).
Adoção pelo mercado e maturidade: Groovy surge em 2003, já tem 17 anos de idade e adoção nos mais variados cenários.
Livros publicados a respeito: há muito material publicado a respeito, o que pode ser verificado, por exemplo, no site da Amazon ou na documentação oficial da linguagem.

Portanto há desenvolvimento e também uma comunidade ativa que usa a linguagem em seu dia a dia, o que lhe confere relevância. Levando em consideração que temos um projeto open source, é seguro dizer que não desaparecerá tão cedo do nosso radar.

Recentemente saiu a versão 4.0 do Groovy, que trás uma série de melhorias e avanços, que podem ser vistos neste link. Entretanto, dado que seu uso mais popular ainda é o Grails, poderá levar um tempo até que este último release se popularize, dado que o último release do Grails (4.0.5) ainda usa a versão 2.5.6 da linguagem. Outro fator que impactará sua adoção é o fato de depender da versão 9 ou posterior do JDK, em um mundo no qual o Java 8 ainda domina, mas estes dois pontos são questão de tempo.

Dificuldades na adoção em equipes

Em nossa experiência encontramos alguns fatores que devem ser levados em consideração caso seu time opte pro adotar Groovy como linguagem de programação. É muito importante levar estes pontos em consideração caso esteja considerando adotar esta tecnologia.

Cuidado com o primeiro contato

A principal dificuldade na adoção do Groovy é o modo como profissionais tem o primeiro contato com a linguagem, normalmente a partir de um framework (Grails). Um comportamento muito similar que observamos com a linguagem Ruby em relação ao Ruby on Rails (e poderíamos também mencionar Python com Django).

Muitas vezes o desenvolvedor se limita ao que é apresentado pelo framework, acabando por não se aprofundar na linguagem e, com isto, usando apenas uma pequena parte do que esta tem a oferecer.

Vícios do Java

Groovy oferece uma sintaxe que é muito próxima à do Java. A vantagem desta abordagem é que a curva de aprendizado é realmente muito pequena para quem já conhece a linguagem, entretanto há um perigo aqui.

A escrita de código Groovy muito similar ao do Java deve ocorrer somente nos primeiros contatos com a linguagem. Com o passar do tempo a equipe deve ser incentivada a escrever código que seja o mais próximo possível do estilo Groovy para que possa tirar máximo proveito do que esta tem a oferecer e, também, evitar uma série de problemas difíceis de serem detectados se lermos código Groovy como se fosse Java.

Caso enfrente este problema, recomendamos que os dois textos a seguir sejam divulgados para o time:

Guia de estilo da linguagem - mostra os padrões adotados na escrita de código Groovy
Diferenças em relação ao Java

Dinamismo

O dinamismo da linguagem também pode ser considerado uma dificuldade por equipes habituadas a trabalhar com linguagens estáticas. Essencialmente vemos aqui estas equipes tendo o mesmo tipo de dificuldade com outras linguagens, tais como Ruby ou Python, o que talvez justifique, nos mesmos times, o sucesso de linguagens como TypeScript.

É muito importante que a equipe esteja consciente do significado de uma linguagem dinâmica para que possa tirar máximo proveito do que esta tem a oferecer, caso contrário há o risco real de comportamentos esperados da linguagem serem mal interpretados como defeitos e não como o que realmente são: funcionalidades.

Ferramental

Após tantos anos no mercado é natural que tenha surgido todo um ferramental que rodeia a linguagem. Seguem algumas ferramentas que consideramos essenciais para a adoção e aprendizado da tecnologia.

SDKMan

Hoje a principal ferramenta para se instalar o Groovy e qualquer outra ferramenta do ecossistema Java é o SDKMan, que nos permite gerenciar diferentes versões das principais ferramentas do ecossistema Java.

Maiores detalhes sobre o SDKMan podem ser obtidas em seu site oficial. Caso queira se aprofundar no assunto, recomendo que leia nosso guia do SDKMan.

IDEs e editores de texto

O fato de Groovy ser uma linguagem dinâmica torna o desenvolvimento de IDEs uma tarefa mais difícil se comparado às linguagens estáticas. Felizmente existem boas opções no mercado que podem ser adotadas:

Intellij IDEA - a melhor IDE para se trabalhar com Groovy e Grails.
Eclipse Groovy Development Tools - a instalação pode ser um pouco mais complicada, mas oferece o essencial para quem está habituado a trabalhar com Eclipse.
Visual Studio Code - apesar de não oferecer recursos avançados como "code complete", já possui plugins que permitem a refatoração de código e, ao que tudo indica, é questão de tempo até que alternativas melhores apareçam no editor.

É possível ter acesso a mais opções na documentação oficial da linguagem neste link, entretanto é importante ter em mente que as opções sempre são bem mais limitadas, devido à natureza da linguagem, que aquelas que temos com linguagens de tipagem estática como Java ou Kotlin.

Um ponto importante a ser levado em consideração é que na maior parte das vezes observamos que as equipes optam por não usar IDEs completas, mas sim editores de texto para escreverem seus sistemas com Groovy.

Para praticamente todos os editores do mercado existem plug-ins que possibilitam aplicar estilos e formatações a código Groovy, atendendo bem a este segmento. Dentre os editores os mais populares são:

REPL

Pelo fato da linguagem poder ser executada como scripts, esta oferece opções interessantes de interfaces REPL (Read Eval Process Loop), tal como o IRB do Ruby ou o interpretador do Python. Dentre estas, destacamos:

Groovy Web Console - que permite experimentar código Groovy na web sem a necessidade de tê-lo instalado localmente.
Groovy Console - interface desktop provida pela instalação padrão da linguagem (comando groovyConsole) que permite editar e executar pequenos scripts (inclusive depurá-los).

Ambas as ferramentas são bastante úteis no dia a dia em momentos nos quais é necessário avaliar possibilidades da linguagem e, principalmente, no aprendizado da mesma.

SonarQube

SonarQube é um analisador estático de código que possui suporte a Groovy. Recomendamos seu uso na adoção da linguagem por poder ser uma poderosa ferramenta pedagógica que ensina diversas boas práticas à equipe de desenvolvimento.

Para saber mais

O objetivo deste post é apresentar, do ponto de vista gerencial, uma tecnologia que pode agregar valor a seus projetos e que dominamos na itexto.

Caso deseje se aprofundar no assunto, segue uma pequena lista de recursos:

Site oficial do projeto Groovy - https://groovy-lang.org
Comunidade Groovy e Grails Brasil - mantida pela itexto - https://grailsbrasil.com.br
Greach - evento anual que ocorre na Espanha sobre desenvolvimento Groovy e Grails - https://www.greachconf.com/
Gr8 Conf - outro evento anual de desenvolvedores Groovy e Grails na Europa - http://gr8conf.eu/
Canais de suporte oficial a Grovoy - http://groovy-lang.org/support.html
Meu livro de Grails (trata de Grails 2.5, bem ultrapassado), que contém uma introdução à linguagem Groovy - https://www.casadocodigo.com.br/products/livro-grails
Meu canal no YouTube no qual há diversos vídeos sobre o assunto - https://youtube.com/kicolobo