Category: Ruby & Rails

How I run puma-dev alongside Rails’ bin/dev

Posted on by Robert Starsi

The bin/dev script Ruby on Rails ships with, if you for example init the app with --css=tailwind or --css=bootstrap is great. It comes with auto-generated Procfile that will launch the web server and the Tailwind CSS (or other) preprocessors. In addition bin/dev will install the foreman gem if it does not exist on your system.

At some point however, you’ll want to run multiple Rails applications on your developer machine. Doing that with localhost:3000 will get annoying at some point (cookie sharing, changing ports, everyone in the team handling it differently, no HTTPS to test with…).

puma-dev has been around for a long time to solve this. However while it takes care of running the web server part for you (in the background), you still want to see the logs, run your CSS (or JS) preprocessor or compiler, job workers, etc. I figured out it’s simply about adjusting the Procfile and bin/dev slightly and one can use the familiar approach in conjunction with all the puma-dev features.

This is what I do:

My Procfile.dev looks like this:

web: tail -f log/development.log
css: bin/rails tailwindcss:watch

The change is in the web: stanza. Instead of launching puma server, we simply tail the logs, as puma will be run by puma-dev in the background for you, as soon as you visit your local .test domain.

My bin/dev looks like this:

#!/usr/bin/env bash

if ! command -v foreman &> /dev/null
then
  echo "Installing foreman..."
  gem install foreman
fi

if ! command -v puma-dev &> /dev/null
then
  echo "Installing puma-dev..."
  brew install puma/puma/puma-dev
  echo ""
  echo "To finish puma-dev setup run:"
  echo "sudo puma-dev -setup"
  echo "puma-dev -install"
  echo "puma-dev link -n myapp ."
  echo ""
fi

foreman start -f Procfile.dev

I’ve added a section that installs puma-dev (if your team is using Homebrew) and prints out instructions on how to complete the setup.

For your use case, simple replace “myapp” above with the name of your app.

This feels like sticking to the Rails way and is easily extensible if you also want to launch other services in development, like job workers, by simply adding a stanza in the Procfile.dev. Neat.

Scaffolding in Rails 7 is amazing

Posted on by Robert Starsi

I’m continuously being impressed by the productivity and ease of use enhancements Rails keeps making after all these years it has been around.

Today I discovered that scaffolds generated in brand new --css=tailwind enabled Rails 7 codebase, is generating basic, beautiful Tailwind markup out of the box.

rails g scaffold_controller User username:string

Produces:

Index of a freshly generated model.
Edit view. Notice the Tailwind markup.

Further I have this in my config/application.rb to prevent generating files that I don’t use for every single resource until they are needed:

config.generators do |g|
  g.assets false
  g.helper false
  g.jbuilder false
end

That’s a damn good job Rails community. ❤️

Easily switch or experiment with different databases in Rails

Posted on by Robert Starsi

I just learned about rake db:system:change task that Rails provides, to speed up switching between different database engines. If you’re experimenting with something, or benchmarking things, this is super useful.

I had a simple PostgreSQL app and running rake db:system:change --to=sqlite3 and afterwards rake db:setup got me going with my task in seconds.

Small detail I noticed, rake -T which should list all available tasks, does not show anything about db:system for some reason.

Starting new Rails applications

Posted on by Robert Starsi

It’s been a while since I reviewed the documentation for rails new console command. There are a few useful features that I didn’t know about:

Most of the times, for database engine, PostgreSQL is my choice. This is easily accomplished with the -d switch, but even more convenient is adding this as a preset to your environment, using the .railsrc dotfile. Configuring such on your system will allow you to just stick to rails new appname without having to add switches.

The second useful thing I didn’t know exists is the Rails Application Templates which makes it faster to start new Rails applications with the same set of gems and configuration that you might be reusing across your apps.

Speeding up office work with Ruby and IRB

Posted on by Robert Starsi

I was just paying taxes 😅. One of the steps involved was copying and pasting a few long reference numbers from a PDF into my banking app. The thing is, when copied, the reference number would contain extra spaces, after each character, making it invalid where I needed to paste it.

Now there are myriad of different solutions for this I’m sure, but as a programmer, let’s take a look at how to speedily create a makeshift tool in Ruby to do this.

irb
space_eater = ->(text) { text.gsub(' ', '') }

We launched into the interactive shell, and defined a lambda we can call on strings we want to sanitize. Like so:

space_eater.call('2 3 9 2 9 9 A 8 2 8 0 0 0 1')
=> "239299A8280001"

And we’re done. ❤️ Ruby.

Don’t forget about X-Forwarded-Host header

Posted on by Robert Starsi

Recently I was working on a Rails application on Heroku living behind a reverse proxy. This application serves requests coming to a specific folder on the target domain. For it to correctly generate full URLs, you have to somehow tell this app the hostname you want it to use. In Rails, you can configure a hostname in the environment config file, but that’s a static value, which has to be maintained and changed per environment. Also it does not work well if you want to access the application from multiple domains.

It’s much better to be able to set something up on the proxy itself. For this reason the X-Forwarded-Host HTTP header exists. Rails–being a good web citizen–supports it out of the box.

Before I learned about this header, I even implemented my own middleware to deal with this issue and a custom header. I was able to dump that extra code once I stumbled at this header.

Speeding up bundle install with in-memory file system

Posted on by Robert Starsi

On some of the servers I work with, due to cheap hard drives in software RAID configuration, I’ve found that bundle install can be extremely slow (take half an hour to complete). This obviously became unacceptable during deploys.

I thought that it might have something to do with how bundler writes a lot of small files during the installation of the gems. So I decided to try putting the deploy bundle directory (where all the gems are being installed) onto the in-memory filesystem. On Ubuntu this is /dev/shm.

It works flawlessly. The install time improved from half an hour down to a few seconds. After the bundle install is complete however, we do not want to leave the installed gems in the memory, as during restart they would be purged. So we just copy the directory back to the disk. Strangely enough, copying the whole directory from /dev/shm does not trash the disk so much and it only takes up to a minute for a few hundred MB of gems.

It’s cool to be able to find and utilize such a useful and simple part of Linux to solve and work around a slow hardware problem, while for everything else the server does, it’s still perfectly usable and more than capable of performing it.

Here’s my Capistrano 3 lib I use in my deploys that integrates this speedup:

namespace :bundler_speedup do
  task :symlink_to_shm do
    on roles(:all) do
      bundle_shm_path = fetch(:bundle_shm_path)
    
      # Make sure bundle dir exists
      execute "if [ ! -d #{shared_path}/bundle ]; then mkdir #{shared_path}/bundle; fi" 

      # todo: what if #{shared_path}/bundle is a symlink - meaning an interrupted install from previous time?

      cmds = []
      # Copy the bundle dir to /dev/shm/
      cmds << "cp -r #{shared_path}/bundle #{bundle_shm_path}"
      # Remove the shared bundle dir and symlink the shm dir instead
      cmds << "mv #{shared_path}/bundle #{shared_path}/bundle.old"
      cmds << "ln -s #{bundle_shm_path} #{shared_path}/bundle"
      # We're ready to do a fast in-memory bundle install now...
      execute cmds.join(' && ')
      
      info "shared/bundle was copied to /dev/shm for in-memory bundle install"
    end
  end

  task :remove_from_shm do
    on roles(:all) do
      bundle_shm_path = fetch(:bundle_shm_path)
      cmds = []
      # Copy the shm bundle to shared
      cmds << "cp -r #{bundle_shm_path} #{shared_path}/bundle.new"
      # Remove the symlink and move in the dir on disk
      cmds << "rm #{shared_path}/bundle"
      cmds << "mv #{shared_path}/bundle.new #{shared_path}/bundle"
      # Remove the in memory bundle
      cmds << "rm -rf #{bundle_shm_path}"
      cmds << "rm -rf #{shared_path}/bundle.old"
      # Bundle is persisted and in place
      execute cmds.join(' && ')
      
      info "shared/bundle was restored from bundle install within /dev/shm"
    end
  end
  
  before 'bundler:install', 'bundler_speedup:symlink_to_shm'
  after 'bundler:install', 'bundler_speedup:remove_from_shm'
end

namespace :load do
  task :defaults do
    set :bundle_shm_path, -> { "/dev/shm/#{fetch(:application).gsub(' ', '_').downcase}_bundle" }
  end
end

In a Rails project, place it in lib/capistrano/tasks/bundler_speedup.rake. Capistrano should auto-load this for you.

This code is released under the MIT license.

Effort – Personal To-do and Project manager

Posted on by Robert Starsi

I have open sourced a Rails app that I’ve been personally using for years. The code is available on Github under the MIT license. From the README:

I’ve modeled this app for my own personal use, note keeping and personal project management loosely after Basecamp. The single most important point for me is to have To-do lists that work in a particular way – that’s why I’ve build this for myself.

I am open-sourcing it to see if somebody finds it useful and can maybe build on it. Let’s see what happens.

This is a standard Rails 4 app, build the “Rails way”. Test coverage is minimal, just enough for the purposes of this app at this stage.

effiort todo lists
To-do lists – the most important and the most used part of this project.

EQAFE – Ecommerce

Posted on by Robert Starsi

This is one of the first projects where I started using Rails in production. EQAFE developed—over the years—from a simple checkout page to sell a single book to an ecommerce platform featuring thousands of products, affiliate program, gifts and more.

Deliverables:

  • UI design and implementation.
  • Backend design and implementation (Rails).
  • Automated test suite.
  • ~4 years running in production (DevOps).

Tour

Front page provides an index of the latest products.
Front page provides an index of the latest products.

Product details.
Product details.

A lot of the functionality is neatly tucked away in the always accessible dropdown menus.
A lot of the functionality is neatly tucked away in the always accessible dropdown menus.

Rails stats

eqafe-code-stats
It’s interesting to observe how each project can have quite a different allocation of the amount of code. Here for example, test vise, most of the code is located in controller tests – this tells us a lot about the app itself – a lot of the control flow is located in the controllers, most of the interesting stuff happens there, like for example users are redirected to different locations depending on their starting point and actions.