Find the bug, Rails edition


I have this code in a model in a Rails project.

  validates :name, presence: true, on: :create
  validates :email, presence: true, format: { with: URI::MailTo::EMAIL_REGEXP }, on: create

Let's put it in an Author model:

class Author 

When retrieving a list of all of the authors without email addresses (because, well, we are cleaning up these things) with this line of code:

  authors = Author.where(:email: nil)

... two new blank authors are created at the WHERE query. Both of their names and emails are blank. This is absurd!

Find the bug.

Run single Rails test


Run a single Rails test in a test file by including the test file (which will run all the tests) and -n with the test name prefixed by test_ and having underscores for spaces for the specific test name

# for the test titled: test 'submitting review'
rails test test/models/submission_review_test.rb -n test_submitting_review 

Rails console in a non-dev environment


Use rails console for a (debugging) console in the current, default environment, usually development.

Use -e [environment] to load a different local to the shell.

# start a console in the test environment 
rails console -e test

Alias Rails columns


When working with APIs, sometimes the fields from the APIs are reserved keywords (looking at you, Shopify, and your type fields). When saving the data directly, you don't can't have a field in the database named type, but you don't want to manipulate the parameters and models for every query call. That would suck.

Alias the field instead.

class User < Activerecord::Base
  alias_attribute :new_column_name, :real_column_name
# specific use case (metafields at Shopify)
ActiveRecord::Schema.define(version: 2022_07_04_191939) do
  create_table "metafields", force: :cascade do |t|
    t.string "namespace"
    t.string "key"
    t.string "value"
    t.string "value_type"
    t.string "variant_type"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
# aliased
class Metafield < ApplicationRecord
  # the Shopify object has 'type' but 'type' is a DB reserved word
  alias_attribute :type, :variant_type

Install different gems in Docker container


I have a development environment that is used locally within docker containers, and deployed to a Heroku-like environment, which has a different setup than the local Docker setup. When running locally in Docker containers, I want to install debase and the ruby-debug-ide gems, so that I can use RubyMine locally, but these are not needed when deployed to the development instance. The deployment does not use the Docker / docker-compose files, so I'm okay with having them be local-development specific.

The trick I found was to use groups in the Gemfile.

In my Dockerfile, I'd call out the groups with the --with={groups} arguments:

RUN bundler install --with=development,docker

group :docker do
  gem 'debase'
  gem 'ruby-debug-ide'

Rails and Ruby things I keep forgetting

# List all rails migrations and their statuses
bundle exec rake db:migrate:status
# Undo the last migration 
bundle exec rake db:rollback
# Undo the last N migrations
bundle exec rake db:rollback STEP=n
# Run a single migration
bundle exec rake db:migrate:up VERSION=20190606020304
# Rerun a single migration
bundle exec rake db:migrate:redo VERSION=20190606020304
# clear all the gems in a gemset (useful for debugging why a dependency is failing, don't do "bundle clean")
rvm gemset empty `cat .ruby-gemset`
# if you need to pass in extra data in a form to a controller,
# allow in the params, then "except" before creating:
# first time you have a new DB and want to use the defined schema
bundle exec rake db:schema:load

What gems are installed?


Have a Gemfile or a Gemfile.lock and want to see what versions are installed.

gem list

Minitest Cookbook

Book Notes

Okay, so, for the record with this review, The Minitest Cookbook was not the book I needed, nor expected. Take the rest of this review with a grain of salt as a result of that disclaimer.

I've been writing code that is tested with minitest tests for nearly a year now. I find that my understanding of when to use mocks versus stubs versus expects versus pick something else, to be somewhat lacking. Sure, I can cut and paste another test and modify as I need to modify it to fit my particular test case, but I don't want to copy and modify a test. I want to understand the reasoning behind what I'm doing and create a test, to understand "this is what I'm testing and this is how I go about it." Being able to do that quickly requires that I understand the system that I'm working on as a whole perhaps better than I do, but being able to do it without a full understanding is needed at this point.

So, I picked up this book as the recommended minitest book. Lots of favorable reviews, this is the book you want if you're learning minitest.

Except, it isn't.

It's too complicated for beginners (are n00b or newbies still derogatory terms, or have they been embraced by beginners - I guess if beginners are okay with being called dummies, they're okay with being n00bs), and not well organized for an intermediate user. I'd consider myself halfway between those two designations, so figured I'd get it, but, eh, didn't really work out that way.

Agile Web Development in Rails 4

Book Notes

Okay, I read this one again, since the first reading was before I knew what things were and why I was doing things and oh, god, what have I gotten myself into? Helps to have development under your belt for these things.

This book was recommended to me as the book to learn Rails development. It has two main sections: a hands-on let's-build-a-rails-app section, and a here-are-the-explanations section. The first is designed to guide you through building an application with Rails, the second to explain what the hell just happened and how all the parts fit together. The book builds a slight e-commerce platform: a store's product display / catalog, administration section, shopping cart, checkout and user authentication. The example is great, I definitely liked that it wasn't a blog or a twitter client.

The book is good and it works. It is not the book for new developers, however. It uses a lot of words and concepts without explaining them, assuming the reader knows what they mean. And this is okay. The book is for a developer who is learning Rails. It does that well.

Time-wise, if you're going to read the book and do the exercises (say, a new employer is giving you a chance to come up to speed with Rails, or the first couple weeks of work to learn), give yourself 2 work weeks to go through it. You can do it faster (you can always do things faster), but doing the exercises and typing things in and playing around with things relevant-to but not part-of the lessons is what makes learning better. So, yeah, play around, poke around, learn something outside the lesson for greater good.

This would be my Rails Rant of the Day


Okay, I know that using rails is supposed to make one's life easier. I recognize that convention over code rules the rails mindset. I even completely agree that rails devs don't feel pain when they develop applications, with all the various pieces kindly hidden from them. That is great. Good for them / us / me.

But, come on, this?

No, not "come on." More like, "COME THE FUCK ON, WHAT THE FUCKING HELL?"