Michael Schuenck

Ontem e hoje (16 e 17 de maio de 2017) estou ministrando um minicurso sobre DevOps e Git no Encoinfo 2017. Neste post, estou compartilhando alguns links importantes com os alunos e também com quem não pôde participar.

Slides do minicurso

Livro oficial de Git

Grupo DevOps Tocantins do Telegram

Grupo DevOps BR do Telegram

Tutorial de Git no Youtube

Parte 1

Introdução ao Git

O servidor de aplicações Wildfly (e JBoss, por tabela) permite que ele seja acessado por um ou mais IP's atribuídos à máquina em que ele está hospedado. Neste post são apresentadas algumas formas de se definir o IP do Wildfly.

Por exemplo, se a máquina possui os IP's 192.168.0.1 e 10.1.1.20, dependendo do que for configurado na inicialização do Wildfly, um cliente em outra máquina pode acessá-la usando um, os dois ou ainda nenhum dos IP's. Caso não seja especificado um endereço, ele só poderá ser acessado a partir da mesma máquina.

Definindo todos os IP's

Caso a máquina possua mais de um IP (a não ser que algo "obscuro" seja feito, isso significa que a máquina possui mais de uma interface de rede), pode-se atribuir todos eles ao Wildfly. Para isso, o comando é:

$WILDFLY_HOME/bin/standalone.sh -b=0.0.0.0

Definindo um IP específico

A forma de se definir um IP específico é a que segue, que é bastante lógica.

$WILDFLY_HOME/bin/standalone.sh -b=10.1.1.20

Definindo o IP de gerência

Com os comandos anteriores, definimos o endereço "público", geralmente usado pela porta 8080. Mas quanto à área de gerência, o acesso continua restrito à máquina local. Para permitir o acesso em outros IP's, usa-se o parâmetro -bmanagement. Os dois comandos abaixo apresentam algumas combinações.

Área "pública" acessível apenas localmente, mas área de gerência acessível por um IP específico:

$WILDFLY_HOME/bin/standalone.sh -bmanagement=10.1.1.20

Área "pública" acessível de quaisquer IP's da máquina e área de gerência acessível de um IP específico.

$WILDFLY_HOME/bin/standalone.sh -b=0.0.0.0 -bmanagement=10.1.1.20

Veja também como aplicar estas definições diretamente nos arquivos de configuração do Wildly, como em neste artigo da documentação do Wildfly.

Esse post é um lembrete para mim mesmo e uma dica para quem precisar.

Para permitir que JBoss e Wildfly recarreguem arquivos estáticos sem necessidade de reload do servidor de aplicação, basta seguir as instruções a seguir. Habilitar essas opções pode ser muito útil em modo de desenvolvimento, pois poupa muito tempo que seria gasto com reload das aplicações e dos servidores de aplicação.

JSP's

Para arquivos JSP, altere o arquivo ${jboss/wildfly-home}/standalone/configuration/standalone.xml substituindo

<jsp-config/>

por

<jsp-config development="true"/>

Depois disso, reinicie o servidor de aplicação.

HTML's e XHTML's

Da série "postar para recordar", esta utilidade é para quando precisamos utilizar, em um projeto Java com Maven, uma biblioteca que não está acessível a partir de algum repositório remoto disponível. A solução consiste em instalar o respectivo .jar no repositório da máquina local e, então, referenciá-lo no pom.xml.

mvn install:install-file -Dfile=jboss-client.jar -DgroupId=org.jboss -DartifactId=jboss-client -Dversion=9.0.2 -Dpackaging=jar

No comando acima, executado em um terminal, estou instalando uma biblioteca disponível na instalação do servidor de aplicações Wildfly (a versão "community" do JBoss), mas que não está disponível em nenhum repositório público. Depois de executado o comando, a biblioteca ficará disponível em ~/.m2/repository/org/jboss/jboss-client.

Desde 2012, à exceção de 2014, a Coordenadoria de Desenvolvimento de Sistemas do TRE-TO tem organizado o FORTES (Fórum de Tecnologias e Engenharia de Software), na cidade de Palmas-TO. Seu objetivo é compartilhar conhecimento com estudantes e profissionais sobre Tecnologia da Informação, e Desenvolvimento de Sistemas em especial. É uma iniciativa que começou de forma despretensiosa, mas devido à quantidade de participantes logo na primeira edição, acabou demonstrando sua importância e, com isso, acabou ganhando impulso para que continuasse ocorrendo.

Agora, estamos organizando mais uma edição, que ocorrerá nos dias 18 e 19 de agosto de 2015, à partir das 19h, e contará com seis palestras. Estamos colocando bastante esforços na definição das palestras, de forma que elas possam ser de máxima utilidade para os participantes. Pretendemos ter as palestras definidas até a próxima sexta-feira (07/08/2015).

Como nas edições anteriores, a taxa de inscrição será simbólica: apenas uma caixa de leite, que será doada a uma instituição de caridade.

Já conseguimos o apoio das Editoras Casa do Código e Packt Publishing, que doaram livros a serem sorteados durante o evento, além de que disponibilizarão códigos promocionais para se obter descontos na aquisição de livros.

No Unix (Mac OS ou Linux, por exemplo), existe o utilitário file, que mostra, para um arquivo, o seu tipo. Neste caso, o tipo pode ser algo como a extensão do arquivo, além de algumas informações adicionais. Para arquivos de texto, ele apresentará também a codificação (UTF-8, ISO-8859-1, etc). Este caso é bem útil para desenvolvedores, que frequentemente se deparam com códigos-fonte em codificações inadequadas.

Mas o utilitário file se aplica a apenas um arquivo, sendo que muitas vezes precisamos encontrar arquivos de um tipo específico, dentre inúmeros outros. Aí entra o comando abaixo, que combina o file com o find, o xargs e o grep.

find . -type f -print0 | xargs -0 file | grep UTF-8

Ontem e hoje (11 e 12 de dezembro de 2014) está acontecendo a conferência Groovy & Grails eXchange 2014, em Londres. As palestras estão sendo ministradas por grandes nomes da comunidade Groovy e Grails, tais como Guillaume LaForge (o líder do projeto Groovy), Graeme Rocher (cofundador e líder do Grails), além de outros membros da equipe do Grails, como Lari Hotari. Peter Ledbrook e Jeff Brown. E o melhor é que as palestras estão ficando disponíveis gratuitamente no site do evento à medida em que elas vão ocorrendo. O site do evento é o seguinte:

Talvez eu tenha conhecido a sigla MVP antes, mas foi ao ler o livro "A Startup Enxuta", de Eric Ries, que este termo mais me marcou (a propósito, fiz um resumo deste livro, que já teve mais de 6 mil visualizações, disponível aqui). MVP refere-se a Minimum Viable Product (Produto Mínimo Viável), que consiste de uma prática para liberação de versões usáveis o quanto antes, mesmo que sem compreender tudo o que fora inicialmente imaginado. Para que sejam úteis, estas versões precisam compreender as funcionalidades que atendem o núcleo do negócio ou da necessidade dos usuários*.

O livro "A Startup Enxuta" apresenta, dentre vários outros, o exemplo da sapataria online Zappos, que se iniciou em um site estático e com o fundador visitando sapatarias de sua cidade para tirar e postar as fotos dos sapatos. Com isto, ele conseguiu validar o que no livro é chamado "hipótese de valor", que a grosso modo é a viabilidade do negócio. Na prática, ele descobriu que os usuários estavam dispostos a comprar sapatos online. Como ele concentrou esforços no núcleo da ideia, sem investir em um supersite, ele minimizou a possibilidade de gastar muito. Atualmente a Zappos é a maior loja estadunidense online de sapatos, tendo sido comprada pela Amazon.

MVP's contrapõem àquele pensamento perfeccionista de que uma solução tecnológica precisa estar completa e bem acabada para que seja útil. Tais soluções bastam ser úteis para poderem ser lançadas. A pergunta não é "se estamos fazendo certo as coisas", mas "se estamos fazendo as coisas certas".

Podemos destacar algumas vantagens dos MVP's:

Permites concentrar esforços na necessidade real

Atendem mais rapidamente o que o cliente ou usuário realmente precisa

Evitam perder tempo e dinheiro com coisas inicialmente imaginadas, mas que na prática agregam pouco ou nenhum valor

Muitas vezes, as funcionalidades inicialmente imaginadas podem ser complexas de se construir e, para piorar, não raramente, são aquilo que carinhosamente chamamos "perfumaria", tal como efeitos visuais avançados. O MVP auxilia nestes casos pois, apesar de muitas vezes trazerem mais conforto para os usuários, tais funcionalidades podem nem ser necessárias. Talvez possam nem mesmo ser desejáveis na prática, pois um número maior de opções geralmente deixa os usuários mais confusos.

Em se tratando de empresas e, em especial as startups, os MVP's podem ser o diferencial entre o sucesso e a falência, uma vez que evitam o desperdício de recursos e, ao reduzir o time-to-market, também reduzem o tempo para se ganhar dinheiro e fazer o negócio se sustentar.

Já no caso do desenvolvimento de sistemas, o emprego de MVP's permite atender as demandas mais urgentes dos clientes e usuários mais rapidamente. Depois que uma versão é lançada e os usuários começam a utilizá-las, eles próprios podem dar feedback e sugestões sobre quais são as próximas demandas mais urgentes. Algumas metodologias de desenvolvimento de sistemas empregam o conceito de MVP's, ainda que não adotem o termo expressamente. É o caso de Getting Real, da mesma empresa que criou o framework Web Ruby on Rails.

Para concluir, ao falar de MVP, é natural se lembrar do Princípio de Paretto, que afirma que 80% das consequências são provenientes de 20% das causas. Podemos então deixar um desafio para quando utilizarmos o conceito de MVP: vamos construir os 20% das funcionalidades que atendam pelo menos 80% de sua utilidade.

Já escrevi vários posts sobre o framewok Grails, mas percebi que faltava falar do principal: por que uma equipe de desenvolvimento de sistemas se beneficiaria dele.

Pois bem, no TRE-TO, usamos Grails desde 2010, com a versão 1.1. Na época, tínhamos várias aplicações Java de terceiros, e tínhamos desenvolvido algumas poucas aplicações em Java. Na busca por produtividade, construímos sistemas com Struts, JSF, VRaptor, Maven e Hibernate. Com exceção de Struts, pessoalmente considero que todos são excelentes frameworks, mas como não havíamos padronizado a estrutura das aplicações, sofríamos com a manutenção. Chegamos a considerar utilizar outras linguagens e frameworks, como Python/Django e Ruby/Ruby on Rails, mas víamos estes como um recomeço na busca por produtividade, perderíamos o know-how com a JVM para a manutenção nos sistemas de terceiros e o pessoal da infra fazia vista grossa - com razão.

Estávamos (eu, Alysson Bruno, Eduardo Koelln e Josué Pires), então, em vias de criar um padrão de aplicações, com todas as peças montadas e organização definida, quando lembramos do Grails. A gente já tinha lido antes sobre ele, mas o reduzíamos a um clone do Ruby on Rails. Só que ao conhecer mais sobre ele, percebemos que ele atendia vários de nossos requisitos (produtividade e manutenibilidade acima dos demais) e resolvemos adotá-lo. Assim, como forma de motivar quem esteja em situação semelhate à nossa no passado, apresento a seguir, vários dos aspectos que nos fizeram escolher por ele.

Usa a linguagem Groovy

Groovy é uma linguagem dinâmica que, tal como as linguagens Java, Scala e Clojure, também executa sobre a JVM (Java Virtual Machine). Ela é um "açúcar sintático" para a linguagem Java, sendo bem mais prática. Ao mesmo tempo, Groovy se assemelha à irmã mais velha, o que facilita sua adoção. É comum que no início da sua utilização, um programador construa códigos bem parecidos com os de Java, mas à medida que ele vai conhecendo melhor sua sintaxe e APIs nativas, ficam nítidas suas vantagens.

Aproveita sua infra Java/JVM

Por Groovy ser uma linguagem que funciona sobre a JVM, aplicações Grails executam nos principais servidores de aplicação Java, incluindo Tomcat, JBoss, Glassfish, Jetty, entre outros. Inclusive, aplicações Grails podem ser empacotadas em arquivos .war como quaisquer outras aplicações Java.

Produtividade

Além da linguagem, outras características do próprio framework também tornam o Grails bastante atrativo.

Convenções ao invés de Configurações

O Grails requer o mínimo de configurações. XML então, raramente você irá precisar. Nele, são adotados vários padrões como, por exemplo, o casamento das URL's com os nomes de actions e controllers, que, por sua vez, casam com os nomes das classes de domínio (entidades do Hibernate). A utilização de convenções, além de reduzir o trabalho, também evita que cada desenvolvedor crie seu próprio "padrão", facilitando significativamente a manutenção das aplicações.

Geração de CRUD's

A partir das classes de domínio, é possível gerar CRUD's (Cadastro, Recuperação, Atualização e Exclusão) completos com o comando (de linha de comando) generate-all. Esta prática, além de agilizar cadastros mais simples, ainda facilita o aprendizado do Grails.

Validação a partir das classes de entidade (ou de domínio)

A validação de entrada de dados no lado do servidor aproveita as regras já definidas nas classes de domínio. Assim, elimina-se a redundância de se ter a implementação das regras de validação nas actions e a definição das mesmas regras nas classes que mapeiam o banco de dados.

Live Reloading

Tal como ocorre com Java, por ser compilada para bytecode, Groovy requer a compilação dos arquivos a cada mudança. No entanto, isto é feito de forma automática pelo Grails a cada vez que um arquivo é alterado e salvo. Ou seja, nada de ficar executando tarefas específicas para recompilação nem de ficar reiniciando o servidor de aplicação. Desta forma, tal como ocorre em linguagens interpretadas (PHP, Python, Ruby, JavaScript), consegue-se rapidez na visualização das alterações realizadas no código.

Adota frameworks consolidados

Por funcionar sobre a JVM, aplicações em Groovy podem utilizar bibliotecas Java naturalmente. E o Grails tira proveito disso, adotando frameworks Java consolidados e respeitados, como Hibernate, Spring, Maven, Ivy e Sitemesh.

Excelente Documentação

A documentação da versão mais recente do Grails pode sempre ser encontrada aqui: http://grails.org/doc/latest/. Você também pode acessar a documentação de uma versão específica informando-a no final da URL, como, por exemplo: http://grails.org/doc/2.3.11/.

A documentação do Grails é bem abrangente, bem exemplificada e bem organizada. Considero-a uma das melhores e mais fáceis de navegar dentre as dos principais frameworks Web. Ela pode não ser completa, mas sempre inclui os links de onde encontrar mais detalhes, como no caso de coisas específicas sobre Hibernate e Spring.

Considerações Finais

Linguagens funcionais são aquelas que consideram as funções como cidadãs de primeira classe. Isso significa que funções podem ser atribuídas a variáveis, passadas e recebidas como parâmetros. Isto permite maior flexibilidade para o desenvolvedor, o que é bastante perceptível no caso da manipulação de coleções. Também permite a redução de linhas de código, o que, como costumo dizer, melhora manutenibilidade dos sistemas. Programação funcional tem ganhado tanta força ultimamente, que até a linguagem Java, criticada pelo conservadorismo na sua evolução, apostou pesado nesta linha, ao permitir expressões lambda, na Java 8.

A primeira linguagem em que vi a utilização prática de operações funcionais foi JavaScript. Por exemplo, os callbacks de chamadas AJAX são funções passadas como parâmetros para a função. Depois, descobri e gostei muito de Scala e de suas capacidades funcionais. Agora, também tenho aproveitado e praticado, em Groovy, as noções de programação funcional que aprendi em JavaScript e Scala.

Em todas as linguagens citadas, é possível passar um código como parâmetro. A maior diferença é que aquilo que o pessoal de Groovy chama de closures, as demais chamam funções anônimas.

Alguns dos métodos que recebem closures em Groovy são os seguintes:

collect: transforma os itens de uma coleção.

find: retorna o primeiro item que atende a condição informada.

findAll: retorna todos os itens que atendem a condição informada.

any: retorna um Boolean indicando se algum dos itens atendem a condição informada.

every: retorna um Boolean indicando se todos os itens atendem a condição informada.

max: retorna o maior valor da coleção, considerando a regra informada para identificar, entre dois valores, qual é o maior.

min: semelhante ao anterior, mas retornando o menor.

sort: retorna a coleção ordenada. Recebe como parâmetro, uma closure com uma regra igual à do método max.

each: executa qualquer código para cada item da coleção.

eachWithIndex: semelhante ao anterior, mas podendo saber a posição do item na coleção.

inject: retorna o resultado de uma operação realizada entre todos os elementos, como uma soma entre todos eles, por exemplo.

Na Prática

A seguir, vou apresentar os métodos acima. Para o primeiro, collect, vou dar um exemplo de código mais tradicional e um utilizando o método. Para os demais, meus exemplos serão apenas dos métodos. Para usar métodos que recebem closures, eles precisam ser chamados com { } (chaves), podendo ou não receber outros parâmetros, que vão entre parênteses.

Transformação de Coleções

Quando temos uma coleção e precisamos transformar cada um de seus itens (por exemplo, se temos uma coleção de objetos e queremos ter uma coleção de mapas criados a partir daqueles objetos), a maneira mais comum de fazer isto é mais ou menos a seguinte:

// considere que "pessoas" é uma coleção de Pessoa, que tem os atribudos nome e idade def lista = [] for (Pessoa p : pessoas) { lista << [nome: p.nome, idade: p.idade] }

Mas temos o método collect, que recebe uma closure de transformação dos objetos da lista, permitindo o seguinte código:

pessoas.collect{ p -> [nome: p.nome, idade: p.idade] }

Neste caso, p refere-se a cada item da coleção. O p poderia ser suprimido, se utilizássemos o it, que é implícito:

pessoas.collect{ [nome: it.nome, idade: it.idade] }

Assim, tem-se um código ainda mais enxuto.

Encontrar itens na coleção

Para encontrar a primeira pessoa com idade maior que 18:

pessoas.find{ it.idade > 18 }

Para encontrar todas as pessoas com idade maior que 18:

pessoas.findAll{ it.idade > 18 }

Verificar se alguma pessoa tem idade maior que 18:

pessoas.any{ it.idade > 18 }

Para verificar se todas as pessoas têm idade maior que 18:

pessoas.every{ it.idade > 18 }

Para encontrar a pessoa com a maior idade:

pessoas.max{ it.idade }

O exemplo acima não recebe uma closure, mas o método max pode receber, o que é útil para casos que requerem uma lógica mais complexa de identificação de quem é maior. Por exemplo, pode-se precisar verificar quem tem o maior IMC (Índice de Massa Corporal), que é calculado com base em altura, peso e idade. O código abaixo ilustra o método max recebendo uma closure como parâmetro.

pessoas.max{ a, b -> a.nome.compareTo(b.nome) }

Algo importante a destacar é que, mesmo usando { ... } estas funções possuem retorno convencional, como aquelas que usam ( ... ). Assim, é possível acessar atributos e métodos dos objetos retornados normalmente, como neste exemplo:

pessoas.max{ it.idade }.nome

Ordenar os itens

Para ordenar os itens de uma coleção, passamos uma closure com o critério para definir, a cada dois elementos, quem é o maior, tal como no caso das funções min e max. O método sort retorna uma coleção de mesmo tamanho, com os itens ordenados.

pessoas.sort{ it.idade }

Realizar uma operação sobre os itens

Para realizar uma operação aleatória, tal como em um for, podemos utilizar o método each e eachWithIndex. Por exemplo, se quisermos adicionar o pronome de tratamento "Sr(a)." a todas as pessoas de uma coleção:

def pessoas2 = [] pessoas.each{ pessoas2 << "Sr(a). ${it.nome}" }

Lembrando que o exemplo acima, também poderia ser conseguido com o método collect, de forma mais sucinta... ;)

Se precisarmos ter acesso à posição do item na coleção, usamos o método eachWithIndex. No exemplo abaixo, imprimimos os nomes das pessoas, antecedidos por sua posição na coleção.

pessoas.eachWithIndex{ item, index -> println "${index + 1}- ${item.nome}" }

Podemos fazer uma operação cumulativa para os itens da coleção, com o método inject. No exemplo abaixo, calculamos a média das idades das pessoas.

pessoas.inject{ soma, item -> soma + item.idade } / pessoas.size()

Caso desejemos que seja considerada uma idade inicial de 30, podemos passá-la como parâmetro também:

pessoas.inject(30){ soma, item -> soma + item.idade } / pessoas.size()

E o valor que é acumulado não precisa ser apenas numérico. No exemplo abaixo, guardamos as idades em uma nova coleção.

def idades = pessoas.inject([]){ lista, item -> lista << item.idade }

Em sistemas de versionamento, tags são meios para marcar versões, como, por exemplo, as que estão disponíveis para a produção. Aqui vão alguns comandos básicos para trabalhar com tags no Git.

Para listar as tags disponíveis localmente:

$ git tag -l

Para listar as tags disponíveis nos remotes:

$ git ls-remote --tags

Para criar uma tag localmente:

$ git tag <nome_tag>

Para enviar uma tag para o remote origin (um servidor):

$ git push origin tag <nome_tag>

Para excluir uma tag localmente:

$ git tag -d <nome_tag>

Para excluir uma tag no remote origin: