ajax analysis api apple apps atom automator backpack blogging blogs browsers camping capistrano cheatsheets code console deadline design editors ergonomics events fluid fowa games gems geocoding geolocation git gitlondon google graphs helipad hpricot internationalisation iphone javascript lies littlebigplanet london mac maps marketing miniapps money optimisation patterns performance personal photography php plugins privacy productivity programming projects prototype rails rapidrails rsi rss ruby server shoes sms snippets software ssb standards sysadmin terminal testing textile textmate theory thoughts tips tools vim web workshops writing xslt
Rails boot up time really starts to drag when you’re working in a TDD or BDD style. There’s projects out there that create long running distributed processes to ease this, but it’s interesting to look at exactly why Rails might boot up slowly.
I have a project that isn’t massively complicated, but it has suffered from “just add” culture. I’ve been told to “just add” Excel support, PDF generation, and a lot more features that require complex libraries. This naturally increases the memory footprint of my application, and it also increases boot time.
Before I started my analysis, the boot…
I wrote a series last year called “Rapid Rails”. It was all about making your Rails app and development process faster. I’ve been analysing the performance of some mature Rails projects recently, so rapid rails is back.
If I’m tasked with improving an application’s performance, the first thing I look at is indexes. Indexes are something you’re told are important when you learn about relational databases, but the effort of domain modeling usually makes most people forget all about them. That means you’ll often come across a slow project that can be improved just by adding indexes.
Rail…
DHH wrote this: Myth #2: Rails is expected to crash 400 times/day – a response to a myth about Rails processes regularly needing restarts.
I’m a big Rails hacker, it’s 90% of what I’ve done for years. I’ve designed and developed these apps: Tiktrac, Ebiwrite, Helipad, Deadline, Loom and Reuters Real Estate, this blog, not to mention work for smaller clients I …
I recently posted my top 5 uses for Capistrano over at Helicoid Insider—including juicy code snippets!
I like Capistrano a lot. It’s now doing all kinds of things to ease my workflow, from backing up servers to providing me with detailed signup statistics for each of my web apps. Whilst I’m still the only developer designing and building 4 successful web apps I need all the help I can get, so I’ve naturally cobbled together a range of software techniques to help….
I’ve just finished writing an article about how I built a single-sign on server in Rails:
Building our centralised authentication system
It was actually an incredibly rewarding experience. I’ve written up design notes, rationale and provided tips on avoiding problems.
Here’s a JavaScript snippet intended for Rails that I just posted over on my company’s technical blog. It displays the error message for each field when you click on the field, making it easier to see exactly what went wrong when saving a record.
Read it here: Dynamic Rails error help
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…
