Desenvolvendo Ruby on Rails no FreeBSD (e por que simplicidade ainda importa)

Quero comentar aqui uma coisa que bastante gente me pergunta: como é desenvolver software usando Ruby on Rails no FreeBSD, mas essa pergunta normalmente vem carregada de várias outras.

• É muito diferente de Linux?
• É complicado?
• Tem alguma limitação?
• Vale a pena?

Tem um link no meu canal do YouTube sobre isso, dá uma olhada lá, tem a parte prática! Aproveita e se inscreve, tem bastante vídeos legais por lá.

E eu acho curioso porque muita gente imagina o FreeBSD quase como um ambiente exótico. Como se desenvolver nele exigisse algum ritual obscuro, alguma espécie de feiticaria, mas a realidade é bem menos dramática.

Na prática, desenvolver software no FreeBSD é muito parecido com desenvolver em qualquer sistema Unix-like e talvez justamente aí esteja a parte mais interessante. Se você desenvolve em Rails e quer testar o FreeBSD, continua lendo que tem uma dica importante dependendo da sua stack!

Meu ambiente

Meu setup hoje é extremamente simples.

Eu uso:

• Kitty como terminal. Sim, já usei o Ghostty, o Alacritty, mas voltei para o Kitty.
• tmux para organizar sessões
• Neovim como editor
• Chromium como navegador, no FreeBSD. Nos outros OSs uso o Brave. Dá para instalar o Brave no FreeBSD também, através do linux-browser-installer. Mas descarrega coisa pra caraca, etc e tal.
• Hyprland como ambiente gráfico. Também dou uma chaveada com o Sway.

Nada muito extravagante.

Na verdade, se você me der um terminal, um editor de texto e um navegador, eu consigo trabalhar praticamente de qualquer lugar, e isso é intencional, ao longo do tempo fui simplificando cada vez mais meu ambiente de trabalho. Não é para contar vantagem de alguma forma, mas para ter:

• Menos distração.
• Menos fricção.
• Menos dependências.
• Mais foco.

Dica para o Tailwind no FreeBSD

E agora vai uma dica específica para o FreeBSD: o Tailwind não é suportado direto pela gem! Mas com alguns pequenos ajustes a coisa funciona legal. Temos que fazer uma instalação local do Tailwind nele. Para isso, vamos usar o pacote nativo:

$ doas pkg install tailwindcss4
$ which tailwind
/usr/local/bin/tailwind

E no projeto do Rails, editar o bin/dev e acrescentar:

if [ "$(uname -s)" = "FreeBSD" ]; then
  export TAILWINDCSS_INSTALL_DIR=/usr/local/bin
  export NODE_PATH=/usr/local/lib/node_modules
fi

Detalhe que ali por estar usando o sh, podemos utilizar o = que não vai ser sinal de atribuição, mas de comparação.

Feito isso, o bin/dev roda normal, carregando o Tailwind de boa.

Workflow normal

Então não tem mistério:

• Ruby funciona.
• Rails funciona.
• PostgreSQL funciona.
• Git funciona.

Tudo como você esperaria em qualquer outro sistema operacional, e isso talvez surpreenda algumas pessoas, porque muita gente imagina que desenvolver no FreeBSD é radicalmente diferente, mas não é.

Tmux, dotfiles e portabilidade

Uma parte importante desse workflow é a consistência entre ambientes. Eu uso Linux no trabalho e uso FreeBSD em casa.

Mas meu ambiente continua muito parecido. Boa parte disso acontece porque eu mantenho meus dotfiles organizados e compartilhados. Inclusive, já falei em outro vídeo sobre GNU Stow como gerencio essas configurações.

Mesmo quando estou no Ubuntu usando o Gnome, configurei os meus atalhos de tecla para os mesmos. Isso reduz muito a carga cognitiva, eu não preciso reaprender meu ambiente toda vez que mudo de máquina ou sistema operacional.

Talvez por isso não gostei muito do Omarchy. ;-)

Mas por que FreeBSD?

Essa é a pergunta que mais fazem: se eu uso Linux no trabalho, por que usar
FreeBSD em casa?

E a resposta sincera talvez decepcione quem espera uma explicação extremamente técnica. Eu não uso FreeBSD porque ele vai me dar performance milagrosa. Nem porque ele vai rodar Rails magicamente mais rápido.

Eu uso porque eu gosto dele.

Gosto da coesão do sistema, da organização, da previsibilidade.

No Linux, quando você manja um pouco mais do sistema operacional, muitas vezes
você sente que está usando uma composição de várias camadas, deixando claro que funcionam sempre muito bem:

• Kernel.
• GNU tools.
• Systemd.
• Ferramentas da distribuição.

No FreeBSD, a sensação é diferente, tudo parece parte de um sistema único, mais coeso, mais integrado. Isso é difícil explicar até você usar por algum tempo. Mas quem já experimentou costuma entender rápido.

Também existe uma certa dose de saudosismo da minha parte, eu sempre gostei da filosofia Unix, inclusive, isso conecta bastante com meu vídeo sobre a história do Unix.

Mas o ponto nem é só o FreeBSD

O ponto também é simplicidade.

Hoje em dia parece que desenvolver software exige cada vez mais ferramentas.

• Mais abstrações.
• Mais plugins.
• Mais camadas.
• Mais complexidade.

E claro, algumas dessas ferramentas realmente ajudam, mas ao longo dos anos eu percebi uma coisa.

• Algumas ferramentas vêm e vão.
• Modas aparecem e desaparecem.

Mas bons fundamentos sempre continuam.

Sobre editores e memória muscular

Isso vale especialmente para editores, eu uso Vim e Neovim há bastante tempo e não é porque terminal é cool, não é por purismo, é, acreditem, por produtividade!

Esses dias precisei usar VSCode para gravar algumas aulas e minha produtividade caiu drasticamente! Mais de 50%, fácil, fácil.

Mas não porque VSCode seja ruim, longe disso. Mas porque eu saí do ambiente onde construí anos de memória muscular.

No Vim e Neovim, muita coisa virou reflexo:

• Navegar.
• Editar.
• Buscar.
• Refatorar.
• Mover blocos.
• Executar comandos.

Tudo acontece quase sem pensar, é como uma extensão da mão e isso tem um valor enorme.

Uma coisa curiosa no mundo dos editores é como as modas mudam, teve uma época em que todo mundo falava de TextMate, depois veio Sublime Text, depois Atom.

Inclusive, na era inicial do Ruby on Rails, TextMate era quase o editor oficial não-oficial da comunidade Rails. Muita screencast famosa usava ele. Era quase ser herege se você não usasse o dito cujo.

Hoje temos VSCode, Cursor e vários editores com foco em IA e provavelmente daqui a alguns anos o cenário já vai ser diferente de novo.

Enquanto isso, os Vims continuam por aí! Décadas! Isso é muito simbólico. Não porque sejam “melhores para todo mundo”. Mas porque foram construídos em cima de conceitos extremamente duráveis:

• edição modal
• keyboard-first
• composabilidade
• automação
• extensibilidade

Esses conceitos continuam úteis independentemente da moda e eu tento investir meu tempo em ferramentas que sobrevivem às modas.

Se a gente olhar a timeline:

• Vim (1991 → hoje)
• Emacs (1980s → hoje)
• TextMate (boom → nicho)
• Sublime (boom → nicho)
• Atom (boom → morreu)
• VSCode (boom atual)
• Cursor / AI editors (boom emergente)

Engraçado que a frase do Atom era "A hackable text editor for the 21st Century", mas parece que o século acabou rapidinho para ele, já que o Github descontinuou o pobre coitado em Dezembro de 2022.

Independência do ambiente gráfico

Outra coisa que gosto nesse tipo de workflow é a independência. Boa parte do meu trabalho nem depende de ambiente gráfico.

Se o ambiente gráfico falhar, ee eu estiver conectado remotamente, se eu estiver em SSH ... quase tudo continua funcionando.

• Shell.
• Git.
• Ruby.
• Rails.
• tmux.
• Editor.

Tudo continua disponível. O navegador talvez seja a única dependência real para validação visual e olha que dá até para usar uns navegadores em modo texto, como o Lynx. E essa portabilidade é extremamente poderosa.

Limitações

Claro, nem tudo são flores, o FreeBSD ainda tem limitações. Suporte a hardware pode ser complicado dependendo da máquina. GPU ainda não é o ponto forte. Wi-Fi em alguns chipsets também pode ser chato. Tive problemas aqui com a minha placa de rede, tive que encontrar uma compatível e trocar.

E sim, em uma era onde muita coisa em inteligência artificial depende fortemente de GPU, isso pode ser uma limitação real, mas esse não é meu caso de uso.

Conclusão

No fim das contas, eu acho que a principal mensagem nem é sobre FreeBSD.

É sobre simplicidade.

Desenvolver software não precisa ser tão complicado quanto às vezes parece. Você não precisa necessariamente de um ambiente gigantesco cheio de camadas e ferramentas.

Muitas vezes, tudo o que você realmente precisa é:

• Um bom terminal.
• Um editor que você domina profundamente.
• E um navegador.
• Só.

O sistema operacional quase vira um detalhe. No meu caso, eu escolhi o FreeBSD porque gosto dele. Mas a parte mais importante é outra, é encontrar ferramentas simples, confiáveis e estáveis e dominá-las profundamente.

Porque no fim, ferramentas vêm e vão, modas passam, mas simplicidade, domínio e bons fundamentos continuam valendo.

Me conta aí nos comentários, você já conseguiu transitar entre vários sistemas operacionais de boa?

Se increve lá no meu canal do YouTube! :-) Sempre estou publicando várias coisas sobre desenvolvimento de software por lá.