DEV Community: Vídeos de Ti

🇧🇷 Continuando a jornada com RubyUI: apresentando o ruby_ui_converter

Jackson Pires — Sun, 14 Jun 2026 19:09:05 +0000

Recentemente publiquei uma gem chamada ruby_ui_scaffold, um gerador de scaffolds para Rails pensado para quem quer construir aplicações modernas utilizando Phlex e RubyUI desde o início do projeto.

A proposta dela era bastante simples:

Em vez de usar o scaffold tradicional do Rails gerando views em .erb, a ideia era criar aplicações já preparadas para uma arquitetura baseada em componentes Ruby, utilizando Phlex e os componentes do RubyUI.

Mas logo percebi uma questão importante.

E quem já possui uma aplicação Rails existente?

O problema das aplicações legadas

O ruby_ui_scaffold resolve muito bem o cenário de novos projetos.

Com ele, você consegue gerar CRUDs completos com controllers, formulários, tabelas, componentes visuais e toda a estrutura baseada em Phlex desde o primeiro dia.

Mas a realidade é que grande parte da comunidade Rails trabalha em aplicações já existentes.

Aplicações que possuem anos de evolução e centenas de arquivos como estes:

app/views/products/index.html.erb
app/views/users/show.html.erb
app/views/orders/_form.html.erb

E nesse cenário surge uma pergunta natural:

Como migrar uma aplicação já existente para Phlex + RubyUI sem precisar reescrever manualmente toda a camada de views?

Foi exatamente essa pergunta que me levou a criar a próxima gem dessa jornada.

Apresentando o ruby_ui_converter

https://github.com/jacksonpires/ruby_ui_converter

Se o ruby_ui_scaffold foi criado para ajudar no desenvolvimento de novas aplicações Rails, o ruby_ui_converter nasce como sua continuação natural.

A proposta é simples:

Permitir que aplicações Rails já existentes possam migrar gradualmente seus templates .erb para componentes baseados em Phlex e RubyUI.

Em outras palavras:

ruby_ui_scaffold → cria aplicações novas já utilizando a stack moderna
ruby_ui_converter → ajuda aplicações existentes a fazer essa transição

Transformando ERB em componentes Ruby automaticamente

A gem percorre uma pasta de views Rails e converte automaticamente arquivos .erb em componentes Ruby.

Exemplo:

bundle exec ruby_ui_converter convert app/views/users

Resultado:

app/views/users/index.html.erb → app/views/users/index.rb
app/views/users/_user.html.erb → app/views/users/user.rb

A ideia é eliminar o trabalho repetitivo que normalmente existiria nesse processo de migração.

Conversão inteligente para Phlex e RubyUI

O objetivo não era simplesmente transformar HTML em Ruby.

A gem entende padrões comuns do Rails e gera código compatível com Phlex e com componentes RubyUI.

Por exemplo:

Um template tradicional:

<%= link_to "Dashboard", dashboard_path %>

vira automaticamente:

Link(href: dashboard_path) { "Dashboard" }

Partials como:

<%= render "form", product: @product %>

são convertidos para componentes Ruby:

render Views::Products::Form.new(product: @product)

E até estruturas mais complexas como:

form_with
collection_select
checkboxes
condicionais (if, unless)
loops (each)
helpers Rails (dom_id, button_to, content_for)

são analisadas e convertidas automaticamente.

Migração gradual, sem reescrever tudo

Esse era um requisito importante para mim durante o desenvolvimento.

A gem não modifica os arquivos ERB originais.

Ela gera os novos arquivos Ruby lado a lado.

Isso permite um processo de migração incremental:

converter apenas uma pasta por vez
revisar o código gerado
testar cada tela individualmente
manter partes da aplicação ainda usando ERB

Sem precisar fazer uma migração radical.

Construindo um ecossistema em torno de RubyUI

Minha ideia com essas gems nunca foi lançar ferramentas isoladas.

O objetivo é construir ferramentas que ajudem a tornar o uso de Phlex e RubyUI cada vez mais acessível dentro do ecossistema Rails.

Hoje essa jornada começa com duas peças complementares:

ruby_ui_scaffold

Para novos projetos.

Cria CRUDs completos utilizando Phlex + RubyUI desde o início.

ruby_ui_converter

Para aplicações existentes.

Ajuda a migrar views tradicionais em ERB para componentes Ruby.

O objetivo final

Tenho explorado bastante a ideia de trazer uma experiência mais moderna de desenvolvimento frontend para aplicações Rails, mas sem abandonar aquilo que sempre gostei no ecossistema Ruby:

Escrever código simples.

Manter produtividade alta.

Continuar trabalhando majoritariamente em Ruby.

Essas gems fazem parte exatamente dessa visão.

Acredito que nos próximos anos veremos cada vez mais aplicações Rails adotando abordagens baseadas em componentes, e quero contribuir para tornar essa transição mais simples.

Se você trabalha com Rails e tem curiosidade em explorar o mundo do Phlex e RubyUI, talvez essas ferramentas possam ajudar nessa jornada.

E isso é só o começo :)

🇺🇸 Continuing the RubyUI Journey: Introducing ruby_ui_converter

Jackson Pires — Sun, 14 Jun 2026 19:07:39 +0000

Recently, I released a gem called ruby_ui_scaffold, a Rails scaffold generator designed for developers who want to build modern applications using Phlex and RubyUI from day one.

The idea behind it was simple:

Instead of relying on the traditional Rails scaffold that generates .erb templates, the goal was to create applications already structured around a Ruby component-based architecture powered by Phlex and RubyUI.

But shortly after releasing it, I realized an important question remained unanswered.

What about existing Rails applications?

The challenge of legacy applications

ruby_ui_scaffold works extremely well for new projects.

It allows developers to generate complete CRUD interfaces with controllers, forms, tables, and UI components entirely built with Phlex and RubyUI.

But the reality is that a huge part of the Rails community works on existing applications.

Applications that have evolved for years and contain hundreds of files like these:

app/views/products/index.html.erb
app/views/users/show.html.erb
app/views/orders/_form.html.erb

And naturally, this leads to an important question:

How do you migrate an existing Rails application to Phlex + RubyUI without manually rewriting the entire view layer?

That question led me to build the next step in this journey.

Introducing ruby_ui_converter

https://github.com/jacksonpires/ruby_ui_converter

If ruby_ui_scaffold was created to help developers build new Rails applications using a modern stack, ruby_ui_converter is its natural continuation.

The goal is simple:

Allow existing Rails applications to gradually migrate their .erb templates into Phlex and RubyUI components.

In other words:

ruby_ui_scaffold → helps build new applications with the modern stack from the beginning
ruby_ui_converter → helps existing applications transition to that stack

Automatically converting ERB into Ruby components

The gem recursively scans Rails view folders and automatically converts .erb templates into Ruby component files.

Example:

bundle exec ruby_ui_converter convert app/views/users

Output:

app/views/users/index.html.erb → app/views/users/index.rb
app/views/users/_user.html.erb → app/views/users/user.rb

The entire idea is to eliminate the repetitive work that usually comes with large migrations.

Intelligent conversion for Phlex and RubyUI

The goal was never to simply transform HTML into Ruby syntax.

The gem understands common Rails patterns and generates code compatible with both Phlex and RubyUI.

For example:

A traditional Rails template:

<%= link_to "Dashboard", dashboard_path %>

gets automatically converted into:

Link(href: dashboard_path) { "Dashboard" }

Partials like:

<%= render "form", product: @product %>

become Ruby components:

render Views::Products::Form.new(product: @product)

It also understands more complex structures like:

form_with
collection_select
checkboxes
conditionals (if, unless)
loops (each)
Rails helpers (dom_id, button_to, content_for)

and converts them automatically.

Gradual migration without rewriting everything

This was one of the most important requirements during development.

The gem does not modify the original ERB files.

Instead, it generates Ruby files alongside them.

This makes incremental migration possible:

convert one folder at a time
review generated code
test each screen individually
keep parts of the application running on ERB

There is no need for a risky “big bang” migration.

Building an ecosystem around RubyUI

My goal with these gems has never been to release isolated tools.

The bigger idea is to create tools that make adopting Phlex and RubyUI easier inside the Rails ecosystem.

Right now, that journey starts with two complementary pieces.

ruby_ui_scaffold

Built for new projects.

Generate complete CRUD applications using Phlex + RubyUI from the very beginning.

ruby_ui_converter

Built for existing applications.

Help legacy Rails apps migrate traditional ERB views into Ruby components.

The bigger vision

I’ve been spending a lot of time exploring ways to bring a more modern frontend development experience into Rails applications without losing what I have always loved about the Ruby ecosystem.

Writing simple code.

Maintaining high productivity.

Continuing to work primarily in Ruby.

These gems are part of that vision.

I believe that over the next few years, we’ll see more Rails applications adopting component-based architectures, and I want to help make that transition easier.

If you work with Rails and are curious about exploring the world of Phlex and RubyUI, I hope these tools can help you on that journey.

And this is only the beginning :)

🇺🇸 Learning RubyUI Through Real Applications with `ruby_ui_scaffold`

Jackson Pires — Wed, 10 Jun 2026 13:01:57 +0000

Building CRUD applications in Ruby on Rails has never been difficult. The challenge begins when we want to create modern, reusable, component-based interfaces without ending up with a mix of ERB templates, helpers, partials, and presentation logic spread across the application.

Over the past few years, tools like Phlex and RubyUI have introduced a compelling alternative for Rails developers who want a cleaner and more maintainable view layer. However, one challenge remains: getting started.

How should you structure your views? Which components should you use? How do you build complete CRUD flows with RubyUI?

To make that journey easier, I built ruby_ui_scaffold.

https://github.com/jacksonpires/ruby_ui_scaffold

What is ruby_ui_scaffold?

ruby_ui_scaffold is a Rails scaffold generator that creates complete CRUD applications using:

Ruby on Rails
Phlex
RubyUI
Tailwind CSS

Instead of generating traditional ERB templates, it produces fully functional Phlex views built with RubyUI components from day one.

Think of it as a modern alternative to:

rails g scaffold

but designed specifically for component-based Rails applications.

More than a Scaffold Generator

While the primary goal is to speed up CRUD development, ruby_ui_scaffold also serves as a practical learning tool.

Every generated resource includes real-world examples of RubyUI components such as:

Table
DataTable
Form
Input
Textarea
Checkbox
Badge
Select
Combobox
DropdownMenu
AlertDialog
DatePicker

Instead of reading documentation and trying to figure out how components fit together, you can study complete working implementations inside your own application.

Learning RubyUI Through Real Code

One of the biggest challenges when learning any component library is moving beyond isolated examples.

For example, generating:

bin/rails g ruby_ui_scaffold Buddy \
  name:string \
  email:string \
  admin:boolean \
  birthday:date

automatically creates:

Forms
Index pages
Show pages
Create and update flows
Delete confirmations

All powered by RubyUI components.

This provides practical examples that developers can inspect, modify, and learn from immediately.

Exploring Relationships

The generator also supports belongs_to relationships out of the box.

For example:

bin/rails g ruby_ui_scaffold Book \
  title:string \
  author:references

automatically generates:

Select inputs for small datasets
Searchable Comboboxes for larger datasets
Human-friendly relationship rendering
Eager loading to prevent N+1 queries

These generated examples demonstrate how advanced RubyUI components can be used in real applications.

Discovering the DataTable Component

Developers looking to explore more advanced UI patterns can enable:

--datatable

This generates fully featured tables with:

Search
Sorting
Pagination
Per-page controls

All built around RubyUI's DataTable component.

For many developers, this becomes one of the easiest ways to understand how to integrate advanced RubyUI features into production applications.

Generate Data and Experiment

The included seed command makes experimentation easy:

bin/rails ruby_ui_scaffold:seed Buddy --count 100

Using Faker, the generator populates your database with realistic sample data.

This allows you to test:

Tables
Forms
Search experiences
Pagination
Selection components

under realistic conditions.

A Playground for Phlex and RubyUI

Although ruby_ui_scaffold is highly productive, I believe its greatest value lies in education.

Every generated scaffold becomes a living collection of RubyUI examples that developers can inspect and learn from.

Rather than starting from a blank page, developers start from a complete application and gradually understand how RubyUI and Phlex work together.

For teams evaluating RubyUI, this can dramatically shorten the learning curve.

Conclusion

ruby_ui_scaffold was not created to replace learning RubyUI.

It was created to make that learning process easier.

By generating real code for real scenarios using real components, the gem helps bridge the gap between documentation and practical application.

If your goal is to accelerate CRUD development, ruby_ui_scaffold can help.

If your goal is to learn RubyUI and Phlex through hands-on examples, it may be one of the fastest ways to get started.

🇧🇷 Aprendendo RubyUI na Prática com `ruby_ui_scaffold`

Jackson Pires — Wed, 10 Jun 2026 13:00:43 +0000

Quem trabalha com Ruby on Rails sabe que gerar um CRUD é fácil. O desafio começa quando queremos construir interfaces modernas, consistentes e reutilizáveis sem cair em uma mistura de ERB, helpers, partials e componentes espalhados pela aplicação.

Nos últimos anos, o ecossistema Rails ganhou ferramentas extremamente interessantes como Phlex e RubyUI, que trazem uma experiência mais orientada a componentes para a camada de apresentação. Porém, para quem está começando, existe uma barreira inicial: como estruturar tudo isso? Quais componentes utilizar? Como conectar formulários, tabelas e ações CRUD usando RubyUI?

Foi exatamente para reduzir essa curva de aprendizado que desenvolvi a gem ruby_ui_scaffold.

https://github.com/jacksonpires/ruby_ui_scaffold

O que é o ruby_ui_scaffold?

O ruby_ui_scaffold é um gerador de scaffold para Rails que cria aplicações CRUD completas utilizando:

Ruby on Rails
Phlex
RubyUI
Tailwind CSS

Em vez de gerar views ERB tradicionais, ele produz views escritas em Phlex utilizando componentes RubyUI desde o primeiro momento.

Na prática, ele funciona como uma alternativa moderna ao tradicional:

rails g scaffold

mas gerando uma interface visual pronta para uso e alinhada com as boas práticas do ecossistema RubyUI.

Mais do que um gerador

Embora o objetivo inicial seja acelerar a criação de CRUDs, o ruby_ui_scaffold acaba se tornando uma excelente ferramenta educacional.

Ao gerar um recurso, você recebe exemplos reais de utilização de componentes como:

Table
DataTable
Form
Input
Textarea
Checkbox
Badge
Select
Combobox
DropdownMenu
AlertDialog
DatePicker

Em vez de consultar a documentação e tentar imaginar como cada componente deve ser utilizado, você passa a ter exemplos completos funcionando dentro da sua própria aplicação.

Aprendendo RubyUI através de código real

Uma das maiores dificuldades ao aprender qualquer biblioteca de componentes é sair dos exemplos isolados e entender como ela funciona em um sistema real.

Por exemplo, ao gerar:

bin/rails g ruby_ui_scaffold Buddy \
  name:string \
  email:string \
  admin:boolean \
  birthday:date

o scaffold cria automaticamente:

Formulários completos
Listagens
Páginas de detalhes
Fluxo de criação e edição
Exclusão com confirmação visual

Tudo utilizando componentes RubyUI.

Isso permite estudar padrões reais de implementação, em vez de exemplos artificiais.

Explorando relacionamentos

Outro aspecto interessante é o suporte automático a associações belongs_to.

Ao gerar um relacionamento:

bin/rails g ruby_ui_scaffold Book \
  title:string \
  author:references

o scaffold cria automaticamente:

Selects para pequenas listas
Comboboxes pesquisáveis para grandes volumes
Exibição amigável do relacionamento
Eager loading para evitar N+1 queries

Além de acelerar o desenvolvimento, isso mostra na prática como utilizar componentes avançados do RubyUI em cenários reais.

Conhecendo o DataTable

Quem deseja explorar componentes mais sofisticados pode utilizar a opção:

--datatable

Com ela, o scaffold gera páginas com:

Busca
Ordenação
Paginação
Controle de quantidade de registros por página

Tudo baseado no componente DataTable do RubyUI.

Essa funcionalidade é particularmente útil para quem deseja aprender como implementar tabelas avançadas utilizando RubyUI sem precisar construir tudo do zero.

Gerando dados para experimentar

Outro recurso interessante é o comando de seed:

bin/rails ruby_ui_scaffold:seed Buddy --count 100

Ele gera dados fictícios utilizando Faker, permitindo que você teste rapidamente:

Tabelas
Formulários
Paginação
Componentes de busca
Componentes de seleção

Quanto mais dados você gera, mais fácil fica entender o comportamento dos componentes RubyUI em situações reais.

Um laboratório para aprender Phlex e RubyUI

Embora a gem seja extremamente útil para acelerar o desenvolvimento, acredito que seu maior valor esteja na capacidade de servir como um laboratório de aprendizado.

Cada scaffold gerado se transforma em uma coleção de exemplos reais que podem ser estudados, adaptados e reutilizados.

Se você está começando com RubyUI ou deseja entender como estruturar aplicações Rails utilizando Phlex, o ruby_ui_scaffold pode funcionar como um excelente ponto de partida.

Em vez de começar com uma página em branco, você começa com uma aplicação funcional e pode evoluir a partir dela, aprendendo os componentes e padrões aos poucos.

Conclusão

O ruby_ui_scaffold não pretende substituir o aprendizado do RubyUI. Pelo contrário: ele foi criado para facilitar esse processo.

Ao gerar código real, utilizando componentes reais e cenários reais, a gem reduz a distância entre a documentação e a aplicação prática.

Se você quer acelerar seus CRUDs, ótimo.

Mas se também quer aprender RubyUI e Phlex de forma prática, provavelmente esse é um dos caminhos mais rápidos para começar.

🇺🇸 3 Essential Gems to Eliminate Friction in Your Rails Workflow

Jackson Pires — Thu, 04 Jun 2026 21:48:37 +0000

Anyone who works with Ruby on Rails knows that, despite the framework being incredible for productivity, there are some classic workflow deficiencies that haunt almost every project.

You are focused on writing code, but suddenly you need to open an external tool like Postman to test a route. Then, you run a complex script to generate a static database diagram. And at the end of the day, you still need to manually update the API documentation, which will inevitably become outdated in the next sprint.

This constant context switching and manual maintenance generates enormous friction. To cover these deficiencies, I developed three gems that bring these tools inside your application. They are so practical that they quickly become indispensable in any Rails project. Meet each one of them:

1. `rails-api-docs`: The End of Outdated Documentation]

https://github.com/jacksonpires/rails-api-docs

The deficiency: API documentation always starts with good intentions, but as the system evolves—new routes, parameters, and response fields—it quickly stops representing reality. Keeping this updated manually is repetitive and frustrating work.

The solution: The rails-api-docs gem solves this by leveraging what Rails already knows. It inspects your routes, controllers (via AST analysis using Prism), and the ActiveRecord schema to automatically generate the first draft of your documentation. Everything is saved in a single YAML file (config/rails-api-docs.yml), which serves as the single source of truth.

Why it is indispensable:

Append-only strategy: When adding new routes and running the generator, the gem only appends what's new. Your descriptions, custom examples, and tags are never modified or deleted, making the documentation a living document.
Zero development friction: You edit the YAML in one window and view the updated documentation in the browser at localhost:3000/rails/api-docs instantly, with no build step required. For production, it exports a single static HTML file without any external dependencies.

2. `rails-http-lab`: Your HTTP Client Right in the App

https://github.com/jacksonpires/rails-http-lab

The deficiency: Testing HTTP endpoints usually requires switching to external tools (like Postman or Insomnia) or creating temporary scripts. Besides the loss of focus, these tools live outside your repository and frequently suffer from CORS issues when trying to access internal services.

The solution: The rails-http-lab is a Rails Engine that couples an HTTP request lab inside your own application. By accessing /rails/http-lab, you have a lightweight interface to test methods, headers, and payloads while visualizing the responses directly in the browser.

Why it is indispensable:

Stays in the Repository: Your requests are saved in .bru format (interchangeable with the Bruno desktop app) inside the project's docs/http-lab/ folder. This means your API tests are version-controlled in Git and can be easily reviewed in Pull Requests.
No CORS limits: Since the requests are executed by the Rails server itself, you don't have CORS problems and can reach internal services transparently.

3. `rails-realtime-erd`: Database Diagrams Always in Sync

https://github.com/jacksonpires/rails-realtime-erd

The deficiency: Understanding database relationships in a growing project is difficult. Traditional tools generate static diagrams (ERD) that require manual tasks and quickly become outdated as soon as a new migration is executed.

The solution: The rails-realtime-erd gem mounts a route at /rails/erd that renders your schema diagram in real-time using Mermaid, all processed by Hotwire (Stimulus), without relying on complex JavaScript frameworks.

Why it is indispensable:
You will never again need to run a rake step to generate a static image file. The introspection is done on the fly: if you run a migration, just refresh the page to see the new tables and relationships reflected in the diagram immediately. It is excellent for onboarding new developers and keeping a live documentation of your architecture.

Conclusion

These three tools share the same philosophy: your code already has the necessary knowledge, and the support tools should live as close to it as possible.

Adopting rails-api-docs, rails-http-lab, and rails-realtime-erd drastically reduces daily friction, eliminating external dependencies and manual rework. With simple installation steps, your development environment will become much more productive, robust, and integrated.

🇧🇷 3 Gems Indispensáveis para Eliminar as Deficiências do seu Fluxo de Trabalho no Rails

Jackson Pires — Thu, 04 Jun 2026 21:47:50 +0000

Quem trabalha com Ruby on Rails sabe que, embora o framework seja incrível para a produtividade, existem algumas deficiências clássicas no fluxo de desenvolvimento que assombram quase todo projeto.

Você está focado escrevendo código, mas de repente precisa abrir uma ferramenta externa como o Postman para testar uma rota. Depois, roda um script complexo para gerar um diagrama estático do banco de dados. E, no fim do dia, ainda precisa atualizar manualmente a documentação da API, que fatalmente ficará defasada na próxima sprint.

Essa constante alternância de contexto e manutenção manual geram um enorme atrito. Para cobrir essas deficiências, eu desenvolvi três gems que trazem essas ferramentas para dentro da sua aplicação. Elas são tão práticas que rapidamente se tornam indispensáveis em qualquer projeto Rails. Conheça cada uma delas:

1. `rails-api-docs`: O Fim da Documentação Desatualizada

https://github.com/jacksonpires/rails-api-docs

A deficiência: A documentação de API sempre começa com boas intenções, mas conforme o sistema evolui — novas rotas, parâmetros e campos na resposta —, ela rapidamente deixa de representar a realidade. Manter isso atualizado manualmente é um trabalho repetitivo e frustrante.

A solução: A gem rails-api-docs resolve isso aproveitando o que o Rails já sabe. Ela inspeciona suas rotas, controllers (via análise AST usando Prism) e o schema do ActiveRecord para gerar automaticamente o primeiro rascunho da sua documentação. Tudo é salvo em um único arquivo YAML (config/rails-api-docs.yml), que serve como fonte da verdade.

Por que é indispensável:

Estratégia Append-only: Ao adicionar novas rotas e rodar o gerador, a gem apenas adiciona o que é novo. Suas descrições, exemplos customizados e tags não são apagados, tornando a documentação um documento vivo.
Zero atrito no desenvolvimento: Você edita o YAML de um lado e visualiza a documentação atualizada no navegador em localhost:3000/rails/api-docs instantaneamente, sem etapa de build. Para produção, ela exporta um único arquivo HTML estático, sem dependências externas.

2. `rails-http-lab`: Seu Client HTTP Direto na Aplicação

https://github.com/jacksonpires/rails-http-lab

A deficiência: Testar endpoints HTTP geralmente exige alternar para ferramentas externas (como Postman ou Insomnia) ou criar scripts temporários. Além da perda de foco, essas ferramentas vivem fora do seu repositório e frequentemente sofrem com problemas de CORS ao tentar acessar serviços internos.

A solução: O rails-http-lab é uma Rails Engine que acopla um laboratório de requisições HTTP dentro da sua própria aplicação. Ao acessar /rails/http-lab, você tem uma interface leve para testar métodos, headers e payloads visualizando as respostas diretamente no navegador.

Por que é indispensável:

Fica no Repositório: As suas requisições são salvas no formato .bru (compatível com o aplicativo desktop Bruno) dentro da pasta docs/http-lab/ do projeto. Isso significa que os testes da sua API são versionados no Git e podem ser revisados nos Pull Requests.
Sem limites de CORS: Como as requisições são executadas pelo próprio servidor Rails, você não tem problemas de CORS e pode alcançar serviços internos de forma transparente.

3. `rails-realtime-erd`: Diagramas de Banco de Dados Sempre Sincronizados

https://github.com/jacksonpires/rails-realtime-erd

A deficiência: Entender os relacionamentos do banco de dados em um projeto que está crescendo é difícil. As ferramentas tradicionais geram diagramas estáticos (ERD) que exigem tarefas manuais e rapidamente ficam defasados assim que uma nova migration é executada.

A solução: A gem rails-realtime-erd monta uma rota em /rails/erd que renderiza o diagrama do seu schema em tempo real usando o Mermaid, tudo processado pelo Hotwire (Stimulus), sem depender de frameworks JavaScript complexos.

Por que é indispensável:
Você nunca mais precisará rodar um passo de rake para gerar um arquivo de imagem estático. A introspecção é feita sob demanda: se você rodar uma migration, basta atualizar a página para ver as tabelas e relacionamentos novos refletidos no diagrama imediatamente. É excelente para o onboarding de novos desenvolvedores e documentação viva da arquitetura.

Conclusão

Essas três ferramentas compartilham a mesma filosofia: o seu código já possui o conhecimento necessário, e as ferramentas de apoio devem viver o mais próximo possível dele.

Adotar o rails-api-docs, o rails-http-lab e o rails-realtime-erd reduz drasticamente o atrito no dia a dia, eliminando dependências externas e o retrabalho manual. Com passos simples de instalação (basta adicionar ao Gemfile e rodar um comando), seu ambiente de desenvolvimento se tornará muito mais produtivo, robusto e integrado.

🇺🇸 I Got Tired of Stale API Documentation in Rails — So I Built `rails-api-docs`

Jackson Pires — Wed, 03 Jun 2026 12:25:33 +0000

API documentation always starts with good intentions.

At the beginning of a project, everything is in sync.

Routes match reality.

Examples are accurate.

Parameters make sense.

Responses reflect exactly what the API returns.

But as the system evolves, documentation starts falling behind.

A new route gets added.

A parameter changes.

An endpoint gains authentication.

A response receives new fields.

And before you realize it, the documentation no longer represents reality.

If you've worked with Rails APIs for long enough, you've probably experienced this.

I certainly have.

And it was exactly that frustration that led me to create rails-api-docs.

GitHub: https://github.com/jacksonpires/rails-api-docs

The idea started with a simple question

Your Rails application already knows a lot.

It knows:

your routes
your controllers
your parameters
your models
your database schema
your HTTP verbs

So why should documentation always start from scratch?

Why do we need to manually rewrite information that already exists inside the application?

The idea behind rails-api-docs was to leverage the knowledge Rails already has to generate the first draft of the documentation automatically.

The workflow I wanted didn't exist

I didn't want another tool where the workflow looked like this:

edit documentation
→ generate artifacts
→ rebuild
→ restart server
→ validate changes

I wanted something closer to the typical Rails development experience:

edit
→ refresh browser
→ keep working

That's where the core concept of the gem came from:

A single editable YAML file that powers both development-time documentation and production-ready documentation.

A single source of truth

The entire workflow revolves around a single file:

config/rails-api-docs.yml

This file becomes the source of truth for your documentation.

From it, the gem generates:

live documentation during development
request examples
response examples
documented schemas
static HTML documentation for production

You update one file.

Everything else updates automatically.

How it works

First, generate the initial YAML file:

rails g rails-api-docs:init

The gem automatically inspects:

Rails.application.routes
controllers (via Prism AST analysis)
ActiveRecord schema

And creates an initial documentation structure.

Then start your application:

rails server

And visit:

http://localhost:3000/rails/api-docs

Whenever you modify the YAML file, simply refresh the page.

No build step.

No frontend tooling.

No intermediate process.

Let the code write the first draft

One of the most interesting parts of this project was using Prism to analyze controllers.

For example:

params.require(:user).permit(
  :email,
  :password,
  :role
)

The gem can automatically identify these fields and use them to build the initial documentation structure.

Combined with ActiveRecord schema information, it can also infer:

field types
required attributes
initial examples
schema metadata

The goal was never to replace developers.

The goal was to eliminate repetitive work.

Let the machine handle what it can already discover.

And let humans focus on the important part: explaining the API.

Documentation updates shouldn't destroy your work

This is probably the feature that frustrated me most in existing approaches.

You generate documentation.

Spend time writing descriptions.

Add examples.

Organize sections.

Customize schemas.

Then you run the generator again.

And hope nothing gets overwritten.

rails-api-docs follows an append-only strategy.

When you add new routes to your application, simply run:

rails g rails-api-docs:update

The gem appends only new endpoints.

Everything you've written remains untouched.

That includes:

descriptions
examples
tags
authentication details
schemas
section organization

In practice, the documentation becomes a living document rather than a disposable artifact.

Organizing larger APIs with tags

As APIs grow, navigation becomes increasingly important.

That's why the gem supports tags:

tags:
  - auth
  - public

These tags aren't just labels.

They also become interactive filters in the generated documentation.

Clicking a tag instantly filters the navigation to show only endpoints associated with that category.

This makes large APIs significantly easier to explore.

Production should be simple

Another important goal was making deployment boring.

When you're ready to publish the documentation, simply run:

rake rails-api-docs:build

The result is:

public/api-docs.html

A single HTML file.

Everything embedded.

Inline CSS.

Inline JavaScript.

No external dependencies.

No CDN.

No Asset Pipeline.

No JavaScript runtime.

Just a static file that can be hosted almost anywhere.

I'm not trying to replace OpenAPI

There are excellent OpenAPI and Swagger-based tools available today.

They solve many problems extremely well.

The goal of rails-api-docs is not to replace that ecosystem.

The idea is different.

I wanted a solution that allows developers to:

generate documentation from an existing Rails application
edit everything in YAML
preview changes instantly
export a static HTML file
keep documentation synchronized with minimal effort

That's the workflow I was looking for.

And since I couldn't find exactly what I wanted, I decided to build it.

Final thoughts

API documentation should be easy to create and easy to maintain.

In my experience, generating the first version isn't the hard part.

Keeping it updated over time is.

rails-api-docs was created to reduce that friction.

By inspecting the application to generate a starting point.

By preserving your customizations over time.

And by providing an extremely fast feedback loop during development.

If you'd like to try it out:

⭐ https://github.com/jacksonpires/rails-api-docs

Feedback, suggestions, and contributions are always welcome.

🇧🇷 Eu Cansei de Documentação de API Desatualizada no Rails — Então Criei a Gem `rails-api-docs`

Jackson Pires — Wed, 03 Jun 2026 12:24:43 +0000

Documentação de API sempre começa com boas intenções.

No início do projeto, tudo está sincronizado.

As rotas batem com a aplicação.

Os exemplos estão corretos.

Os parâmetros fazem sentido.

As respostas refletem exatamente o que a API retorna.

Mas conforme o sistema evolui, a documentação começa a ficar para trás.

Uma nova rota é criada.

Um parâmetro muda.

Um endpoint ganha autenticação.

Uma resposta recebe novos campos.

E, sem perceber, a documentação deixa de representar a realidade.

Se você trabalha com APIs em Rails há algum tempo, provavelmente já passou por isso.

Eu certamente já passei.

E foi justamente essa frustração que me levou a criar o rails-api-docs.

GitHub: https://github.com/jacksonpires/rails-api-docs

A ideia surgiu de uma pergunta simples

Sua aplicação Rails já sabe muita coisa.

Ela conhece:

suas rotas
seus controllers
seus parâmetros
seus modelos
seu schema do banco
seus verbos HTTP

Então por que a documentação precisa começar sempre do zero?

Por que precisamos reescrever manualmente informações que já existem dentro da aplicação?

A ideia por trás do rails-api-docs foi justamente aproveitar esse conhecimento que o Rails já possui para gerar um primeiro rascunho da documentação automaticamente.

O workflow que eu queria não existia

Eu não queria mais uma ferramenta onde o fluxo fosse:

editar documentação
→ gerar artefatos
→ rebuild
→ reiniciar servidor
→ validar alterações

Eu queria algo mais próximo do desenvolvimento Rails tradicional:

editar
→ atualizar navegador
→ continuar trabalhando

Foi daí que surgiu o conceito central da gem:

Um único arquivo YAML editável que gera tanto a documentação em desenvolvimento quanto a documentação de produção.

Uma única fonte da verdade

O fluxo da gem gira em torno de apenas um arquivo:

config/rails-api-docs.yml

Esse arquivo é a fonte da verdade para toda a documentação.

A partir dele a gem gera:

visualização em tempo real durante o desenvolvimento
exemplos de requisição
exemplos de resposta
schemas documentados
documentação HTML estática para produção

Você altera um único lugar.

Todo o resto é atualizado automaticamente.

Como funciona

Primeiro você gera o YAML inicial:

rails g rails-api-docs:init

A gem inspeciona automaticamente:

Rails.application.routes
controllers (via análise AST usando Prism)
schema do ActiveRecord

E cria uma estrutura inicial de documentação.

Depois basta subir a aplicação:

rails server

E acessar:

http://localhost:3000/rails/api-docs

Sempre que você alterar o YAML, basta atualizar a página.

Não existe etapa de build durante o desenvolvimento.

Não existe pipeline frontend.

Não existe processo intermediário.

Deixe o código escrever o primeiro rascunho

Uma das partes mais interessantes do projeto foi utilizar o Prism para analisar controllers.

Por exemplo:

params.require(:user).permit(
  :email,
  :password,
  :role
)

A gem consegue identificar automaticamente esses campos e utilizá-los para montar a estrutura inicial da documentação.

Quando combinamos isso com as informações do ActiveRecord, também é possível inferir:

tipos dos campos
obrigatoriedade
exemplos iniciais
informações do schema

O objetivo nunca foi substituir o trabalho do desenvolvedor.

O objetivo foi eliminar tarefas repetitivas.

Deixar a máquina fazer aquilo que ela consegue descobrir sozinha.

E deixar os humanos cuidarem da parte importante: explicar a API.

Atualizações não deveriam apagar seu trabalho

Essa talvez seja a característica que mais me incomodava em algumas abordagens existentes.

Você gera documentação.

Investe tempo escrevendo descrições.

Adiciona exemplos.

Organiza seções.

Personaliza schemas.

Então roda novamente o gerador.

E precisa rezar para não perder nada.

No rails-api-docs o YAML segue uma estratégia append-only.

Quando você adiciona novas rotas à aplicação basta executar:

rails g rails-api-docs:update

A gem adiciona apenas os endpoints novos.

Todo o conteúdo que você escreveu continua intacto.

Isso inclui:

descrições
exemplos
tags
autenticação
schemas
organização das seções

Na prática, a documentação deixa de ser um artefato descartável e passa a ser um documento vivo.

Organizando APIs maiores com Tags

Conforme uma API cresce, navegar pela documentação pode ficar mais difícil.

Por isso a gem possui suporte a tags:

tags:
  - auth
  - public

Essas tags não são apenas informativas.

Elas também funcionam como filtros interativos na documentação gerada.

Ao clicar em uma tag, a navegação passa a exibir apenas os endpoints relacionados àquela categoria.

Isso facilita bastante a exploração de APIs maiores.

Produção deveria ser simples

Outro objetivo importante era simplificar o deploy da documentação.

Quando chega o momento de publicar, basta executar:

rake rails-api-docs:build

O resultado é:

public/api-docs.html

Um único arquivo HTML.

Tudo embutido.

CSS inline.

JavaScript inline.

Sem dependências externas.

Sem CDN.

Sem Asset Pipeline.

Sem runtime JavaScript.

Apenas um arquivo estático que pode ser hospedado praticamente em qualquer lugar.

Não estou tentando substituir OpenAPI

Existem excelentes ferramentas baseadas em OpenAPI e Swagger.

Elas resolvem muito bem diversos cenários.

O objetivo do rails-api-docs não é substituir esse ecossistema.

A proposta é diferente.

Eu queria uma solução que permitisse:

gerar documentação a partir de uma aplicação Rails existente
editar tudo em YAML
visualizar mudanças instantaneamente
exportar um HTML estático
manter a documentação sincronizada com pouco esforço

Era esse workflow que eu procurava.

E como não encontrei exatamente dessa forma, resolvi construir.

Considerações finais

Documentação de API deveria ser simples de criar e simples de manter.

Na minha experiência, o maior problema não é gerar a primeira versão.

O desafio é mantê-la atualizada ao longo do tempo.

O rails-api-docs nasceu justamente para reduzir esse atrito.

Inspecionando a aplicação para gerar um ponto de partida.

Preservando suas customizações ao longo do tempo.

E oferecendo um ciclo de feedback extremamente rápido durante o desenvolvimento.

Se quiser experimentar:

⭐ https://github.com/jacksonpires/rails-api-docs

Feedbacks, sugestões e contribuições são muito bem-vindos.

🇺🇸 Introducing Rails HTTP Lab: Test Your Rails Routes Directly Inside Your Application

Jackson Pires — Fri, 29 May 2026 17:57:35 +0000

When working with Ruby on Rails, testing HTTP endpoints is part of everyday development.

Most of the time, we rely on tools like Postman, Insomnia, curl, or even temporary scripts just to validate requests, headers, payloads, and responses.

But during development, I found myself asking:

What if I could test my Rails routes directly from inside the application itself?

That idea led me to create Rails HTTP Lab.

What is Rails HTTP Lab?

rails-http-lab is a Rails Engine that provides an embedded interface inside your Rails application to test HTTP requests against your own routes.

Think of it as a lightweight HTTP client focused on your Rails app.

With it, you can experiment with your endpoints without constantly switching between your editor, terminal, browser, and external API tools.

Features

Current capabilities include:

Support for common HTTP verbs
Send request parameters and payloads
Inspect responses directly in the browser
Mountable Rails Engine
Seamless integration with your Rails development workflow
Simple setup

Installation

Add the gem to your Gemfile:

gem "rails-http-lab"

Then install it:

bundle install

Now start your Rails server and access:

/rails/http-lab

And you're ready to start testing your routes.

Why build this?

I wanted something that felt more integrated with the Rails developer experience.

External API clients are great, but sometimes you simply want a quick way to:

test an endpoint
tweak parameters
inspect responses
validate controller behavior

…without leaving your application context.

Rails HTTP Lab was created to reduce that friction.

Open Source & Feedback Welcome

The project is open source and still evolving.

If you like the idea, have suggestions, or want to contribute, feel free to check out the repository:

👉 https://github.com/jacksonpires/rails-http-lab

Feedback, issues, PRs, and ideas are very welcome.

Happy hacking 🚀

Special thanks to Vini (https://github.com/viniwenz) and Karine (https://github.com/karinevieira) for helping me with testing!

🇧🇷 Apresentando Rails HTTP Lab: teste rotas Rails diretamente dentro da sua aplicação

Jackson Pires — Fri, 29 May 2026 17:55:55 +0000

Quem trabalha com Ruby on Rails sabe que testar endpoints HTTP faz parte da rotina de desenvolvimento.

Na maioria das vezes usamos ferramentas como Postman, Insomnia, curl ou até scripts temporários apenas para validar requests, headers, payloads e responses.

Mas durante o desenvolvimento eu comecei a me perguntar:

E se fosse possível testar as rotas da própria aplicação Rails diretamente de dentro dela?

Foi dessa ideia que nasceu o Rails HTTP Lab.

O que é o Rails HTTP Lab?

rails-http-lab é uma Rails Engine que adiciona uma interface integrada à sua aplicação para testar requisições HTTP contra as próprias rotas da aplicação.

Pense nele como um cliente HTTP leve, mas focado no seu ambiente Rails.

Com ele você pode experimentar endpoints sem precisar alternar constantemente entre editor, terminal, navegador e ferramentas externas de API.

Funcionalidades

Atualmente a gem oferece:

Suporte aos principais verbos HTTP
Envio de parâmetros e payloads
Visualização das responses diretamente no navegador
Rails Engine mountável
Integração natural com o fluxo de desenvolvimento Rails
Configuração simples

Instalação

Adicione a gem ao seu Gemfile:

gem "rails-http-lab"

Depois instale:

bundle install

Agora basta iniciar o servidor Rails e acessar:

/rails/http-lab

Pronto. Você já pode começar a testar suas rotas.

Por que criar isso?

Eu queria algo mais integrado à experiência de desenvolvimento com Rails.

Ferramentas externas de API são excelentes, mas às vezes você só precisa de uma forma rápida de:

testar um endpoint
ajustar parâmetros
inspecionar responses
validar o comportamento do controller

…sem sair do contexto da própria aplicação.

O Rails HTTP Lab surgiu justamente para reduzir esse atrito.

Open Source e feedback são bem-vindos

O projeto é open source e ainda está evoluindo.

Se a ideia parece interessante, você tem sugestões ou quer contribuir, confira o repositório:

👉 https://github.com/jacksonpires/rails-http-lab

Issues, PRs, feedbacks e ideias são muito bem-vindos.

Happy coding 🚀

Agradecimento especial a Vini (https://github.com/viniwenz) e Karine (https://github.com/karinevieira) que me ajudaram nos testes!

🇺🇸 Glancer — Ask your Rails database questions in plain language

Ernane Ferreira — Wed, 27 May 2026 17:11:10 +0000

A Rails engine that allows you to query the database using natural language, with RAG and LLMs. No need to write any code.

Every Rails project reaches a point where someone on the team (product, support, management) needs data, but no one has time to write a quick query for them. You know the drill: a Slack message, a GitHub issue titled "how many users signed up last week?", or a CSV request that ends up in someone's backlog.

So, I think about Glancer.

What it is

Glancer is a Ruby on Rails engine that mounts a full chat interface at /glancer inside your app. You type a question in plain language, it retrieves the relevant schema context, generates a SELECT query (or an ActiveRecord expression), validates and executes it safely, then returns the result with a human-readable explanation.

"How many orders were placed in the last 30 days, grouped by status?"
→ SELECT executed, results shown, answer written in plain language.

It is inspired by Blazer, but instead of writing SQL yourself, you just ask.

Getting started

Add it to your Gemfile:

gem "glancer"

Run the generator:

rails generate glancer:install
rails db:migrate
rails glancer:index:all

Then visit /glancer and start asking questions.

The generator creates an initializer where you configure your LLM provider. A minimal setup with Gemini looks like this:

Glancer.configure do |config|
  config.llm_provider   = :gemini
  config.llm_model      = "gemini-2.0-flash"
  config.gemini_api_key = ENV["GEMINI_API_KEY"]

  config.schema_permission = true
end

OpenAI and OpenRouter are also supported. It runs on top of RubyLLM, so any model it supports works here too. You can assign different models per role: a smarter model for query generation, a cheaper one for writing the response.

What it can do

A few things worth knowing:

Safety is not optional. Every query runs inside a transaction that always rolls back. The keyword blocklist rejects DELETE, UPDATE, INSERT, DROP, and friends before they even touch the executor. You can also point it at a read-only replica.

No extra infrastructure. Embeddings live in your existing database as a JSON column. No Pinecone, no Weaviate, nothing to set up.

It understands your domain. You can drop a Markdown file at config/glancer/llm_context.glancer.md and teach Glancer your business rules — what status values mean, how revenue is calculated, which columns to ignore:

- `orders.status` values: "pending" | "paid" | "shipped" | "refunded"
- Monthly revenue = SUM(orders.total) WHERE status = "paid"
- When asked about "churn", use the `churned_at` column on `subscriptions`

The UI has some nice touches. Results render in a table with one-click CSV export. Charts are auto-generated where they make sense. Queries run in a background thread, so the main app thread stays free. You can type @table_name to pin a specific table to your question, edit the generated SQL inline and re-run it, and even dictate questions via microphone. There is also a schema viewer at /glancer/db-schema.

Blazer integration. If you already have Blazer installed, Glancer shows a button to open the generated SQL there directly.

The story behind it

This started as a study project. I had never published a gem before and wanted to understand the full process, from engine internals to gemspec to CI. I shared it with a few colleagues and they actually found it useful, so I decided to put it out there for the community.

It is version 1.0.0.

If you try it, I would love to hear what you think, about the code or the idea itself. Issues and pull requests are open.

If you find it useful, a star on the repo goes a long way in helping more people discover it.

GitHub: https://github.com/ErnaneJ/glancer
RubyGems: https://rubygems.org/gems/glancer

🇧🇷 Glancer — Converse com seu banco de dados Rails em linguagem natural

Ernane Ferreira — Wed, 27 May 2026 17:05:40 +0000

Uma engine Rails que permite consultar o banco de dados com linguagem natural, usando RAG e LLMs. Sem precisar escrever código.

Todo projeto Rails chega num ponto em que alguém do time (produto, suporte, gestão, etc.) precisa de um dado, mas ninguém tem tempo de parar para compreender a necessidade e escrever uma query. A mensagem no Slack, o card aberto, o pedido de CSV que some no backlog. Quem nunca.

Foi isso que me fez pensar no Glancer.

O que é

Glancer é uma engine Ruby on Rails que monta uma interface de chat em /glancer dentro da sua aplicação. Você digita uma pergunta em linguagem natural, ele busca o contexto relevante do sistema, gera um SELECT (ou uma expressão ActiveRecord), valida, executa com segurança e retorna o resultado.

"Quantos pedidos foram feitos nos últimos 30 dias, agrupados por status?"
→ SELECT executado, resultados exibidos, resposta escrita em português.

A inspiração direta foi o Blazer, uma gem que já usei bastante. A ideia aqui é dar um passo a mais: em vez de escrever o SQL, você só pergunta.

Como começar

Adicione no Gemfile:

gem "glancer"

Execute o gerador:

rails generate glancer:install
rails db:migrate
rails glancer:index:all

Acesse /glancer e comece a perguntar.

O gerador cria um initializer onde você configura o provider de LLM. Uma configuração mínima com Gemini:

Glancer.configure do |config|
  config.llm_provider   = :gemini
  config.llm_model      = "gemini-2.0-flash"
  config.gemini_api_key = ENV["GEMINI_API_KEY"]
  config.schema_permission = true
end

OpenAI e OpenRouter também são suportados. Ela roda em cima do RubyLLM então os modelos que ele suportar, o Glancer suportará. Dá para usar modelos diferentes por papel, por exemplo, um modelo mais capaz para gerar a query e um mais barato para escrever a resposta.

O que ele faz

Alguns pontos que vale conhecer:

Segurança por padrão: Toda query roda dentro de uma transaction que sempre faz rollback. Um blocklist de palavras rejeita DELETE, UPDATE, INSERT, DROP e afins antes mesmo de chegar no executor. Também é possível apontar para uma réplica de leitura.

Sem infraestrutura adicional: Os embeddings ficam no seu banco existente, numa coluna JSON. Sem Pinecone, sem Weaviate, sem nada extra para subir. Raramente será muita coisa, por isso essa abordagem.

Ensina o contexto do seu negócio. Você coloca um arquivo Markdown em config/glancer/llm_context.glancer.md e explica as regras do domínio: o que os valores de status significam, como a receita é calculada, quais colunas/tabelas/modelos ignorar, etc:

- `orders.status`: "pending" | "paid" | "shipped" | "refunded"
- Receita mensal = SUM(orders.total) WHERE status = "paid"
- Para perguntas sobre "churn", usar a coluna `churned_at` em `subscriptions`

Informações adicionais mais dinâmicas podem ser adicionadas em um campo texto nas configurações. Entretanto, não será gerado embedding disso pois será utilizado de contexto ao modelo base.

A interface tem uns detalhes legais. Os resultados aparecem em tabela com export CSV de um clique. Gráficos são gerados automaticamente quando fazem sentido. O processo de execução foi pensado para não travar a thread principal da aplicação. Dá para digitar @nome_da_tabela para fixar e ser mais assertivo sobre uma tabela específica na pergunta, editar o SQL gerado e reexecutar, e até ditar a pergunta pelo microfone. Tem também um visualizador de schema em /glancer/db-schema.

Integração com Blazer. Se você já usa o Blazer, o Glancer mostra um botão para abrir o SQL gerado direto lá.

A história por trás

Comecei isso como projeto de estudo. Estudei bastante sobre RAG e LLMs ao longo do ano passado e quando a ideia surgiu eu nunca tinha publicado uma gem antes e queria experimentar o processo completo, de engine a gemspec a CI. Com isso, juntei o útil ao agradável. Como mostrei para alguns colegas e eles acharam útil, então decidi abrir para a comunidade.

Atualmente está na versão 1.0.0.

Se você testar, adoraria saber o que achou, seja sobre o código ou sobre a ideia. Issues e pull requests são bem-vindos.

Se gostar do projeto, uma estrela no repositório ajuda bastante a divulgar para mais pessoas da comunidade.

GitHub: https://github.com/ErnaneJ/glancer
RubyGems: https://rubygems.org/gems/glancer

DEV Community: Vídeos de Ti

🇧🇷 Continuando a jornada com RubyUI: apresentando o ruby_ui_converter

O problema das aplicações legadas

Apresentando o ruby_ui_converter

Transformando ERB em componentes Ruby automaticamente

Conversão inteligente para Phlex e RubyUI

Migração gradual, sem reescrever tudo

Construindo um ecossistema em torno de RubyUI

ruby_ui_scaffold

ruby_ui_converter

O objetivo final

🇺🇸 Continuing the RubyUI Journey: Introducing ruby_ui_converter

The challenge of legacy applications

Introducing ruby_ui_converter

Automatically converting ERB into Ruby components

Intelligent conversion for Phlex and RubyUI

Gradual migration without rewriting everything

Building an ecosystem around RubyUI

ruby_ui_scaffold

ruby_ui_converter

The bigger vision

🇺🇸 Learning RubyUI Through Real Applications with `ruby_ui_scaffold`

What is ruby_ui_scaffold?

More than a Scaffold Generator

Learning RubyUI Through Real Code

Exploring Relationships

Discovering the DataTable Component

Generate Data and Experiment

A Playground for Phlex and RubyUI

Conclusion

🇧🇷 Aprendendo RubyUI na Prática com `ruby_ui_scaffold`

O que é o ruby_ui_scaffold?

Mais do que um gerador

Aprendendo RubyUI através de código real

Explorando relacionamentos

Conhecendo o DataTable

Gerando dados para experimentar

Um laboratório para aprender Phlex e RubyUI

Conclusão

🇺🇸 3 Essential Gems to Eliminate Friction in Your Rails Workflow

1. rails-api-docs: The End of Outdated Documentation]

2. rails-http-lab: Your HTTP Client Right in the App

3. rails-realtime-erd: Database Diagrams Always in Sync

Conclusion

🇧🇷 3 Gems Indispensáveis para Eliminar as Deficiências do seu Fluxo de Trabalho no Rails

1. rails-api-docs: O Fim da Documentação Desatualizada

2. rails-http-lab: Seu Client HTTP Direto na Aplicação

3. rails-realtime-erd: Diagramas de Banco de Dados Sempre Sincronizados

Conclusão

🇺🇸 I Got Tired of Stale API Documentation in Rails — So I Built `rails-api-docs`

The idea started with a simple question

The workflow I wanted didn't exist

A single source of truth

How it works

Let the code write the first draft

Documentation updates shouldn't destroy your work

Organizing larger APIs with tags

Production should be simple

I'm not trying to replace OpenAPI

Final thoughts

🇧🇷 Eu Cansei de Documentação de API Desatualizada no Rails — Então Criei a Gem `rails-api-docs`

A ideia surgiu de uma pergunta simples

O workflow que eu queria não existia

Uma única fonte da verdade

Como funciona

Deixe o código escrever o primeiro rascunho

Atualizações não deveriam apagar seu trabalho

Organizando APIs maiores com Tags

Produção deveria ser simples

Não estou tentando substituir OpenAPI

Considerações finais

🇺🇸 Introducing Rails HTTP Lab: Test Your Rails Routes Directly Inside Your Application

What is Rails HTTP Lab?

Features

Installation

Why build this?

Open Source & Feedback Welcome

🇧🇷 Apresentando Rails HTTP Lab: teste rotas Rails diretamente dentro da sua aplicação

O que é o Rails HTTP Lab?

Funcionalidades

1. `rails-api-docs`: The End of Outdated Documentation]

2. `rails-http-lab`: Your HTTP Client Right in the App

3. `rails-realtime-erd`: Database Diagrams Always in Sync

1. `rails-api-docs`: O Fim da Documentação Desatualizada

2. `rails-http-lab`: Seu Client HTTP Direto na Aplicação

3. `rails-realtime-erd`: Diagramas de Banco de Dados Sempre Sincronizados