DEV Community: Giovanny Cordeiro

Multithreading e corrotinas com Ruby

Giovanny Cordeiro — Sat, 07 Sep 2024 16:03:12 +0000

O mecanismo de multithreading é o que permite ao desenvolvedor executar várias rotinas simultaneamente, promovendo um resultado mais rápido e eficiente em alguns cenários. Metaforicamente, seria como em uma loja: enquanto uma pessoa atende o cliente, outra está no estoque separando o pedido, outra oferecendo um café e assim por diante, todas colaborando para a melhor experiência do cliente. Agora, relacionando esse exemplo com a computação, a loja seria o programa multithread e as pessoas, as threads. Neste artigo, explico como utilizar os principais módulos de multithreading em Ruby, como Threads, Fibers e Ractors.

Tabela de conteúdos

Como o Ruby lida com multithread
Thread: O Principal modulo para multithread em Ruby
Fibers: Utilizando corrotinas com Ruby
Ractors: Como passar por cima do GIL
Conclusão e agradecimentos

Como o Ruby lida com multithread

Antes de entrar de cabeça no entendimento dos módulos é necessário dar uma contextualização a respeito de como o Ruby lida por padrão com threads e como ele garante o thread safety.

O Ruby lida com Threads e garante o thread safety de suas aplicações por meio do GIL (Global Interpreter Lock), é o GIL que bloqueia que um programa Ruby tenha mais que uma thread, pois, com apenas uma thread executando, garantimos que não teremos nenhum dos problemas que multithreads podem acarretar, como race condition, deadlocks, starvation e etc, caso deseje aprender a respeito desse o conteúdo, recomendo o ártigo Deadlock, Livelock, Race condition and Starvation para começar.

A utilização do GIL é bastante frequente em linguagens de programação interpretadas. O Python, por exemplo, também tem um GIL e é isso que garante o Thread Safety.

Com base nessa explicação, geralmente não é possível implementar multithread com Ruby, a menos que ignoremos o GIL ou Ruby nos forneça outra maneira de usar um código paralelo.

E é por meio da utilização de outro artifício que a classe Thread implementa multithread. Agora vamos entender como utilizar o modulo Thread e como esse “outro artifício” funciona.

Thread: O Principal modulo para multithread em Ruby

O principal módulo para realizar multithread em Ruby, como já mencionado, é o módulo Thread. É dele que podemos criar e manipular threads no Ruby. Primeiramente vamos entender como criar uma Thread.

Para criar uma Thread em Ruby, é necessário seguir algumas etapas bastante simples, vou apresentar um exemplo e logo em seguida vou explicar como o mesmo se comporta.

Thread.new { puts 'Uma mensagem que esta executando na thread' }
puts 'Fim do programa'

Primeiramente, declaramos a nova Thread, instânciando a classe Thread com o método ⁣.new. Em seguida, declaramos o código que desejamos que a Thread execute, que no nosso caso é a mensagem no terminal Uma mensagem que está executando na thread⁣
Ao final do programa, mandamos uma mensagem com o texto "Fim de programa"

No entanto, caso executemos esse código, o resultado será a mensagem "Fim do programa", quando gostaríamos que fosse, "uma mensagem que está executando na thread" e, logo em seguida, a mensagem do "Fim do programa".

Para entender esse erro no fluxo de execução, precisamos entender como a classe Thread utiliza o “artificio” que mencionamos no começo do artigo e como isso impacta a execução do programa.

O Artificio da classe Thread

Para manter o Thread Safety garantido pelo GIL, o Ruby usa um mecanismo que, em resumo, "desvia" do GIL. Vamos entender isso mais de perto.

Ao usar o método .new que instância a classe, o que acontece por debaixo dos panos é que o Ruby passa a Thread recém criada para o scheduler. O scheduler agenda a execução da Thread para que ela seja executada assim que possível pelo Sistema Operacional. Quando essa ela for executada, o valor é retornado para a Thread principal, que é a Thread do GIL e do interpretador Ruby.

Por meio dessa manobra, não conseguimos controlar exatamente quando a nova Thread será executada. Pois, quando ela é passada para o scheduler não temos mais poder algum sobre ela, apenas temos a garantia de que será executada assim que possível.

Com isso, vamos ter o mecanismo semelhante ao multithreading, mas que é gerenciado diretamente pelo sistema operacional.

Agora, para resolver o problema do fluxo de execução do nosso exemplo, é importante entender que, enquanto a nova thread está sendo criada e agendada, a thread principal continuará a ser executada normalmente.

Mas no caso de a thread principal terminar, ela automaticamente encerrará todas as suas threads filhas, o que pode impedir que as threads filhas alcancem o resultado desejado.

E é justamente isso que está acontecendo no nosso caso: o programa principal termina antes que a execução da(s) filha(s), seja porque o scheduler não encontrou um momento oportuno para agendar a thread, seja porque estávamos no meio da execução do código passados a ela.

Resolvendo o problema

Para resolver esse problema, precisaríamos desenvolver um método que avise à thread principal para aguardar a conclusão da execução da thread filha (ou das threads filhas, caso haja mais de uma) antes de finalizar a principal.

Felizmente, não é necessário implementar esse método manualmente, pois o Ruby já fornece o método .join. Método esse serve exatamente para fazer com que a thread principal aguarde a conclusão de uma ou mais threads filhas antes de terminar a sua própria execução.

Vamos corrigir o nosso exemplo:

thread = Thread.new { puts 'Uma mensagem que está executando na thread' }
puts 'Fim do programa'
thread.join

'Fim do programa'
'Uma mensagem que está executando na thread'

Agora, temos o resultado desejado com ambas as mensagens exibidas no terminal. Note que a mensagem "Fim do programa" aparece antes da mensagem "Uma mensagem que está executando na thread". Caso você queira inverter a ordem, basta chamar o método .join antes da linha puts 'Fim do programa'.

Uma aplicação mais próxima da realidade

Vamos agora explorar um exemplo mais real, que mostra uma aplicação prática e poderosa do uso de multithreading, permitindo-nos também explorar outros conceitos.

No seguinte exemplo, temos um programa em Ruby que tem como objetivo baixar 12 imagens de maneira rápida, utilizando as URIs dessas imagens.

require 'net/http'
require 'uri'

pictures = %w[ <<lista_com_12_URIs_de_imagens>> ]
parts_list = pictures.each_slice(3).to_a

threads = parts_list.each_with_index.map do |part_list, group_index|
  Thread.new(part_list) do |arr_url|
    arr_url.each_with_index do |uri, image_index|
      total_index = group_index * 3 + image_index
      file_name = "pica-pau-#{total_index}.jpg"
      url = URI.parse(uri)
      response = Net::HTTP.get_response(url)
      if response.is_a?(Net::HTTPSuccess)
        File.open(file_name, 'wb') do |file|
          file.write(response.body)
        end
      else
        puts "Falha no momento da requisição #{response.code}: #{response.message}"
      end
    end
  end
end
threads.each(&:join)

A lógica central do algoritmo é a seguinte: temos uma lista de 12 URIs de imagens armazenadas na variável pictures. Dividimos essa lista em 3 partes iguais, que são armazenadas na variável parts_list. Em seguida, utilizamos o método parts_list.each_with_index.map para criar uma thread para cada parte da lista.

Cada thread criada percorre a parte correspondente da lista de URIs usando o método arr_url.each_with_index. Para cada URI, a thread realiza uma requisição que baixa a imagem e a salva na máquina do usuário, desde que a resposta da requisição seja bem-sucedida (if response.is_a?(Net::HTTPSuccess)). Caso contrário, uma mensagem de falha é exibida no terminal.

No entanto, vamos alisar um ponto especifico do código, que é o seguinte:

threads = parts_list.each_with_index.map do |part_list, group_index|
  Thread.new(part_list) do |arr_url|
    arr_url.each_with_index do |uri, image_index|
      # logica restante

Perceba que, ao criar uma thread para cada parte da lista, precisamos passar a variável como argumento para o construtor da classe Thread. Isso é feito na linha Thread.new(part_list) do |arr_url|, onde part_list é passado como argumento. Para que em seguida, utilizemos a variável como parâmetro dentro da thread, como mostrado em arr_url.each_with_index do |uri, image_index|.

Você pode se perguntar por que devemos fazer dessa forma, quando poderíamos usar a variável part_list diretamente, sem passá-la como argumento para a Thread, como mostrado no exemplo a seguir:

threads = parts_list.each_with_index.map do |part_list, group_index|
  Thread.new do
    part_list.each_with_index do |uri, image_index|
      # logica restante

Existe uma razão bem plausível para isso, nós priorizamos a primeira abordagem que passa a variável para a Thread como argumento, para garantir o Thread safety e o compartilhamento eficaz de variáveis entre as threads.

Usar a variável part_list diretamente, por meio do escopo global como exemplificado na segunda abordagem, poderia causar problemas de execução e dessincronia entre as threads. Por exemplo: Se a Thread 01 for criada e entrar em execução, e logo em seguida a Thread 02 ser criada, a Thread 01 poderia modificar part_list enquanto a Thread 02 ainda estaria lendo a variável. Isso pode levar a erros de sincronização e tornar a detecção e correção desses erros bastante complicada.

Para evitar esse tipo de confusão, seguimos a primeira implementação, que faz uma cópia do valor que queremos utilizar para cada nova Thread. Dessa forma, cada uma delas trabalha com sua própria cópia da variável, evitando problemas entre threads e garantindo a sincronização.

A ilustração a seguir apresenta a primeira implementação de maneira mais visual.

Esse tipo de implementação utilizando Multithreading promove uma melhoria de desempenho muito significativa quando comparado com a abordagem tradicional mono thread.

Confira no vídeo a seguir e observe a diferença de tempo entre um algoritmo executado com uma única thread tradicional e o mesmo algoritmo otimizado com multithreading.

Caso tenha curiosidade em ver a diferença de desempenho na sua máquina ou analisar o código, você pode ver ambas implementações disponíveis aqui no meu GitHub.

Fibers: Utilizando corrotinas com Ruby

Fibers é um mecanismo que torna possível interromper a execução de uma parte do código para executar outra. Esse tipo de funcionalidade é também conhecido como corrotinas (or coroutines, if you prefer to speak English).

Quando a rotina principal é interrompida, ela permite que uma rotina secundária seja executada, com a expectativa de que, em algum momento, a rotina secundária retorne o controle para a rotina principal.

É essa característica que faz com que as Fibers sejam multitarefas cooperativas, permitindo que as tarefas colaborem para que, ao final do programa, o resultado esperado seja alcançado.

Por isso, fibers não são uma ferramenta que recorre a multithreading, mas sim uma ferramenta para a implementação de corrotinas, que pode tornar sua aplicação menos complexa e/ou mais flexível.

Vamos entender os comandos principais da abstração Fiber:

Fiber.new é usado para criar uma nova Fiber. Com esse comando, você pode definir a lógica da Fiber por meio de um bloco.
example_fiber.resume: Utilizado para executar o código que esta dentro de uma fiber.
Fiber.yield: Utilizado para retornar o controle para a rotina principal.

Vamos analisar como esses comandos são utilizados com o exemplo prático seguinte:

fiber_example = Fiber.new do
  data = [1, 2, 3]
  data.each do |item|
    puts "Processando #{item}"
    Fiber.yield
  end
  nil
end

3.times do
  puts 'Ola'
  fiber_example.resume
end

Neste exemplo, criamos uma Fiber usando o comando Fiber.new e a armazenamos na variável fiber_example. Dentro da Fiber, definimos uma lógica simples: percorrer cada item do array armazenado na variável data. A cada iteração do array, registramos a mensagem "Processando #{item}" e retornamos a execução para a rotina principal, que foi a que chamou a Fiber.

Toda essa lógica está apenas presente dentro da variável fiber_example e será executada somente quando a Fiber for chamada com fiber_example.resume.

Em seguida, temos um loop que executa o mesmo código três vezes. Em cada iteração, o loop envia a mensagem "Olá" e chama a Fiber.

O resultado após a execução do código é o seguinte:

Ola
Processando 1
Ola
Processando 2
Ola
Processando 3

O que está acontecendo no algoritmo é o seguinte: ele executa o loop 3.times, que imprime a mensagem "Olá" no terminal durante a primeira iteração. Em seguida, o código da Fiber é executado, percorrendo o primeiro item do array data e registrando a mensagem "Processando 1" no terminal. Após essa iteração, a execução da Fiber é pausada e retorna ao loop 3.times na rotina principal. Esse processo se repete até que o loop 3.times termine.

Você pode estar se perguntando sobre o nil após o loop each. O retorno de nil é necessário para informar à Fiber que sua execução chegou ao fim. Neste caso, o nil explícito não é necessário, pois o loop .each já retorna nil ao final de sua execução.

Veja o video da execução do algoritmo:

Caso você tenha interesse em ver outro exemplo de uso de Fibers, vou deixar disponível no meu GitHub um algoritmo de contagem de palavras implementado com Fibers. Exemplo esse que vi no livro "Programming Ruby - The Pragmatic Programmers' Guide".

Ractors: Como passar por cima do GIL

É por meio do modulo Ractor que conseguimos realmente criar multithreads com Ruby. Pois cada Ractor mantém seu próprio GIL, o que pode melhorar o desempenho.

Com ractors podemos compartilhar valores entre threads, mas apenas por maneiras pre-definidas.

No livro "Programming Ruby - The Pragmatic Programmer's Guide", os autores explicam metaforicamente que um Ractor é como uma sala com uma porta de entrada e uma porta de saída, cada uma com possíveis filas.

O conteúdo que preenche a sala representa o código que o Ractor executa, a porta de entrada é por onde os inputs chegam, e a porta de saída é por onde os outputs são gerados. É através dessas "portas" (metaforicamente falando) que o mecanismo de compartilhamento de variáveis funciona.

Para compartilhar variáveis entre Ractors, ou seja, entre threads, você possui quatro opções:

Você pode enviar um valor diretamente para outro Ractor usando o método .send, por exemplo, other_ractor.send. Na metáfora proposta pelo livro, isso é como enviar uma pessoa para a porta de outro Ractor. Essa mecânica é não bloqueante entre as threads.
Você pode receber o output de outro Ractor usando o método other_ractor.take. Na metáfora, isso é como deixar uma pessoa na porta de saída do outro Ractor, com a tarefa de pegar o que sai da porta. No entanto, esse mecanismo é bloqueante, pois aguarda o resultado da outra thread.
Dentro do código de um Ractor, você pode esperar receber um input externo para executar uma determinada ação. Metaforicamente, isso é como esperar alguém entrar pela porta de entrada. Isso pode ser feito usando o método Ractor.receive.
Também dentro do código de um Ractor, você pode esperar que outro Ractor solicite um valor. Essa tarefa é bloqueante entre threads, pois o Ractor aguarda a solicitação de outro. É como esperar alguém bater na porta de saída para pedir algo, e então o Ractor reage, similar a um serviço de drive-thru.

Um conceito muito importante em Ractors é que todo novo Ractor criado é completamente isolado. Isso significa que o código dentro do Ractor só existe dentro dele e não pode acessar variáveis globais nem passar variáveis diretamente. A única forma de passar variáveis para um Ractor é por meio de chamadas ao método .send.

Existem duas formas de chamadas a um Ractor:

Chamadas externas: Mensagens enviadas para o Ractor a partir de outros lugares no código.
Chamadas internas: Mensagens enviadas de dentro de uma classe que conhece a implementação específica do Ractor.

Esses tipos de comunicação são de grande valia, porque permitem que você garanta o thread safety automaticamente, enviando valores entre Ractors por meio do método .send e recebendo valores usando os métodos .yield e .take.

Vamos ver um exemplo simples utilizando Ractors: um conversor paralelo de valores Celsius para Fahrenheit e Kelvin.

temperatures = [0, 10, 20, 30, 40, 50]
ractor_fahrenheit = Ractor.new(temperatures) do |celsius_list|
  celsius_list.map { |temp| (temp * 9.0 / 5) + 32 }
end

ractor_kelvin = Ractor.new(temperatures) do |celsius_list|
  celsius_list.map { |temp| temp + 273 }
end

list_fahrenheit = ractor_fahrenheit.take
list_kelvin = ractor_kelvin.take

puts "List temperatures in Celsius: #{temperatures}"
puts "Converted temperatures in Fahrenheit: #{list_fahrenheit.inspect}"
puts "Converted temperatures in Kevin: #{list_kelvin.inspect}"

Nesse exemplo, o resultado no terminal seria:

List temperatures in Celsius: [0, 10, 20, 30, 40, 50]

Converted temperatures in Fahrenheit: [32.0, 50.0, 68.0, 86.0, 104.0, 122.0]

Converted temperatures in Kevin: [273, 283, 293, 303, 313, 323]

É importante deixar claro que o módulo Ractor ainda é experimental na versão Ruby 3.3.1, que foi a versão que utilizei para testar os códigos enquanto escrevia este artigo. Portanto, o módulo pode conter erros que ainda não foram corrigidos. Se optar por usá-lo, faça-o por sua própria conta e risco.

Além disso, como Ractors realmente passam por cima do GIL e implementam multithreading real no Ruby, é crucial estar atento a problemas de sincronização de dados e deadlocks ao utilizar este módulo.

Conclusão e agradecimentos

Neste artigo, passamos pelos principais módulos de multithreading e corrotinas no Ruby: Threads, Fibers e Ractors. Enquanto estudava sobre esse tema, me surgiu várias ideias sobre como utilizá-los em diferentes cenários. Por isso, decidi escrever este artigo para compartilhar o conhecimento e ajudar outras pessoas a encontrarem outras formas de utilizar.

Não poderia deixar de agradecer a Cherry, o Henry e o Clinton por ter disponibilizado um tempinho para ler esse artigo e propor melhorias e dicas, muito obrigado de verdade gente ❤️. Agradeço também a toda comunidade da He4rt Developers que sempre me ajuda quando passo por perrengues técnicos.

Espero que o artigo tenha sido útil para entender os conceitos e as implementações desses módulos. Se você encontrar qualquer ponto negativo ou erro, estou totalmente à disposição para corrigir e aprender com você nos comentários!

Referências

Memorização em Ruby

Giovanny Cordeiro — Mon, 22 Jul 2024 20:58:39 +0000

Gostar de desenvolver algoritmos que desempenham bem é uma característica presente na maioria dos devs, quando vemos aquele algoritmo bem escrito que performa lindamente sentimos aquela felicidade na alma, mas sabemos que muitas das técnicas de melhoria de desempenho envolvem muitos tradeofs e implementações complexas. Hoje eu vou explicar uma técnica bem simples para melhorar o desempenho dos seus algoritmos, a memorização.

O que é memorização
Primeira implementação utilizando operador de atribuição ou
Segunda implementação utilizando a palavra chave defined
Quando utilizar uma implementação ou outra
Terceira implementação utilizando método tap
Conclusão

O que é memorização

Em termos gerais, memorização é uma técnica que envolve você memorizar, lembrar ou guardar, de alguma forma, uma resposta de um método caro para evitar ficar usando desnecessariamente.

O que seria um "método caro"?

Um "método caro" seriam aqueles métodos que podem demandar muita memória, processamento, chamam diversos serviços terceiros ou que naturalmente têm uma complexidade inevitavelmente maior.

Com essa definição em mente, o Ruby oferece ferramentas interessantes que permitem técnicas interessantes de implementação de memorização. Separei três técnicas que achei interessante para apresentar e vou explicá-las na seguinte ordem.

Primeiramente, eu mostrarei as duas implementações principais de memorização, após isso, explicarei quando escolher uma ao invés da outra a depender do caso específico e por fim mostrarei uma terceira forma diferente de implementação a fim de conhecimento.

Primeira implementação utilizando operador de atribuição ou

A primeira forma de implementar memorização é utilizando apenas o “operador de atribuição ou” ||=, sendo muito importante para o funcionamento adequado da memorização.

Você pode estar se perguntando: “Certo, mas o que é esse abençoado 'operador de atribuição ou'?”

Este operador segue apenas uma condição, só atribui um novo valor à variável se o valor atual for false ou nil. Caso contrário, ele irá manter o valor atual da variável.

Vamos para um exemplo:

example_variable = false
example_variavel ||= 'Giovanny'
puts example_variable # 'Giovanny'

example_variavel ||= 'Fulano'
puts example_variable # 'Giovanny'

Perceba que na primeira atribuição do valor Giovanny utilizando o “operador de atribuição ou” a variável example_variable foi bem-sucedida, pois o valor atual da example_variable era false.

No entanto, na segunda atribuição, que tinha como valor Fulano utilizando o “operador de atribuição ou” para a variável example_variable, não foi bem-sucedida, pois o valor atual da variável example_variable era uma string “Giovanny” e não valores nil ou false.

Com isso em mente, podemos guardar o valor de retorno vindo de um método caro em uma variável utilizando o “operador de atribuição ou”. Uma vez que esse método for executado, a variável guardará esse valor e não será necessário executar o método novamente para o caso.

No exemplo a seguir, o método caro será o expensive_method e ele retornará como valor uma string. Para deixar ainda mais claro, fixarei uma string de retorno a fim de exemplificação, que nesse caso será a string MOLA.

Exemplo:

class EspecifiqClass
  def some_method
    @store ||= expensive_method
  end

  private

  def expensive_method
    puts 'Executando expensive_method'
    # many logic
    'MOLA'
  end
end

example = EspecifiqClass.new
puts example.some_method # Retorno do valor "Mola" executando o expensive_method
puts example.some_method # Retorno do valor "Mola" sem executar o expensive_method

Resultado:

algorith_test git:(main) ✗ ruby test.rb
Executando expensive_method
MOLA
MOLA

Nesse caso, percebe-se que estamos chamando duas vezes o método some_method, no entanto, o método some_method vai apenas chamar o método privado expensive_method apenas na primeira vez.

Isso faz sentido porque a variável example é uma instância da classe EspecifiqClass e, na primeira execução do método some_method a variável @store não tinha nenhum valor, logo, a condição do “operador de atribuição ou” vai ser atendida executando o método privado expensive_method e armazenando seu resultado na variável @store.

Já na segunda chamada do método some_method a variável @store agora tem um valor MOLA, fazendo a condição do “operador de atribuição ou” não seja atendida e fazendo o método some_method retorne o valor MOLA.

Com isso, na segunda chamada, você acaba de ter o resultado esperado, mas sem demandar executar novamente o método caro. Podemos comprovar isso pela mensagem no console "Executando expensive_method" ser executada apenas uma vez.

E se...

E se em vez o valor do retorno do método expensive_method se uma string estivéssemos recebendo um valor booleano (true e false), o que aconteceria?

Aconteceria que teríamos o caso em que o valor false seria efetivamente um valor a ser guardado na variável, mas como estamos utilizando diretamente o "operador de atribuição ou" (||=) ele não iria guardar esse valor, pois, a condição do operador vai ser sempre positiva nesse caso, pois o valor vai ser efetivamente false.

Vamos mudar o método expensive_method para que ele retorne um booleane vamos avaliar o seu funcionamento. Para facilitar a explicação, vamos fixar o valor false como retorno.

class EspecifiqClass
  def some_method
    @store ||= expensive_method
  end

  private

  def expensive_method
    puts 'Executando expensive_method'
    # many logic
    false
  end
end

example = EspecifiqClass.new
puts example.some_method
puts example.some_method

Resultado:

algorith_test git:(main) ✗ ruby test.rb
Executando expensive_method
false
Executando expensive_method
false

Podemos perceber que o expensive_method está executando duas vezes mesmo quando efetivamente estamos devolvendo um valor false que deveria ser guardado. Pelo motivo antes explicado da condição do "operador de atribuição ou" está sendo positiva ele não está guardando o valor false e executando novamente o método expensive_method.

Nesse caso, temos valores falsos legítimos e precisamos consertar esse problema guardando o valor. Para suprir essa lacuna, a segunda implementação de memorização será bem útil.

Segunda implementação utilizando a palavra chave defined

Para resolver o problema de “valores falsos legítimos” no caso do nosso método caro retornar valores falsos, precisamos verificar se existe um valor anterior na variável efetivamente.

Caso exista algum valor, a gente retorna esse valor, caso contrário, a gente executa o método caro.

Para verificar se a variável tem um valor ou não, podemos usar a palavra-chave defined?. Essa palavra-chave verificará se a variável está definida ou não, caso esteja, ela retornará o tipo da declaração dela, caso não esteja, ela retornará nil.

Segue o exemplo desse conceito, na prática, utilizando o REPL do Ruby:

irb(main):001> defined? example
=> nil
irb(main):002> example = 'test'
=> "test"
irb(main):003> defined? example
=> "local-variable"

Como podemos ver, quando verificamos se uma variável que não foi definida previamente está definida na primeira linha, ele retornará o valor nil. Nesse caso, estamos verificando se a variável example foi definida na primeira linha.

Mas quando realmente definimos a variável na segunda linha e depois verificamos se ela foi definida na terceira linha o Ruby retorna o tipo de declaração dela.

Agora, com esse entendimento da palavra-chave defined? podemos realmente guardar valores false legítimos da seguinte forma:

class EspecifiqClass
  def some_method
    return @store if defined? @store
    @store = expensive_method
  end

  def expensive_method
    # many logic, return the boolean value
    false
  end
end

example = EspecifiqClass.new
puts example.some_method # false (Executando o expensive_method)
puts example.some_method # false (Não executando o expensive_method)

Na primeira linha do método some_method ele verificará se a variável @store foi definida, em caso positivo, ele retornará diretamente à variável com seu valor. Caso contrário, ele chamará o método expensive_method que armazenará o valor retornado na variável @store e retornará à variável.

Quando utilizar uma implementação ou outra

Após mostrar as duas implementações, acredito que você já tenha uma boa noção de quando usar ambas, no entanto, eu vou apenas recapturar.

Utilize a segunda implementação que usa a palavra-chave defined? quando o método caro poder retornar um valor falso legitimo, com isso, você armazenará efetivamente o valor false na variável normalmente.

Caso o retorno da função cara seja de outros tipos como stringsou objects, por exemplo, você pode seguir a primeira implementação que utiliza apenas o “operador de atribuição ou” (||=) normalmente, você estará tranquilo com essa implementação.

Terceira implementação utilizando método tap

Existe uma terceira forma de fazer uma implementação de memorização onde o retorno do “método caro” é um hash no Ruby, que o engenheiro de software “Alex MacArthur” apresentou no seu artigo "Elegant Memoization with Ruby’s .tap Method".

Inclusive, teve uma discussão interessante nesse artigo onde algumas pessoas alegam não enxergar efetivamente um “beneficio” na forma de implementação que o Sr. MacArthur trouxe. Caso tenha curiosidade sobre essa discussão (como eu tive), leia os comentários e os pontos que as pessoas trouxeram no artigo, não vou me atentar a detalhes aqui.

De toda forma, achei interessante ver outra forma de implementação sobre o tema e por isso decidi mencionar aqui.

Antes de ir para a implementação, é necessário entender o que é esse método .tap.

De acordo com a documentação do ruby em uma tradução direta, o método .tap:

Entrega-se ao bloco e depois devolve-se. O objetivo principal deste método é “entrar” numa cadeia de métodos, de modo a realizar operações em resultados intermédios dentro da cadeia.

A documentação menciona a "cadeia" porque esse método brilha especialmente no debbug de cadeia de métodos, no entanto, vamos nos ater ao nosso tema.

O que importa para nós é que ele apenas entra na cadeia e depois devolve normalmente, o que significa que podemos entrar em um hash e depois devolver resultados a ele

Parece confuso, eu sei, mas vamos para um exemplo da implementação de memorização utilizando o método .tap.

Nesse exemplo, temos uma classe chamada ExampleClasse onde o método people_detail vai memorizar detalhes das informações da pessoa, como nome e idade, mantendo o padrão do artigo, todos os dados também serão fixados no código.

Segue o exemplo:

class ExampleClass
  def name
    people_detail['name']
  end

  def age
    people_detail['age']
  end

  private

  def people_detail
    @people_detail ||= {}.tap do |people_store|
      puts 'Memorização people_detail'
      people_store['name'] = 'Giovany'
      people_store['age'] = 21
    end
  end
end

instance_one = ExampleClass.new
puts instance_one.name
puts instance_one.age

O resultado no console:

Memorização people_detail
Giovany
20

Nota-se que essa implementação é bem concisa em apenas um método, onde o próprio método verifica se a variável @people_detail é false ou nil com o “operador de atribuição ou” e em caso positivo, ele dispara o método .tapque aplica a lógica que está sendo passada a ele que por sua vez armazena as informações no hash. Achei superinteressante essa outra forma de implementação.

O resultado no console prova que a memorização dos dados foi feita de forma bem sucedida, pois a lógica passada para o método .tap foi apenas executada uma vez, pelo que mostra a mensagem Memorização people_detail no console.

Conclusão

Existem mais formas de tornar mais complexo o tema, como, por exemplo, colocando mais parâmetros para memorizar, mas está fora do escopo desse artigo introdutor, talvez no futuro eu faça uma parte dois sobre esse tema. Espero que esse artigo tenha te ajudado a aprender sobre memorização!

E claro, não poderia deixar de agradecer à Cherry, Cliton e ao Williams por darem feedback nesse artigo antes dele ser postado, foi por conta deles que eu consegui deixar esse artigo melhor, meus sinceros muito obrigado ❤️.

Referências

Pequeno guia de webhooks com Ruby!

Giovanny Cordeiro — Thu, 16 May 2024 10:50:02 +0000

Nesse artigo irei explicar um pouco sobre Webhooks, seu uso e um exemplo prático ao final, espero que ajude seus estudos!

Inicio!

O conceito formal fornecido pela RedHat é:

"Um webhook é uma função de retorno de chamada baseada em HTTP que viabiliza a comunicação lightweight e orientada por eventos entre duas interfaces de programação de aplicações (APIs, na sigla em inglês)."

Para sintetizar, um webhook existe para comunicar que um evento aconteceu em um sistema A para um sistema B.

Se pararmos para pensar, esse conceito de "comunicar um evento que aconteceu em um sistema A para um sistema B" é muito útil, já que muitos sistemas precisam desse tipo de funcionalidade recorrentemente.

Um exemplo legal e bem comum é um e-commerce, que depende de muitos sistemas diferentes se comunicando para funcionar adequadamente como sistema de pagamento, entrega, o marketplace, mecanismos de recomendações, etc.

Para ficar mais fácil o exemplo que eu vou dar não irei mencionar muitas variáveis como essas no sistema, então, imagine então um sistema de e-commerce simples com apenas um serviço de pagamento.

O e-commerce é naturalmente responsável por promover a venda e captar todas as informações necessárias do cliente, validar os dados, etc.

Já o serviço de pagamento tem como objetivo de efetivamente comprovar o pagamento a respeito do pedido do cliente.

É intuitivo pensar que você só poderá atualizar a página de feedback do pedido para "pagamento efetuado" depois que realmente o pagamento for efetuado, mas como a gente vai fazer para que o e-commerce saiba que o cliente efetivamente pagou o pedido?

O serviço de pagamento é um sistema diferente do e-commerce, como a gente vai fazer para poder integrar ambos?

A primeira abordagem.

A primeira e mais obvia solução é vc fazer uma função dentro do seu e-commerce que vai ficar fazendo requisições para o serviço de pagamento, perguntando se o cliente fez o pagamento daquele pedido, você não vai querer ficar disparando toda hora essa requisição e pode fazer com que ela faça a requisição de 1 em 1 minuto, parece OK certo?

ERRADO!

Vamos supor que ocorreu o primeiro pedido do e-commerce e agora só falta o cliente realizar o pagamento, agora é só esperar ele pagar e dentro de 1 minuto sua aplicação vai atualizar a tela.

No entanto... o usuário não paga depois desse 1 minuto e nem da o ar da graça nas próximas 2hrs, o que aconteceu foi que ele, enquanto fazia o pedido no e-commerce, esqueceu que tinha que levar a vó dele para o treino de Jiu Jitsu e como ele é um bom neto, vai ficar para prestigiar o treino de sua vó e vai demorar 2hrs para voltar. Mas o mesmo usuário pensou "vou deixar o pedido aqui, quando voltar eu pago".

Nessas duas horas que se passaram seu e-commerce fez 120 requisições para o seu serviço se pagamento sem qualquer informação relevante do pagamento, sem qualquer nova atualização, perdendo capacidade computacional e gerando desperdício no sistema (Leia perca de dinheiro).

E isso foi apenas de um usuário imagina se fosse 100 usuários, que é um numero baixo, seria 12000 requisições jogadas completamente no lixo.

E qual seria uma abordagem melhor?

Abordagem com Webhook

Agora imagina que a gente pode ter um intermediário que avisa para o e-commerce que o pagamento de um pedido foi realizado? Isso seria ótimo certo? Iriamos fazer com que todo aquele desperdício da primeira abordagem fosse excluído e o sistema teria as informações atualizadas mais breve possível.

E esse intermediário ótimo tem nome, ele se chama Webhook. Com o Webhook sendo orientado a evento, podemos avisar por meio dos serviço de pagamento que um determinado pedido foi pago para o e-commerce, de forma simples e fácil, a lógica é a seguinte:

O serviço de pagamento avisa que foi pago um determinado pedido para o webhook, o webhook repassa essa informação para o e-commerce que atualiza agora a tela do usuário para "pagamento realizado" ou outra mensagem escolhida.

Fazendo o primeiro webhook simples!

Vamos colocar a mão na massa e ver como realmente como implementar webhooks. Como eu já expliquei anteriormente webhooks servem para comunicar que um evento aconteceu em um sistema A para um Sistema B, para deixar mais enxuto, vou fazer APIs simples para do webhook.

Para isso é necessário os seguintes elementos:

Primeira API: A primeira API fica esperando um evento acontecer na segunda, ligando com o exemplo que eu dei, poderia ser a API do e-commerce.
O webhook
Segunda API: Que acontece o evento e informa para o webhook para a primeira API, ligando com o exemplo, seria o serviço de pagamento.

As APIs nesse caso poderiam também ser um serviço ou outro sistema!

Só para deixar claro, os exemplos a seguir foram feitos em Ruby com o micro-framework Sinatra, pelo fato de ser a linguagem que eu estou mais gostando de estudar e aprender, mas você pode implementar o mesmo exemplo na sua ferramenta preferida.

Também deixei todo os códigos em um repositório no Github para que você não precise ficar copiando, clicka aqui.

Vamos começar criando a segunda API que é responsavel por notificar o evento para o webhook, o que ela precisa fazer é justamente fazer uma requisição simples para o webhook, como a gente faria para uma API normalmente. Segue o código.

require 'sinatra'
require 'rest-client'  
get '/' do
    puts 'test second app'
end    
post '/service' do
    # Logica do serviço de pagamento...     
    data_service = {
        'body' => 'dados para o primeiro serviço'
    }
    RestClient.post(
        'http://127.0.0.1:4568/webhook/event-created',
        data_service.to_json,
        {content_type: :json, accept: :json}
    )
end

Agora vamos criar o próprio webhook, para isso você precisa criar outra API normalmente, no entanto, essa API vai receber os dados que vem da API 2 (no exemplo que dei, serviço de pagamento) e vai passar para a API 1 por meio de uma requisição POST (no exemplo que dei, e-commerce). Não atoa Webhook são chamados também como APIs inversas.

Ou seja, o webhook recebe uma requisição de uma API (ou serviço) e faz outra requisição POST passando esses dados para outra API (ou serviço).

require 'sinatra'
require 'rest-client'
post '/webhook/event-created' do
    puts 'chegou no webhook'
    request_first_app = RestClient.post(
        'http://127.0.0.1:4567/recieve_event',
        request.body,
        headers: { 'Content-Type': 'application/json' }
    )
end

Só ficou faltando criar a primeira API, que vai receber os dados da Segunda API por meio do webhook, fazendo assim com que tudo funcione da forma adequada.

require 'sinatra'
before do
    request.body.rewind
    @request_payload = JSON.parse request.body.read
end
get '/' do
    puts 'hello world'
end
post '/recieve_event' do
    puts "evento que ocorreu no sistema 2, os dados são: #{@request_payload['body']}"
    # logica após receber o dado do body....
end

Agora o que vai acontecer? Quando você fizer uma requisição POST na rota /service da segunda API essa ela mesma vai executar sua logica e avisar para o webhook que determinado evento evento ocorreu passando os dados escolhidos, o webhook repassa para a primeira API.

Antes de testar, se atente em rodar as APIs e o Webhook nas portas certas, caso contrario, pode ser que tenha dor de cabeça com isso, logo as portas nesse meu exemplo são as seguintes:

first_app: porta 4567
weebhook: porta 4568
second_app: porta 4569

Após rodar todas as aplicações com:

ruby src/nome_do_servico -p numero_da_porta

Faça uma requisição POST com body JSON para o endpoint http://127.0.0.1:4569/service, você notará que o dado mockado que você mandou no second_app vai ser logado da mesma forma no first_app, o que prova que conseguimos implementar de forma bem-sucedida o webhook.

É isso!

Espero que esse artigo tenha te ajudado a entender sobre webhooks! Qualquer coisa estou a disposição de ajudar e trocar uma ideia sobre tech nas minhas redes sociais, é isso!

14 Produtores de conteúdo da área de desenvolvimento de software.

Giovanny Cordeiro — Mon, 15 Jan 2024 20:54:53 +0000

Produtores de conteúdos são de suma importância para todas as áreas, isso é fato. Muitas vezes são eles que apresentam novos conteúdos, dão aquele empurrãozinho para você tirar aquele projeto que tanto queria do papel ou faz você começar a desenvolver aquela virtude que tanto queria a um tempo.

Na área de tecnologia não é diferente, existe muitos produtores de conteúdo e com eles é possível ficar atualizado de vários segmentos e/ou temas, nesse artigo, eu vou vou listar 14 produtores(as) de conteúdo de tecnologia que mais me encheram os olhos nos últimos tempos.

Já passa essa lista para aquele amigo/conhecido que começou na área que para ele melhore o aprendizado e fique por dentro das novidades.

E para melhorar, todos dessa lista são brasileiros!

TL; DR;

Caso de você queira apenas a lista dos canais PT-BR.

Filipe Deschamps, Atekita Dev, Loiane Groner, Glaucia Lemos, Lucas Montano, LINUXTips, Codigo fonte TV, Fabio Akita, Mano Deyvin, Fernanda Kipper, Erick Wendel, Eduardo Mendes, Mario Solto, Gabs Ferreira.

Filipe Deschamps - Canal: Filipe Deschamps

Também chamado de Michel Teló da computação, Filipe Deschamps tem um estilo cativante e uma oratoria calma. O que mais chama atenção no canal dele é que ele aborda diversos assuntos que fogem até do escopo de tecnologia de uma forma clara e sucinta trazendo paralelos (ou não) com a área de tecnologia, a sensação que tenho ao terminar de assistir algum um vídeo dele é geralmente de, "puts mas já acabou?", sentimento esse que me faz ansioso esperando seu próximo vídeo.

Karol Attekita - Canal: Attekita Dev

Karol Attekita foi uma grata surpresa desde que a conheci, com seu canal muito versátil ela explica desde conceitos simples até conteúdos mais técnicos mostrando mais o segmento em que trabalha (Nativo em IOs). Ela alimenta seu canal de forma recorrente e aborda os mais diversos temas relacionados a tecnologia, como dicas de carreira, soft, hard skills, tendências, etc. Além do mais ela tem experiência apenas como desenvolvedora Senior IOS na RIOT GAMES, a mulher é simplesmente braba.

Loiane Groner - Canal: Loiane Groner

Se tu não conhece essa mulher tu ta perdendo muito, mas eu vou te tirar dessa escuridão, ela é simplesmente a autora do Livro "Estrutura de dados e algoritmos em JavaScript" que é apenas umas das principais referencias para começar os estudos de estruturas de dados para iniciantes. Saber que ela é brasileira e saber que ela produz conteúdo em PT-BR é para mim simplesmente sensacional. No canal dela ela aborda majoritariamente conteúdos técnicos em Java e Angular, tecnologias que ela domina a provavelmente mais tempo do que eu tenho de vida, quer aprender mais sobre Angula, Java? Canal da Loiane.

Glaucia Lemos - Canal: Glaucia Lemos

Glaucia Lemos é outra mulher absurda da nossa lista, ela é atualmente Developer Advocate II na Microsoft e tem muito conteúdo técnico em seu canal sobre Typescript e Azure, não somente isso, como também ela tema diversas entrevistas sobre outras tecnologias com outras pessoas extremamente qualificadas em seu canal, se você quer um canal brabo sobre Typescript e Azure, que tem um curso de typescript que da um pau em muito pago ai, o canal dela é o lugar. Não posso esquecer de mencionar que ela simplesmente tem uma carreira brilhante, com contribuição na Node.js Foundation.

Lucas Montano - Canal: Lucas Montano.

Lucas Montano do canal Lucas Montano é outro cara insano da área de desenvolvimento de software, ele é atualmente trabalha como Senior Android Engineer na Disney e aborda em seu canal diversos temas relacionados a tecnologia colocando seu ponto de vista baseado em sua experiência. Ele vai desde carreira, tecnologias, mercado, tendências, e até (porque não?) tretas. O que mais me atrai em assistir os vídeos do Montano é a sua personalidade e forma do qual guia os vídeos, que é sempre de uma forma espontânea e singular.

Vanessa Weber e Gabriel Fróes - Canal: Código Fonte TV

Vanessa Weber e Gabriel Fróes são um casal de programadores que tem um canal de tecnologia muito relevante, além de serem empreendedores na área e tecnologia com a empresa RW Studio.

O canal deles é recheado de quadros um melhores que os outros e que são feitos claramente com muita dedicação, dentre esses quadros eu particularmente gosto muito do "Compilado do código fonte TV", onde eles fazem um resumão das noticias de tecnologia da semana. No canal desse casal o que não falta é conteúdo, carisma e proficiência.

Fábio Akita - Canal: Akitando

Fábio Akita é desenvolvedor de software com muitos anos de experiência e Co-Founder da Codeminers 42, empresa que é "uma boutique de software", como eles mesmos dizem.

Se você estiver querendo aprender sobre desenvolvimento de software e tecnologia de forma HARDCORE, definitivamente é o seu lugar, o Akita produz conteúdos densos, objetivos, com comentários ácidos e opiniões fortes.

Geralmente seus vídeos tem uma média de tempo de 1hr ou mais, por ai você consegue imaginar o tanto de informação e conteúdo que esse cara tem para te dizer.

Quando assisto ou reassisto algum vídeo do Akita eu sempre tenho uma avalanche de informações e detalhes técnicos que muitas vezes eu não fazia ideia que existia ou deixei passar, definitivamente um canal para aprender de forma sólida conteúdos que não são tão "main stream", mas que são de suma importância na área de tecnologia.

Fernanda Kipper - Canal: kipperdev

Fernanda Kipper é atualmente desenvolvedora de software Pleno na Itaú tem um canal no Youtube onde ela aborda diversos temas relacionados a tecnologia, como tendências, lifestyle, desafios, dentre outros. O que me chama atenção no canal dela além de sua oratória é a forma do qual ela é direta em relação a passar a ideia do vídeo, acho os vídeos dela sucintos, claros e bem fluidos. Focada em Java e Spring é outro canal muito bom para quem quer saber mais sobre essas tecnologias.

Erick Wendel - Canal: Erick Wendel

Erick Wendel é desenvolvedor de software Senior, Linkedin Top Voice, Google Dev Expert, Microsoft MVP, Github Star, Node.JS core team member e outras porradas de coisas.

Além de todos esses títulos Erick foi o dev que corrigiu o bug no Node.Js (runtime do Javascript) que afetava o Facebook Jest, nem vou me arriscar explicando o que ele fez, até porque ele fez um vídeo onde explica de forma bem detalhada como corrigiu esse bug.

Em seu canal Erick aborda sobre diversos temas de desenvolvimento de software, mas se você quiser um lugar para aprender mais sobre Node.js, para mim, o canal dele é um dos melhores.

Eduardo Mendes - Canal: Eduardo Mendes

Eduardo Mendes é desenvolvedor de software e seu canal é majoritariamente focado em conteúdos relacionados a Python. O que mais me surpreende no canal dele é a facilidade e didática que o Eduardo tem em relação a passar conteúdos mais técnicos, suas lives são ótimas e muito informativas. Caso você queira um canal para aprender mais sobre Python, o canal do Eduardo é um dos lugares para isso.

Mario Souto - Canal: Mario Souto - Dev Soutinho

Mario Souto é Github Stars, Google Developer Expert e atualmente Lead Software Enginner na Nubank. Seu canal no youtube aborda diversos temas sobre tecnologia onde ele discute, explica e por muitas vezes implementa algo relacionado ao tópico.

O que mais se destaca para mim no canal do Soutinho é o jeito alegre, espontâneo e (quando é necessário) sério, que ele aborda os temas, seja eles mais simples ou um pouco mais complexos, da para perceber a dedicação empregada no seu canal, acho isso sensacional.

Jeferson Fernando Vitalino - Canal: LINUXtips

Jeferson Fernando é Senior Platform Engenier e tem um dos canais mais influentes que eu conheço quando se trata de DevOps.

O canal da Linux Tips é definitivamente um dos canais que mais tem conteúdo técnico sobre esse assunto, mas seu canal não é apenas focado nesse nicho. Ele também faz muitos eventos online onde há diversas palestras sobre diversas tecnologias e metodologias diferentes, o que eu mais gosto no canal Linux Tips é isso, conteúdo, muito conteúdo.

Confesso que atualmente um dos meus quadros preferidos do canal é o "Falando e andando" onde ele fala sobre algum tema relacionado a tecnologia e vai caminhando em Amsterdam, cidade no qual ele vive atualmente.

Gabs Ferreira - Canal: Gabs ferreira

Gabs é produtor de conteúdo em tempo integral atualmente, mas por muitos anos trabalhou na área de tecnologia e suas ultimas experiências foram como Developer Advocate.

Seu canal do youtube é basicamente uma versão com vídeo do seu podcast "Olá Gabs" que foi uma grata surpresa para mim esse ano. Ele conduz o seu podcast de forma sensacional, com papos reflexivos, produtivos e memoráveis.

Se você gosta de podcast e me pedisse uma lista de podcasts de desenvolvimento de software certamente o "Olá Gabs" estaria nessa lista.

Mano Deyvin - Canal: Mano Deyvin

Many Devyn é Senior Software Engenier atualmente e com seu canal do youtube comenta de forma despojada e caótica temas relacionados a tecnologia. O conteúdo do Mano Deyvin me lembra muito lives da Twitch onde o conteúdo é bem doido, com um chat maluco e comentários zueiros, no entanto, repleto de informações valiosas para olhares atentos.

Eu recomendo o canal do Devyn para quem curte esse estilo mais caótico de enxergar o mundo, com muita zuera.

Finalizando...

Decidi fazer esse artigo porque infelizmente sinto que o Brasileiro ainda tem a famosa síndrome do vira-lata em relação a nós mesmos, muitas pessoas preferem um gringo ruim do que um BR bom e nesse artigo eu vim mostrar que existe muita gente foda sim no Brasil, e digo mais, não tem somente eles não, pesquise e você vai descobrir cada vez mais gente absurda fazendo um trabalho maneiro em comunidades e outras redes.

Se eu falei alguma bobagem sobre os produtores de conteúdos aqui citados gostaria bastante que você mencione aqui nos comentários, meu intuito é apenas espalhar a mensagem da comunidade para mais pessoas.

Espero que eu tenha te ajudado ao pelo menos encontrar um criador de conteúdo novo por aqui e se você acha que tem outro produtor de conteúdo maneiro que era para está na lista, coloca aqui nos comentários!

DEV Community: Giovanny Cordeiro

Multithreading e corrotinas com Ruby

Tabela de conteúdos

Como o Ruby lida com multithread

Thread: O Principal modulo para multithread em Ruby

O Artificio da classe Thread

Resolvendo o problema

Uma aplicação mais próxima da realidade

Fibers: Utilizando corrotinas com Ruby

Ractors: Como passar por cima do GIL

Conclusão e agradecimentos

Referências

Memorização em Ruby

Table of contents

O que é memorização

Primeira implementação utilizando operador de atribuição ou

E se...

Segunda implementação utilizando a palavra chave defined

Quando utilizar uma implementação ou outra

Terceira implementação utilizando método tap

Conclusão

Referências

Pequeno guia de webhooks com Ruby!

Inicio!

A primeira abordagem.

Abordagem com Webhook

Fazendo o primeiro webhook simples!

É isso!

14 Produtores de conteúdo da área de desenvolvimento de software.

TL; DR;

Filipe Deschamps - Canal: Filipe Deschamps

Karol Attekita - Canal: Attekita Dev

Loiane Groner - Canal: Loiane Groner

Glaucia Lemos - Canal: Glaucia Lemos

Lucas Montano - Canal: Lucas Montano.

Vanessa Weber e Gabriel Fróes - Canal: Código Fonte TV

Fábio Akita - Canal: Akitando

Fernanda Kipper - Canal: kipperdev

Erick Wendel - Canal: Erick Wendel

Eduardo Mendes - Canal: Eduardo Mendes

Mario Souto - Canal: Mario Souto - Dev Soutinho

Jeferson Fernando Vitalino - Canal: LINUXtips

Gabs Ferreira - Canal: Gabs ferreira

Mano Deyvin - Canal: Mano Deyvin

Finalizando...