I 💖 Ruby

Make RuboCop Part of Your Tests (Updated)

Mon, 21 Jun 2021 14:14:22 +0000

Note: This is an update to the previous Make RuboCop Part of Your Tests post.

RuboCop is a static code analyzer, and can be a wonderful tool to help you keep your style consistent either across multiple developers, or just across a project that you work on by yourself.

This will show you how you can make it part of your specs, so you don’t forget to run it, and neither does your continuous integration tool (if applicable).

Gemfile

First, add the following to your Gemfile, making sure to not require the Rubocop library by default in Rails:

group :development, :test do
  gem 'rubocop', require: false
end

Minitest

If you are using Minitest, this is where I put my test (put yours where it makes the most sense to you).

In test/linters/rubocop_test.rb:

require 'test_helper'

class RuboCopTest < Minitest::Test
  def subject
    `rubocop --config .rubocop.yml`
  end

  def test_no_offenses_found
    assert_match(/no\ offenses\ detected/, subject)
  end
end

RSpec

If you are using RSpec, this is where I put my test (again, put yours where it makes the most sense to you).

In spec/linters/rubocop_spec.rb:

require 'spec_helper'

RSpec.describe 'rubocop analysis' do
  subject(:report) { `rubocop --config .rubocop.yml` }

  it 'has no offenses' do
    expect(report).to match(/no\ offenses\ detected/)
  end
end

RuboCop Settings

Now, you’ll likely notice that RuboCop can be a bit of a style… cop. To override any of the default settings, you’ll need to make sure to create a .rubocop.yml file, at the root of your project.

Continuous Integration

CI itself may cause issues when using RuboCop, as the vendor/ directory is generally not committed, but that doesn’t mean that it won’t be scanned unless told otherwise.

This will help with that.

AllCops:
  Exclude:
    - 'vendor/**/*'

Minitest

To override the default RuboCop settings for Minitest, use something like the this:

In .rubocop.yml:

AllCops:
  Exclude:
    - 'Guardfile'
    - 'bin/*'
    - 'db/**/*'
    - 'config/**/*'
    - 'vendor/**/*'
    - 'test/test_helper\.rb'

Documentation:
  Enabled: false

# skips style of child classes and modules.
Style/ClassAndModuleChildren:
  Enabled: false

RSpec

To override the default RuboCop settings for RSpec, use something like the following:

AllCops:
  Exclude:
    - 'Guardfile'
    - 'bin/*'
    - 'db/**/*'
    - 'config/**/*'
    - 'vendor/**/*'
    - 'spec/rails_helper\.rb'
    - 'spec/spec_helper\.rb'

RSpec/DescribeClass:
  Exclude:
    - 'spec/features/*'
    - 'spec/views/**/*'
    - 'spec/lint/rubocop_spec\.rb'

Documentation:
  Enabled: false

# skips style of child classes and modules.
Style/ClassAndModuleChildren:
  Enabled: false

Metrics/BlockLength:
  ExcludedMethods: ['describe', 'context', 'shared_examples']

Know When Pushing to Main

Wed, 27 Jan 2021 14:50:00 +0000

I previously blogged twice about a way how to Know When Pushing to Master (Redux). Since then, tech is in the process of moving away from the term master and, for git, moving towards calling the primary branch main.

A reminder that this works with any potential alias.

I decided to create a new shell function, git(), that will be called instead of git (Note: this does not require uninstalling git, or any other change to it). I then hand that off to my shorthand function, g(), which performs some parsing to detect which branch you are pushing to (if you are pushing).

This versions checks to see if you are pushing, and if so, which branch you may be on. If you are on either the main or master branch, it prompts for confirmation. If you are not pushing, it executes whichever git-based command you had typed. If only git() or g() was called, without commands, it would execute git status.

# remap git to point to g()
git () {
  g "$@"
}

# git super command
# make sure with zsh that the git plugin is not used
# as it will override this command
g () {
  if [[ $# -gt 0 ]]
    then
      if [[ $1 = "push" ]]; then
        branch=`command git rev-parse --abbrev-ref HEAD`
        if [[ $branch = 'main' ]]; then
          while true; do
            echo -n "Push to 🔥  Main 🔥 ? (y/n) "
            read yn
            case $yn in
              [Yy]* ) command git "$@"; break;;
              [Nn]* ) echo "❤️  Push-to-Main crisis averted ❤️"; break;;
              * ) echo "Please answer yes or no.";;
            esac
          done  
        elif [[ $branch = 'master' ]]; then
          while true; do
            echo -n "Push to 🔥  Master 🔥 ? (y/n) "
            read yn
            case $yn in
              [Yy]* ) command git "$@"; break;;
              [Nn]* ) echo "❤️  Push-to-Master crisis averted ❤️"; break;;
              * ) echo "Please answer yes or no.";;
            esac
          done  
        else
          if [[ $# -eq 1 ]]; then
            command git push origin $branch
          else
            command git "$@"
          fi
        fi
      else
        command git "$@"
      fi
    else
      command git status
  fi
}

As you can see, not only does this work quite well, it also lends itself to being extended. Since I tend to create personal projects while also at work, it does matter to me whether my personal vs work email is used for new repositories. That’s when I created this bit of code to ask me exactly what I want. If you’d like it to always ask you, then simply remove the Darwin check.

# if on a macOS system and creating a new repository
if [[ `uname` = 'Darwin' && $1 = "init" ]]; then
  command git "$@"
  # prompt for the username and email to use
  while true; do
    echo -n "Will this be a ⚠️  work-related ⚠️  repo? (y/n) "
    read yn
    case $yn in
      [Yy]* ) git_work; break;;
      [Nn]* ) git_personal; break;;
      * ) echo "Please answer yes or no.";;
    esac
  done
fi

It also included the creation of the following functions to force the new repo to be configured properly.

# git local repo user
git_personal () {
  command git config user.name "I 💖 Ruby"
  command git config user.email "iheartruby@home-email.com"
}

# git work repo user
git_work () {
  command git config user.name "I Work with Ruby"
  command git config user.email "iheartruby@work-email.com"
}

In the end, I wound up combining them into a nice little family of functions. The only issue I ran into was having the git plugin enabled when using zsh. Disabling that made all the problems go away.

The final version that has been working for me now for quite some time is as follows.

# remap git to point to g()
git () {
  g "$@"
}

# git super command
# make sure with zsh that the git plugin is not used
# as it will override this command
g () {
  if [[ $# -gt 0 ]]
    then
      # if on a macOS system and creating a new repository
      if [[ `uname` = 'Darwin' && $1 = "init" ]]; then
        command git "$@"
        # prompt for the username and email to use
        while true; do
          echo -n "Will this be a ⚠️  work-related ⚠️  repo? (y/n) "
          read yn
          case $yn in
            [Yy]* ) git_work; break;;
            [Nn]* ) git_personal; break;;
            * ) echo "Please answer yes or no.";;
          esac
        done
      elif [[ $1 = "push" ]]; then
        branch=`command git rev-parse --abbrev-ref HEAD`
        if [[ $branch = 'main' ]]; then
          while true; do
            echo -n "Push to 🔥  Main 🔥 ? (y/n) "
            read yn
            case $yn in
              [Yy]* ) command git "$@"; break;;
              [Nn]* ) echo "❤️  Push-to-Main crisis averted ❤️"; break;;
              * ) echo "Please answer yes or no.";;
            esac
          done
        elif [[ $branch = 'master' ]]; then
          while true; do
            echo -n "Push to 🔥  Master 🔥 ? (y/n) "
            read yn
            case $yn in
              [Yy]* ) command git "$@"; break;;
              [Nn]* ) echo "❤️  Push-to-Master crisis averted ❤️"; break;;
              * ) echo "Please answer yes or no.";;
            esac
          done
        else
          if [[ $# -eq 1 ]]; then
            command git push origin $branch
          else
            command git "$@"
          fi
        fi
      else
        command git "$@"
      fi
    else
      command git status
  fi
}

# git local repo user
git_personal () {
  command git config user.name "I 💖 Ruby"
  command git config user.email "iheartruby@home-email.com"
}

# git work repo user
git_work () {
  command git config user.name "I Work with Ruby"
  command git config user.email "iheartruby@work-email.com"
}

Feel free to use this everywhere and anywhere it helps you.

New Goals

Mon, 04 May 2020 15:20:43 +0000

I like to learn new things, but over the past few months, that’s gone kind of stale. So, in an effort to improve myself, I thought I might take the initiative and get back in the swing of things.

Here’s the languages I’m going to spend time with, and a short list of the goals I would like to achieve. In no particular order…

Go

My biggest hindrance is using concurrency, everything else seems to be good. So I would like to wrap my brain around some practice examples just to make sure I’m applying it in ways that are real-world-enough.

Elixir

I’ve dabbled with it enough to know that I like it, but not enough to be comfortable. I’d like to get there, along with the concurrency that it apparently excels at. I have no plans to make Phoenix a part of this, but if the course / book takes me there, then I will consider it.

JavaScript

It’s been years since I’ve focused on this. ES6 wasn’t even a thought. AJAX was a new, uncoined phrase. I’d like to get back up to speed. This might include Node.js, but unlikely. My goal is to get comfortable writing a JavaScript-laden page without using jQuery or any other tool.

Elm

I’ve been wanting to learn Elm for some time. I figure if I know the hard parts of JS then I can also see where this alleviates those problems. I’ve heard nothing but good things and would like to write a couple plugins and patch those into existing HTML pages.

Know When Pushing to Master (Redux)

Thu, 30 Aug 2018 09:50:41 +0000

Update: See Know When Pushing to Main for a more up-to-date solution.

I previously blogged about a way how to Know When Pushing to Master. It was amazingly helpful, but I wanted it to work with stock git commands, not just custom aliases I would define for myself. I wanted it to work with any potential alias.

And it does.

The first version would check to see if any extra arguments were passed, and if so, it would check to see if push was the primary one, and then it would check the current branch for master, so it could prompt you for confirmation (if required). If it was not push, it would execute whichever git-based command you had typed. If only git() or g() was called, without commands, it would execute git status.

# remap git to point to g()
git () {
  g "$@"
}

# git super command
# make sure with zsh that the git plugin is not used
# as it will override this command
g () {
  if [[ $# -gt 0 ]]
    then
      if [[ $1 = "push" ]]; then
        branch=`command git rev-parse --abbrev-ref HEAD`
        if [[ $branch = 'master' ]]; then
          while true; do
            echo -n "Push to 🔥  Master 🔥 ? (y/n) "
            read yn
            case $yn in
              [Yy]* ) command git "$@"; break;;
              [Nn]* ) echo "❤️  Push-to-Master crisis averted ❤️"; break;;
              * ) echo "Please answer yes or no.";;
            esac
          done
        else
          if [[ $# -eq 1 ]]; then
            command git push origin $branch
          else
            command git "$@"
          fi
        fi
      else
        command git "$@"
      fi
    else
      command git status
  fi
}

# if on a macOS system and creating a new repository
if [[ `uname` = 'Darwin' && $1 = "init" ]]; then
  command git "$@"
  # prompt for the username and email to use
  while true; do
    echo -n "Will this be a ⚠️  work-related ⚠️  repo? (y/n) "
    read yn
    case $yn in
      [Yy]* ) git_work; break;;
      [Nn]* ) git_personal; break;;
      * ) echo "Please answer yes or no.";;
    esac
  done
fi

It also included the creation of the following functions to force the new repo to be configured properly.

# git local repo user
git_personal () {
  command git config user.name "I 💖 Ruby"
  command git config user.email "iheartruby@home-email.com"
}

# git work repo user
git_work () {
  command git config user.name "I Work with Ruby"
  command git config user.email "iheartruby@work-email.com"
}

The final version that has been working for me now for quite some time is as follows.

# remap git to point to g()
git () {
  g "$@"
}

# git super command
# make sure with zsh that the git plugin is not used
# as it will override this command
g () {
  if [[ $# -gt 0 ]]
    then
      # if on a macOS system and creating a new repository
      if [[ `uname` = 'Darwin' && $1 = "init" ]]; then
        command git "$@"
        # prompt for the username and email to use
        while true; do
          echo -n "Will this be a ⚠️  work-related ⚠️  repo? (y/n) "
          read yn
          case $yn in
            [Yy]* ) git_work; break;;
            [Nn]* ) git_personal; break;;
            * ) echo "Please answer yes or no.";;
          esac
        done
      elif [[ $1 = "push" ]]; then
        branch=`command git rev-parse --abbrev-ref HEAD`
        if [[ $branch = 'master' ]]; then
          while true; do
            echo -n "Push to 🔥  Master 🔥 ? (y/n) "
            read yn
            case $yn in
              [Yy]* ) command git "$@"; break;;
              [Nn]* ) echo "❤️  Push-to-Master crisis averted ❤️"; break;;
              * ) echo "Please answer yes or no.";;
            esac
          done
        else
          if [[ $# -eq 1 ]]; then
            command git push origin $branch
          else
            command git "$@"
          fi
        fi
      else
        command git "$@"
      fi
    else
      command git status
  fi
}

# git local repo user
git_personal () {
  command git config user.name "I 💖 Ruby"
  command git config user.email "iheartruby@home-email.com"
}

# git work repo user
git_work () {
  command git config user.name "I Work with Ruby"
  command git config user.email "iheartruby@work-email.com"
}

Feel free to use this everywhere and anywhere it helps you.

The Why - My Programming Career

Sat, 28 Jul 2018 16:02:15 +0000

Recently, I’ve picked up Go as another language, and I find myself falling in love with yet another programming language. I find it also interesting that it is causing me to be introduced to more computer science history and language design, which has caused me to ask myself, Why have I used the languages I have in my career?

So I thought I would answer that for myself, and for anyone else that might be interested (and for future me, who will surely look back on this post someday).

PHP - Post College and Paying the Bills

PHP paid the bills for over a decade. It’s what my first post-college job was all about, being tossed into the deep end and learning to swim in a web programming world. My second post-college job also leveraged that skill, and I spent a total of 11 years writing PHP professionally.

I don’t quite remember what got me into Ruby, but I vaguely remember it being due to a local meetup. I didn’t know him well at all, but Jim Weirich (a legend in the Ruby community) worked out of that same space. Him and a few others gave talks over the weeks I attended, and it ended up sparking an interest in me that I wasn’t aware of.

Eventually, my time with PHP came to an end when, during that 11th year, I suffered major burnout. Writing it was like bashing my head against a padded wall. I simply couldn’t do it. My brain still actively rejects it whenever I am asked to code review anything in PHP.

Ruby - So Good They Couldn’t Ignore Me

Maybe it was social media, maybe it was the Ruby Rogues, maybe it was my curiosity and desire to learn something new to use on the commandline. I think it was all of the above, to be honest. Having people (the Ruby Rogues) that were active learners and considered experts by others made it much more interesting than PHP had been for me (I was getting ready to deal with a massive bout of burnout with it).

Then there was Matz, and the whole “developer happiness” aspect that was core to the language. I felt like I could actually write programs non-programmers could read. I still remember how I felt when I first learned about the unless keyword: amazed.

Ruby also offered me things I had never really considered for PHP, refactoring and testing. I still go back to talks by Katrina Owen and Sandi Metz on these topics because they’re relevant, regardless of the language.

Ruby and its community made me realize it was ok to be happy as a developer. It also made me realize that I could automate tests. It’s where I learned “make it work, then make it right” (in regards to refactoring).

I think the biggest thing that Ruby taught me, though, was that it was okay to be myself. If I wasn’t okay with being myself, I’m quite certain I wouldn’t be where I am now in my career.

I don’t think I’ll ever stop being a Rubyist, and I’m quite ok with that.

Go - Commandline Heaven

Now that I’ve spent time getting really good with Ruby, it finally felt like it was time for Go. I had looked at it a few years back, and my brain just wasn’t ready for it. Having been writing gems and other commandline scripts in Ruby, I was at the point where a cross-compiling language spoke to me. So earlier this year, I took another look at it, and to my surprise, my brain was excited to learn it.

Since then, I’ve realized that the community is remniscient of Ruby’s, which is incomparable. I also noticed that Katrina Owen, someone I have the utmost respect for as a software developer, is also a part of the community. Then there are the language creators (Rob Pike, Rob Griesemer, and Ken Thompson), all of which have had a long and successful career. In a world where people want to put developers on a management track, I have a much better understanding of where I’d like to actually be in my career down the road.

In The End

PHP was chosen for me. I needed a job, and I found one (well, two), and it payed the bills for a long time.

Ruby was there when I needed happiness. It and its community have been a beacon of hope and joy and terrible puns, and I love all of it. It also gave me people to look up to that I never had with PHP, to show me right from wrong, and to learn that it was ok to not know things.

Go is helping me understand the why and the how of the career developers before me, and that makes me realize that I will still have a place as a developer when I get further down the road. It’s also given me more people to look up to, and to strive to be better at what I do.

Go Programming Language Promo

Wed, 27 Jun 2018 11:29:28 +0000

Back in 2009 they decided to promote one of my new favorite programming languages. I find it entertaining to look back on these videos to remind myself of a lot of stuff that we may take for granted.

Watch Russ Cox give a delightful performance. :sparkling_heart:

Make Vim Format JSON For You

Mon, 22 Jan 2018 11:29:28 +0000

Badly Formatted?

I will sometimes capture the JSON-based response body from another application to use as a fixture, but will end up with the standard one-liner file that is visually difficult to parse.

Surely Something Already Exists?

I looked around on the web and found a Python-based implementation, but it was padding with too many spaces and I had no insight into what it was actually doing. I spent a bit of time trying to see if I could make it conform to my needs, and shortly thereafter, decided to write it in Ruby.

Implementing A Custom Solution

The solution was quite simple once I knew how to pass in the current Vim file content (read: the buffer), how to access said content in Ruby, properly formatting it, and sending it back to Vim.

The basic Vim command I ended up with is

%!ruby -r json -e 'content = ARGF.read; object = JSON.parse(content); json = JSON.pretty_generate(object); puts json'

The Command Portion

%!ruby -r json -e

% grabs the current file content / buffer
!ruby calls Ruby
-r json tells Ruby to require the json library
-e tells Ruby to execute the code that follows

The Code Portion

# ARGF.read reads the content that Vim sent over
content = ARGF.read

# the content is still in JSON format, and it needs to be in object format
object = JSON.parse(content)

# the object then needs to be converted to "pretty" JSON
json = JSON.pretty_generate(object)

# outputting the "pretty" JSON sends it back to Vim
puts json

I actually ended up compressing the code to the following:

puts JSON.pretty_generate(JSON.parse(ARGF.read))

In Action

Vim Commands

To make sure Vim always has this available, I bound it to a leader-based command in my .vimrc

nmap <leader>json :%!ruby -r json -e 'puts JSON.pretty_generate(JSON.parse(ARGF.read))'<CR>
vmap <leader>json :%!ruby -r json -e 'puts JSON.pretty_generate(JSON.parse(ARGF.read))'<CR>
imap <leader>json :%!ruby -r json -e 'puts JSON.pretty_generate(JSON.parse(ARGF.read))'<CR>

Now, with just a couple keystrokes, formatting JSON is as simple as I hoped it could be.

RuboCop for Changes

Tue, 09 May 2017 12:00:00 +0000

One of the biggest problems of adopting RuboCop into existing projects is the onboarding of other developers, in a graceful manner.

Previously, I posted about using RuboCop for tests. While that’s all good and fine, being responsible for style issues outside of the files you’ve changed can cause a fair amount of friction and/or anger.

The following class is something that could be adapted to work within specs to better validate changes.

class RuboCopHelper
  OutOfSyncError = Class.new StandardError

  def analyze
    validate!
    return branch_clean if clean?
    system 'rubocop', '--display-cop-names', *files
  end

  def autofix
    validate!
    return branch_clean if clean?
    system 'rubocop', '--auto-correct', '--display-cop-names', *files
  end

  def valid?
    validate!
    return true if clean?
    `rubocop #{files.join(' ')}`.include? 'no offenses detected'
  end

  def remote_master
    "#{remote}/master"
  end

  def project_current?
    up_to_date_branches.include? branch
  end

  private

  def clean?
    files.empty?
  end

  def branch_clean
    puts 'Branch has no files to analyze and is considered clean'
  end

  def validate!
    raise OutOfSyncError, error_message unless project_current?
  end

  def error_message
    "Please merge in #{remote_master}"
  end

  def files
    @files ||= (changed_files + untracked_files + staged_files + unstaged_files)
               .split("\n")
               .uniq
               .select { |f| ruby_file?(f) && File.exist?(f) }
  end

  def changed_files
    @changed_files ||= `git diff --name-only #{branch} #{remote_master}`
  end

  def untracked_files
    @untracked_files ||= `git ls-files . --exclude-standard --others`
  end

  def staged_files
    @staged_files ||= `git diff --name-only --cached`
  end

  def unstaged_files
    @unstaged_files ||= `git diff --name-only`
  end

  def ruby_file?(file)
    file[-3..(file.length)] == '.rb'
  end

  def branch
    @branch ||= `git rev-parse --abbrev-ref HEAD`.chomp
  end

  def remote
    @remote ||= `git remote`.chomp
  end

  def master_hash
    `git rev-parse --short #{remote_master}`
  end

  def up_to_date_branches
    `git branch --contains #{master_hash}`
      .split("\n")
      .map { |b| b.delete '*' }
      .map(&:lstrip)
  end
end

You can then inspect the current branch with all relevant Ruby files being analyzed by RuboCop.

puts RuboCopHelper.new.valid? ? 'Looks Good' : 'Ugggggghhhh'

Know When Pushing to Master

Wed, 15 Mar 2017 12:15:00 +0000

Update: See Know When Pushing to Master (Redux) for a more complete solution.

You really probably shouldn’t be pushing to the master branch of your repo. Well, at least not for all repos. After I facepalmed recently when realizing what I had done, I figured it was time to at least question myself before doing so.

So, since I have shared aliases, I decided it was time to update my git push one, gp, to something a bit more… investigative.

alias gp="ruby -e 'if \`git rev-parse --abbrev-ref HEAD\`.chomp == :master.to_s; print \"You are on **MASTER**. Seriously, though. Do you honestly want push to **MASTER**? (Y/N) \"; unless gets.chomp.downcase == :y.to_s; puts \"♥ Push-to-Master crisis averted ♥\"; exit 1;end;end' && git push"

Sure, it’s a bit longer than I like, but it does what I want it to do: remind me of which branch I am actually on, and then confirm if I still want to go through with it.

The caveats are, of course, if I don’t use gp, this won’t run. However, my muscle-memory keeps git push from being used much at all. So, while not 100% coverage, definitely better than 0%. And, it’s system-wide.

Feature Specs vs. Functional Specs

Fri, 24 Feb 2017 12:15:00 +0000

I’ve come across projects where specs that can run self-contained don’t exist. They require the environment to be setup (like third-party APIs), and make development more difficult for new maintainers. These are Functional Specs, and they are meant to test out the application in a final state of polish (at least in my experience).

However, functional specs are not nearly as useful as Feature Specs. To be able to be able to run specs against a perfectly recreated environment is where feature specs shine. Yes, they are more complex to write than functional specs, but their value is in being able to run them exactly how you want. Whether it be with a specially crafted database record or a third-party API.

Feature specs allow you handle concerns like:

How should the application work in the browser?
Are there JavaScript issues?
What should happen when a third-party API is having issues?
What should the user see when there are problems?

Sure, there are many more areas that can be covered, but basically, being able to mock third-party API interactions and create database records to meet your needs, is invaluable.

If you can write a functional spec for it, you can write a feature spec for it. Yes, it takes more effort, but future maintainers (including yourself) will be thankful you did.