A refactoring epiphany

There are tons of resources out there that list ideals for ruby code and methods to learn about refactoring your code(an example) if you didn’t follow those ideals. All of these ideas sound great but implementing them while you’re in the middle of dealing with bugs or tricky features can be tough. This past week I commited to refactoring a messy before_action I wrote for a controller. Our project was Dinner Dash. Read On →

99 bottles of robots: our first code retreat

Last Friday our gSchool class took a field trip to the Source for our first code retreat. If you’re not familiar with code retreats definitely check them out. There are a ton listed on Meetup and there’s one happening in Denver in December. We were given two seemingly simple problems to work on, 99 Bottles of Beer and a moveable robot. To make things more interesting though we worked under some constraints. Read On →

Array arithmetic in Ruby

I was digging around in some Rake source code this morning to learn about navigating file structure and ran down a rabbit hole of array math. I found some pretty neat things. With Ruby#Array you can do something like the below: ARRAY_METHODS = (Array.instance_methods - Object.instance_methods) giving you the methods that are direct descendants of Array (and not inherited from Object). +1 for reading source code. And back with the file traversal idea in mind I found a way to recursively list all the files in a directory without shipping out to the shell. Read On →

Run a single Minitest test

Being able to single out a particular minitest test from a full suite can be a huge time saver when you’re in the middle of debugging a problem and all you care about is one test. Similar to RSpec, Minitest allows you to run just one test with the following command: ruby /path/to/file/name.rb --name name_of_test_method Or for an example: ruby test/spec/user_test.rb --name test_it_can_sign_in I’ve found narrowing down the tests running to be particularly helpful when you’re seeing odd behavior in application code from only a single test but others tests are running fine. Read On →

Cleaning up require statements with Ruby's $: global variable

Ever run across something like the below line in helper files? $:.unshift File.expand_path("../../lib", __FILE__) This little trick allows you to be lazy with your require statements further down the road. This line will load onto your path your lib directory so that your downstream require statments can look like require '/class_name' instead of require './lib/class_name' Doesn’t seem like much but it does make file dependencies easier to sort out if you have a big project. Read On →

Testing Sinatra apps with Capybara and Minitest

I went through some headaches recently getting a Sinatra app configured to use Capybara with Minitest (plain vanilla Minitest as opposed to Unit or Spec). There’s a lot of nuiance I skip over but below I walk through setting up Capybara with Minitest for a Sinatra app. Please chime in if you have any tips. My test folders look like this test | |\ | \acceptance | |\ | \helpers | |\ | \integration | |\ | \unit All that we’re interested in are acceptance and helpers. Read On →

A primer on Bundler basics

Ruby’s Bundler performs all sorts of magic for your apps’ dependencies. All sorts of magic I don’t fully understand but after reviewing some open source projects this week I gained some new insight on some of the knobs that Bundler makes available to you. Below is a summary of some of the more commmon Gemfile configs and associated Bundler commands you’ll see in the wild. Here’s an example Gemfile we’ll use to illustrate our points: Read On →

Set a default rake task

Ever found yourself with a large Rakefile and forgot the names of frequently used tasks? Well, you can set a default Rake task so when you run rake by itself you’ll run that default task. task :default => [:test] task :test do ruby "test/unittest.rb" end The above is pulled from the docs. Although it’s a small thing, having a default task set (such as your test suite) can be helpful. Read On →

Focus Week Reflection

This week was a ‘rest’ week at gSchool where we worked on shorter and more open ended projects. My team made a tic tac toe game in Ruby-Processing. As we’re between larger multi-week projects I had some more time to read and play around with some extra libraries. I wrote a very simple Shoes app on top of one of our last projects. My inspiration came form listening to Zachary Scott talk about Shoes at RMR13. Read On →

The power of hashes: why thinking about your problem matters

We wrapped up the SalesEngine project this week and during our code review we discussed ways to improve the performance of our code. We were given a spec harness to run against our code to validate all the features worked. Most students’ first round implementations took 10-15 minutes to run the specs. That amount of time is painful when trying to debug problems. But, most of us just dealt with it and moved on. Read On →