SecondForge

Previously, I wrote about the Acer C720 Chromebook that I purchased on Black Friday. I have just returned from my first major travel experience with just the Chromebook in tow, and the verdict is in: this device is fantastic.

I used my Chromebook on the bus from Gainesville to Tampa, on the plane from Tampa to Detroit and from Detroit to Salt Lake, in the airport while waiting for my connections. It’s lightweight, easy to wrestle out from under the seat in front of you on a plane, easy to put aside to accept your complimentary in-flight peanuts. It is small enough to be usable on a tray table even on coach seats, and even reasonably comfortable for me to use with my longer arms.

Granted, I am still running into the occasional memory shortage and related slowdown. But after a few weeks with the device, this isn’t occurring as often as it had before, as I’ve trained myself not to open quite as many tabs. I even managed to do some fairly heavy development while working on the Chromebook using a Digital Ocean server for the heavy lifting. Reasonably reliable internet is ubiquitous enough today that doing the majority of my development work through SSH while traveling is totally possible.

The only major complaint is that using the device is anything but ergonomic. While using it, I spend most of my time staring into my lap, which is not good. But this is a problem with any laptop; and hard to blame on the Acer in particular.

My favorite part about traveling with the c720, though, is that it is cheap enough not to worry about. The device cost less than half as much as my phone, and about as much as I spent on food on the trip. It is cheap enough to leave in a hotel room or on a bus during a fueling stop without worrying about the possibility of it being stolen.

Ultimately, I’d like to have a device with a separable keyboard that could be somehow hung on the seat in front of me. It’d be great to be able to have my keyboard in my lap but have the screen at eye level while working on long flights or bus rides. Perhaps the next device will fulfill that dream.

Until then, I highly recommend the c720 for anyone looking for a cheap, lightweight development machine.

This evening Gary Bernhardt posted a series of tweets pointing out that printing a stack trace (or backtrace, in ruby parlance) in order with the most recent method call at the top and oldest method call at the bottom, as most languages do, doesn’t make much sense. Application programmers are interested in the most recent method call much more often than they are interested in the deepest method call, so putting that information at the bottom, where their eyes will be on the terminal, would be better.

Apparently, Python is the only (common) language that gets this right. Being a Rubyist, I was immediately filled with hubris - well, Ruby isn’t anything without its fantastic metaprogramming capabilities.

If Exception were a normal class, we could just monkey-patch the exception class as follows:

1
2
3
4
5
6
7
8

class Exception
  alias :old_backtrace :backtrace

  def backtrace
    old_backtrace.reverse
  end

end

I threw that into a gem and defined a test file to make sure that my method would work appropriately. Certainly, I don’t know all the details of the ruby internals - I never had any delusion that this would be a good idea in a production environment, necessarily, but I certainly expected it to basically work.

Of course, it didn’t. Not only did it not work, but none of the regular debugging strategies that I tried to employ worked; alias the method worked so long as the new method directly called the old, but didn’t work otherwise. Putting a ‘puts’ statement would cause stack overflows; adding a .to_a on the old method (which shouldn’t do anything) caused no output to be sent at all, &c.

It turns out that Exception is defined directly in error.c in CRuby (also called MRI). It seems that overriding cRuby classes is not the same as overriding regular ruby classes.

Ruby isn’t rubies all the way down - eventually, you hit some C.

Happy Coding!

Rails has fantastic AJAX and unobtrusive JavaScript support. I’ve found that I can usually get 80% of the effect that one would normally build with a JavaScript framework like backbone or angular with rails remote actions for about 20% of the effort - usually a good trade, especially early in a project. Here’s a five minute rundown of how to use them.

You can add the remote: true parameter to any link_to or button_to or form_for. Behind the scenes, rails will do some magic to make that link, when clicked, fire off an XHR HTTP request to whatever action you specified. The request gets sent to the controller in your rails application just like it normally would - adding remote: true doesn’t change which parameters get sent, or how they’re formatted, just whether they are sent with AJAX or a regular, page-refreshing HTTP request.

The only difference in the controller is that instead of returning html via the format.html block, it’ll return JavaScript via the format.js block. As such, the template that will be rendered won’t be (for example) /show.html.erb, it’ll be /show.js.erb. The .js.erb file is exactly what you’d expect - JavaScript with embedded ruby. The JavaScript that gets produced gets run the page just like any other JavaScript, and you have full access to jQuery and the rest of your JavaScript libraries.

What’s the easiest way to make use of this? The easiest way is to use your .js.erb file to render a partial and replace the element on the page with your rendered partial. Let’s say you have a partial called _item.html.erb which renders an Item object. Suppose that on some page somewhere you have a ‘featured item’ display that calls <%= render "item", item: @item %>, which renders your _item.html.erb partial. You want to be able to refresh it to re-render the same item with a button.

Your featured item display might look like this:

1
2
3

<div id="featured-item">
  <%= render "item", item: @item %>
</div>

Your link will look like this (of course, you can add any styling class: and such that you like):

1

<%= link_to "Refresh", item_path(@item), remote: true %>

What should we put in show.js.erb? This will work:

1

$("#featured-item").html("<%=j render "item", item: @item %>");

This will call the .html method, which replaces the inner html of the target element with its argument. The <%=j allows us to embed the result of some ruby expression, but with appropriate escaping so that it is a valid JavaScript string. And render "item" does exactly what it always does, rendering a partial into a string of html.

That’s it. Now when you click the ‘refresh’ link, it’ll replace the content of #featured-item with the appropriate new content. Hooray, AJAX!

Of course, you can get fancier with it - you can put any (and as much) JavaScript as you want in your .js.erb files, but keeping it to a dull roar is probably ideal. The only downside of these methods is that the actions can be somewhat hard to debug, because if there is a parse error on your JavaScript generated by .js.erb, it won’t appear in your JavaScript console. To debug, you can (on Chrome / Chromium) go to the developer console, find the “Network” tab, and use the display to find the body the appropriate XHR request, then copy-paste it into the JavaScript console, where any parse errors will be displayed. Not optimal, but this is still a great technique.

Happy coding!

Ruby is fantastic for creating domain-specific languages. This means ruby (& therefore rails) development tools are full of domain specific languages - things like ActiveRecord’s Migration syntax, Rspec’s expect() syntax, and so on.

When working with these domain-specific languages, it is easy to forget that you still have the full power of Ruby at your disposal. Case in point: I am currently working on rails application that involves tracking golf scores. Ergo, there is a scores table that stores a player’s results for an outing. Storing a score for a round of golf means inputting 18 integers - one for each hole that the player played. I wanted to just have 18 columns in the database, instead of having some sort of HoleScore class and then expanding it - certainly this might change later, but starting with the simplest answer is usually the right way to go.

How to create the migration? It’s easy to forget that you can use plain old Ruby in your ActiveRecord Migrations! This solution works splendidly:

1
2
3
4
5

create_table :scores do |t|
  18.times do |n|
    t.integer "hole_#{n+1}_score"
  end
end

The above creates 18 columns, all integers, named hole_1_score through hole_18_score. Great!

This can be extended to writing specs as well - although needing to write specs like this is probably a code smell, sometimes it is easiest to just put your spec in a loop:

1
2
3

  [:one, :two, :three].each do |arg|
    expect(a_method(arg)).to eq(a_value)
  end

Happy coding!

I use vim for text editing. I’m not religious about it by any means, but it is a pretty decent tool. Like most *nix tools, though, part of the art of making the most of using vim is building up a suite of your own shortcuts, commands, and re-mappings to make the editor your own and suit your own workflow.

I recently added two simple lines to my .vimrc that have helped me practice test-driven development all the better by letting me run my tests quickly and efficiently from vim. There are entire plugins for making vim work with ruby or rails easier, but I’ve never gotten much use out of them as they represent another set of things to learn and another dependency to keep updated, and they can sometimes conflict with my existing sets of aliases and remaps.

To do this in vim, you need to edit your .vimrc file. By default on Linux, this file is stored in your home folder. To this file, I added the following lines

1
2

map <leader>S :! rake spec <cr>
map <leader>s :! rspec % <cr>

What do these do? map maps a key combination in normal mode (e.g. <leader>S) to a command (e.g. :! rake spec <cr>). :! allows vim to run an external command; vim’s normal window will be hidden temporarily, the command will be run, and when it is done you can press any key to jump right back into vim. In an external command, % will be replaced with the file path of the current buffer (file).

So, by hitting <leader>S, I can run rake spec and be one key press away from being back in the file I was editing¹. Great! By hitting <leader>s, I can run just the spec file that I’m currently in, saving a little time on the execution for large spec suites and keeping me from being distracted by the output of other tests.

If you use vim, I highly recommend adding a mapping like this for your own project setup. Reducing the barrier to running your tests or specs means you will run them more often, which can only help. And saving a few key strokes only makes your development experience more enjoyable.

Happy coding!