I'm Jason, a web application developer in East Tennessee.

  1. Spree Extension Development Environment using RVM

    I’ve found that there is trouble working with a Spree extension when your gem set does not include the gems included with the Spree gem itself. I discovered this after generating a Spree extension, confining the extension to it’s own gem set using RVM, and then running ‘bundle install’ based on the Gemfile/gemspec configuration of just the extension itself.

    To overcome this, I recommend making a folder named ‘spree’, then configuring that folder to use a shared ‘Spree’ gem set.

  2. Creating a Gem

    In the past gems were created manually, or generated using the echoe gem (last release Sept 21, 2011), or the Jeweler gem (last release November 7, 2011).

    Since then it appears that the most automated way to create a gem is by using Bundler, via the bundle gem command.

    $ bundle gem my_tools
          create  my_tools/Gemfile
          create  my_tools/Rakefile
          create  my_tools/LICENSE
          create  my_tools/
          create  my_tools/.gitignore
          create  my_tools/my_tools.gemspec
          create  my_tools/lib/my_tools.rb
          create  my_tools/lib/my_tools/version.rb
    Initializating git repo in /Users/jsmith/Sites/my_tools

  3. Ruby File Modes

    When working with files, you can open them in one of several modes."/file/path.txt", "w")

    You can find the description of these modes in the IO documentation.

  4. Return FALSE or Raise Error?

    I was working on a gem a couple months ago, and it came time for my boss to do a code review before we install the gem on another teams system. My boss pointed out that there were areas where I was returning FALSE, and baking in a lot of conditional statements and other handling, instead of using Ruby’s built in feature of error handling, which is designed to bubble exceptions up the call stack. He informed me that in situation that are not expected to occur, it’s best to raise an exception to halt execution and report the issue. He even recommended that I read Exceptional Ruby, a book devoted to the subject of proper exception handling.

  5. When Testing Seems Pointless

    I remember when I was first exposed to the concept of test driven development (TDD), it seemed like you were writing a test that did the same thing as the function itself. This really left me perplexed as to why everyone was raving about it’s value.

    Take for instance the following method:

    class SomeClass
      def self.todays_date"%Y-%m-%d")

  6. Using Rspec to Test Controllers

    Here are some tips that will help you with Controller tests in Rspec.

    Common Response Methods

    # Get HTTP response code with message. Example: "302 Found"
    # Get HTTP response code. Example: 200
    # Get response body
    # Get location header, used with redirects

  7. Good Guy Greg

    Edits your code, updates your Rspecs

  8. Using Rails 2.3.8

    I’m working on a project that is stuck on Rails 2.3.8 due to the size and complexity of the codebase. Upgrading it would be a nightmare. I recently ran into an issue with the database_cleaner gem, which isn’t rolling back transactional queries properly. I’m not sure if the issue is with the gem, or perhaps some configuration with the system (ActiveRecord) which is causing the issue. Because of this, I’m wanting to create a dummy Rails 2.3.8 application so that I can reproduce the issue on a fresh, simple, vanilla Rails application.

    I created a new ‘rails238’ directory and switched to it, then created a new gemset via RVM.

  9. Rspec Executable Not Found

    I’m working on an older Rails 2.3.8 application that is way too complicated and without tests to make it worth upgrading to Rails 3 or higher. Because of this we must use RSpec-Rails 1.3.4, with RSpec 1.3.2.

    I was just trying to run a single test from the command line like so:

    $ bundle exec rspec spec/models/post.rb
    bundler: command not found: rspec
    Install missing gem executables with `bundle install`

  10. Changing the Default Text Editor

    Certain command line utilities drop into an external text editor program to accept certain types of input. For instance, when using the command ‘crontab -e’ to edit your cron table, your default text editor program will be opened up with the current cron table configuration. The same also applies to the Git versioning system when using the interactive rebase mode. This helps the program avoid supporting it’s own text editor, and allows the user to specify their preferred text editor.

    To specify the default text editor, simply edit or place the following definition inside of the .bash_profile file in your home directory. This example uses ‘/usr/local/bin/mate -w’ to specify that the Textmate editor be used. You may configure this value to reflect the path for Vim, Nano, or any other text editor you wish to use.