Rails and Active Record make many things easy: connecting to the database, building complex queries based on your object model, and easily migrating your schema up, down, and sideways. They also let you very easily introduce N+1 queries. Read more on Custom Rspec Matcher for N+1 Queries in Rails…
It seems that on every Rails project I work on, I end up writing utility scripts that make changes to the production data in some way or another. Perhaps it’s pre-loading hundreds of user accounts for a customer that wants to provide a spreadsheet of users, or populating an account with fake data that can be used for a demo, or manually fixing a data integration issue with an external system. Often, this requires parsing and processing a source file (like a CSV file). Read more on Code Generation for Rails Utility Scripts…
I was recently working on a piece of code from a legacy Rails application. An unusually large number of queries being run on a particular page let me know there was an N+1 query lurking.
The application was an online assessment platform dealing with assessments, questions, and responses. The question listing page was simply asking each question if it’s locked—which happens if it has any responses. So what’s the best way to query for lots of questions and their locked status? Read more on Active Record Aggregate Fields via Sub-Selecting Scopes…
Heroku provides a convenient command line interface for executing snippets of Ruby code remotely. One-liners can easily be piped into the
heroku run console command. But what about much longer scripts that you write locally and want to execute in a remote Heroku environment? In this post, I’ll show you how to execute a long Ruby/Rails script in a remote Heroku environment.
When working on a Rails project, you will inevitably need to move data around in your database. Some join table value will need to be moved into its own table or what have you. When approaching these kinds of migrations, there are two major complications: future-proofing and testing. In this post, let’s walk through an example migration.
Read more on Testing Data Migrations in Rails…
Our use cases were a little bit different, though. He was storing the file contents directly in the database, whereas I needed to be able to uplaod a firmware image file to the server’s filesystem, parse the file name, and perform some validations on the file. I decided to use the Paperclip gem to manage the file processing and storage. Using Job’s advice on Active Admin file uploads, I expanded his example to incorporate Paperclip.
Read more on Uploading Files in Rails Using Paperclip and Active Admin…
I was recently pointed to Ben Singelman’s post on Why Nobody Should Use Rails For Anything, Ever.
We seem to never get enough of arguing about application frameworks: I’m not going to do that. What irks me is when Ruby get thrown out with the Rails bathwater. As one commenter on Singleman’s post demonstrates:
“Interesting perspective. I agree on your general points — Ruby’s fine at an MVP stage I think, but when it comes to creating something for market, it just falls over.”
(This despite the second sentence of the post stating “Independent of ruby, I see Rails as the emperor with no clothes on.”)
A few months ago, I came across the Settingslogic gem. I wish I’d discovered it years ago.
Until then, I’d found myself manually handling configuration and settings via raw access to YAML files. This meant I was repeatedly writing code like the follow to handle my various needs:
require 'fedora/connection' config_file = Rails.root.join('config', 'fedora.yml').to_s if not File.exist?(config_file) raise "You need a config/fedora.yml file. Try starting with config/fedora.example.yml if you need a sample to start from." end configuration = HashWithIndifferentAccess.new(YAML.load_file(config_file))[Rails.env] Fedora.connect!(configuration)
All of that checking for the config file’s presence, parsing it with YAML, extracting and passing around the configuration, testing it… blah. Any individual operation is simple and straightforward, but performing all of those operations together, multiple times, is irritating and prone to errors.
Teaching a workshop involves a lot of thought and preparation. There’s research to do, content prep, slides to tweak — and you have to figure out some way of getting all the attendees started with the same setup. If you’re lucky, you’ll be presenting in a lab with machines that can be set up ahead of time. Puppet, Vagrant, and VirtualBox are fantastic tools to help you get your workshop setup. Using them saved me time and kept me from having to deal with issues on the day of the workshop.
I recently did an “Intro to Rails” workshop at Hope College. Their lab was set up with powerful laptops that were already equipped with VirtualBox. I just needed to provide them with an image to use. If your attendees are bringing their own equipment, think about having them install VirtualBox ahead of time.
Sending email from a Ruby on Rails application is easy. Sending well-formed and aesthetically-pleasing HTML emails that render reliably in all mail clients is rather more difficult.
The code/test/edit cycle can be greatly eased by a number of great tools such as mail_view or MailCatcher, but in the end there’s no substitute for actually trying your email templates. There are a lot of differences in HTML handling across email clients, so testing your emails is critical.
Here’s an approach to email template testing that I’ve found useful.
Read more on Testing Email Templates in Rails…