Recentemente eu fiz uma atualização no e-book sobre Apache Camel. Essa atualização vem com algumas alterações importantes:
Eu converti o e-book para um website com visual moderno e bonito. Assim fica muito mais fácil de manter o conteúdo atualizado. O link para acessar o livro é: http://angusyoung.org/camel-passo-a-passo/. A partir de agora, não irei mais manter as versões em PDF ou e-pub.
Atualizei o material para o #Apache#Camel3.11.1 3.14.2. O exemplo com #Camel#Quarkus foi atualizado para a versão 2.2.0. Minha intenção é fazer pequenas revisões do livro a cada nova versão de suporte estendido (LTS – long-term support) do Apache Camel. A próxima versão LTS será a 3.17.
Adicionei algumas informações sobre funcionalidades que não tinha mencionado anteriormente: Camel Main, links para APIs relevantes. Também melhorei as explicações sobre funcionalidades em diversas partes do texto, bem como corrigi alguns erros.
E o mais importante de tudo, a partir de agora todo o texto do livro está disponível no GitHub. Desta forma, basta abrir um ticket ou um pull request no repositório do livro caso alguém encontre algum problema, queira oferecer alguma sugestão ou contribuir com algum material. O endereço do repositório é: https://github.com/integracao-passo-a-passo/ebook.
Recentemente tive a oportunidade de participar do excelente podcast Dev Sem Fronteiras, aonde pude contar um pouquinho da experiência de morar e trabalhar em #Brno, causos da vida na República Checa e um pouco do caminho até aqui.
Você pode conferir o episódio do podcast nesse link aqui.
Muitas vezes bugs acabam sendo introduzidos inadvertidamente em um projeto mesmo após passarem pelos testes unitários, eventualmente sendo descobertos somente após a execução de testes de integração, performance ou e2e na CI.
Nem sempre é fácil encontrar qual foi o commit causador do problema, dependendo do volume de alterações do projeto, práticas internas de engenharia de software e do número de desenvolvedores trabalhando no código.
Felizmente o git tem uma ferramenta bastante prática para automatizar o processo de encontrar o commit problemático: git bisect.
O git bisect é uma funcionalidade do git que usa um algoritmo de busca binária para “navegar” pelo histórico de commits do projeto e encontrar qual o commit problemático (não sabe o que é busca binária? Aprenda aqui).
Para isso o git bisect precisa de duas informações: um commit “ruim” (o hash do commit onde o problema ocorre) e um commit “bom” (o hash do commit onde o problema não ocorre). Tendo essas informações em mãos você pode rodar: git bisect start "ruim" "bom" e ele vai fazer o checkout dos commits para você.
Aí, basta você executar os comandos para compilar e testar a aplicação (por exemplo: “mvn clean verify“). Se o teste passar, você deve marcar o commit como bom (git bisect good). Caso ele falhe, você deve marcar o commit como ruim (git bisect bad). Após rodar um desses dois comandos para marcar o commit como bom ou ruim, ele vai prosseguir para o próximo commit no histórico.
Você deve repetir o processo até que ele termine de navegar pela lista de commits e lhe mostre qual foi o primeiro commit problemático que introduziu o problema.
Mas peraí, eu falei que o lance era automatizar a investigação de bugs, e esse processo parece muito manual né? É aí que entra o git bisect run. Essa funcionalidade permite que você forneça um script que teste o projeto. O script tem um requisito básico: o script deve retornar 0 para marcar um commit como bom, e um valor entre 1 e 127 para marcar um commit como ruim.
Por exemplo, suponha que você precise usar o docker-compose para subir a infra de testes, então rodar o build e os testes, e depois de executado encerrar a execução dessa infraestrutura. Para isso, você usaria um script parecido com esse aqui.
E, então, basta rodar o script usando o seguinte comando: git bisect run meu-script-de-testes.sh.
cf63ab12cbe3cfa598fcb83e6447c3c39718b3a4 is the first bad commit commit cf63ab12cbe3cfa598fcb83e6447c3c39718b3a4 Author: Otavio R. Piske some-email@domain.com Date: Wed Jun 28 09:05:14 2022 +0300
Added support for whatever in module foo.
Dependendo de quão grande é seu projeto, esse processo pode demorar um pouco. Então, agora basta sair para tomar um café, ler as notícias do dia ou fazer uma thread legal no Twitter, enquanto o git bisect procura o commit problemático para você.
Recentemente eu tive a honra de participar do super evento Tchelinux (um evento online com mais de 40 horas de conteúdo gratuito) . Na palestra que eu preparei para este evento eu falarei um pouquinho sobre os desafios de integração de sistemas na era da computação em nuvem. Nessa palestra eu apresento o Apache Camel, Camel K, Camel JBang e Kamelets.
Confira a palestra para aprender um sobre como tudo isso se relaciona e como essas tecnologias podem acelerar a maneira como você desenvolve integrações. A palestra vai ao ar nessa quarta-feira, dia 18 de novembro.
O JBang é uma aplicação que permite executar códigos em Java sem a necessidade de compilar diretamente o código e/ou criar projetos usando Maven ou Gradle. Simplificando, o JBang traz para o Java a agilidade dos scripts em Shell ou Python com o poder e a flexibilidade do Java.
O JBang pode ser instalado facilmente usando o SDKman!:
sdk install jbang
Uma vez instalado, você pode gerar um projeto a partir de um template padrão:
jbang init -t cli hello.java
Como resultado desse comando, ele irá criar um arquivo hello.java com um conteúdo parecido com o seguinte:
///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS info.picocli:picocli:4.5.0
import picocli.CommandLine;
import picocli.CommandLine.Command;
import picocli.CommandLine.Parameters;
import java.util.concurrent.Callable;
@Command(name = "hello", mixinStandardHelpOptions = true, version = "hello 0.1",
description = "hello made with jbang")
class hello implements Callable<Integer> {
@Parameters(index = "0", description = "The greeting to print", defaultValue = "World!")
private String greeting;
public static void main(String... args) {
int exitCode = new CommandLine(new hello()).execute(args);
System.exit(exitCode);
}
@Override
public Integer call() throws Exception { // your business logic goes here...
System.out.println("Hello " + greeting);
return 0;
}
}
Algumas particularidades interessantes do arquivo acima:
O JBang permite gerenciar dependências de diversas maneiras, a mais comum sendo através desse tipo de linha de configuração (modeline) precedida por //DEPS.
As dependências são referenciadas através da nomenclatura GAV (grupo, artefato, versão) no formato: G:A:V. Além disso é possível tanto usar BOM POMs para facilitar o gerenciamento de versões quanto trocar a versões fixas no código por propriedades que podem ser passadas por linha de comando:
Tornando possível executar o projeto usando algo semelhante ao seguinte:
jbang -Ddependencia.versao=2.0.1
Outra particularidade muito interessante do JBang é o uso do projeto PicoCLI para o gerenciamento das opções de linha de comando, o que permite tornar o script bastante flexível de maneira bastante elegante e direta.
Para executar esse arquivo você pode rodar:
./hello.java
ou
jbang run hello.java
Ao executar qualquer um dos comandos acima, temos o resultado esperado que é a impressão da famosa mensagem “Hello World”. E claro, também podemos brincar com a PicoCLI para mudar parte da mensagem:
jbang run hello.java --gretting Mundo! Hello Mundo!
Obviamente essa é só uma introdução bastante simples sobre o JBang. A capacidade de utilizar as inúmeras bibliotecas reutilizáveis que temos disponíveis em Java, torna o projeto bastante interessante para desenvolvedores com a necessidade de automatizar tarefas e que, talvez, não se sintam confortáveis com Shell Scripts. Além disso pode ser uma plataforma extremamente interessante para desenvolvedores iniciantes, pois remove a necessidade de gerenciar os projetos com Maven ou Gradle.
Recentemente um amigo me perguntou sobre alguns projetos interessantes no universo Kafka. E eu separei 3 projetos que eu acompanho, 1 dos quais eu contribuo, e que acho interessantes. É uma lista bem pessoal e nem de longe representa toda a riqueza do universo Kafka.
O Strimzi é um projeto que facilita o trabalho de rodar o Kafka em Kubernetes (k8s) e suas distribuições (OpenShift, GKS, k3s, etc). O Kafka é relativamente complicado para gerenciar e botar em produção, e ainda mais complicado de rodar dentro de Kubernetes. Esse projeto abstrai a maior parte da complexidade de manter um cluster Kafka rodando nesse tipo de ambiente.
O Camel Kafka Connector (disclaimer: eu contribuo com esse projeto) é um runtime do Apache Camel que envelopa todos os mais de 300 componentes do Camel e permite roda-los como conectores dentro de uma instância do Kafka Connect. O Kafka Connect é um componente do Kafka pra rodar programas que movem dados pra dentro ou pra fora do Kafka. Na maior parte das vezes você consegue fazer integrações pra dentro ou fora do Kafka sem precisar escrever uma linha de código sequer.
O Debezium é um projeto pra Change Data Capture (CDC) e que permite capturar as alterações que ocorrem e um banco de dados e publicá-las no Kafka. O Debezium usa a API do Kafka Connect para rodar seus “source connectors”.
Nessa postagem mostrarei como fazer um KVM-switch para Linux usando apenas software e um pouco de hardware compatível.
Para começar você precisa dos seguintes dispositivos:
Um monitor compatível com o padrão DDC/CI (no meu caso, LG27UD59)
Um teclado Logitech MX Keys (para outros dispositivos, veja os comentários no final)
Um mouse Logitech MX Master 3 (para outros dispositivos, veja os comentários no final)
E dos seguintes softwares instalados: ddcutil e Solaar. A instalação deles no Fedora é bastante simples, já que eles estão nos repositórios oficiais do projeto:
sudo dnf install -y solaar ddcutil
Mouse e Teclado
É bem provável que você já tenha o Solaar instalado se você tem o teclado e o mouse da Logitech. De qualquer maneira, a documentação do projeto fornece os passos iniciais para configurar o Solaar, caso seja necessário.
Você pode inspecionar a configuração dos dispositivos usando o comando solaar show. Pessoalmente acho mais simples verificar na GUI do Solaar, já que ela também mostra quais os valores aceitáveis para o comando que usaremos adiante. A informação relevante para nós é a mostrada em “Change Host“. Ela mostra os nomes dos hosts com os quais seu dispositivo está pareado.
Usando as informações mostradas na UI, podemos usar a linha de comando para trocar o host ativo:
solaar config "MX Keys" change-host 1:mercury
Note que o nome do host tem que ser igual ao mostrado na UI e em alguns casos pode ser que somente o número do ID seja mostrado.
Repita o mesmo para o mouse, tomando cuidado de garantir que o ID utilizado é o ID do dispositivo, pois é possível que os eles sejam diferentes entre o mouse e o teclado (ex.: o host 1 do teclado é o host 2 do mouse, etc):
solaar config "MX Master 3" change-host 1:mercury
Monitor
Para controlar o monitor, usamos o programa ddcutil, que serve para interagir com o software do monitor através do conjunto de protocolos DDC-CI. Nesse link aqui, que serviu de referência pra implementar o controle do monitor, você encontra algumas dicas legais sobre o ddcutil.
O primeiro passo é detectar o monitor e ver quais as funcionalidades estão disponíveis:
sudo ddcutil detect
Em algumas distribuições pode ser necessário carregar o módulo i2c-dev. O Fedora já costuma fazer isso por padrão, então nenhum passo a mais é necessário. Se estiver usando outra distro, consulte a documentação.
Se executado com sucesso, o comando vai mostrar uma saída semelhante a esta aqui:
Display 1 I2C bus: /dev/i2c-2 EDID synopsis: Mfg id: GSM Model: LG Ultra HD Serial number: Manufacture year: 2017 EDID version: 1.3 VCP version: 2.1
Se você estiver usando um laptop, o comando também vai mostrar a informação do monitor embutido. Esse monitor embutido não é relevante para o KVM-switch virtual, portanto podemos ignorar as mensagens de erro referentes a ele.
A informação relevante mostrada pelo comando acima é o I2C bus. Mais especificamente, o número do bus (2, no caso de /dev/i2c-2). Tendo a informação do bus, podemos usa-la para descobrir as funcionalidades do monitor. Para o KVM-switch estamos interessados na funcionalidade “Input Source“. Podemos usar o seguinte comando para descobrir o ID da feature e os valores aceitáveis para configura-la.
sudo ddcutil capabilities --bus=2 | grep -A 5 "Input Source"
Isso nos mostra que para mudar o dispositivo de entrada do monitor, podemos usar a feature ID 60 usando os valores (em hexadecimal) 0x11, 0x12, 0x0f e 0x10. Para testar, nesse caso:
sudo ddcutil --bus=2 setvcp 60 0x0f &
Executando esse comando já é possível trocar a entrada do monitor usando apenas a linha de comando.
Finalizando e Integrando no Gnome
Tendo em mãos os comandos para mudar o mouse, teclado e monitor. Podemos colocar tudo isso num script:
Em 2014 eu escrevi um mini e-book sobre integração de sistemas com Apache Camel. Naquela época o Apache Camel encontrava-se por volta da sua versão 2.10.x. Desde então, graças a velocidade de inovação da comunidade Open Source, inúmeras mudanças e melhorias foram feitas no Apache Camel (que hoje está em sua versão 3.6 ou 3.4.4 na versão LTS). Além disso, ao longo dos anos o projeto Camel foi adicionando números subprojetos novos, como o Camel Quarkus, o Camel Kafka Connector e o Camel K.
Para atualizar o livro para as versões atuais do Camel e cobrir um pouco sobre os novos subprojetos eu resolvi fazer uma extensa atualização na edição passada. Essa nova atualização também conta com algumas atualizações de cenários de integração, dando maior enfoque nos projetos de integração da Apache como o Apache Kafka e o Apache Artemis (futura nova geração do Apache ActiveMQ).
Hoje eu resolvi liberar uma versão preliminar do ebook que, ressalto, está disponível completamente de graça e sem custo algum. Essa é uma versão preliminar que cobre, no momento, detalhes básicos sobre integração de sistemas com Camel e uma introdução sobre o Camel Quarkus (para integrações subatômicas e supersônicas com Java). O livro vêm com alguns exemplos comentados que dão uma noção básica do funcionamento e servem de acompanhamento para os trechos de código do ebook.
Como o livro ainda é uma versão preliminar, é bastante possível que contenha alguns erros e pequenas inconsistências. Neste caso, eu agradeceria comentários e correções que pudessem ajudar a melhorar o conteúdo do livro através do meu email pessoal (angusyoung@gmail.com).
Os livros estão disponíveis em formato PDF e epub em formato amigável para leitura em tablets (como o iPad) e podem ser baixados nos seguintes links:
Desde sua versão inicial, em 13 de julho de 2004, o Apache Maven promoveu uma revolução na forma como projetos Java são desenvolvidos. Esse projeto, que começou com um subprojeto do Apache Turbine em 2002, modernizou a forma como o projetos gerenciavam as dependências em Java (entre muitas outras inovações, na verdade). Até então, as estratégias mais comum para construir projetos em Java eram baseados no Apache Ant, Makefiles ou Shell Scripts.
Após todos esses anos o Maven continua sendo uma ferramenta poderosa e popular. Entretanto, tendo sido inicialmente desenvolvido em uma época que as CPUs mais comuns eram Pentium 4 e semelhantes, ou até mesmo, com as Intel Core 2 Duo, populares por volta de 2010 quando a atual série 3.x do Maven foi lançada, o Maven mostra algumas limitações em utilizar todo o poder de processamento em paralelo das CPUs da atualidade.
Embora o Maven tenha suporte a paralelização do processo de build, esse processo é bastante rudimentar e não costuma ser muito confiável ou estável. Com os projetos atuais se tornando cada vez maiores e mais complexos, utilizar todo o poder de processamento disponível para diminuir o tempo de build se tornou cada vez mais urgente.
Pensando nisso, um grupo de programadores da comunidade open source resolveu utilizar o técnicas utilizadas em outros sistemas de build, como o Gradle, para melhorar a capacidade do Maven em utilizar esse poder de processamento disponível, otimizar a utilização de recursos e diminuir o tempo de build dos projetos.
O resultado desse trabalho é o Maven Daemon (também conhecido como mvnd). Esse projeto, desenvolvido em cima do próprio Maven, utiliza as seguintes técnicas para aumentar o desempenho do Maven:
Usa um daemon, mantido em memória para rodar os builds, evitando múltiplas execuções da JVM.
Utiliza um cliente nativo, construído com a GraalVM, para uma inicialização quase imediata.
Cache de classes dos plugins do Maven, reutilizado entre múltiplos builds.
Todo esse trabalho de otimização resulta numa considerável diminuição do tempo de build. Usando, por exemplo, um dos projetos que contribuo com frequência, esse tempo cai de 32 minutos e 51 segundos com o Maven para 7 minutos e 16 segundos com o mvnd.
Em comparação com um build feito com o mvnd, o build Maven padrão fica parecendo uma lesma com preguiça numa segunda-feira de manhã 🐌:
O processo de instalação do mvnd é bastante simples e não difere muito do que já ocorre com o Maven. Basta extrair os arquivos de instalação de exportar o diretório bin para o PATH. Usuários do igualmente fantástico SDKMAN! podem instalá-lo ainda mais facilmente usando o seguinte comando:
sdk install mvnd 0.0.9
Para rodar os builds com o mvnd, basta utilizar o comando mvnd ao invés do tradicional mvn. Todas as opções do Maven são completamente aceitas e compatíveis e não é necessário fazer nada mais.
Por fim, é possível que alguns builds apresentem problemas ao rodarem em paralelo. Isso geralmente é causado por plugins desatualizados ou, infelizmente, incompatíveis. Nesse caso, a recomendação é atualizar ou desabilitar o plugin mal comportado.
Estava acompanhando uma discussão sobre sistemas Unix no grupo de usuários Fedora Brasil e resolvi pesquisar, a título de curiosidade, se existiam e quais as distribuições Linux certificadas dentro da Especificação Única do Unix (Single Unix Specification – SUS).
Segundo o artigo da Wikipedia que fala a respeito da SUS, existem duas distribuições Linux certificadas como Unix 03:
Ambas são distribuição Linux da família “Red Hat”. O artigo não diz, exatamente, se é uma variante do Red Hat Enterprise Linux – RHEL, portanto cito-o exatamente como descrito no artigo.
Obs.: a versão em português do artigo da Especificação Única do Unix também cita uma distribuição chamada Linux-FT, mas não encontrei nada recente sobre essa distribuição. Esse artigo do Linux Journal de Agosto de 1996 fala um pouco sobre ela. Parece que a distribuição/produto (???) foi adquirida pela Caldera.
Eu empacotei o OpenPHT, um fork do Plex Home Theater mantido pela comunidade. O Plex Home Theater faz parte de um conjunto de aplicações para “media centers” e roda em diversos sistemas operacionais.
Os pacotes podem ser baixados desse link (no futuro espero contribuir o spec do pacote para o projeto upstream mas, antes disso, pretendo garantir que eles estão plenamente funcionais).
Para os interessados, as instruções de compilação podem ser encontradas nesse gist ou então, na especificação do arquivo RPM que está disponível neste link.
