Posts

• A Rails IDE with Vim

  I’ve been a casual user of vim for many years now. It’s my $EDITOR everywhere, I write my commit messages using it, and anything else that needs to get edited in a terminal session. However, it was only less than two years ago that I decided to go all in on vim and use it exclusively as my IDE for programming work. The process has been slow, and has included bringing in new peripheral things like tmux, as well as building on existing things such as a dotfiles repo.

• Prepending Modules in Ruby

  We’ve been prepending classes a lot recently as a means of mokeypatching, but in a “nicer” way. Turns out you can do this with modules too.

• Stage Builds on Travis, in Color!

  We’ve been having a problem with Coveralls lately were we get incorrect coverage reports because we split up our builds to save time. Unfortunately, our test suite runs very slowly, for reasons I won’t get into now, so we run two parallel builds: one for feature tests–aka, everything in spec/features; and, another for unit tests which is everything else.

• Javascript Frameworks in Rails with Webpacker

  We recently conducted a series of qualitative discovery sessions around each of the different types of Javascript frameworks that are available in Rails via the webpacker gem. While we didn’t really reach any conclusions, we did get pretty adept at installing new frameworks. The documentation is a little scarce in certain places, so here’s what I’ve learned from it so far.

• Strictly by the ABCs

  Metrics can be great tools to measure things, but like any tool, there’s the right one for the job. Not only do you need to know which one to use, you also have to wield it correctly; otherwise, you’ll do more harm than good.

• Refactoring A Fibonacci Sequence Generator

  I came across some sample interview questions for a senior Ruby developer the other day, and one of them caught my eye:

• Commit Messages: Love letters to our future selves

  A colleague of mine once referred to commit messages as “love letters to our future selves.”

• Booleans and ActiveRecord::Callbacks

  I lost a few hours while I puzzled my way through this one.

• grammar

  It goes without saying, grammar counts. Take for example:

• Commutative Multiplication in Ruby

  I discovered this today while working through the roman numerals kata on exercism.io: Multiplication of strings in Ruby is not commutative.

• (Yet Another Post About) Presenters in Rails

  YAPAPIR! Lots of virtual ink has been spilled over presenters in Rails. My take on them that follows came about after our team decided to arrive at an adoption strategy. We’d been using them in other projects, and were starting to go down a road of implementing them different ways, when we though we should pick one way and stick to it.

• Rebuilding Your Github Pages Site

  This happens to me a lot because I go so long without writing a post. By the time I’ve gotten around to writing something, I’ve had my laptop reimaged, or I’ve deleted the repo. So I end up having to recreate the entire Github pages setup… and I don’t remember how!

• HTTP Headers with Capybara's Drivers

  I stumbled across this very slight but significant difference when trying to inject some HTTP headers into an application being tested with Capybara.

• Capistrano

  I’ve been working recently on a side project with a very restrictive server environment. Capistrano has turned out to be a good way to deploy news apps easily and quickly. Admittedly, I have a bit of a love/hate relationship with Cap. I use it at work, and it’s wonderful when it works… until it doesn’t, and then it becomes very frustrating. Part of this was was due to the fact that it was setup before I came on to my current job, so I didn’t see it getting built from the ground up. So I figured with this side project I could set it up myself and see better how it works.

• Surveying the Javascript Landscape

  Taking a break from my usual Ruby work, I did a “recovery sprint” and explored some Javascript. My skills are weak at best in this area and it was my intention to improve them by learning some new technologies.

• RSpec: Testing Inputs

  After trying to do this the other day, there are a lot of different approaches to doing this. Here’s mine:

• Watching Your Test Application

  When I run test with a sample Rails app, for example if I’m working on an engine gem, it’s sometimes difficult to see what’s going on if a test is failing. I’m a big proponent of having a clean database before every test. This means running a database cleaner and other tools that wipe out the data before and afterwards. This can present problems when you’re trying to nail down a particular failure because the data gets wiped after it’s over.

• Filters, Not Overrides

  When refactoring some controllers, I realized it’s much nicer to filter actions on controllers instead of overriding them.

• Git

  This is my usual workflow when submitting patches, or even working on my own applications. There’s been a lot of focus on Git branching models as of late. This is a good one, for example. Mine isn’t always that complicated, but no matter how many topic branches, my workflow is pretty much the same.

• A Passenger in a Passenger

  Here’s something I didn’t know you could do, until today…

• No Breaks

  New year, yes I know, it’s late. I’ve been doing lots of front-end and web design work which I readily admit is not my strong suit. However, I stick to using the Bootstrap framework and try to work within its defaults as much as possible. I find this helps force me to be consistent and maintain control over layout.

• Rails Manifesto: Views

  I’ve been developing with Ruby on Rails for about three years now, and while that’s not as long as some other folks, it’s long enough for me to have formulated some of my own personal programming maxims. One of these is about views. This past week, I was rewriting view code in order to completely remove all Ruby logic so that it was solely HTML code as much as possible. While you’re allowed to do lots of things in Rails views, I prefer to keep views what they’re supposed to be: just about display. To that end, I use lots of helper methods to handle the logic, and leave the view code as simple nested HTML blocks.

• Glob-ins

  A couple of months ago, I spent a harrowing Friday afternoon deploying one of my Rails apps. All the tests were passing on my laptop and on the development server. However, once I got the same code on the production box, none of the spec tests were running. Everything was failing with same error:

• Testing Engines Under Rails4

  Recently, I’ve been using engines a lot, and have run into problems with testing them. The current guide on creating Rails engines covers the basics of creating the engine and touches a bit on testing them. The gist is that there is a dummy application under test/dummy and the code you write in the engine is tested against it.

• chruby

  This is the third, in a sort-of-three-part-series on Ruby managers. In the first post, I discussed using rbenv in place of rvm which I had been using up until that point. I found rbenv to be more lightweight than rvm, and it proved to be a better fit for my production environment.

• Using Rbenv in Production

  In the last post, I went over the procedures I used to install the Ruby environment manager, rbenv, and setup it for developing rails applications.

• Moving to Rbenv

  I’ve been a loyal RVM user for several years now, but recently I grew a bit tired of using it in production. It seemed too heavy-handed and updating was arduous. After some looking around, I settled on rbenv, mostly because it was simpler, smaller and could work well in all my environments: from my laptop, where I develop, to the different servers on which I deploy everything. Keeping it all identical across these is very important to me because I don’t want to have to re-think anything when releasing new code.

subscribe via RSS