ajax analysis api apple atom automator backpack browsers camping cheatsheets code console editors ergonomics gems google helipad hpricot internationalisation javascript lies mac optimisation patterns performance personal php plugins productivity programming prototype rails rapidrails rsi rss ruby server snippets standards sysadmin terminal testing textile textmate theory tips tools vim workshops writing xslt
My Rails tutorial (part 1 of 4) has been published in Linux Format 108. It shows you how to build a Rails-powered photo gallery, by using basic techniques and popular plugins.
Grab it from your favourite newsagent and let me know what you think!
Welcome to Rapid Rails Part 3: Desktop mastery, the third article in my series focussing on making Rails (and yourself) faster.
A good programmer recognises when to reuse and therefore reduce code. A great programmer applies this tendency to their own workflow. Whether you use an IDE or text editor, working with Rails can be made more pleasant and efficient by observing commonly performed tasks and simplifying them.
The examples given below have a heavy bias toward TextMate, Vim and Mac OS. If you work in Windows or Linux, at the very least consider the following 10 ideas.
This is part 2 of the Rapid Rails series. Part 1 featured tips on how to work more efficiently with Rails by making the most of the bundled and related command line tools. This part discusses how to make your Rails application perform faster, with particular focus on server optimisation. Why? Because systems administration requires a very different skill set to programming, and I’ve been often been expected to manage sysadmin tasks on my Rails contracts—and I bet you have too!
I’ve included real-world e…
Rapid Rails is a series of articles containing succinct tips to increase your productivity when working with Ruby on Rails. This is the first part, and shows you how to make the most of the command-line tools that come with Rails.
The Rails generator script (found inside an application’s directory at script/generate) allows you to quickly create templates for anything you need within Rails. As well as models and controllers, you can also use it to write entire migrations:
scr…
This article is an introduction to testing Rails plugins. It’s a relatively lengthy post, so if you’re reading this in an RSS reader flag it and come back when you’re not too busy. It follows the “taxonomy” style of my previous plugin article, A taxonomy of Rails plugins, where examples are used from open source software.
Knowledge of both unit and functional testing is assumed. The following topics are covered:
There are now almost 1000 entries in the main resource for Ruby on Rails plugins, Agile Web Development’s Plugins Directory. Of these, 596 have repositories listed that are accessible. I wanted to see how many of these plugins came with some form of tests, so I created a spider (using a web spider library) and performed some basic analysis on each repository.
After reading a few magazines, and watching two entire TV shows, the spider came back with a result: 54% of the plugins have tests.
It’s amazing to …
A common stumbling block for Rails developers is learning the basics required to write plugins. This is made more complicated by the fact that Ruby is inherently dynamic and offers many techniques for code reuse. Luckily, if you can write Rails applications you can write plugins by simply drawing on a handful of basic patterns.
The purpose of this article is to demystify writing plugins using examples of common patterns used by popular plugins.
Writing a plugin will:
Have you ever been working on a project that has session variables controlling important aspects of functionality? When they start falling out of controllers and views into a big pile of soup on the floor it’s probably time to encapsulate them.
Although relying on the session object in controllers and views is relatively easy to understand, you should be very wary when you’re tempted to use them this way. Thinking, “I’ll just add a session variable for this” will probably lead to misunderstandings or bugs later on. And on…
Have you found that any of your Rails projects get hits to controller methods that expect parameters? A neat way of handling this is the ActionController::Verification module.
By adding calls to verify in your controller, you can elegantly catch all kinds of unexpected but reasonable uses of your system: from mistyped URLs and browser history auto-complete to web crawlers blindly following links. This way, you can redirect people somewhere logical instead of flashing them with an error message.
You can even insert a message into the flash:
verify :params => “user”,
:only => ...
Have you ever tried concatenating your JavaScript and CSS files for performance improvements? The idea is that latency is a bigger issue than file size when loading web pages, so stuffing all your JavaScript into a monolithic file for deployment should improve performance.
I wrote a rake task to do this for some of my applications (such as tiktrac). This is slightly more cumbersome than a feature I spied in the ActionPack changelog:
Added caching option to AssetTagHelper#stylesheet_link_tag and
AssetTagHelper#javascript_include_tag [DHH]. Examples:
stylesheet_link_tag :all, :cache => ...
I’ve created quite a few Rails projects over the last year, some commercial projects, and others are applications released under Helicoid. Here’s a few things I’ve found save time and help make projects as maintainable as possible.
Named routes
You can refer to routes in your forms and links like this: document_edit_url(:id => document.id). Isn’t that much nicer than other means? It can often make code easier to understand quickly, thus helping maintainability.
To use named routes, instead of the usual map.connect directive, use map.my_name.
Migrations
I use migrations for…
I’ve been working hard to improve the performance of Tiktrac, just because it’s been in beta for a few months and I’m really sharpening it up to finally stump up the cash for some serious hardware to run it (and other) applications on.
When I need to improve performance in a rails app, I start off with a few basic questions:
At this point, I start loading slow pages and watching the logs. The logs will show you interesting data like this:
Rendered sheet/_she…
I had a User class, which then had a Moderator class. I was using the “type” field in my database to denote whether a user was a User or a Moderator. However, my validations weren’t working as I expected:
validates_as_unique :name, :email
Users could have the same email address as Moderators. Obviously sometimes this kind of scoping makes sense for STI classes, but it doesn’t here. I ended up writing this:
module ActiveRecord
module Validations
module ClassMethods
# Intended for use with STI tables, helps ignore the type field
def validates_overall_u…
