Forem: Marco Ollivier

Como resolver um "Failed to Download Module" do Terraform / OpenTofu

Marco Ollivier — Sat, 18 May 2024 00:40:17 +0000

Do nada as coisas quebram

Eu rodo quase que diariamente o meu projeto principal de infra da empresa e tudo funciona super bem.

Eis que um belo dia... talvez não a toa... numa sexta feita no final do expediente um módulo simplesmente deixa de responder e apresenta o erro Error: Failed to download module.

Provavelmente você tá muito identificado nesse momento. Aposto que isso já aconteceu com você em algum momento. Nem precisa ser com Terraform.

Pois é. Aconteceu comigo. Do nada, ao rodar o meu tofu init, meu módulo do Aurora parou de responder

Initializing the backend...
Initializing modules...
Downloading registry.opentofu.org/terraform-aws-modules/rds-aurora/aws 9.3.1 for global.aurora.xxx_rds_aurora...
╷
│ Error: Failed to download module
│
│   on global/aurora/aurora.tf line 1:
│    1: module "xxx_rds_aurora" {
│
│ Could not download module "xxx_rds_aurora" (global/aurora/aurora.tf:1) source code from "git::https://github.com/terraform-aws-modules/terraform-aws-rds-aurora?ref=v9.3.1": error downloading
│ 'https://github.com/terraform-aws-modules/terraform-aws-rds-aurora?ref=v9.3.1': /opt/homebrew/bin/git exited with 128: Cloning into '.terraform/modules/global.aurora.xxx_rds_aurora'...
│ ssh: Could not resolve hostname github.comterraform-aws-modules: nodename nor servname provided, or not known
│ fatal: Could not read from remote repository.
│
│ Please make sure you have the correct access rights
│ and the repository exists.
│ .

Investigação

Obvio que a AI não me ajudou

E agora o que fazer?

No Novo Mundo das AIs a primeira reação é perguntar pro ChatGPT. Foi o que eu fiz. Eu nem li o erro direito.

E é óbvio que ele me deu uma pá de soluções que nem fazia sentido.

Por que eu não li o erro desde o começo?

Fiz os checks básicos:

Leu o erro? Agora sim!
O modulo ainda existe? Sim!
A versão existe? Sim!
Eu mudei alguma coisa? Não!
Alguém mudou alguma coisa? Não!

Então por que diabos ele não tá achando?

O erro fala sobre download... e tava mais obvio do que eu poderia imaginar

Could not download module "xxx_rds_aurora" (global/aurora/aurora.tf:1) source code 
from "git::https://github.com/terraform-aws-modules/terraform-aws-rds-aurora?ref=v9.3.1": error downloading

Foi quando eu me dei conta: ele está tentando baixar o módulo via https só que meu git está configurado pra baixar via ssh. Obvio que vai dar ruim.

A partir daqui vai o checklist seguinte:

Meu ~/.gitconfig está configurado corretamente? Sim!

[url "ssh://git@github.com/"]
    insteadOf = https://github.com/

A configuração de usar o ssh em vez do https está ativa.

Bom. Só sobrou a nível de Terraform e OpenTofu.

E realmente era o que faltava.

Solução

Não sei exatamente o motivo disso ter mudado do nada. Eu realmente não fiz nenhum tipo de alteração no meu ambiente de trabalho.

Mas a solução é simples. Se você ainda não tem um arquivo ~/.terraformrc ou ~/.opentofurc crie... e adicione um provider mirror.

provider_installation {
  network_mirror {
    url = "ssh://git@github.com/"
    match = "github.com"
  }
}

Isso vai evitar que você não consiga baixar os módulos por causa do seu Github.

E, crianças... leiam os erros e as documentações. Isso vai ser um diferencial em relação a carreira de vocês.

Pratique com APIs de verdade - ClimaTempo

Marco Ollivier — Thu, 10 Aug 2023 01:25:18 +0000

Já aconteceu mais de uma vez de pessoas que estão começando me pedirem dicas de projetos para começar. Ainda nessa questão de pedir dicas, também já me perguntaram como poderia praticar consumir APIs em projetos backend para terem a sensação que estão construindo algo que faça sentido e não algo que eles mesmos inventaram.

Um tempo atrás, eu fui apresentado ao TMDB (The Movie DB), que é basicamente um serviço online criado e mantido pela comunidade e que você consegue consumir informações referentes a filmes e series. Esse serviço já é excepcional pro nosso propósito e, francamente, já usei algumas vezes pra praticar com novos frameworks e ter um resultado mais agradável e até mesmo mais real. Só que... ainda é uma coisa meio como se eu mesmo tivesse feito. Não tem aquela sensação boa de aplicação real e prática.

Foi quando, navegando pela internet esses dias, eu descobri que o ClimaTempo tem uma API que te dá resultados reais sobre clima e tempo (sem trocadilhos com o nome). E você encontra essa API no endereço https://advisor.climatempo.com.br/

A API ClimaTempo

A API em números

Eles oferecem um serviço que dispõe de uma versão free (obviamente com algumas limitações) e prometem ter um uptime de 99,8%. O que considero um valor bem satisfatório.

Além disso, também fornecem uma documentação bem interessante e bem explicada da sua API que será fornecida usando o modelo REST.

Também oferecem um dashboard bem interessante que te ajuda a acompanhar o quanto você está dentro do seu plano.

O Dashboard

Quando você cria sua conta, uma das primeiras coisas que você vai ter acesso é ao Board. Que vai te ajudar a ver informações sobre o status da API, o uptime, o tempo médio de resposta e quantos hits/dia você já vez.

Lembrando que o plano free te oferece um limite de 10req/min ou 100req/dia. Mais do que suficiente.

A Documentação

A documentação não foge muito do padrão e você pode encontrar aqui. Mas como a forma com que modelamos uma API reflete muito na doc, aqui vale ressaltar que considero o contrato que foi desenhado nessa API bem interessante e que pode servir de inspiração caso você esteja criando uma do zero e esteja com algumas dúvidas sobre como estruturar.

Aqui pegamos o gancho para seu token de acesso. Todos (os que eu vi, ao menos) endpoints vão pedir para você passar seu token como query parameter.

Aqui uma opinião pessoal: acho estranho passar o token dessa forma. Eu optaria por passar via header, mas tudo bem.

E esse token você consegue gerar um novo com muita facilidade no painel.

Também é outro ponto que eu talvez mudasse. Esse modelo de token é um pouco inseguro, pois em caso de vazamento, ele não é gerado novamente depois de x minutos. O que pode ser um problema, mas como aqui não estamos falando de dados sensíveis, também não é o fim do mundo. Você só teria indisponibilidade por atingir o máximo de acessos diários.

Colocando em prática

Pra esse post não ficar apenas na pegada de textão, vamos fazer uma integração simples usando Go da forma mais básica possível?

Vamos começar criando um projeto e para isso, vou usar toda a minha criatividade de dev para nomear coisas e criar uma pasta chamada climatempo-go

$ mkdir climatempo-go
$ go mod init github.com/marcopollivier/climatempo-go

Para esse projeto eu estou usando ainda a versão 1.20 (a 21 saiu ontem... dá o desconto)

E aqui pra esse primeiro post, eu vou simplesmente criar um main.go e fazer tudo dentro dele. Eu coloquei ali nas tags que era pra iniciante, então não reclama. Vou tentar fazer outros posts avançando com esse projeto.

Vamos de Hello, world pra ver se tá tudo bem com meu ambiente. Eu SEMPRE faço isso.

package main

import "fmt"

func main() {
    fmt.Println("Oi, mundo")
}

Como eu vou usar o pacote net/http vamos de documentação ou de go by example pra ter certeza que nada mudou.

Ah... aqui, como nós vamos pegar uma informação de algum lugar, nós vamos ser considerados clientes, se pensarmos em uma estrutura cliente/servidor.

Se você tiver dúvidas em relação a isso, pense: eu estou pedindo ou servindo... acho que agora ficou claro, certo?

Bom. Vamos de condições atuais do tempo. Você vai encontrar essa parte aqui nesse endereço da documentação: http://apiadvisor.climatempo.com.br/doc/index.html#api-Weather-CurrentWeatherByCity

E de acordo com ela, faremos um GET no endpoint /api/v1/weather/locale/:id/current?token=your-app-token

O que, no fim, ficaria algo parecido com isso aqui, caso chamássemos via terminal.

$ curl -i http://apiadvisor.climatempo.com.br/api/v1/weather/locale/3477/current?token=your-app-token

Traduzindo isso para código Go, teríamos:

package main

import "net/http"

func main() {
    http.Get("http://apiadvisor.climatempo.com.br/api/v1/weather/locale/3477/current?token=your-app-token")
}

Mas isso ainda não faz nada... quer dizer... esse Get até acontece, mas não pegamos essa informação e criamos alguma coisa com ela.

Aqui vale um passo atrás e mostrar que não tirei nada da minha cabeça. Eu sei que você já clicou e viu a documentação que mandei ali em cima, mas caso o texto tenha envolvido tanto você que fez você perder essa oportunidade, você vai perceber algumas coisas na documentação.

Ela vai ser composta por:

o contrato (endereço e método HTTP)
um exemplo de como fica esse contrato (usando o curl por padrão)
os parâmetros que você precisa passar.
O que essa API vai retornar quando tiver em um cenário de sucesso
E o que ela vai retornar em um cenário de erro.

E o nosso código vai precisar representar cada uma dessas informações. Vamos ver isso acontecer?

O contrato

Vamos começar por essa parte do nosso contrato. Onde tempos os 3 primeiros items dessa lista acima.

E vamos fazer essa correlação com o código que estamos criando.

Dessa forma, vamos evoluir nosso código da seguinte forma.

package main

import (
    "bufio"
    "fmt"
    "net/http"
)

func main() {
    resp, _ := http.Get("http://apiadvisor.climatempo.com.br/api/v1/weather/locale/3477/current?token=your-app-token")
    defer resp.Body.Close()

    fmt.Println(resp.StatusCode)

    scanner := bufio.NewScanner(resp.Body)
    for i := 0; scanner.Scan() && i < 5; i++ {
        fmt.Println(scanner.Text())
    }

}

Dando uma resumida no que esse código está fazendo:

ele pega a resposta desse Get e atribui o valor pra variável resp. Como essa função http.Get tem um retorno multivalorado, o segundo parâmetro seria um erro, mas pra esse exemplo não quero me preocupar com isso. De modo que uso _(underline) para dizer que não quero fazer nada com esse retorno.

Um disclaimer sobre o underline: esse aqui é um exemplo meramente didático pra falarmos sobre o processo básico de consumir uma API. Evite ao máximo usar isso em um código que vá para o ambiente produtivo, especialmente se for um retorno de erro como era esse caso.

Logo depois de pegar o retorno, eu chamo um defer que vai chamar a função de Body.Close() e colocar no final da pilha de execuções. Dessa forma depois de executar tudo que está previsto nessa função, ele vai fechar essa conexão da chamada.

Depois disso, imprimimos o status code dessa chamada. Se voltarmos a documentação, sabemos que isso está devidamente documentado lá. No caso, quando temos o exemplo de sucesso, ela afirma que retornará um código 200 e quando tiver um erro, retornará algo com 4xx.

Esse 4xx representa que retornará algum código da família 400. (400: bad request, 401: Unauthorized etc). Veja mais nesse artigo

Nesse momento se executarmos o código exatamente como está, ele irá retornar um desses erros. No caso retornará um erro 400 com o seguinte JSON de erro

{"error":true,"detail":"Invalid token"}

Isso está acontecendo justamente por não termos mudado o token no endereço ali em cima.

http://apiadvisor.climatempo.com.br/api/v1/weather/locale/3477/current?token=your-app-token

Mude o texto onde está your-app-token para o token que aparecer no seu painel. CUIDADO para não deixar isso público e nem compartilhar isso com ninguém.

Com isso passaremos a ter uma resposta com o padrão de sucesso como apresentado na documentação. Nesse caso, teremos um retorno 200 e um JSON parecido com esse:

{
   "id":3477,
   "name":"S\u00e3o Paulo",
   "state":"SP",
   "country":"BR  ",
   "data":{
      "temperature":17,
      "wind_direction":"SSE",
      "wind_velocity":19,
      "humidity":94,
      "condition":"Chuva fraca",
      "pressure":1023,
      "icon":"5n",
      "sensation":17,
      "date":"2023-08-09 19:20:08"
   }
}

Conclusão

Eu vou parar por aqui nesse exemplo para não ficar cansativo. Principalmente se pensarmos que esse primeiro post sobre esse tema foi bem direcionado para apresentar a API do ClimaTempo e a parte de código bem direcionada para um público iniciante, acredito que onde paramos é um bom momento.

Nesse post conseguimos ver detalhes de como entender uma documentação de uma API. Vimos que o ClimaTempo pode ser um bom projeto pra praticarmos alguma tecnologia nova na hora de testar soluções de client http.

E também oficializamos esse exemplo com um código básico usando o pacote net/http do Go.

Próximos passos

Provavelmente o próximo passo vai ser a evolução desse aqui. vamos melhorar um pouco nosso projeto transformando nosso JSON em uma struct por exemplo.

Se você gostou desse post, curta e compartilhe nas redes. Qualquer duvida ou feedback deixe nos comentários e me siga nas redes :)

Até mais.

Não se preocupe mais com o package manager do seu projeto NodeJS

Marco Ollivier — Thu, 06 Jul 2023 23:25:07 +0000

Eu que venho de outras tecnologias como Go, Clojure e Java, as vezes fico um pouco irritado com a quantidade de alternativas que são usadas de maneira tão ampla no universo NodeJS. Pra esse post específico eu ilustro com gerenciadores de pacote... meu deus... é npm, é yarn, é pnpm.
Parece que cada dia aparece um novo.

(tá... não é pra tanto, mas eu quero fazer um drama pra justificar o post)

Mas fazendo aqui um mea-culpa, talvez isso seja um problema mais meu do que da tecnologia em si, já que até hoje minha memória muscular digita no terminal lein lint:fix em vez de yarn lint:fix ou qualquer outro comando que realmente funcione pra projetos Node.

(pra quem não entendeu, lein é de Leiningen, o gerador de pacotes que eu usava pra trabalhar com Clojure)

Mas meus problemas acabaram. Esses dias scrollando alguma rede social por aí, chegou ao meu conhecimento o ni. Mas o que seria o Ni? Um novo gerador de pacotes? Não, mas ele vai acabar de vez com meus problemas em relação a projetos diferentes com gerenciadores diferentes.

O Ni

É tão simples usar o Ni, que escrever sobre ele também não demanda um texto muito grande.

Basicamente é uma ferramenta desenvolvida pra você que tem vários projetos e, eventualmente, cada um com um package manager. O Ni simplesmente vai abstrair isso pra você e você pode passar a se preocupar apenas com um único padrão de comandos.

O Ni dá suporte a npm, yarn,pnpme bun e com apenas um conjunto de comandos você trabalha com qualquer projeto que use um desses.

Por exemplo: se eu quero adicionar um novo pacote no meu projeto Node, mas apenas no contexto de desenvolvimento, pra cada um dos geradores de pacotes acima, eu teria essas opções abaixo:

# npm i @types/node -D
# yarn add @types/node -D
# pnpm add -D @types/node
# bun add -d @types/node

Se você tem o Ni configurado na sua máquina, basta executar o comando ni @types/node -D e ele vai identificar qual o gerenciador de pacotes você tá usando e encontrar qual desses comandos ele deveria executar por debaixo dos panos.

Só por isso o Ni já se justifica pra mim, mas além disso, ele também é uma CLI bem interativa. O que pra mim é muito interessante quando estou tentando executar um projeto que eu ainda não conheço muito bem.

Por exemplo: pra eu rodar algum comando que está configurado dentro do meu package.json basta eu rodar nr (ni run) e ele vai listar pra mim todos os comandos de scripts disponíveis nos scripts do arquivo em um menu navegável pra ajudar na execução.

O Ni também tenta te ajudar na repetição de comandos. Se você executar o comando nr - ele vai executar o último comando rodado. No caso, se eu rodei um nr start:dev, na vez seguinte eu posso apenas executar o nr - que ele vai executar o start:dev pra mim.

E aqui se eu não te convenci, não sei mais como posso fazer isso, mas se curtiu, instalar também é absurdamente simples. Basta apenas executar o comando

$ npm i -g @antfu/ni

E se quiser olhar como o projeto foi construído e até mesmo colaborar com o projeto, o Github é esse aqui.

antfu-collective / ni

💡 Use the right package manager

ni

~~npm i in a yarn project, again? F**k!~~

ni - use the right package manager

npm i -g @antfu/ni

npm · yarn · pnpm · bun · deno

`ni` - install

ni

# npm install
# yarn install
# pnpm install
# bun install
# deno install

ni vite

# npm i vite
# yarn add vite
# pnpm add vite
# bun add vite
# deno add vite

ni @types/node -D

# npm i @types/node -D
# yarn add @types/node -D
# pnpm add -D @types/node
# bun add -d @types/node
# deno add -D @types/node

ni -P

# npm i --omit=dev
# yarn install --production
# pnpm i --production
# bun install --production
# (deno not supported)

ni --frozen

# npm ci
# yarn install --frozen-lockfile (Yarn 1)
# yarn install --immutable (Yarn Berry)
# pnpm install --frozen-lockfile
# bun install --frozen-lockfile
# deno install --frozen

ni

…

View on GitHub

Conclusão

Pra pessoas como eu que trabalho em várias frentes - trabalho, voluntariado, comunidade etc - ter uma ferramenta que me ajuda em coisas pequenas que não deveriam tomar mais do que alguns poucos segundos faz muita diferença e por isso eu curti tanto a proposta do Ni. Espero que, de alguma forma, esse post também ajude você a ganhar um pouquinho mais de produtividade.

XML Parsing em NodeJS com XMLBuilder2

Marco Ollivier — Sun, 16 Apr 2023 20:13:37 +0000

Bom, como dito no post que serviu como preâmbulo, eu tive um primeiro momento onde eu pensei que não iria ter acesso a definição do WebService. Dessa forma minha vida ficaria um pouco mais complexa. Não seria exatamente o fim do mundo, mas eu teria que fazer parsing de XML e isso é algo relativamente chato.

Bom. Foi quando eu conhecia a biblioteca XMLBuilder. Mais precisamente a v2 dessa lib (elas estão em repos diferentes).

oozcitak / xmlbuilder2

An XML builder for node.js

xmlbuilder2

An XML builder for node.js.

Installation:

npm install xmlbuilder2

Documentation:

See: https://oozcitak.github.io/xmlbuilder2/

Usage:

xmlbuilder2 is a wrapper around DOM nodes which adds chainable functions to make it easier to create and work with XML documents. For example the following XML document:

<?xml version="1.0"?>
<root att="val">
  <foo>
    <bar>foobar</bar>
  </foo>
  <baz/>
</root>

can be created with the following function chain:

const { create } = require('xmlbuilder2');
const root = create({ version: '1.0' })
  .ele('root', { att: 'val' })
    .ele('foo')
      .ele('bar').txt('foobar').up()
    .up()
    .ele('baz').up()
  .up

…

View on GitHub

Custo x Benefício da biblioteca

Eu não estou há taaantos anos assim no universo JS/TS. Meu maior background é de Java, Go e Clojure. Dessa forma eu sempre fico com um pé atrás de sair usando qualquer biblioteca que eu encontro por aí. Então eu recorri ao snyk.io para "qualidade" da biblioteca.

Eu coloquei qualidade entre aspas, porque isso não é o que realmente vai definir a qualidade dela, mas pelo menos me dá um score de algumas coisas que eu acho importante como: vulnerabilidades de segurança encontradas, quantidade de novos downloads por semana e suporte frequente pelo criados.

Bom... a nota foi de 79 de 100. Não é das melhores, mas passa de ano. Uma das coisas que impactou a nota foi o tempo do último release. Mas eu levei em conta uma coisa pra decidir acabar utilizando: XML não é exatamente uma tecnologia que tem sofrido grandes mudanças nos últimos tempos. E se a lib não apresenta problemas com segurança, talvez faça sentido não ter sofrido alterações recentemente.

Utilização

Bom. Chega de enrolação. Pra demonstra como foi a utilização da biblioteca eu criei um projeto NodeJS bem simples que você vai encontrar nesse repo aqui...

marcopollivier / practice.node-with-xml

Projeto de PoC sobre como manipular XMLs com NodeJS de uma forma menos custosa

practice.node-with-xml

View on GitHub

Pra instalar é o básico

$ npm install xmlbuilder2

E como base vamos começar com um XML básico. Como, no caso de não termos um WSDL, o que faremos é uma requisição HTTP usando o método POST e passando um XML no payload, aqui vamos nos ater a simplesmente como vamos criar nosso XML pra enviar nesse payload. Todo o resto iria apenas atrapalhar nosso objetivo.

Então vamos tomar como base o seguinte XML inicialmente (que eu vou tentar deixar o mais próximo possível do XML de uma WebService SOAP):

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:tns="http://wms2.marcopollivier.dev/soap/webservice.xpto"
               xmlns:types="http://wms2.marcopollivier.dev/soap/webservice.xpto/encodedTypes"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

        <!-- Cadastra Livros - Requisição -->
        <tns:CadastraLivros id="id1" xsi:type="tns:CadastraLivros">
            <LivrosArray href="#id2"/>
        </tns:CadastraLivros>

        <!-- Livros - Array -->
        <soapenc:Array id="id2" soapenc:arrayType="tns:Livro[1]">
            <Item href="#id3"/>
        </soapenc:Array>

        <!-- Livros - Array -->
        <tns:Livro id="id3" xsi:type="tns:Livro">
            <Pedido xsi:type="xsd:string">O Conde de Monte Cristo</Pedido>

            <ExemplaresArray href="#id4"/>
        </tns:Livro>

        <!-- Exemplares - Array -->
        <soapenc:Array id="id4" soapenc:arrayType="tns:Exemplar[1]">
            <Item href="#id5"/>
        </soapenc:Array>

        <!-- Exemplar -->
        <tns:Exemplar id="id5" xsi:type="tns:Exemplar">
            <Quantidade xsi:type="xsd:nonNegativeInteger">5</Quantidade>
            <AnoEdicao xsi:type="xsd:string">2022</Pedido>
        </tns:Exemplar>


    </soap:Body>
</soap:Envelope>

Eu sei que o XML ficou meio grande, mas eu queria representar algumas peculiaridades que são importantes desse xml que eu considerei importantes estarem aqui

Primeira tentativa: A solução padrão

Bom. O primeiro exemplo que a biblioteca oferece é você fazer de uma forma em que você meio que navega na hierarquia do XML.

Como essa biblioteca por baixo dos panos utiliza a estratégia de XPath pra navegar nas tags, essa estratégia é até meio óbvia e, talvez, por isso seja a primeira apresentada.

E francamente, eu vou fazer só as primeiras tags, porque essa também é a forma mais verbosa...

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:tns="http://wms2.marcopollivier.dev/soap/webservice.xpto"
               xmlns:types="http://wms2.marcopollivier.dev/soap/webservice.xpto/encodedTypes"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema">

Talvez a parte mais chata seja esse começo. Onde eu tenho que definir alguns muitos atributos no elemento do soap:Envelop

create({ version: '1.0' })
  .ele('soap:Envelope', { 'xmlns:soap': 'http://schemas.xmlsoap.org/soap/envelope/', 
                          'xmlns:soapenc': 'http://schemas.xmlsoap.org/soap/encoding/',
                          'xmlns:tns': 'http://wms2.marcopollivier.dev/soap/webservice.xpto',

                          'xmlns:types': 'http://wms2.marcopollivier.dev/soap/webservice.xpto/encodedTypes',
                          'xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance',
                          'xmlns:xsd': 'http://www.w3.org/2001/XMLSchema',
                        })
  .up();

Só essa primeira parte que representa o soap:envelop já parece que vai ser uma forma muito verbosa. E isso se confirma com a continuação do código.

Se você bem notou, no final tem uma chamada de função up(). Lembra que eu disse que essa lib usa a estratégia de XPath por baixo dos panos? Aqui isso fica bem claro. Já que no, se eu não quero continuar aninhando elementos, eu tenho que dizer que eu quero subir um nível antes de criar o próximo. Ou seja:

el('a').el('b').el('c') vai gerar algo como:

<a>
 <b>
  <c>
  </c>
 </b>
</a>

de modo que se você mudar para el('a').el('b').up().el('c').up(), você terá algo como:

<a>
 <b></b>
  <c></c>
</a>

Então, dessa forma, pra representar o próximo nível do nosso exemplo (soap:body) basta fazer algo do tipo:

create({ version: '1.0' })
  .ele('soap:Envelope', { 'xmlns:soap': 'http://schemas.xmlsoap.org/soap/envelope/', 
                          'xmlns:soapenc': 'http://schemas.xmlsoap.org/soap/encoding/',
                          'xmlns:tns': 'http://wms2.marcopollivier.dev/soap/webservice.xpto',

                          'xmlns:types': 'http://wms2.marcopollivier.dev/soap/webservice.xpto/encodedTypes',
                          'xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance',
                          'xmlns:xsd': 'http://www.w3.org/2001/XMLSchema',
                        })
    .ele('soap:Body', { 'id': '#1', 'soapenc:arrayType': "tns:Livro[1]" })
  .up();

E agora o resto é repetição...

Segunda tentativa: Usar um objeto JSON

Sim. A lib oferece essa opção. E eu não apresentei ela primeiro porque eu queria reforçar que existe uma outra forma que pode ter suas vantagens.

O modelo anterior pode se mostrar verboso e repetitivo pra XMLs muito grandes (o que é o nosso caso), mas querendo ou não, você vai ter mais controle do que você tá fazendo. Pra XMLs mais simples, eu acho que iria pra essa opção.

Entretanto não dá pra negar o apelo que tem a possibilidade de criar um XML por meio de um JSON.

Só que logo uma coisa vem na minha cabeça: o XML tem os atributos, que, como vimos, é bem comum em XMLs SOAP.

Mas sim... ficou muito mais simples. Tanto que eu me empolguei e fiz mais que no exemplo anterior.


  const obj = {
    'soap:Envelope': {
      '@xmlns:soap': "http://schemas.xmlsoap.org/soap/envelope/",
      '@xmlns:soapenc': "http://schemas.xmlsoap.org/soap/encoding/",
      '@xmlns:tns': "http://wms2.marcopollivier.dev/soap/webservice.xpto",
      '@xmlns:types': "http://wms2.marcopollivier.dev/soap/webservice.xpto/encodedTypes",
      '@xmlns:xsi': "http://www.w3.org/2001/XMLSchema-instance",
      '@xmlns:xsd': "http://www.w3.org/2001/XMLSchema",

      'soap:Body': {
        '@soap:encodingStyle': 'http://schemas.xmlsoap.org/soap/encoding/',

        'tns:CadastraLivros': {
          '@id': 'id1',
          '@xsi:type': 'tns:CadastraLivros',

          'LivrosArray': {
            '@href': '#id2'
          }

        }

      }

    }
  };

Como você já deve ter reparado, esse modelo usa o @ na frente pra poder indicar que aquilo é um atributo e que ele precisa saber montar de acordo.

Bom. Tudo vai indo bem, até que esbarramos no seguinte problema: Como o XML tem atributos que conseguem distinguir elementos com o mesmo nome, o nosso XML pode ter elementos repetidos no mesmo nível. O que é o caso dos elementos


        <soapenc:Array id="id2" soapenc:arrayType="tns:Livro[1]">
            <Item href="#id3"/>
        </soapenc:Array>

        <soapenc:Array id="id4" soapenc:arrayType="tns:Exemplar[1]">
            <Item href="#id5"/>
        </soapenc:Array>

Entretanto, quando representamos isso no JSON ele simplesmente sobrescreve o primeiro elemento pelo segundo.

Para tentar resolver isso, eu tentei appendar o elemento, mas também não deu muito certo original.root().ele('soap:Body').ele('aaa')

Conclusão

Talvez ter chegado no final desse artigo tenha sido um pouco frustrante, mas foi importante pra mostrar que faz muita diferença a forma que integramos entre serviços. E que, quando você opta por fazer um WebService SOAP você vai criar um nível de complicação que talvez não seja necessário. Principalmente pensando que você tem outras formas de integração usando o mesmo protocolo e que vai gerar bem menos trabalho.

Quanto a biblioteca, ela se mostrou interessante, mas esbarramos em problemas que precisamos dar uma volta grande pra tentar resolver e, dependendo do problema, vamos esbarrar em algumas limitações. Como foi o caso da sobrescrita do elemento.

Francamente eu nem achei que valia mais a pena tentar resolver esse problema, pois nesse meio tempo descobri que eu iria ter acesso ao WSDL desse WS. Então desse texto, fica o quanto essa lib pode te ajudar e também algumas limitações dependendo do caso. Se você quiser avançar daqui e postar nos comentários como deixar essa solução redondinha, eu agradeço e certamente te darei os devidos créditos quando eu ajustar o texto. :)

Se você não tiver opções e tiver que integrar com um WebService SOAP, buque saber se o WSDL está disponível de alguma forma. Dessa forma sua vida ficará mais simples (como veremos no próximo texto).

Vale aqui eu finalizar com uma experiência passada com esse mesmo tipo de problema: nessa minha experiência prévia, nós havíamos feito uma integração também em SOAP parseando XML. O que tivemos foi uma alteração de contrato do lado do fornecedor do WS. Nós não conseguimos identificar que havia sido feita uma mudança e a falha na integração gerou uma perda financeira considerável. Então aqui ficam duas lições. Cuidado com os contratos das integrações e estejam com a observabilidade dos seus serviços em dia.

SOAP com TypeScript em pleno 2023

Marco Ollivier — Sun, 16 Apr 2023 20:12:35 +0000

Soap soup

TL;DR: blablabla tive que fazer um parsing XML e depois descobri que ia conseguir usar o WSDL. Se não quiser ler o textão, vai pro próximo tópico sobre como eu resolvi primeiro o parsing XML.

O ano é 2023. Estamos falando em gRPC, tRPC, Rest, GraphQL blablabla. Pois eis que do nada surge uma integração que precisa ser feita via SOAP e XML. Sim... você não entendeu errado... um Web Service... SOAP... com direito a XML.. e tudo mais.

Pois é. Fui transportado no tempo e automaticamente me lembrei de quando eu estava na faculdade, nos idos de 2009. Quando em uma cadeira de Java nós falávamos de JAX-WS e de como poderíamos gerar classes stubs pelo Eclipse. Meu Deus... aqui a nostalgia não vem acompanhada de saudade. Também impossível não lembrar dos trocadilhos com sabão, sopa ou coisas que tem sonoridade parecida. Inclusive a capa desse artigo é uma Sopa de Sabão que eu pedi pro Midjourney gerar pra mim haha.

Mas bem. Estamos em 2023 e hoje eu estou construindo soluções em JavaScript... ou melhor: em TypeScript. E tenho como fiel companheiro o Fastify para que as coisas fiquem menos dolorosas.

Mas quem foi que disse que a vida é simples? Pois é. Eu contava que eu teria o WSDL pra facilitar minha vida e, em um primeiro momento eu tive uma negativa em relação a isso.

Dessa forma eu teria que fazer o parsing do XML... na mão. Dando um spoiler, depois eu consegui o WSDL e a vida vai ficar mais fácil, mas eu já tinha feito uma PoC de como eu faria o parsing desse XML na mão então vai ser a primeira parte dessa sequência de posts. Espero que você não tenha que precisar usa-los, mas se precisar, espero que sejam úteis hehe.

Alinhando os patos

Antes de irmos pro primeiro texto vamos alinhar alguns conceitos para quem não souber do que eu estou falando consiga ficar na mesma página.

WebService, SOAP, SOA e até mesmo REST

Talvez o termo menos problemático aqui seja WebService. Vamos defini-lo como "uma aplicação distribuída cujos componentes podem ser aplicados e executados em dispositivos distintos." -- Martin Kalim.

Provavelmente você pensou em APIs Rest. E não está de todo errado. Inclusive há anos atrás, bibliografias dividiam WebServices em dois grupos: baseados em SOAP e de "estilo" REST. Inclusive considerando SOAP uma espécie de caso especial do REST. Muito disso tem relação com o fato de ambos rodarem em cima do protocolo HTTP.

Outro ponto que ajuda a confundir as definições é quando entra a definição de SOA no meio. Originalmente SOAP significa Simple Object Access Protocol enquanto SOA significa Service Oriented Architecture. Então como podemos ver pelos próprios nomes, SOA é um estilo arquitetural enquanto SOAP é um dialeto XML.

Aqui vale frisar que nosso foco não é SOA, então paramos por aqui em relação a esse termo e que, SOAP e SOA são conceitos que podem ser utilizados de forma totalmente independente entre si.

Se você quiser uma visualização simples de como funciona um WebService SOAP, abra seu postman e chame o seguinte serviço (exatamente da mesma forma que você faria com um endpoint Restful).


POST /webservicesserver/NumberConversion.wso HTTP/1.1
Host: www.dataaccess.com
Content-Type: text/xml
Content-Length: 276

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <NumberToWords xmlns="http://www.dataaccess.com/webservicesserver/">
      <ubiNum>500</ubiNum>
    </NumberToWords>
  </soap:Body>
</soap:Envelope>

Esse WebService traduz um número inteiro para sua representação por extenso. E o retorno dele será.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
            <m:NumberToWordsResult>five hundred </m:NumberToWordsResult>
        </m:NumberToWordsResponse>
    </soap:Body>
</soap:Envelope>

const axios = require('axios');
let data = '<?xml version="1.0" encoding="utf-8"?>\n<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">\n  <soap:Body>\n    <NumberToWords xmlns="http://www.dataaccess.com/webservicesserver/">\n      <ubiNum>500</ubiNum>\n    </NumberToWords>\n  </soap:Body>\n</soap:Envelope>';

let config = {
  method: 'post',
  maxBodyLength: Infinity,
  url: 'https://www.dataaccess.com/webservicesserver/NumberConversion.wso',
  headers: { 
    'Content-Type': 'text/xml'
  },
  data : data
};

axios.request(config)
.then((response) => {
  console.log(JSON.stringify(response.data));
})
.catch((error) => {
  console.log(error);
});

Perceba que ele é um XML bem diferentão, mas ainda é um XML. E como sua requisição usa como base o protocolo HTTP, fica muito fácil fazer uma requisição dessa forma.

O problema é que os serviços dificilmente são simples dessa forma. E se precisarmos integrar com um WebService que tenha uma quantidade grande de métodos ou a informação tenha uma estrutura mais complexa, fazer a requisição dessa forma será bem mais complicado. E veremos isso nos próximos dois artigos dessa série.

O WSDL

Eu comentei que dependendo do que tivermos no nosso WebService, essa integração pode ser bem complexa. Existe uma forma de tentar fazer com que isso seja menos problemático?

A resposta é sim. Não é bonito, mas torna a vida mais simples.

Lá pra 2010 quando eu estava ainda na faculdade, eu tive uma cadeira sobre isso e por mais que eu lembre de poucas coisas da época, uma coisa ficou na minha cabeça: os stubs que eram gerados via Eclipse por meio de um arquivo chamado WSDL.

O WSDL significa WebService Description Language e também é baseado em XML. Ele vai servir justamente pra definir a interface dos serviços SOAP e nele estarão coisas como o formato de entrada e de saída, os tipos que precisam ser passados, quais métodos estão disponíveis etc.

<wsdl:definitions 
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
 xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" 
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
 xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
 xmlns:tns="http://tempuri.org/" 
 xmlns:s="http://www.w3.org/2001/XMLSchema" 
 xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" 
 xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" 
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
 targetNamespace="http://tempuri.org/">
 <wsdl:types>
  <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
  <s:element name="Add">
    <s:complexType>
      <s:sequence>
        <s:element minOccurs="1" maxOccurs="1" name="intA" type="s:int"/>
        <s:element minOccurs="1" maxOccurs="1" name="intB" type="s:int"/>
      </s:sequence>
    </s:complexType>
</s:element>
<s:element name="AddResponse">
  <s:complexType>
    <s:sequence>
      <s:element minOccurs="1" maxOccurs="1" name="AddResult" type="s:int"/>
    </s:sequence>
  </s:complexType>
</s:element>

...

Repare que também é um XML, mas é diferente. Nele você encontra o nome dos parametros, os tipos aceitos e o nome dos métodos. Assim como o padrão de suas respostas.

Com essa documento a vida fica consideravelmente mais simples, pois muitas tecnologias oferecem ferramentas para que você crie o código que será usado pra integrar com o WebService por meio desse documento.

Em Java por exemplo, existe o wsimport que vai escrever quase que completamente um cliente que será usado para consumir o serviço disponibilizado.

Conclusão

Esse texto é inicial pra dar o termômetro do que precisaremos fazer e também serve como alinhamento de entendimento de alguns termos que por muito se confundem entre si.

Pros próximos passos, vamos ver as duas maneiras de fazer uma integração com um WebService SOAP. Primeiro vamos fazer um parsing direto do XML e depois vamos usar libs que entendem o padrão WSDL para que nossas vidas sejam mais fáceis.

Até lá :)

READMEs: o primeiro passo para uma boa documentação

Marco Ollivier — Wed, 12 Oct 2022 19:36:01 +0000

Do começo

Aqui vai um pouco de contexto como como eu cheguei as conclusões que vou falar daqui a pouco. Se quiser pular essa parte, vá direto para o Better read-me's

Acho que uma das coisas que não posso negar sobre ter passado 2 anos e meio trabalhando no Nubank é que lá foi uma grande escola de boas práticas. Tanto para aprender uma técnica nova quanto pra consolidar práticas que eu já adotava de alguma forma lá era um ambiente que sempre me trazia a oportunidade de aperfeiçoar alguma técnica. Uma dessas técnicas é sobre documentar documentar e documentar. Escrever e manter documentações talvez tenha sido uma das coisas que eu mais aprendi/aperfeiçoei nesses anos.

Como bom dev, eu sempre me preocupei mais me documentar fluxos e, de alguma forma, tinha um pouco em mim o ceticismo de que manter documentação era algo complexo. Certamente hoje eu vejo isso de uma forma totalmente diferente. Pra mim, hoje, escrever uma boa documentação - não apenas fluxos, mas também porque e como decisões foram tomadas - é algo muito importante no meu dia-a-dia.

Nesse texto eu poderia falar sobre como manter, ou sobre como não tornar burocracias uma tarefa burocrática, mas acho que não é o meu propósito no momento. Acho que posso até pensar em fazer isso em um outro texto.

Mas em um mundo com milhares de siglas como ADR, RFC, PDR, 6-pager, 1-page... ufa... não podemos deixar de pensar no básico como desenvolvedores: o bom e velho read-me escrito com o maravilhoso Markdown.

Aqui vale lembrar que nenhuma dessas documentações será substituída pelo Read-me e nem que todas essas documentações serão usadas o tempo todo. Vamos lembrar que todas são ferramentas e ferramentas devem ser usadas pra resolver problemas específicos.

Bom... Então vamos ao que interessa. O Read-me.

Twitter... fale comigo

Eu já tentei diversos modelos de read-me's no passar dos anos e acho que isso é algo que sempre estará em mutação. Mas pra buscar não ser tão enviesado com meu gosto pessoal do que eu gostaria que tivesse nessa documentação, eu resolvi falar com a minha bolha... a famigerada bolha tech. E pra isso eu abri essa thread aqui no twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1563254362402885637-461'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1563254362402885637&theme=dark" }

E com isso eu consegui entender o que as pessoas viam de valor no read-me de um projeto e com isso eu tentei consolidar o seguinte pros meus projetos (pessoais e da empresa).

Better read-me's

Bom... aqui eu começo fazendo um apelo. Por favor... por favor meesmo... não deixem o projeto sem o mínimo de informação no Read-me ou com a documentação padrão gerada pelo framework que você tá usando.

Feito esse apelo, vamos ao que interessa.

Comece pelo básico

Algumas informações são essenciais para que as pessoas minimamente entendam o que o seu projeto está fazendo e deveriam estar em todo README como o mínimo aceitável.

O nome do projeto
Uma breve descrição do projeto (mesmo que você repita isso no About do Github)
E comandos importantes que possam ser executados no projeto.

Com esse mínimo, você vai tirar as pessoas da mais completa zona de escuridão e vai permitir que ela tenha um entendimento básico do escopo do projeto e vai saber o que ela precisa fazer pra rodar o projeto.

Nesse contexto mínimo ainda vale adicionar uma área para dependências (sejam elas quais forem) para rodar/testar o projeto.

Veja um exemplo de README enxuto aqui https://gist.github.com/marcopollivier/7d4a378332f23d5c6302abc357848064#file-readme_minimo-md

Vá além do básico

O modelo anterior é o mínimo que um projeto deveria ter. Nenhum projeto novo que será usado por outra pessoa - ou por você mesmo no futuro - deveria ter menos do que isso.

Porém se você quiser ir um pouco mais além, existem outras informações que também não são complexas de manter e que proporcionarão um maior suporte ao seu projeto. São elas:

Toda a lista anterior (obviamente);
Principais funcionalidades
Breve desenho da arquitetura (especialmente as principais integrações. Para esse ponto, recomendo fortemente utilizar a integração entre Github e Mermaid)
Características relevantes como latência, escalabilidade e segurança
Links para documentações e links de referências

README campeão

O modelo anterior já podemos entender que será um excelente apoio para quem está chegando no repositório pela primeira vez. Mas vale lembrar que com o advento dos micro-serviços, a gestão ficou muito mais granular e complexa de manter. Então, para um readme campeão, esse ponto precisa ser levado em conta. E para isso, busque chegar a esse modelo final, adicionado os seguintes tópicos ao anteriores:

O Contexto de criação do projeto/serviço
Quais problemas tentam ser resolvidos
O escopo do projeto (para qual finalidade ele foi pensado e o que ele NÃO vai atender) e
Alternativas que poderiam ser usadas no lugar desse projeto e porque não foram usadas.

Ah... use e abuse de tags como essas

Essas tags podem ser usadas tanto para métricas básicas como ferramentas para ajudar a criar links para documentações, boards e etc.

No fim, seu README campeão vai ficar parecido com esse aqui https://gist.github.com/marcopollivier/7d4a378332f23d5c6302abc357848064#file-readme_campeao-md

Considerações finais

Escrever e manter uma boa documentação é tão importante quanto escrever e manter um bom código. Se você não faz um dos dois, existe a grande possibilidade de você também negligenciar o outro. Documentações são uma forma de você dar contexto histórico ao que estava acontecendo em um determinado momento para que pessoas no futuro entendam o motivo das decisões tomadas. Além de ser uma excelente ferramenta de performance. Isso mesmo que você escutou. As pessoas associam a criação de documentação como algo burocrático, tedioso e que toma tempo. Mas quando você escreve o mínimo (como mostrei aqui nesse texto), as próximas pessoas que precisarem entender, ganharão um tempo absurdo no entendimento do que o projeto ou serviço se propõe. Escrever documentação faz parte da rotina de um bom Engenheiro de Softwares. Escrever documentação faz parte do processo de amadurecimento de qualquer profissional.

Gerencie suas versões Go com GVM

Marco Ollivier — Tue, 25 Aug 2020 22:42:56 +0000

Ganhe produtividade gerenciando as versões Go na sua máquina de forma simples usando o GVM

Introdução

A configuração de um ambiente de desenvolvimento Go pode ser um pouco confusa para quem está acostumado a trabalhar com outras linguagens. Quando estamos falando de versões do Go inferiores a 1.11, o cenário ainda pode se tornar mais chato devido suas peculiaridades (que não serão abordadas nesse momento, mas quem já precisou, sabe do que se trata).

Como de padrão no mundo Go, a documentação oficial traz uma solução que se mostra relativamente fácil, bem clara e objetiva; e que, inclusive, fala sobre a questão de ter mais de uma versão do Go instalada ao mesmo tempo.

veja mais sobre como configurar o seu ambiente na Documentação Oficial Golang

Mesmo assim, o gerenciamento é um trabalho manual que exige uma quantidade grande de passos e que tende a ficar mais complicada dependendo da quantidade de versões instaladas que você possui.
O chaveamento entre versões também pode ser um problema quando você possuir diferentes projetos no seu workspace que estejam em fases de maturidade diferentes. Se você tem projetos antigos em uma determinada versão, mas quer escrever um novo com uma versão mais atual, isso também pode ser um processo trabalhoso.
Pensando em diminuir essa complexidade e melhorar o gerenciamento de versões, surgiu o GVM.

Admito que me preocupo um pouco em escrever sobre uma ferramenta que não tem recebido commits recentes (enquanto escrevo esse texto, tem 1 ano desde o último commit), mas como ele ainda tem se mostrado uma ferramenta relativamente útil no meu dia-a-dia, prefiro apostar na recomendação.
Note que algumas outras linguagens já possuem ferramentas que fazem um trabalho similar. É o caso, por exemplo, do NVM para o gerenciamento de versões Node.JS.

Ambiente

É importante frisar antes de mais nada que estamos fazendo todo esse processo em um ambiente Linux. Mais precisamente para esse exemplo estamos utilizando a Versão 18.04.2 LTS do Ubuntu, mas já fiz o mesmo procedimento em um ambiente MacOS e funciona tão bem quanto.

Instalação

Para instalar execute o seguinte comando de acordo com o seu interpretador shell.

Bash

$ bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)

$ zsh < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)

Esse comando irá gerar uma .gvm dentro da sua home. Mo meu caso, a pasta foi criada em ~/.gvm

Restarte o terminal e execute o comando gvm version para confirmar que a instalação foi efetuada com sucesso.
Eventualmente pode acontecer de algumas dependências não estarem instaladas. Por exemplo, no ambiente que estou usando como base para esse texto, ainda faltava instalar algumas dependências.

Com as dependências devidamente instaladas, executamos novamente o comando gvm version e teremos o seguinte retorno.

Note que para que o comando gvm seja identificado pelo Sistema Operacional, uma nova linha foi adicionada dentro do seu arquivo bashrc.

Instalando Go

Agora vamos efetivamente instalar as versões que queremos ter como opções no nosso ambiente. Nesse caso, vamos instalar as versões 1.10 e a 1.11, sendo a última como nossa versão padrão. Para isso, basta executar os seguintes comandos:

$ gvm install go1.10 -B
$ gvm install go1.11 -B

Para a versão 1.11 como padrão, execute:

$ gvm use go1.11 --default

Para validar, liste as versões instaladas por meio do comando:

$ gvm list

Você terá o seguinte retorno

Feito isso já teremos nosso ambiente pronto para uso e as variáveis de ambiente $GOROOT e $GOPATH já foram configuradas automaticamente. Por padrão são definidos nos caminhos:

#GOPATH
~/.gvm/pkgsets/go1.11/global
#GOROOT
~/.gvm/gos/go1.11

Validando

Feito todo esse processo de instalação, a forma que usamos o Go no nosso ambiente não deve ser influenciada. Então vamos validar o que fizemos. Para isso, vamos criar um Hello.go com o seguinte código.

package main

import "fmt"

func main() {
    fmt.Printf("hello, world\n")
}

E aí está…. verificamos que a versão instalada é a que selecionamos e também que nosso código foi executado com sucesso.

Conclusão

Mesmo a documentação mostrando que pode ser relativamente simples manter mais de uma versão instalada ao mesmo tempo de forma “nativa”, gastar tempo configurando ambiente é uma coisa que ninguém gosta e o GVM se mostra eficiente nesse aspecto. Instalar uma nova versão e chavear entre elas se mostra uma tarefa muito menos custosa usando esse gerenciador de versões. E você, o que achou? Deixe seu comentário e até a próxima.

Gostou do GVM.? Leia mais detalhes na documentação oficial no Github

moovweb / gvm

Go Version Manager

gvm

By Josh Bussdieker (jbuss, jaja, jbussdieker) while working at Moovweb

Currently lovingly maintained by Benjamin Knigge

Pull requests and other any other contributions would be very much appreciated.

GVM provides an interface to manage Go versions.

Features

Install/Uninstall Go versions with gvm install [tag] where tag is "60.3", "go1", "weekly.2011-11-08", or "tip"
List added/removed files in GOROOT with gvm diff
Manage GOPATHs with gvm pkgset [create/use/delete] [name]. Use --local as name to manage repository under local path (/path/to/repo/.gvm_local).
List latest release tags with gvm listall. Use --all to list weekly as well.
Cache a clean copy of the latest Go source for multiple version installs.
Link project directories into GOPATH

Background

When we started developing in Go mismatched dependencies and API changes plagued our build process and made it extremely difficult to merge with other peoples changes.

After nuking my entire GOROOT several times and…

View on GitHub

Forem: Marco Ollivier

Como resolver um "Failed to Download Module" do Terraform / OpenTofu

Do nada as coisas quebram

Investigação

Obvio que a AI não me ajudou

Por que eu não li o erro desde o começo?

Solução

Pratique com APIs de verdade - ClimaTempo

A API ClimaTempo

A API em números

O Dashboard

A Documentação

Colocando em prática

O contrato

Conclusão

Próximos passos

Não se preocupe mais com o package manager do seu projeto NodeJS

O Ni

antfu-collective / ni

💡 Use the right package manager

ni

ni - install

Conclusão

XML Parsing em NodeJS com XMLBuilder2

oozcitak / xmlbuilder2

An XML builder for node.js

xmlbuilder2

Installation:

Documentation:

Usage:

Custo x Benefício da biblioteca

Utilização

marcopollivier / practice.node-with-xml

Projeto de PoC sobre como manipular XMLs com NodeJS de uma forma menos custosa

practice.node-with-xml

Primeira tentativa: A solução padrão

Segunda tentativa: Usar um objeto JSON

Conclusão

SOAP com TypeScript em pleno 2023

Soap soup

Alinhando os patos

WebService, SOAP, SOA e até mesmo REST

O WSDL

Conclusão

READMEs: o primeiro passo para uma boa documentação

Do começo

Twitter... fale comigo

Better read-me's

Comece pelo básico

Vá além do básico

README campeão

Considerações finais

Leia mais sobre documentação

Gerencie suas versões Go com GVM

Introdução

Ambiente

Instalação

Instalando Go

Validando

Conclusão

moovweb / gvm

Go Version Manager

gvm

Features

Background

`ni` - install