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?"

Have ruby irb console save history


Add this to your ~/.irbrc file (creating one if it doesn't already exist):

require 'irb/ext/save-history'
IRB.conf[:SAVE_HISTORY] = 200
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-history"

Boom! Last 200 commands are saved, such that you can up arrow / command-p or down arrow / command-n to move through your ruby console history!


MySQL config for Rails app

  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000
  adapter: sqlite3
  database: db/test.sqlite3
  pool: 5
  timeout: 5000
  adapter: mysql1\2
  encoding: utf8
  database: your_db
  username: your_user
  password: your_pass
  socket: /tmp/mysql.sock
  host: your_db_ip     #defaults to
  port: 3306          
# mongodb
host: <%= ENV['MONGOID_HOST'] %>
port: <%= ENV['MONGOID_PORT'] %>
username: <%= ENV['MONGOID_USERNAME'] %>
password: <%= ENV['MONGOID_PASSWORD'] %>
database: <%= ENV['MONGOID_DATABASE'] %>
# slaves:
#   - host: slave1.local
#     port: 27018
#   - host: slave2.local
#     port: 27019

This was supposed to be easy


So, in interviewing for a job as a front end developer (awwwwwwwww yisssssssssss, automate all the things front end!), I ended up excited about a company that uses Rails (and Ruby) as their application framework. When I was asked, "How would you feel about never writing another line of code in PHP?" I responded, "I'd be okay with it." Languages are ways to communicate, with PHP being just one dialect. If I need to learn how to speak Ruby, *shrug* If the people are awesome, hand me the Ruby book.

Right, the Ruby book.

I'm heading through "Agile Web Development with Rails 4," as it was recommended by the director of engineering at the company. The contents indicate that it's a reasonable introduction to Ruby, which is great. Fortunately for me, I took Chookie's suggestion of problems from Project Euler to play around with languages. I'm currently solving my problems in PHP, JavaScript, Python and Ruby, so that Ruby isn't a blocker on the learning.


Except I have to say, the length of time it took me to get to this screen:

was stupidly too long.

Seriously, this file exists:

bash-3.2$ more /usr/bin/rails 
echo 'Rails is not currently installed on this system. To get the latest version, simply type:'
echo '    $ sudo gem install rails'
echo 'You can then rerun your "rails" command.'

I really want to ask who thought having this was a good idea, when THIS is the correct response on every single flavor of *nix I can think of:

bash-3.2$ rails
bash: rails: command not found

I'm really glad I know what I'm doing on the command line, because the "oh, just run it with sudo before the command" really doesn't cut it. Really.

Hey, how about those PATH variables?


Okay, fine now. All set with the demo app. Hello, localhost:3000 (groan! that port will stay around maybe 2 chapters in, and then it's back to my numbering scheme).