DEV Community: Cirdes Henrique

Beyond Autocomplete: How Cursor AI is Helping Standardize and Write Ruby on Rails Code

Cirdes Henrique — Sun, 23 Mar 2025 20:48:47 +0000

Context

Until recently, aside from code autocomplete capabilities, I had yet to see a truly reliable way to generate AI-powered code that would be useful for my company, Linkana.

I agree with DHH when he says that AI is merely an excellent junior developer—sometimes producing overly complex code or introducing subtle, hard-to-spot bugs. Whether this will change in the future is uncertain. What matters is that today, by providing good context, we can get AI to help us write high-quality code.

Cursor AI

In September of last year, Rafael França (Rails Core) spent a few days in São Paulo and showed me that he was using Cursor instead of VSCode. I decided to switch to Cursor AI, and since then, I’ve been taking advantage of its superior autocomplete capabilities and its ability to explain code snippets. So far, nothing too sophisticated.

Cursor Rules

Over the past few weeks, I discovered the Rules for AI feature—a way to teach AI how to "think." This allows us to guide Cursor to behave like a good junior developer would: recognizing code patterns, replicating them in similar contexts, and ensuring consistency across the project.

Migrating from RSpec to MiniTest

Last year, we decided to migrate to MiniTest. We started writing new tests in MiniTest, but we still have hundreds of files written in RSpec. As expected, no one wants to prioritize rewriting tests, making this migration extremely slow.

To speed up the process, we created a structure like this, allowing us to define specific rules for different contexts within our code:

.cursor/rules/
  ├── rails8.mdc
  ├── models/
  │   ├── active_record.mdc
  │   ├── tests.mdc
  │   └── postgresql.mdc
  ├── controllers/
  │   ├── api.mdc
  │   └── tests.mdc
  └── views/
      ├── phlex.mdc
      └── components.mdc

Let's take a look at models/tests.mdc:

---
description: ""
globs: test/models/**/*.rb
alwaysApply: true
---

# Rails Model Testing with Minitest and FactoryBot

## General Structure

- Each model should have its own corresponding test file (e.g., `user_test.rb` for the `User` model)
- Test files should be organized within the `test/models` directory, mirroring the application structure
- Subdirectories can be used to organize specific components (e.g., `test/models/documents/`)

## Test Configuration and Organization

- Each file should include `require "test_helper"` at the beginning
- The test class should inherit from `ActiveSupport::TestCase`
- Tests should be written using `test "description" do` instead of `def test_description`
- Related tests should be grouped together
- The `setup` method should be used to create test data with factories

## Using Factories

- Factories should be defined in `test/factories/`
- Use `create(:factory_name)` for persisted records and `build(:factory_name)` for non-persisted ones
- Use `build_stubbed(:factory_name)` when persistence is not needed
- Use descriptive traits for factory variations (e.g., `:with_buyer`, `:not_clear`)

## Example Structure

# frozen_string_literal: true

require "test_helper"

class ModelNameTest < ActiveSupport::TestCase
  def setup
    @model = create(:model_name, :with_trait)
  end

  test "associations" do
    assert_respond_to(@model, :association_name)
    # Test other associations...
  end

  test "validations" do
    invalid_model = build(:model_name, required_attribute: nil)
    refute(invalid_model.valid?)
    assert_equal(invalid_model.errors[:required_attribute], ["expected error message"])
  end
end

## Style and Best Practices

- Tests should be independent and isolated
- Avoid fixtures whenever possible, preferring factories
- Use meaningful test data to clearly express intent
- Test edge cases and failure scenarios
- Follow the "Arrange, Act, Assert" pattern
- Cover both positive and negative cases

This rule establishes standards for things like using factories, organizing tests, and formatting test "instance_method" do statements. Beyond guiding AI in writing tests, these rules help maintain project standardization and serve as documentation of best practices for both the human team and the AI itself.

The most interesting part is that I generated this rule with a single prompt in Cursor. I provided documentation and examples from my own code, and the AI automatically created the instructions—I only had to make minor adjustments.

Using It in Practice

With the rules in place, it was time to test them in practice. When I asked Cursor to migrate an RSpec test to MiniTest, it automatically identified the applicable rule based on globs: test/models/**/*.rb.

To validate the process, I migrated the files one by one. The only error I encountered was related to language—Cursor expected error messages in English, but my application is in Portuguese.

In the end, I was able to open a Pull Request with minimal effort and the expected quality. Will this PR be merged without any requested changes?

Além do autocomplete: como o Cursor AI está ajudando na padronização e escrita do código Ruby on Rails

Cirdes Henrique — Sun, 23 Mar 2025 20:48:17 +0000

ENGLISH

Contexto

Até pouco tempo atrás, além da capacidade de autocompletar código, eu ainda não tinha visto uma forma realmente confiável de gerar código com IA que fosse útil para minha empresa, a Linkana.

Concordo com o DHH quando ele diz que a IA é apenas um excelente programador júnior, que por vezes pode gerar um código excessivamente complexo ou introduzir bugs quase imperceptíveis. Se no futuro isso será diferente, não sabemos. O que importa é que, hoje, podemos fornecer um bom contexto para que a IA nos ajude a escrever código de qualidade.

Cursor AI

Em setembro do ano passado, o Rafael França (Rails Core) passou alguns dias em São Paulo e me mostrou que estava usando o Cursor no lugar do VSCode. Decidi migrar para o Cursor AI e, desde então, tenho aproveitado sua melhor capacidade de autocomplete e a funcionalidade de explicar trechos de código. Até então, nada muito sofisticado.

Cursor Rules

Nas últimas semanas, conheci a funcionalidade de Rules for AI, uma maneira de ensinar à IA como ela deve "pensar". Dessa forma, conseguimos orientar o Cursor a agir como um bom desenvolvedor júnior se comportaria, reconhecendo padrões de código, replicando-os em contextos semelhantes e garantindo consistência no projeto.

Migrando de RSpec para MiniTest

No ano passado, decidimos migrar para MiniTest. Passamos a escrever novos testes em MiniTest, mas ainda temos centenas de arquivos escritos em RSpec. Como era de se esperar, ninguém quer priorizar a reescrita de testes, o que tornou essa migração extremamente lenta.

Para acelerar esse processo, criamos uma estrutura semelhante a esta, permitindo definir regras específicas para diferentes contextos do nosso código:

.cursor/rules/
  ├── rails8.mdc
  ├── models/
  │   ├── active_record.mdc
  │   ├── tests.mdc
  │   └── postgresql.mdc
  ├── controllers/
  │   ├── api.mdc
  │   └── tests.mdc
  └── views/
      ├── phlex.mdc
      └── components.mdc

Vamos dar uma olhada no models/tests.mdc:

---
description: ""
globs: test/models/**/*.rb
alwaysApply: true
---

# Rails Model Testing with Minitest and FactoryBot

## General Structure

- Each model should have its own corresponding test file (e.g., `user_test.rb` for the `User` model)
- Test files should be organized within the `test/models` directory, mirroring the application structure
- Subdirectories can be used to organize specific components (e.g., `test/models/documents/`)

## Test Configuration and Organization

- Each file should include `require "test_helper"` at the beginning
- The test class should inherit from `ActiveSupport::TestCase`
- Tests should be written using `test "description" do` instead of `def test_description`
- Related tests should be grouped together
- The `setup` method should be used to create test data with factories

## Using Factories

- Factories should be defined in `test/factories/`
- Use `create(:factory_name)` for persisted records and `build(:factory_name)` for non-persisted ones
- Use `build_stubbed(:factory_name)` when persistence is not needed
- Use descriptive traits for factory variations (e.g., `:with_buyer`, `:not_clear`)

## Example Structure

# frozen_string_literal: true

require "test_helper"

class ModelNameTest < ActiveSupport::TestCase
  def setup
    @model = create(:model_name, :with_trait)
  end

  test "associations" do
    assert_respond_to(@model, :association_name)
    # Test other associations...
  end

  test "validations" do
    invalid_model = build(:model_name, required_attribute: nil)
    refute(invalid_model.valid?)
    assert_equal(invalid_model.errors[:required_attribute], ["expected error message"])
  end
end

## Style and Best Practices

- Tests should be independent and isolated
- Avoid fixtures whenever possible, preferring factories
- Use meaningful test data to clearly express intent
- Test edge cases and failure scenarios
- Follow the "Arrange, Act, Assert" pattern
- Cover both positive and negative cases

Podemos notar que essa regra define padrões como o uso de factories, a organização dos testes, e o formato das declarações test "instance_method" do. Além de guiar a IA na escrita dos testes, essas regras também ajudam a manter a padronização do projeto e servem como documentação de boas práticas tanto para a equipe humana quanto para a própria IA.

O mais interessante é que consegui gerar essa rule com um único prompt no Cursor. Forneci a documentação e exemplos do meu próprio código, e a IA criou as instruções automaticamente – precisei apenas ajustar alguns detalhes.

Utilizando na prática

Com as regras definidas, chegou a hora de testar na prática. Ao solicitar que o Cursor fizesse a migração de um teste de RSpec para MiniTest, ele identificou automaticamente a regra aplicável com base no globs: test/models/**/*.rb.

Para validar o processo, fiz a migração arquivo por arquivo. O único erro que encontrei foi relacionado ao idioma: o Cursor esperava mensagens de erro em inglês, mas minha aplicação está em português.

No final, consegui abrir um Pull Request com baixíssimo esforço e com a qualidade esperada. Será que esse PR vai ser mergeado sem pedidos de correção?

Why Your Company Should Sponsor Events

Cirdes Henrique — Sun, 10 Nov 2024 21:19:52 +0000

Versão em Português

Let's start by better defining a special type of event: non-commercial events aimed at the developer community. These are events like Tropical on Rails, Rails World, Ruby/Rails Conf, EuRuko, Friendly.rb, and many others. I want to help you—whether you’re a developer, a business owner, or an HR manager—understand why you should encourage your company to sponsor these events.

For Developers:

There are two types of developers: those who have attended a great event and those who haven’t. The first group knows what I’m talking about—they were the ones who sold out Tropical tickets 10 times faster, in just over 6 hours. But what actually happens at these events?

We Learn New Techniques

If you're developing software the same way you did last year, you're likely missing out on productivity, quality, or speed. Rails 7 and 8 have introduced various tools that impact one or more of these pillars. Technical events are where you learn new ‘tricks’ or meet people who are solving similar problems in different ways.

Access to Real-World Problem Solving

Hearing how other developers are tackling similar challenges can bring immediate value to your work. Events address real-world problems and solutions, shared by experienced developers who have tested various approaches and can help you solve challenges you may be facing right now.

We Meet Inspiring People

At events, you meet inspiring people, and—whether for better or worse—the people you choose to connect with have a greater impact on your life than you might think. The connection you create with someone after attending their talk and chatting in the hallway is incomparable to reading a blog article.
You leave the event motivated to learn and to become like that amazing person you met at the conference. It’s common to see stories of projects, whether open source, companies, or even other events, that emerge after these encounters.

For Companies

Who has been questioned for choosing Ruby on Rails in recent years? Who has struggled to find good developers? Events are a key factor in strengthening the community.

Motivated Developers

The most common feedback I heard from companies that participated in Tropical was that employees returned from the event eager to make things happen. Some organized internal workshops to share the knowledge they gained, while others adopted new practices they learned. Collectively, we’ve seen several meetups revive across Brazil, and according to Rafael França (Rails Core), more Brazilians have started contributing to the Rails project. For business owners, having motivated developers is essential for success. Motivated professionals are the ones who become seniors faster and produce more.

Employer Branding

Building your employer brand is essential. The best developers aren’t chosen by you; they choose your company.
This choice happens daily, whether during hiring or when deciding to stay with the company.
Attendees will have the chance to get to know your company and your team members. In a future hiring process, this will be remembered. The best developers I know are not only driven by salary; it’s important, but not decisive.

From the Organizer’s Perspective

Organizing an event, like contributing to open source, is a gift. To organize Tropical, I need to dedicate about 15% of my annual work time. Tropical is a 100% pro bono project. I've already talked about the challenges of organizing a conference and that Tropical came from my perception that the Ruby community in Brazil needed a large-scale event more than ever.

The challenge of events like this is that, in my case, ticket revenue only covers 50% of the conference costs. The other 50% I need to obtain with sponsor support. This isn’t different for Rails World or RubyConf: tickets are subsidized, and they also need the support of companies. Here, we have three types of companies:

There are companies like AppSignal, the first sponsor of Tropical in 2024, which sponsors events worldwide; CedarCode, a small company from Uruguay that not only sponsors various events but also supports the Rails Foundation; and Brazilian companies like SmartFit, Agendor, and others that proactively reach out to sponsor the event because they know the importance of these events for the community and want to give back to the ecosystem.
Then, we have companies that still don’t understand the importance of events. These are companies that have never had the opportunity to participate or have a very commercial view. Their first reaction is to calculate the return on investment (ROI). Of course, we need to generate value for sponsors, but this ROI isn’t easy to calculate. It manifests as strengthening the “Employer Brand,” “Motivation,” and “Training” of employees and has the collective impact of events, which help attract and retain Ruby developers, ultimately benefiting the sponsor. Some of these companies sponsor the event, while others don’t.
The third type of company understands the importance of events but opts to gain the benefits without effectively contributing. They buy tickets and encourage developers to submit talks but don’t sponsor. It’s okay for these companies to exist; what matters is that we have enough companies of types 1 and 2 to keep conferences like Tropical viable.

I need your help to convince companies about the importance of sponsoring events, not just Tropical. If you think your company needs a better understanding of the importance of events, share this text with leadership or try to explain it to them. If you’re interested in supporting Tropical, send me an email at sponsors@tropicalonrails.com

Por que sua empresa deveria patrocinar eventos

Cirdes Henrique — Sat, 09 Nov 2024 15:25:04 +0000

English version

Vamos começar definindo melhor um tipo especial de evento: os eventos não comerciais voltados para a comunidade de desenvolvedores. São eventos como o Tropical on Rails, a Rails World, a Ruby/Rails Conf, EuRuko, Friendly.rb e tantos outros. Quero ajudar você, desenvolvedor, dono de empresa ou responsável pela área de RH, a entender melhor por que você deveria incentivar sua empresa a patrocinar eventos.

Para os desenvolvedores:

Existem dois tipos de desenvolvedores: aqueles que já participaram de um bom evento e aqueles que nunca foram. O primeiro grupo sabe do que estou falando – foram eles que esgotaram os ingressos da Tropical 10 vezes mais rápido, em pouco mais de 6 horas. Mas o que acontece nesses eventos?

Aprendemos novas técnicas

Se você está desenvolvendo software da mesma forma que no ano passado, está perdendo em produtividade, qualidade ou velocidade. O Rails 7 e o 8 trouxeram diversas ferramentas que impactam um ou mais desses pilares. São em eventos técnicos que você aprende novos 'truques' ou conhece pessoas que estão resolvendo problemas parecidos com os seus, de uma forma diferente.

Acesso à Resolução de Problemas do Mundo Real

Ouvir como outros desenvolvedores estão enfrentando desafios semelhantes pode trazer valor imediato ao seu trabalho. Os eventos abordam problemas e soluções do mundo real, compartilhados por desenvolvedores experientes que testaram várias abordagens e que podem ajudar você a resolver desafios que esteja enfrentando no momento.

Conhecemos pessoas inspiradoras

Nos eventos, você conhece pessoas inspiradoras e, para o bem ou para o mal, as pessoas com quem você escolhe se conectar têm mais efeito na sua vida do que você imagina. A conexão que você cria com alguém depois de assistir à palestra dele e conversar no corredor não se compara a ler um artigo de blog.
Você sai do evento motivado a aprender e a se tornar como aquela pessoa incrível com quem conversou na conferência. É comum ver relatos de projetos, sejam open source, empresas ou até outros eventos que surgem após esses encontros.

Para as empresas

Quem já foi questionado por ter escolhido Ruby on Rails nos últimos anos? Quem tentou achar bons desenvolvedores e não conseguiu? Eventos são um fator chave para fortalecer a comunidade.

Desenvolvedores motivados

O relato mais comum que escutei das empresas que participaram do Tropical foi que as pessoas que foram ao evento voltaram com muita vontade de fazer acontecer. Algumas realizaram workshops internos para compartilhar o conhecimento adquirido, outras adotaram novas práticas aprendidas. Coletivamente, vimos vários meetups voltarem pelo Brasil e, segundo Rafael França (Rails Core), mais brasileiros começarem a contribuir com o projeto do Rails. Para donos de empresas, ter desenvolvedores motivados é essencial para o sucesso. São esses profissionais motivados que se tornam seniors mais rapidamente e produzem mais.

Marca empregadora

Trabalhar sua marca empregadora é fundamental. Os melhores desenvolvedores não são escolhidos por você; eles escolhem sua empresa.
Essa escolha é feita diariamente, seja em uma contratação ou na decisão de permanecer na empresa.
Os participantes terão a oportunidade de conhecer sua empresa e seus colaboradores. Em um futuro processo seletivo, isso será lembrado. Os melhores desenvolvedores que conheço não são motivados apenas por salário; ele é importante, mas não decisivo.

Ponto de vista do organizador

Organizar um evento, assim como contribuir com open source, é um presente. Para organizar o Tropical, preciso dedicar cerca de 15% da minha jornada de trabalho anual. O Tropical é um projeto 100% pró bono. Já falei sobre os desafios de organizar uma conferência e que o Tropical surgiu da minha percepção de que a comunidade Ruby no Brasil precisava, mais do que nunca, de um evento de grande porte.

O desafio de eventos assim é que o valor do ingresso, no meu caso, cobre apenas 50% dos custos da conferência. Os outros 50% eu preciso obter com o apoio de patrocinadores. Não é diferente para a Rails World ou a RubyConf: os ingressos são subsidiados e eles também precisam do apoio das empresas. Temos três tipos de perfis de empresas aqui:

Temos empresas como a AppSignal, a primeira patrocinadora do Tropical em 2024, que patrocinam eventos pelo mundo todo; a CedarCode, uma empresa do Uruguai, com poucas pessoas, que não só patrocina vários eventos, mas também apoia a própria Rails Foundation; e empresas brasileiras como a SmartFit, Agendor e outras que me procuram proativamente para patrocinar o evento, pois sabem da importância dos eventos para a comunidade e querem contribuir com o ecossistema.
Temos empresas que ainda não entendem a importância dos eventos. São empresas que nunca tiveram a oportunidade de participar ou que possuem uma visão muito comercial. A primeira reação delas é tentar calcular o retorno do investimento (ROI). É claro que precisamos gerar valor para os patrocinadores, mas esse ROI não é fácil de calcular. Ele se manifesta como fortalecimento da "Marca Empregadora", "Motivação" e "Capacitação" dos funcionários e também tem o aspecto coletivo dos eventos, que ajudam a atrair e reter programadores para a linguagem Ruby, o que acaba retornando para o patrocinador. Algumas dessas empresas patrocinam o evento; outras, não.
O terceiro tipo de empresa entende a importância dos eventos, mas opta por tentar obter o benefício sem colaborar efetivamente. Elas compram ingressos e incentivam que os desenvolvedores enviem palestras, mas não patrocinam. Tudo bem existirem empresas assim; o importante é termos empresas do tipo 1 e 2 em quantidade suficiente para que conferências como o Tropical continuem viáveis.

Preciso da sua ajuda para convencer as empresas sobre a importância de patrocinar eventos, não apenas o Tropical. Se você acha que sua empresa precisa entender melhor a importância dos eventos, compartilhe este texto com a liderança ou tente explicar para eles. Se você tem interesse em apoiar o Tropical, me envie um e-mail para sponsors@tropicalonrails.com

Tropical.rb - Os desafios de organizar uma conferência de Ruby/Rails - [PT-BR]

Cirdes Henrique — Tue, 02 Jul 2024 11:41:03 +0000

English version

Introdução

Meu objetivo com este relato é ajudar outros organizadores de eventos, contando um pouco sobre o desafio de organizar o Tropical.rb - The Latin America Rails Conference.

Para quem não participou, esse vídeo destaca alguns momentos da conferência:

Eventos de tecnologia fazem parte da minha vida há bastante tempo. Minha primeira empresa foi uma startup de eventos, a Eventick. Por conta dela, tive a oportunidade de participar de, ou até mesmo ajudar no credenciamento de, diversos eventos. Alguns exemplos são: BrazilJS, AgileTrends, FrontInSampa, FrontInVale, FrontInBh, RubyConf e alguns eventos internacionais como a Rails World, DPW e a Waza do Heroku. Inclusive, foi na Waza em 2013 que conheci o Matz, criador do Ruby. ❤️

O Início do Plano

O Tropical.rb já existia, e sua última edição havia acontecido em 2015. Ele começou como um evento local organizado pelo grupo de usuários Ruby de Recife, o FrevoOnRails. Na época, o evento se chamava AbrilProRuby. Eu organizei a segunda edição regional do evento e ajudei na primeira edição nacional, que foi idealizada por Lailson Bandeira e também teve Thiago Diniz como organizador.

No começo de 2023, eu estava sentindo falta de eventos de Ruby/Rails no Brasil. Os meetups regionais não estavam acontecendo com regularidade, e ouvia-se falar muito pouco sobre Ruby. Os grandes responsáveis por divulgar o Rails no Brasil, Fábio Akita e a Plataformatec, já não estavam mais focados em Ruby. Estava claro para mim que era preciso retomar os eventos.

O primeiro grande desafio de organizar um evento é que a maioria deles é deficitária. A última edição do Tropical.rb, em 2015, teve um prejuízo, em valores atuais, de R$ 250.000,00 (USD 50k). A RubyConf, a TheConf, a FrontInSampa e tantas outras conferências deram prejuízo, e muitas vezes vi esse custo recaindo sobre o organizador.

Quando levei essa ideia para o meu sócio, Leo Cavalcanti, ele topou imediatamente. Como ele gosta de dizer, a Linkana é uma startup independente e lucrativa. Decidimos nos arriscar e organizar uma conferência, mesmo que nossos clientes não fossem desenvolvedores, pois sabíamos que era algo importante a ser feito. Com isso, a Linkana assumiu o risco financeiro do evento.

A primeira pessoa que procurei para me ajudar foi Rafael França, membro do Rails Core e amigo de longa data.

França topou imediatamente ajudar a organizar o evento, e isso fez toda a diferença. Pela rede de contatos dele e pela credibilidade que a conferência ganhou ao ser co-organizada por um membro do Rails Core. Alguns meses depois, Ju Dias e Débora Fernandes se juntaram ao time.

Buscando Palestrantes

Boa parte da experiência de uma conferência são as pessoas que você conhece ou reencontra. Nos melhores eventos que já participei, além do networking, aprendi muito com as palestras. Para conseguir a atenção dos keynotes mais famosos, sabia que precisava convidá-los pessoalmente para o evento. Fui um dos "sortudos" que conseguiu comprar um dos ingressos da primeira edição do Rails World em Amsterdã.

Encontrei pessoalmente boa parte dos palestrantes que vieram de fora. Preparei um kit com camisa, havaianas, cachaça e uma bolsa de praia. Também levei várias camisas que distribuí para os brasileiros e os membros do Rails Core. O evento foi "invadido" pelo Tropical.rb, e todo mundo estava se perguntando o que era essa camisa roxa. Até o DHH ganhou a dele:

Com a divulgação do evento em https://rubyconferences.org/, nas newsletters e no Twitter, conseguimos mais de 100 propostas de palestras. Outro ponto importante para a conferência foi que definimos bem o nosso foco. Assim como na Rails World, queríamos falar sobre o futuro do framework e sobre startups. Ter o Rafael França como um dos revisores foi muito importante; ele nos dizia o que estava ou não alinhado com o Rails 8.

Para que os palestrantes se sentissem em casa, pensamos em vários detalhes. Para os palestrantes que não falavam português, eu e os outros organizadores fomos pessoalmente buscá-los no aeroporto e levá-los para o hotel. O hotel que escolhemos era uma rede internacional, que os palestrantes já conheciam e ficava próxima ao local do evento. Thiago Diniz ficou responsável por cuidar de todos os palestrantes durante todo o período de estadia deles.

Boa parte das empresas de fora possuem política de arcar com custos de viagem e hospedagem caso seus funcionários sejam selecionados para palestrar. Isso ajuda muito, já que fica inviável para o evento arcar com passagem e hospedagem. Para os demais, pagamos os custos de hospedagem.

A Venda dos Ingressos

Para vender os ingressos, inspirei-me no Rails World, que focou bastante na divulgação antes de iniciar as vendas. Isso deu muito certo para nós também. Com os keynotes confirmados, colocamos um site no ar para que as pessoas pudessem manifestar interesse em participar, e comecei a participar de meetups, podcasts e lives no YouTube. Reativamos nosso LinkedIn e Twitter.

Com o público já aguardando, abrimos as vendas e, em menos de 3 dias, todos os ingressos esgotaram. Entre ingressos e patrocinadores, tivemos um público de aproximadamente 400 pessoas.

Busca por Patrocinadores

Pelo fato de nossa equipe ser enxuta, acabamos não paralelizando as iniciativas, e a busca por patrocinadores ficou por último. Acontece que isso foi, acidentalmente, a melhor coisa que fizemos. Esse era o meu maior desafio de longe, tanto porque não sou um vendedor quanto pelo histórico do evento. Por ter ficado por último, quando chegamos para falar com potenciais patrocinadores, já tínhamos os keynotes anunciados e todos os ingressos para o público geral esgotados.

As empresas que patrocinam eventos não têm recursos ilimitados. Elas precisam escolher quais eventos vão poder patrocinar. Fizemos um documento bem elaborado para listar tudo que fazia parte do pacote e mapeamos diversas empresas que utilizam Ruby on Rails. Com um bom material de patrocínio, ingressos esgotados e keynotes confirmados, acabou sendo mais fácil do que eu esperava. Diferente da última edição, as empresas que utilizam Rails estão bem mais maduras e tem faltado profissionais de Ruby no mercado; elas querem associar a marca ao evento para consolidar sua marca empregadora. Também conseguimos apoio de empresas que vendem para desenvolvedores e outras de fora do país que estão interessadas em contratar no Brasil. No final, conseguimos fechar as contas do evento no azul.

Outro fator importante é que abrimos um CNPJ de uma associação sem fins lucrativos, a "Rubi nos Trilhos do Brasil", para que pudéssemos emitir nota fiscal para os patrocinadores, ao mesmo tempo que os recursos seriam destinados única e exclusivamente para o evento. Nenhum organizador ou voluntário recebeu nada do evento. No final, tivemos 19 patrocinadores incríveis!

O Dia do Evento

A escolha do local e do formato foi crucial. Eu queria associar o Rails às startups, por isso escolhi o Cubo Itaú, o maior hub de startups da América Latina. Um auditório moderno com excelente infraestrutura.

Um dos desafios foi acumular a responsabilidade de co-apresentador do evento. Para enfrentar esse desafio, a Larissa Santana e a consultoria Calor me ajudaram muito.

Além das palestras tradicionais, tivemos algumas iniciativas diferentes.

A primeira delas foi um painel com quatro fundadores das maiores empresas brasileiras que utilizam Rails. Wagner Narde da Vindi, Carlos Brando da Enjoei, Thiago Scalone da CloudWalk e o Bruno Ghisi da RD Station. Muitos desenvolvedores sonham em empreender, e eu queria que as pessoas percebessem que o Rails continua sendo um dos melhores frameworks para iniciar uma startup.

O outro painel foi sobre a Rails Foundation. A criação da fundação foi uma das iniciativas mais importantes do Rails para a comunidade. Eu acreditava que as pessoas da América Latina precisavam conhecer a fundação, ao mesmo tempo que a fundação precisava entender melhor as demandas e necessidades dos desenvolvedores Ruby que estão fora do eixo América do Norte/Europa. Foi incrível contar com a participação de Amanda Perino, Diretora Executiva da Rails Foundation, Bruno Miranda, brasileiro e membro do conselho da Rails Foundation, e Robby Russel como mediador das perguntas.

Como um dos objetivos do evento era fortalecer a comunidade, todos os organizadores de meetups de Ruby/Rails do Brasil foram homenageados no palco, juntamente com Fábio Akita, responsável por criar e organizar a RubyConfBR ao longo de vários anos. Além disso, tivemos a oportunidade de homenagear Paulo Fagiani, organizador do histórico evento Oxente Rails, que infelizmente nos deixou alguns meses depois.

Por fim, junto com a Le Wagon, selecionamos desenvolvedores juniors recém-formados no bootcamp para criar um catálogo de empresas que utilizam Ruby on Rails no Brasil, apresentado no palco do evento. Muitos membros da equipe conseguiram seu primeiro emprego durante o processo.

Essas quatro iniciativas certamente tornaram o Tropical.rb ainda mais único.

Por fim

Organizar eventos de tecnologia trata-se de doar o que você tem de mais precioso: seu tempo. É crucial que sua motivação esteja no lugar certo. Não se trata de ROI (Retorno sobre o Investimento), não é sobre marketing de carreira. Trata-se de contribuir para algo em que você acredita.

Links para as palestras: Assista às palestras aqui

Links para as fotos: Veja as fotos aqui

Esperamos todos vocês em 2025!

Se quiserem discutir sobre organização de eventos, estou disponível no Linkedin e Twitter.

Tropical.rb - The Challenges of Organizing a Ruby/Rails Conference [EN]

Cirdes Henrique — Tue, 02 Jul 2024 11:40:29 +0000

Versão em Português

Introduction

My goal with this post is to help other event organizers by sharing a bit about the challenge of organizing the Tropical.rb - The Latin America Rails Conference.

For those who didn't attend, this video highlights some moments from the conference:

Technology events have been a part of my life for quite some time. My first company was an event startup, Eventick. Because of it, I had the opportunity to participate in, or even help with the accreditation of, several events. Some examples are: BrazilJS, AgileTrends, FrontInSampa, FrontInVale, FrontInBh, RubyConf, and some international events like Rails World, DPW, and Heroku's Waza. In fact, it was at Waza in 2013 that I met Matz, the creator of Ruby. ❤️

The Beginning of the Plan

Tropical.rb already existed, and its last edition had taken place in 2015. It started as a local event organized by the Recife Ruby user group, FrevoOnRails. At the time, the event was called "AbrilProRuby". I organized the second regional edition of the event and helped with the first national edition, which was conceived by Lailson Bandeira and also had Thiago Diniz as an organizer.

At the beginning of 2023, I was missing Ruby/Rails events in Brazil. Regional meetups were not happening regularly, and there was very little talk about Ruby. The main promoters of Rails in Brazil, Fábio Akita and Plataformatec, were no longer focused on Ruby. It was clear to me that events needed to be revived.

The first major challenge of organizing an event is that most of them operate at a loss. The last edition of Tropical.rb, in 2015, had a loss of R$ 250,000 (USD 50k) in today's values. RubyConf, TheConf, FrontInSampa, and so many other conferences have incurred losses, often with the organizer bearing the cost.

When I brought this idea to my partner, Leo Cavalcanti, he agreed immediately. As he likes to say, Linkana is an independent and profitable startup. We decided to take the risk and organize a conference, even though our clients weren't developers, because we knew it was something important to do. With that, Linkana took on the financial risk of the event.

The first person I reached out to for help was Rafael França, a member of the Rails Core and a long-time friend.

França immediately agreed to help organize the event, and that made all the difference. His network and the credibility that the conference gained by being co-organized by a Rails Core member were invaluable. A few months later, Ju Dias and Débora Fernandes joined the team.

Seeking Speakers

A significant part of the conference experience is the people you meet or reconnect with. At the best events I've attended, in addition to networking, I've learned a lot from the talks. To get the attention of the most famous keynotes, I knew I had to invite them personally. I was one of the "lucky ones" who managed to get a ticket to the first edition of Rails World in Amsterdam.

I met most of the speakers who came from abroad in person. I prepared a kit with a shirt, flip-flops, cachaça, and a beach bag. I also brought several shirts that I distributed to Brazilians and Rails Core members. The event was "invaded" by Tropical.rb, and everyone was wondering what that purple shirt was. Even DHH got his:

With the event's promotion on https://rubyconferences.org/, newsletters, and Twitter, we received over 100 talk proposals. Another important point for the conference was defining our focus well. Like Rails World, we wanted to talk about the framework's future and startups. Having Rafael França as one of the reviewers was very important; he told us what was or wasn't aligned with Rails 8.

To make the speakers feel at home, we thought of several details. For the speakers who didn't speak Portuguese, the organizers and I personally picked them up from the airport and took them to the hotel. The hotel we chose was an international chain that the speakers were familiar with and was close to the event venue. Thiago Diniz was responsible for taking care of all the speakers during their stay.

Many foreign companies have policies to cover travel and accommodation costs if their employees are selected to speak. This helps a lot since it's unfeasible for the event to cover these expenses. For the others, we covered the accommodation costs.

Ticket Sales

To sell tickets, I was inspired by Rails World, which focused heavily on promotion before starting sales. This worked very well for us too. With the keynotes confirmed, we launched a website where people could express interest in attending, and I started participating in meetups, podcasts, and YouTube lives. We reactivated our LinkedIn and Twitter.

With the audience already waiting, we opened sales, and in less than three days, all tickets sold out. Between tickets and sponsors, we had an audience of approximately 400 people.

Seeking Sponsors

Because our team was small, we didn't parallelize initiatives, and finding sponsors was the last task. This turned out to be the best thing we did. It was my biggest challenge by far, both because I'm not a salesperson and due to the event's history. By the time we approached potential sponsors, we already had the keynotes announced and all tickets for the general public sold out.

Companies that sponsor events do not have unlimited resources. They need to choose which events to sponsor. We created a well-crafted document listing everything included in the package and mapped several companies that use Ruby on Rails. With good sponsorship material, sold-out tickets, and confirmed keynotes, it was easier than I expected. Unlike the last edition, companies using Rails are now much more mature, and there is a shortage of Ruby professionals in the market. They want to associate their brand with the event to strengthen their employer brand. We also received support from companies that sell to developers and others from abroad interested in hiring in Brazil. In the end, we managed to break even.

Another important factor is that we opened a non-profit association, "Rubi nos Trilhos do Brasil," so we could issue invoices to sponsors, ensuring that resources were dedicated exclusively to the event. No organizer or volunteer received any compensation from the event. In the end, we had 19 amazing sponsors!

The Day of the Event

Choosing the venue and format was crucial. I wanted to associate Rails with startups, so I chose Cubo Itaú, the largest startup hub in Latin America. A modern auditorium with excellent infrastructure.

One of the challenges was taking on the responsibility of co-presenting the event. To tackle this, Larissa Santana and the consultancy Calor helped me a lot.

Besides the traditional talks, we had some unique initiatives.

The first was a panel with four founders of the largest Brazilian companies that use Rails: Wagner Narde from Vindi, Carlos Brando from Enjoei, Thiago Scalone from CloudWalk, and Bruno Ghisi from RD Station. Many developers aspire to become entrepreneurs, and I wanted people to see that Rails remains one of the best frameworks for launching a startup.

The other panel was about the Rails Foundation. The creation of the foundation was one of the most important initiatives for the Rails community. I believed that people in Latin America needed to know about the foundation, and the foundation needed to understand the demands and needs of Ruby developers outside the North America/Europe axis. It was incredible to have Amanda Perino, Executive Director of the Rails Foundation, Bruno Miranda, a Brazilian and a member of the Rails Foundation board, and Robby Russel as the question moderator.

One of the event's goals was to strengthen the community, so all the organizers of Ruby/Rails meetups in Brazil were honored on stage, along with Fábio Akita, who created and organized RubyConfBR for many years. Additionally, we had the opportunity to honor Paulo Fagiani, organizer of the historic Oxente Rails event, who sadly passed away a few months later.

Finally, in collaboration with Le Wagon, we selected junior developers recently graduated from the bootcamp to create a catalog of companies that use Ruby on Rails in Brazil, presented on stage at the event. Many team members got their first jobs during this process.

These four initiatives certainly made Tropical.rb even more unique.

In Conclusion

Organizing tech events is about giving what is most precious: your time. It's crucial that your motivation is in the right place. It's not about ROI (Return on Investment), nor is it about career marketing. It's about contributing to something you believe in.

Links to the talks: Watch the talks here

Links to the photos: See the photos here

We hope to see you all in 2025!

If you want to discuss event organization, I'm available on LinkedIn and Twitter.

From React to Hotwire - Part II - [EN]

Cirdes Henrique — Sun, 16 Jun 2024 15:50:03 +0000

Versão em Português

Introduction

In the first article about this migration from React to Hotwire, I discussed how we arrived at our current React stack. In this Part II, I will talk about the return to Rails views at Linkana.

Evolution of Rails and SSR

One of Rails' most brilliant characteristics is its obsession with simplicity. Since Rails was born within Basecamp, a company that chose to have few employees, it is part of Rails' DNA to seek ways to keep web development simple. This is why Rails is known as the One Person Framework.

Attending the latest edition of Rails World and watching the talk by DHH made me realize that generating views on the backend with Rails was no longer synonymous with slow, ugly interfaces that do not care about UX. With Hotwire, through Turbo and Stimulus, it was possible to create applications as complex as Gmail, Hey, or Slack, Campfire. And this became even more surreal with Turbo 8.

But the great benefit of returning to Server Side Rendering (SSR) is not needing APIs. Creating an API, whether REST or GraphQL, makes development slower. And it's not just Rails that is realizing this; Elixir with Liveview, PHP with Livewire, and even JS with HTMX, and React are following this trend. As Deno.js says: The Future (and the Past) of the Web is Server Side Rendering.

Components Are Here to Stay

As we saw in Part I of this article, views in React/Vue/etc. introduced the concept of components. These components are small interface blocks that condense "Style (Tailwind)", "Structure (HTML)", and "Behavior/JavaScript". Componentization, in addition to promoting reuse and facilitating testing, allows customization or use to create your own Design System. But most importantly, they are ready-made. You don't need to reinvent the wheel. A great example is Shadcn, launched only in March 2023 and already has 60k stars on Github.

Unfortunately, Rails views were created in a pre-components context. Html.erb is very good for writing HTML, but it is not good for writing behavior. Partials are great for writing behavior, but they are terrible for HTML.

To try to solve this, the first solution that emerged was ViewComponents, a framework created by the folks at Github. ViewComponent is our React, allowing the frontend to be thought of as components. It is the most popular solution today. Although I have never used it, I feel it lacked boldness. It seems like a fusion of partials with erb. But what disappointed me the most was that Github is migrating from Rails to React, and the maintainers of ViewComponents don't seem very enthusiastic.

As an alternative to ViewComponent, I found Phlex. It comes with the boldness of creating components using only Ruby code. This is the kind of boldness that scares. I was scared when I first saw React put HTML, JS, and CSS (StyledComponents) inside a component. I was scared to see Tailwind create classes for each CSS property and have HTML created with dozens of classes in an element. Letting go of this "prejudice" and testing Phlex was important here. But the decisive factor was following the creator of Phlex, Joel Drapper, on social media and realizing how motivated he is.

Component Library

As we do not like to reinvent the wheel here at Linkana, we decided to look for component libraries that we could use and evaluated:

We ended up choosing Phlex UI, not because we believe it is ready, but because we believe the path it has chosen is the most suitable for the premise of reusable and easily customizable components. It is a library clearly inspired by Shadcn and brought some Shadcn innovations to the Rails world.

Encouraging you to customize components by copying them into your codebase.
A component structure very similar to React:

Shadcn

<Accordion type="single" collapsible className="w-full">
  <AccordionItem value="item-1">
    <AccordionTrigger>Is it accessible?</AccordionTrigger>
    <AccordionContent>
      Yes. It adheres to the WAI-ARIA design pattern.
    </AccordionContent>
  </AccordionItem>
</Accordion>

PhlexUI

render PhlexUI::Accordion.new do
  render PhlexUI::Accordion::Item.new do
    render PhlexUI::Accordion::Trigger.new do
      p { "What is PhlexUI?" }
    end

    render PhlexUI::Accordion::Content.new do
      p { "PhlexUI is a UI component library for Ruby devs who want to build better, faster." }
    end
  end
end

All CSS is written with Tailwind inside the component itself. It is very easy to make small adjustments/changes.
The components are made up of several very simple Ruby classes. It is very easy to understand code.

Integration with Stimulus through specific controllers for each component.

Putting it into Production

The first step to start the migration to SSR with Phlex and Hotwire was to map the PhlexUI components and place them in Lookbook within our application with our brand colors.

The second step was to create a Rails version of all navigation elements. Sidebar, tabs, etc.

This way, we managed to rewrite route by route using SSR while the React (SPA) routes continued to function. For example:

Everything that is part of the Dashboard is already using SSR. Navigating between the "Summary" and "Lead time" tabs is a navigation that uses Hotwire's Turbo.

When the user clicks on the pending tab, we disable Turbo, and an HTML request is made to the backend that loads our SPA in React and displays the page. Thus, the application switches to SPA mode, and the requests return to being via our GraphQL API with JSON exchange.

If the user clicks on a link that is already in Hotwire, we make React perform an HTML request, and the application returns to being an SSR.

The transition from SPA to SSR is practically imperceptible, but from SSR to SPA is a bit slower, without hindering the user experience. Our idea is to complete this transition by the next edition of Tropical.rb.

Since June 11th, we have been running Phlex in production, and as a form of gratitude, Linkana has become one of the sponsors of the project. We have also started contributing to the PhlexUI project.

If you are also working with components in Rails, leave a comment about what you have been doing.

Do React ao Hotwire - Parte II - [PT-BR]

Cirdes Henrique — Sun, 16 Jun 2024 15:44:26 +0000

English version available

Introdução

No primeiro artigo sobre essa migração do React para o Hotwire, eu abordei como chegamos à nossa stack atual em React. Nesta Parte II, vou falar sobre o retorno às views do Rails na Linkana.

Evolução do Rails e o SSR

Uma das características mais brilhantes do Rails é sua obsessão pela simplicidade. Como o Rails nasceu dentro do Basecamp, uma empresa que escolheu ter poucos funcionários, faz parte do DNA do Rails buscar maneiras de manter o desenvolvimento web simples. Por isso, o Rails é o Framework de uma pessoa só.

Ter participado da última edição do Rails World e assistido à palestra do DHH me fez perceber que gerar views no backend com Rails já não era mais sinônimo de interfaces lentas, feias e que não se preocupam com UX. Com Hotwire, através do Turbo e do Stimulus, era possível criar aplicações tão complexas como o Gmail, Hey ou Slack, Campfire. E isso ficou ainda mais surreal com o Turbo 8.

Mas o grande benefício do retorno ao Server Side Rendering (SSR) é não precisar de APIs. Criar uma API, seja ela REST ou GraphQL, torna o desenvolvimento mais lento. E não é apenas o Rails que está percebendo isso, é o Elixir com o Liveview, PHP com o Livewire, e até mesmo o próprio JS com HTMX, além do próprio React. Como diz o Deno.js: O Futuro (e o Passado) da Web é a Renderização do Lado do Servidor.

Componentes vieram para ficar

Como vimos na Parte I desse artigo, views em React/Vue/Angular introduziram o conceito de componentes. Esses componentes são pequenos blocos de interface que condensam "Estilo (Tailwind)", "Estrutura (HTML)" e "Comportamento/JavaScript". Componentizar, além de promover o reuso e facilitar os testes, também facilita a customização. Mas o mais importante, eles já estão prontos. Você não precisa reinventar a roda. Um grande exemplo é o Shadcn, lançado apenas em março de 2023 e que já conta com 60k estrelas no Github.

Infelizmente, as views do Rails foram criadas no contexto pré-componentes. O html.erb é muito bom para se escrever HTML, mas não é bom para escrever comportamento. Já os partials são ótimos para se escrever comportamento, mas são péssimos para HTML.

Para tentar resolver isso, a primeira solução que surgiu foi o ViewComponents, um framework criado pelo pessoal do Github. O ViewComponents é o nosso React, permitindo que o frontend seja pensado na forma de componentes. Ele é a solução mais popular hoje. Apesar de eu nunca ter usado, sinto que faltou ousadia. Ele me parece uma fusão dos partials com o erb. Mas o que mais me decepcionou foi que o Gihub está migrando do Rails para o React e os próprios mantenedores do ViewComponents não me parecem muito empolgados.

Como alternativa ao ViewComponents, encontrei o Phlex. Ele vem com a ousadia de criar componentes utilizando somente código Ruby. Esse é o tipo de ousadia que assusta. Eu me assustei quando vi pela primeira vez o React colocar HTML, JS e CSS (StyledComponents) dentro de um componente. Eu me assustei ao ver o Tailwind criar classes para cada propriedade do CSS e termos HTML criados com dezenas de classes em um elemento. Abrir mão desse "preconceito" e testar o Phlex foi importante aqui. Mas o fator decisivo foi acompanhar o criador do Phlex, o Joel Drapper, nas redes sociais e perceber o quão motivado ele está.

Biblioteca de componentes

Como não gostamos de reinventar a roda aqui na Linkana, resolvemos buscar bibliotecas de componentes que pudéssemos usar e chegamos a avaliar:

Acabamos escolhendo a Phlex UI não por acreditar que ela está pronta, mas por acreditar que o caminho que ela escolheu é o mais adequado à premissa de componentes reutilizáveis e de fácil customização. Ela é uma biblioteca que foi claramente inspirada na Shadcn e trouxe para o mundo Rails algumas inovações do Shadcn.

Incentivar que você customize os componentes copiando-os para a sua codebase.
Uma estrutura de componentes muito parecida com o React:

Shadcn

Accordion type="single" collapsible className="w-full">
  <AccordionItem value="item-1">
    <AccordionTrigger>Is it accessible?</AccordionTrigger>
    <AccordionContent>
      Yes. It adheres to the WAI-ARIA design pattern.
    </AccordionContent>
  </AccordionItem>
</Accordion>

PhlexUI

render PhlexUI::Accordion.new do
  render PhlexUI::Accordion::Item.new do
    render PhlexUI::Accordion::Trigger.new do
      p{ "What is PhlexUI?" }
    end

    render PhlexUI::Accordion::Content.new do
      p { "PhlexUI is a UI component library for Ruby devs who want to build better, faster." }
    end
  end
end

Todo o CSS é escrito com Tailwind dentro do próprio componente. É muito fácil fazer pequenos ajustes/mudanças.
Os componentes são formados por várias classes Ruby muito simples. É um código muito fácil de entender.

Integração com Stimulus através de controllers específicos de cada componente.

Colocando em produção - SSR + SPA

O primeiro passo para começar a migração para SSR com Phlex e Hotwire foi mapear os componentes do PhlexUI e colocá-los no Lookbook dentro da nossa aplicação com as cores da nossa marca.

O segundo passo foi criar uma versão em Rails de todos os elementos de navegação. Sidebar, tabs, etc.

Dessa forma, conseguimos ir reescrevendo rota por rota usando SSR ao mesmo tempo que as rotas em React (SPA) continuam funcionando. Por exemplo:

Tudo que faz parte do Dashboard já está utilizando SSR. Navegar entre as abas "Resumo" e "Lead time" é uma navegação que utiliza o Turbo do Hotwire.

Quando o usuário clica na aba de pendências, desabilitamos o Turbo e é feita uma requisição de HTML ao backend que carrega nossa SPA em React e a página é exibida. Com isso, a aplicação muda para o modo SPA e as requisições voltam a ser via nossa API GraphQL com troca de JSON.

Se o usuário clicar num link que já está em Hotwire, fazemos com que o React realize uma requisição de HTML e a aplicação volte a ser uma SSR.

A transição do SPA para o SSR é praticamente imperceptível, mas do SSR para o SPA é um pouco mais demorada, sem atrapalhar a experiência do usuário. Nossa ideia é finalizar essa transição até a próxima edição do Tropical.rb.

Desde o dia 11 de junho, estamos rodando o Phlex em produção e, como forma de agradecimento, a Linkana passou a ser um dos sponsors do projeto. Também já começamos a contribuir com o projeto do PhlexUI.

Se você também está trabalhando com componentes em Rails, deixe nos comentários o que você tem feito.

From React to Hotwire - Part I - [EN]

Cirdes Henrique — Sun, 16 Jun 2024 12:31:21 +0000

Versão em Português do Brasil

Part II

In the latest edition of Tropical.rb, I announced that Linkana would be transitioning from React to Hotwire. This transition has already begun, and I want to share with you the challenges we are encountering. Before starting, I would like to look back on my experience with the frontend of my applications over the past few years.

Past - Server Side Rendering (SSR) - 2011/2017

At my first company, Eventick, we used only Rails views to create our frontend. The big challenge was creating layouts in a world where Flexbox or Grid did not exist. We relied on floats, absolute/relative positioning, and tables. JavaScript was limited to jQuery; trying to use pure JS was madness, as each browser behaved differently.

During this time, JavaScript began to be taken seriously. Internet Explorer was losing market share, and the first "modern" frameworks/libs began to emerge. I started using AngularJS 1.0, still integrated with Rails views. Angular's role was to create more interactive interfaces without needing to write many lines of JS or jQuery just to hide or show an element. The JavaScript ecosystem was gaining strength, while in Rails, it was very difficult to use NPM packages. The mindset was to use gems to add JS and CSS files, but the libs would get updates while their gems would not. This was when Rails fell behind in the frontend.

Shortly after, React appeared and started gaining attention, especially with the appeal of the Virtual DOM. It was a library that promised performance while being lightweight. At that time, Google decided to change the entire architecture of Angular with Angular V2, making V1 incompatible with the framework's future. Seeing Angular in crisis and React emerging, I started experimenting with React. Around this time, Eventick was sold to Sympla, and I knew my next project needed to be a SPA with React. It was inconceivable to start a startup in 2018 using the Rails approach.

Present - SPA - 2017/2024

At Linkana, we opted for GraphQL after reading an article from Airbnb mentioning that they were advancing 10 times faster with GraphQL and Apollo. But also due to my frustration with Redux, which always seemed like a complex and bureaucratic solution to me. Looking back, I believe it was the right decision. With Apollo and GraphQL, we could develop APIs in less time and avoid the complexity of managing state with Redux, Reflux, etc. However, the main drawback of GraphQL is that it makes the N+1 problem quite complex, something we still face today. Additionally, it complicates implementing cache in requests, though fortunately, this is not a problem we need to tackle at Linkana.

React also proved to be a good bet due to the large number of available libraries. On the other hand, being a library and not a framework, React code tends to become messy. It lacks the conventions of Rails. This is something we face at Linkana, but I don't consider it one of the most serious problems. We always try to organize our components using Atomic Design and a folder structure that we believe makes sense.

Another important bet at the beginning of Linkana was Grommet, a UI framework that offers React components for creating interfaces. Some may think it was a wrong bet since we eventually moved away from it and Grommet never took off, but that was not the case. At the time, we believed that "creating our own Design System" was a vanity common in many companies, large and small. This mentality, I believe, was a legacy of Twitter Bootstrap. Although Bootstrap was the first UI library to become popular, its strength was never customization. As a result, many sites ended up looking similar. Grommet, besides being a ready-to-use UI framework, was the only one available in 2017/2018 with a Figma file. More popular options like MUI and Ant Design did not offer this feature. Having the Figma file meant that design projects would be done within Grommet's sandbox, avoiding unnecessary customizations.

This architecture served Linkana well for a few years until we realized that Grommet, which initially made our work easier, was becoming an obstacle when we needed to make simple customizations. Additionally, it distanced us from CSS; we were learning Grommet, but not CSS. It was then that we set out to find Stack V2.

Stack V2 with Shadcn and Tailwind

Linkana's Stack V2 needed to maintain or increase our productivity while allowing us to make the minimal modifications we still desired.

The first bet I made was on Tailwind. Tailwind is known for "looks ugly and feels good." At first, many people may feel repulsed by looking at Tailwind classes in an HTML tag, but after a few hours of use, you realize how convenient it is not to worry about separate .css files anymore. Everything is available through classes. To understand this, I had to work on a side project.

Soon after, I discovered a new concept called "unstyled-ui," which are JS libraries that implement all the behavior of library components, leaving the CSS to be applied by you. Good examples are: Radix-ui, Headless-ui, and Tanstack.

The idea of having components without UI like Radix allows it to be added to any project. It is no longer necessary to "fight" to remove the component's style and make it fit your project. Or reinvent the wheel and build the component from scratch. When I saw this, the direction made a lot of sense to me.

But the real find was Shadcn. Shadcn is a library that brings together all these concepts. It uses Radix as a base, incorporates Tailwind to add style to Radix, and has a Figma file. Additionally, Shadcn innovated in one more aspect: instead of being an npm/lib package, it is just a set of reusable code that you can copy and paste into your project. As it says:

This is NOT a component library. It's a collection of reusable components that you can copy and paste into your apps.

Although this might seem strange, I have seen this model being increasingly applied in other projects, as it allows you to use components while giving you a customization possibility like never before. It combines the practicality of Bootstrap with the customization of a bespoke "Design System." Additionally, it includes an AI for generating graphical interfaces.

Bringing all this together, we have Linkana's React SPA frontend.

I will talk about Hotwire in part II of this article.

Do React ao Hotwire - Parte I - [PT-BR]

Cirdes Henrique — Sun, 16 Jun 2024 12:19:29 +0000

English version available

Parte II

Na última edição do Tropical.rb, anunciei que a Linkana iria iniciar a transição do React para o Hotwire. Essa transição já começou e quero contar para vocês quais desafios estamos encontrando. Antes de começar, gostaria de fazer uma retrospectiva de como tem sido minha experiência no Frontend das minhas aplicações nos últimos anos.

Passado - Server Side Rendering (SSR) - 2011/2017

Na minha primeira empresa, Eventick, usávamos apenas as views do Rails para criar nosso Frontend. O grande desafio era elaborar layouts em um mundo onde Flexbox ou Grid não existiam. Dependíamos de floats, posicionamento absoluto/relativo e tabelas. O JavaScript se resumia ao jQuery; tentar usar JS puro era uma loucura, já que cada navegador se comportava de maneira diferente.

Nessa época, o JavaScript começou a ser levado a sério. O Internet Explorer estava perdendo mercado e os primeiros frameworks/libs "modernos" começaram a surgir. Comecei a utilizar o AngularJS 1.0, ainda integrado com as views do Rails. O papel do Angular era criar interfaces mais interativas, sem que fosse necessário escrever várias linhas de código em JS ou jQuery apenas para ocultar ou exibir um elemento. O universo JavaScript estava ganhando força, enquanto no Rails era muito difícil usar os pacotes do NPM. O mindset era utilizar gems para adicionar arquivos JS e CSS, mas as libs recebiam atualizações mas as suas gems não. Foi o momento em que o Rails ficou para trás no Frontend.

Pouco tempo depois, o React apareceu e começou a chamar atenção, principalmente com o apelo do DOM Virtual. Era uma lib que prometia desempenho ao mesmo tempo que era leve. Nesse momento, o Google decidiu mudar toda a arquitetura do Angular com o Angular V2, tornando o V1 incompatível com o futuro do Framework. Vendo o Angular em crise e o React emergir, comecei a brincar com o React. Foi mais ou menos nessa época que a Eventick foi vendida para a Sympla e eu sabia que meu próximo projeto precisaria ser um SPA com React. Era inconcebível iniciar uma startup em 2018 utilizando o caminho do Rails.

Presente - SPA - 2017/2024

Na Linkana, optamos pelo GraphQL depois de ler um artigo do Airbnb mencionando que estavam avançando 10 vezes mais rápido com o GraphQL e o Apollo. Mas também devido à minha frustração com o Redux, que sempre me pareceu uma solução complexa e burocrática. Olhando para trás, acredito que foi uma decisão acertada. Com o Apollo e o GraphQL, conseguimos desenvolver APIs em menos tempo e nos livramos da complexidade de lidar com o estado usando Redux, Reflux, etc. No entanto, o principal ponto negativo do GraphQL é que ele torna o problema de N+1 bastante complexo, algo que ainda enfrentamos hoje. Além de dificultar a implementação de cache nas requisições, felizmente não é um problema que precisamos enfrentar na Linkana.

O React também se mostrou uma aposta acertada, devido à grande quantidade de bibliotecas disponíveis. Por outro lado, por ser uma biblioteca e não um framework, o código React geralmente tende a se tornar bagunçado. Falta a convenção do Rails. Isso é algo que enfrentamos na Linkana, mas não considero ser um dos problemas mais graves. Sempre tentamos organizar nossos componentes utilizando o Atomic Design e uma estrutura de pastas que acreditamos fazer sentido.

Outra aposta importante no início da Linkana foi o Grommet, um framework UI que oferece componentes React para criação de interfaces. Alguns podem pensar que foi uma aposta errada, já que eventualmente migramos dele e o Grommet nunca decolou, mas não foi o caso. Na época, tínhamos em mente que a "criação do nosso Design System" era uma vaidade comum em muitas empresas, grandes e pequenas. Essa mentalidade, acredito, foi um legado do Twitter Bootstrap. Embora o Bootstrap tenha sido a primeira biblioteca de UI a se popularizar, seu ponto forte nunca foi a personalização. Como resultado, muitos sites acabaram com uma aparência semelhante. O Grommet, além de ser um framework UI pronto, foi o único disponível em 2017/2018 que tinha o arquivo do Figma disponível. Outras opções mais populares, como MUI e Ant Design, não ofereciam esse recurso. Ter o arquivo do Figma significava que os projetos de design seriam realizados dentro do Sandbox do Grommet, evitando a necessidade de personalizações desnecessárias.

Essa arquitetura serviu bem à Linkana por alguns anos, até percebermos que o Grommet, que inicialmente facilitava nosso trabalho, estava se tornando um obstáculo quando precisávamos fazer customizações simples. Além disso, ele nos afastava do CSS; estávamos aprendendo Grommet, mas não CSS. Foi então que partimos em busca da Stack V2.

Stack V2 com Shadcn e Tailwind

A Stack V2 da Linkana precisava manter ou aumentar nossa produtividade, ao mesmo tempo que nos permitisse fazer as modificações mínimas que ainda desejávamos.

A primeira aposta que fiz foi no Tailwind. O Tailwind é conhecido por "looks ugly and feels good". A princípio, muitas pessoas podem sentir repulsa ao olhar as classes do Tailwind em uma tag HTML, mas depois de algumas horas de uso, percebe-se o quão conveniente é não precisar mais se preocupar com arquivos .css separados. Tudo está disponível através de classes. Para compreender isso, tive que trabalhar em um projeto paralelo.

Logo depois, descobri um conceito novo chamado "unstyled-ui", que são bibliotecas JS que implementam todo o comportamento dos componentes de uma biblioteca, deixando o CSS para ser aplicado por você. Bons exemplos são: Radix-ui, Headless-ui e Tanstack.

A ideia de ter componentes sem UI como o Radix permite que ele seja adicionado a qualquer projeto. Não é mais necessário "lutar" para remover o estilo do componente e fazê-lo se adequar ao seu projeto. Ou ter que reinventar a roda e fazer o componente do zero. Quando vi isso, essa direção fez muito sentido para mim.

Mas o grande achado mesmo foi o Shadcn. O Shadcn é uma biblioteca que reúne todos esses conceitos. Ele usa o Radix como base, incorpora o Tailwind para adicionar estilo ao Radix e possui um arquivo do Figma. Além disso, o Shadcn inovou em mais um aspecto: em vez de ser um pacote npm/lib, ele é apenas um conjunto de código reutilizável que você pode copiar e colar em seu projeto. Como ele mesmo diz:

Isto NÃO é uma biblioteca de componentes. É uma coleção de componentes reutilizáveis que você pode copiar e colar nos seus aplicativos

Embora isso possa parecer estranho, tenho visto esse modelo sendo aplicado cada vez mais em outros projetos, pois ele permite que você utilize componentes, mas ao mesmo tempo te dá uma possibilidade de personalização como nunca antes foi possível. Ele junta a praticidade de um Bootstrap com a customização de um "Design System" próprio. Além disso ele conta uma IA para gerar interfaces gráficas.

Ao juntar tudo isso, temos o Frontend SPA com React da Linkana.

Falarei sobre o Hotwire na parte II desse artigo.