☢ Thoughts on software development, with an odd jaunt into language learning

Screencast: Using Shell History to Create Aliases

| Comments


  1. Introduction to aliases @ 0:00
  2. Analysing shell history to create relevant aliases @ 4:43

Download: mov 24MB, 8:26 (Recommended)

Watch (recommended in full screen and in HD):


Make an alias:

    alias l="ls -al"
    alias glog="git log"

Add those to your ~/.aliasrc.

Modify ~/.zshrc or ~/.bashrc (works for both):

    if [[ -r ~/.aliasrc ]]; then
      source ~/.aliasrc

View shell history: history

View count of common commands:

    history | awk '{ print $2 }' | sort | uniq -c | sort -n
    history | awk '{ print $2,$3 }' | sort | uniq -c | sort -n

Use that output to create better aliases!

Here’s some of my favourite aliases:

    alias ..='cd ..'
    alias ...='cd ../..'
    alias ....='cd ../../../'
    alias .....='cd ../../../../'
    alias be='bundle exec'
    alias g=git
    alias ga='git add'
    alias gc='git commit -v'
    alias gca='git commit -v -a'
    alias gch='git checkout'
    alias gl='git pull'
    alias gst='git status'
    alias l='ls -al'

Machinist and Association Validations

| Comments

While upgrading to Machinist 2, I had a hell of a time getting blueprints with associations to actually save.

The problem turned out to be that the code was using validates_presence_of :hometown_id, where hometown is the name of the association, and the solution is to use validates_presence_of :hometown, or the newer version: validates :hometown, presence: true.

If you have a given class:

class Viking < ActiveRecord::Base
  belongs_to :hometown

  validates_presence_of :hometown_id

and blueprints:

Viking.blueprint do
  name { "Heiðrek" }

Then calling Viking.make will properly return an unsaved Viking object (with a Hometown object viking.hometown), but valid? will return false.

Calling Viking.make! will throw an exception: ActiveRecord::RecordInvalid: Validation failed: Hometown can't be blank

If you really want to keep using validates_presence_of :hometown_id, you can modify the blueprint like this:

Viking.blueprint do
  name { "Heiðrek" }
  hometown { Hometown.make! }

Then Viking.make! will succeed. Viking.make will also work, and will return an unsaved Viking object, but it will actually create and save the associated Hometown object, which negates part of the point of calling .make instead of .make! (make creates objects but does not save them to the database, giving quite a performance boost for test suites).

The proper solution is to adjust the validation in your model:

class Viking < ActiveRecord::Base
  belongs_to :hometown

  validates :hometown, presence: true
  validates_associated :hometown

The key is that we’ve changed validates_presence_of :hometown_id to validates :hometown, presence: true. The validation actually checks the association itself, not the presence of an id field (which is only ever set once the hometown is saved).

We’ve also added a validates_associated :hometown call, which will check hometown.valid? before saving, and if the hometown fails validation, then the viking object will as well.

See API docs about validations here:

Goðan Daginn!

| Comments

Goðan Daginn, Heimur!

I just set up this new octopress instance in roughly half an hour! Hooray!