JustinFrench.com - notebook

A Better iPhone Mute Switch

2012-01-29T21:16:00Z

Two weeks back, many of my favorite tech bloggers were covering the story of a switched-off iPhone’s alarm stopping a performance at the New York Philharmonic.

It should be smart!

John Gruber argued that this is an edge case—while Apple’s design is more complicated than simple “Off” and “Mute” switches, it’s far more likely to do what the user expects in most cases:

I think the current behavior of the iPhone mute switch is correct. [...] if the mute switch silenced everything, there’d be thousands of people oversleeping every single day because they went to bed the night before unaware that the phone was still in silent mode.

I mostly agree with this sentiment.

It should be dumb!

Andy Ihnatko argues that Apple’s design made it hard for the user to prevent the interruption:

No. I should slide the switch to “Mute,” and then the phone goes SILENT. If I miss an appointment because I did that, it’s completely on me. If my phone disrupts a performance despite the fact that I took clear and deliberate action to prevent that from happening…that’s the result of sloppy design. Or arrogant design, which is harder to forgive.

My phone is almost always switched into silent mode (usually deliberately), and I rely on the alarm to wake me every day. The interesting thing here is that I learned that this is how the iPhone works, and have now become accustomed to it. If I interrupted this performance, I’d argue that the fault was completely on me—I could have ensured that there were no active alarms, or left the phone at home.

In the case of the Philharmonic, this was a brand new iPhone, and the owner learned the hard way how it works. It’s hard not to fault Apple here, despite Apple’s overall design being much better most of the time.

Recap

Here’s the requirements I’m hearing so far:

It would suck to miss an important alarm, no matter who is at fault
It would suck to be that guy, no matter who was at fault

As Marco Arment succinctly points out:

The user has issued conflicting commands, and the iPhone can’t obey both.

What about a preference?

Dan Benjamin also argued for a dumb switch, but in a later update, raised the idea of a preference:

Know what would be really cool? Let users decide for themselves what the switch does. They could call it a “side switch” like they do on the iPad, and give us choices about what it controls.

A preference or user configuration is a pretty obvious and valid design crutch when faced with requirements that contradict each other so drastically, but in this case, I think it raises more questions:

What would the default preference be? If it defaulted to Apple’s existing behavior, the conductor was still going to get interrupted, and if it was the other way around, I would have missed quite a few important alarms by now.
As they choose their preference, would users understand the design trade-offs and spend as much time thinking about this as Apple, John, Andy, Dan, you or I have?
Would this preference still result in people being surprised and disappointed?

What else could we do?

I think Apple has solved most of the problems already with a great design – the alarm does the right thing in the majority of use cases. At this point, with millions of iPhone customers now relying on how this stuff already works, it would be a shame to either go back to something dumb or offer a preference between smart and dumb without first answering a simple question:

Given this new information, could we improve the experience by making the smart stuff smarter, instead of dumber or configrable?

I think the answer is yes! Let’s take a look at those two opposing requirements again:

It would suck to miss an important alarm, no matter who is at fault
It would suck to be that guy, no matter who was at fault

What about this: When the iPhone is in “silent” mode, all alarms start off with vibration only. After a minute or so, the audio gradually fades in, increasing to full volume over the course of another two minutes.

Most mornings, I think the vibration of my iPhone alone would be enough to wake me. If not, I’d much prefer I wake up a few minutes later than completely miss the alarm because of a dumb switch (or a dumb user!). I think this satisfies this first requirement just fine.

For the second requirement, that guy would have had 60 seconds of silent vibration in his pocket to realise something’s going on, and another 60–120 seconds before the alarm was at full volume. Not as perfect as a dumb switch, but a significant improvement.

Maybe I’ve missed something, maybe it’s already been mentioned elsewhere, maybe it’s already built and tested by Apple, but this sure is an interesting design problem I enjoyed thinking though over the weekend!

Formtastic 2.1.0.beta1 Released

2012-01-17T22:05:00Z

Putting this release together has been a lot of fun. We added Andrew Haines to the core team after a few stellar patches improving documentation and refactoring internals, and the sheer number of pull requests (from tiny documentation changes, through to epic commits) we’re seeing is absolutely fantastic.

The Formtastic 2.1.0.beta1 gem is now available on RubyGems.org, compatible with Rails 3.0.x, 3.1.x and 3.2.x (3.2.0.rc2 at the time of writing).

New Features

Added Rails 3.2 compatibility
Added a new Actions DSL (f.actions, f.action) — see below for deprecation of the Buttons DSL
Added new i18n_localizer configuration, allowing you to use your own localiser class instead of Formtastic::Localizer
Added a hidden input before mutli-selects, to allow full clearing of the select (like we do for checkboxes)
Added support for integers in a :collection for radio and check_boxes inputs
Added support for time inputs with no current value to default render blank inputs rather than pre-selecting the current time
Brought back the Form Generator from 1.2.x versions of Formtastic
Added support for placeholder text on textareas (text inputs)

Deprecations

Deprecated the Buttons DSL (f.buttons, f.commit_button) in favor of the new Actions DSL — see above
Removed the previously deprecated :label_method, :value_method & :group_label_method options
Removed the previously deprecated :as => :numeric
Removed the previously deprecated inline_errors_for and related methods
Removed the previously deprecated SemanticFormHelper and SemanticFormBuilder

Fixes

Fixed the behavior of :include_blank and :prompt options to be inline with Rails’
Fixed that :input_html => { :multiple => true } did not force a single choice select into a multi choice
Fixed date, time and datetime legend labels to correspond to the first visible input, rather than the first input (which may be hidden)
Fixed that DateInput should treat fragments excluded from :order option as discarded
Fixed that the :wrapper_html options could not be reused in the view (like in a with_options block) because they were modified by Formtastic
Fixed numerous Mongoid and MongoMapper compatibility issues
Fixed that we should be calculating the length of integer columns as bytes
Fixed many inputs (date, datetime, time, checkboxes, select & boolean) that did not correctly use the :index option in fields_for
Fixed Haml and Slim template indentation
Fixed invalid html output for nested inputs with multiple siblings
Fixed i18n keys with nested objects
Many documentation fixes and improvements
A few performance improvements

I’ll be writing more on the new Actions DSL in the future, but it closely follows the patterns of the Inputs DSL, allowing for your own custom actions (pretty buttons, different markup, different labelling, whatever you like). For the moment, there’s some basic documentation of ActionsHelper, which should feel pretty familiar.

Please test this release, please add issues to Github for any bugs WTF moments you have, and spread the word!

Sharing Todo Lists with iOS 5's Reminders app

2011-10-17T21:40:00Z

Last night I figured out that it’s possible to share your reminder lists with other iCloud users, like a Groceries list shared with my wife Kate, which we’re trying out right now.

The new Reminders app in iOS 5 leaves a lot of room for improvement, and this is a big one — there’s no indication anywhere in the iOS interface that you can share these lists, but you can!

Under the hood, the reminder lists are stored on iCloud as part of iCal’s data. On a whim, I logged into iCloud’s web interface, went to my calendar, found the Groceries reminder list, and shared it with Kate’s iCloud email address, just like we already do with some shared calendars.

So far, it works great!

Talking to Your Customers

2011-10-11T22:32:00Z

Talking to your customers is crucial to the success of your product. Call it Customer Development, User Centered Design or Market Research, just make sure you’re doing it.

It’s not hard to do

Find a customer, or a potential customer, and start talking. If you’re nervous or lack the confidence to do this one-on-one (you’re absolutely not alone), grab your product manager, designer, tech lead, CEO or anyone else in your team and do it together. Reduce the formality and ceremony over a coffee or a beer. Start over email, on the phone. Invite your most trusted customers to talk among themselves in a private email group.

Starting is far more important than how you start. I don’t need to prepare too much either – it’s pretty easy to get people to talk about themselves and their work.

What not to do

Don’t talk about features. Asking them what features they want (or letting them push the conversation that way) is a complete waste of time. There’s two predictable outcomes, both of which should be considered negatives:

You walk away with a checklist of stuff you need before they’ll buy
The customer walks away with a list of reasons not to buy your product

What to do instead

Ask them about their job, tasks, workflow, process and constraints. Ask them how they get stuff done. Ask them what they do, not what they need. The outcomes from this are far more positive:

You know if this is the sort of customer you want to help.
You build empathy for this customer.
You have a much deeper insight into the customer’s true needs.
You have real scenarios to draw upon and real problems to solve.
The customer builds a relationship with you and your product far beyond the software.
The customer talks directly with someone who can shape the product.
The customer invests time in your product, and has an interest in it’s success.

If you must talk about features, always dig deeper. Shift the conversation away from the implementation to the reasons behind it. Instead of talking about that epic reporting widget they need, talk about why they need it, and how that helps them get stuff done.

Push them to articulate the problem, rather than prescribe the solution. It’s your job as a product designer to aggregate and consider the problems from many customers and design your own solution. Yes, it’s your product, you design it.

After listening to the problem, you may already have features that can help. This is awesome! You’ve just avoided a conversation about “missing features” and showed them how your product can help them right now.

If you find a real gap in your product, don’t instantly promise a feature to fill it. Instead, promise to spend time thinking about it. Ask them if they’d mind a follow-up conversation (if this is important to them, they’ll be excited to help).

“What they do” is far more valuable and interesting than “what they want”.

Formtastic 2.0

2011-09-26T05:33:00Z

Formtastic 2.0 finally shipped over the weekend.

It’s been an epic, epic ride with contributions from 43 awesome coders. Many many thanks to Aditya Sanghi, Balazs Nagy, beawesomeinstead, Bruce Williams, Chad Ostrowski, Christoph Thiel, Corin Langosch, Corin Langosch, Daiki Ueno, DeLynn Berry, Edgars Beigarts, eugen neagoe, Gabriel Sobrinho, Ijonas Kisselbach, iscra, Jakub Okoński, Jan Schwenzien, Jason King, Joe Winter, Josh Kalderimis, Juan M. Cuello, Justin French, Kent Fenwick, Kjel Delaey, Kjel Delaey, Konstantin Shabanov, Kouhei Sutou, Lars O. Overskeid, Matt Huggins, Matt Vague, Mattias Pfeiffer, Mikael Henriksson, nashby, Nathan S, Petteri Räty, Pirogov Evgenij, Robin Stocker, Ryan Garver, smix, Thomas Walpole, Timothy Klim, Victor Stan and Wojciech Wnętrzak.

The changelog has the full details blow-by-blow, but for those with a short attention span, here’s the big tickets:

Dropped Rails 2 support
Added Rails 3.1 support, including the asset pipeline
Massive internal refactor, allowing for much simpler custom inputs
Added many new classes to DOM elements to enable more efficient and descriptive CSS
Massive refactor and simplification of the stylesheets
Massive documentation effort
Added support for HTML5 required, min, max, step, placeholder and autofocus attributes
Improved support for Mongoid and MongoMapper documents
Changed nested inputs() blocks to be automatically wrapped in an <li> tag to preserve HTML validity
Changed quick forms to skip polymorphic associations (they didn’t work)
Changed short hand forms to raise an error when trying to render an input for a polymorphic association (it didn’t work, need a collection)
Changed input() to raise an error when a :collection is not provided for a polymorphic association (we can’t guess which class to use)
Changed :label_method option to :member_label, :value_method option to :member_value, :grouped_label_method to :grouped_label (with backwards compat and deprecation warnings)

Enjoy!

Head, Heart & Hand

2011-09-13T01:11:31Z

I love TED talks. Randomly selected for my commute home this evening was How I became 100 artists by Shea Hembrey. What I love about these talks is how often I can apply these ideas and experiences to my own world.

So amongst all the criteria I have, there’s two main things. One of them, I call my Mimaw’s Test. And what that is is I imagine explaining a work of art to my grandmother in five minutes. And if I can’t explain it in five minutes, then it’s too obtuse or esoteric and it hasn’t been refined enough yet. It needs to worked on until it can speak fluently. And then my other second set of [...] criteria would be the three H’s, which is head, heart and hand. And great art would have head — it would have interesting intellectual ideas and concepts. It would have heart in that it would have passion and heart and soul. And it would have hand in that it would be greatly crafted.

This goes far beyond curating art, right? He could just as easily been describing the type of projects we love to work on, the companies we respect and the products that delight us.

Announcing Formtastic 2.0.0.rc5

2011-09-01T13:56:00Z

It’s been a long but enjoyable path from the first release candidate, but I think we’re finally here! Pending any major new issues found, this will be the final release candidate and Formtastic 2 will ship in the next week.

Here’s an extract from the CHANGELOG since 2.0.0.rc1:

2.0.0.rc5

Changed perform_browser_validations and use_required_attribute configuration defaults from true to false for a better out-of-the-box experience and upgrade path
Fixed that the novalidate attribute was being applied to the <form> tag when it shouldn’t have been (and vice-versa)
Fixed undefined method `last' for #<Classname> with a :collection containing an array of arrays

2.0.0.rc4

Fixed that TimeInput was not rendering hidden y/m/d inputs by default.
Fixed test suite under Rails 3.1.0.rc5
Fixed false and blank fragment labels on date/time inputs producing unsafe HTML.
Fixed that inputs were ‘required’ without considering :on => :create validations
Fixed that collections of strings in CheckBoxesInput were not being correctly checked be checked if they match the model
Fixed that the required attribute was added to the choices in a :radio or :check_boxes input, instead of just the parent input wrapper
Fixed semantic_fields_for when used with a hash-like model
Fixed that models without defined validations (even if validators_on exists) should not be considered required
Fixed min/@max@ attributes when the validation uses a Proc
Fixed that inputs should not be considered required if :allow_blank => true is set on validates_inclusion_of
Fixed that inputs should not be considered required if either :allow_blank => true, :minimum is > 0, or :within’s least value is > 0 is set on validates_length_of
Fixed a typo in the config template
Fixed semantic_fields_for to work with Rails 3 and 3.1’s method sigs, many thanks to the simple_form guys for figuring this out
Changed HTML5 step attribute to default to any instead of 1
Added CarrierWave support for to file input detection
Added a configuration perform_browser_validations to opt out of HTML5 browser validations.
Added more support for mongo documents, including MongoMapper-specific reflection capability
Added IE specific stylesheets & moved those styles out of main stylesheet, include them yourself if needed
Added a new configuration to opt out of HTML5 required attribute

2.0.0.rc3

Fixed that .label class was incorrectly applied to <label> tags inside a .choice on radio and checkbox inputs

2.0.0.rc2

Fixed install instructions in README to reflect 2.0.0.rc1
Fixed that the checkbox was mistakenly placed after the label text in BooleanInput, not before it as per 1.x
Fixed that select inputs had two blank options at the top in some cases
Added documentation for Timeish inputs (date, datetime, time)

With Rails 3.1 freshly released, now is a great time to help ensure this is a solid release.

Announcing Formtastic 2.0.0.rc1

2011-06-09T11:22:00Z

I’ve just pushed Formtastic 2.0.0.rc1 up to Ruby Gems including a massive 493 commits made by 26 contributors. I’ll start with the highlights, then work down to the details.

A massive refactor

My major goal was a long overdue internal refactor of the code to suit it’s current requirements. We’ve come a long way from a couple of helper methods.

drop Rails 2.x support and the many work-arounds we had in place to support it
pay down massive debt in the code base
make the code more approachable for contributors
make the code easier to document
make the code easier to override and customise

We’ve definitely acheived this (I started to recieve pull requests rather than bug reports almost imediately after I merged in my work), and I’m now proud of most corners of the code base. The giant monster formtastic.rb has been broken down into around 40 classes and modules with much smaller methods. It’s generally Good Ruby™, with room for improvement of course.

A massive documentation effort

By breaking up the code, it became way easier to document, so I poured more hours than I care to admit into Yard documentation which you can see on rdoc.info/github/justinfrench/formtastic. Have a read, send pull requests, make it ever better!

Custom inputs

Another benefit of breaking up the code into smaller classes, modules and methods is that it’s now ridiculosly easy to modify the inputs to suit your needs, or make your own custom inouts with plain old Ruby. For more detail, see Formtastic 2 Preview: Custom Inputs from back in April.

Rails 3.1 support, including the asset pipeline

Rails threw us a bit of a curve ball with Rails 3.1 mid-refactor, but the transition was pretty smooth. There’s one known issue with semantic_form_for (see below for a longer description and a work-around if it affects you) which I’m still looking into, with a second RC to follow as soon as possible.

Cleaner, leaner, descriptive CSS

A lot has changed since I cobbled together the first version of formtastic.css as a proof of concept. I no longer believe in ultra specific selectors, I prefer styling by class names instead of elements, and I like finding ways for my CSS to be more expressive and composable. The result for Formtastic is that the CSS is now about 40% of it’s original size, much easier to work with and hooks into a bunch of new classes I’ve added to the generated HTML. You also won’t find yourself fighting a specificity war to override something.

Other additions

Added support for HTML5 required attribute on <input>, <select> and ≤textarea> tags
Added support for HTML5 min, max and step attributes on NumericInput (aka NumberInput)
Added support for HTML5 placeholder attributes on “stringish” inputs (string, email, phone, url, search, number, password)
Added support for HTML5 autofocus attribute
Added support for a Method object in :member_label/@:member_value@ (aka :label_method/@:value_method@)
Added improved support for Mongoid documents
Added many new HTML classes to DOM elements to enable more efficient and descriptive CSS
Added targetted IE6 and IE7 stylesheets for specific fixes if needed (uncomplicates formtastic.css)

Other changes

Changed Formtastic::SemanticFormHelper to Formtastic::Helpers::FormHelper (SemanticFormHelper still exists as a module which includes the new module, need to handle deprecation notices somehow)
Changed Formtastic::SemanticFormBuilder to Formtastic::FormBuilder (SemanticFormBuilder still exists as a subclass, need to handle deprecation notices somehow)
Changed the HTML id attribute used for hidden inputs to be consistent with all other inputs
Changed form generator include the wrapping semantic_form_for block
Changed nested inputs() blocks to be automatically wrapped in an <li> tag to preserve HTML validity without extra mark-up in the form DSL
Changed quick forms (f.inputs without args) to skip over polymorphic associations (they didn’t work)
Changed short hand forms (f.inputs(:att, :att, :att)) to raise an error when trying to render an input for a polymorphic association (it didn’t work, need a :collection)
Changed input() to raise an error when a :collection is not provided for a polymorphic association (we can’t guess which class to use)
Changed :label_method option to :member_label (with backwards compatibility and deprecation warnings)
Changed :value_method option to :member_value (with backwards compatibility and deprecation warnings)
Changed :grouped_label_method option to :grouped_label (with backwards compatibility and deprecation warnings)
Changed Rails dependency to ~3.1 allow Rails 3.1, 3.2, etc
Changed install generator to copy a form partial into lib/templates/, overriding the standard form scaffold like Simple Form does (removed formtastic:form generator)
Changed NumericInput to NumberInput (:as => :number) to align with the new HTML5 number input type

Other fixes

Fixed visual/spacing consistency on checkboxes and radio buttons
Fixed CSS compatibility and visual consistency in IE7, fixed/added support for IE6 by removing > selectors
Fixed that overly specific CSS rules weren’t applied to nested form elements properly

Stuff we burned

Removed formtastic_stylesheet_link_tag (use stylesheet_link_tag("formtastic"), or use asset pipeline)
Removed the inline_order configuration option (use custom inputs or redefine the input_wrapping method instead)
Removed our custom implementation of f.label() helper
Removed semantic_remote_form_for etc, the remote form helpers are gone in Rails 3
Removed some overly eager CSS resets on form elements that made Opera and Firefox inputs look pretty ugly
Removed specificity and duplication in CSS
Removed formtastic:form generator (we override scaffolding generator form template, see above)

Known issues

Rails 3.1 introduced some incompatibilities on the fields_for API (which is wrapped by semantic_fields_for) see this Rails issue and this Formtastic issue for the work-around
SemanticFormBuilder and SemanticFormHelper have been renamed, but not much has been done about deprecation warnings to get folks migrating
Folks who subclassed SemanticFormBuilder and created their own custom inputs as methods will be in for some pain
No documentation on upgrading yet (help!)

A call to action

Create a branch in your app today. Bundle in 2.0.0.rc1 and spin up your app, have a click around, run your test suite, pay attention to any deprecations and create issues on Github for anything broken, surprising, unexpected or frustrating. Tweet @formtastic if you’re happy!

If you’re keen, keep an eye out for issues and send pull requests.

Rails 3.1 could be final two weeks from now, and I’d love to ship a solid release on the same day.

Updates…

2.0.0.rc2

Fixed install instructions in readme to reflect 2.0.0.rc1
Fixed that the checkbox was mistakenly placed after the label text in BooleanInput, not before it as per 1.x (#591)
Fixed that select inputs had two “blank” options at the top in some cases (#590)
Added documentation for Timeish inputs (date, datetime, time) (#589)

2.0.0.rc3

Fixed that .label class was incorrectly applied to tags inside a .choice on radio and checkbox inputs (#599)

Formtastic 1.2.4

2011-05-31T22:07:00Z

This isn’t the big 2.0 refactor release, but I’ve just pushed Formtastic 1.2.4 up to RubyGems. It contains a bunch of small bug fixes and improvements over the past few months.

If you’ve been using 1.2.4.beta2, this release is identical. If you’ve been rolling with 1.2.3, there’s no changes that should prevent you from upgrading.

This release should be compatible with Rails 2 and Rails 3, although we’re focusing most of our Rails 3.1 work in the master branch for Formtastic 2.

Speaking of Formtastic 2, we’re aiming to ship a release candidate this week! Bundle in from master direct with the :git option if you want to try it out before then.

Changelog from 1.2.3–1.2.4:

Changed :boolean inputs to use Rails’ check_box_checked? instead of our own logic (addresses many bugs)
Fixed :boolean inputs to disable the included hidden input when disabling the visible checkbox
Fixed that Formtastic was making changes to the options hash directly instead of on a duplicate, causing problems for those trying to reuse options on multiple inputs in the view
Fixed that tiny scroll bars were appearing on legends in date/time/radio/cbheckboxes fielsets
Fixed an issue when Formtastic fails to determine if a checkbox is checked with custom checked and unchecked values
Fixed that the hidden input rendered with a boolean checkbox did nt use the custom :name from :input_html options hash if provided
Fixed CSS/Firefox issue where Firefox 4 gave focus to the <li> wrapper, requiring the user to press tab twice to jump between inputs
Improved compatibility with Mongoid Documents
Updated i18n dependency to ~> 0.4

Announcing Nestive – Better Nested Layouts for Rails

2011-05-26T23:17:00Z

Last night at the monthly Melbourne Ruby meet-up I gave a quick presentation on Nested Layouts (aka Inheritable Layouts, Extensible Layouts, etc). I stepped through a bunch of the options, plugins and strategies available today, then finally showed off a new plugin I’ve been working on called Nestive.

Nestive is a partial answer to two things that have been really bugging me:

The current Rails best practice for nested layouts, as described in the Rails Guides is utterly flawed for anything except the most basic examples
I’ve had serious framework envy ever since Jeff Croft’s Django Templates: The Power of Inheritance was published back in 2006

We’re going to have trouble replicating Django’s DSL in ERB/ActionView (with keywords like `block` and `super`), but I think I’ve come up with a pretty tidy DSL involving just four simple methods.

area (declare an area in the layout, similar to yield)
extend (tell your layout or view to extend/inherit the another layout)
append (similar to content_for, add stuff onto an area)
prepend (the opposite of append, duh)
replace (set completely new content for an area)

You can read about all this in much more detail with a bunch of examples in the Nestive README on GitHub, or download the slides from my presentation (sorry there’s no presenter notes).

Right now, I’d love help from the community validating the entire concept. Try it out in a small project or a small part of a big project (it doesn’t mess with any of the Rails internals), try it with Haml, report issues, give me feedback on the DSL, etc.

I’m also wondering if it could be wired into Sinatra and other Ruby frameworks, and how it will impact things like Rails 3.1’s content streaming.

Fork it, patch it, break it, create issues, help me write some tests!

Formtastic 2 Preview: Custom Inputs

2011-04-06T21:28:05Z

I’ve been pouring more hours than I care to admit into a massive refactor of Formtastic. I’m really happy with where it’s headed, so it’s time to share some of the goodies!

Custom inputs (the ability to define your own input type) has been on my list since day one, and the refactor has made it really easy. Each input is now handled by it’s own class, which obviously lets us take advantage of things like class inheritance and composition with modules.

Under the hood, when you render an input with something like this:

  <%= f.input :title, :as => :number %>

We’re creating a new instance of the Formtastic::Inputs::NumberInput class and calling #to_html on it. That class looks something like this:

  class NumberInput 
    include Base
    include Base::Stringish
    def to_html
      input_wrapping do
        label_html <<
        builder.number_field(method, input_html_options)
      end
    end
    def input_html_options
      {
        :min => validation_min,
        :max => validation_max,
        :step => validation_integer_only? ? 1 : nil 
      }.merge(super)
    end
  end

Most of the heavy lifting is done in the included modules. This class is only concerned with the things that are different about a number input compared to other “stringish” inputs like SearchInput, PhoneInput, EmailInput and of course StringInput.

In this case, we’ve added default min, max and step attributes for the <input> tag, and implemented #to_html, which calls Rails’ number_field helper. It could (and probably will) be abstracted even further before I’m done, but for now it’s all about the vibe of the thing.

Here’s the cool bit. Before instantiating Formtastic::Inputs::NumberInput, we try to instantiate a top-level class NumberInput. This means you can create a NumberInput class in app/inputs/number_input.rb, inherit from Formtastic::Inputs::NumberInput and make any modifications you want to the class. Under the hood, there’s about 55 methods available on NumberInput which you can override, but you could ultimately do anything you want by overriding #to_html:

  class NumberInput < Formtastic::Inputs::NumberInput
    def to_html
      "Return whatever HTML string you want, however you want."
    end
  end

A more likely and less dramatic scenario might be to add a special class to the <li> wrapper tag, ditch those new HTML5 min, max & @step attributes and use a text input instead of the HTML5 number input. Easy:

  class NumberInput < Formtastic::Inputs::NumberInput
    def to_html
      input_wrapping do
        label_html <<
        builder.text_field(method, input_html_options)
      end
    end
    def input_html_options
      super.reject { |k, v| [:min, :max, :step].include?(k) }
    end
    def wrapper_html_options
      super.merge(:class => "#{super[:class]} special-class" )
    end
  end

Thank you, Ruby!

Maybe you want to alter EmailInput so that it always includes some fluffy hint text about privacy, and maybe some placeholder text. In other words, you want to define what your app needs from an email input, so that you don’t have to repeat yourself all over the app. Easy:

  class EmailInput < Formtastic::Inputs::EmailInput
    def hint_text
      "Trust us, we never send spam and never share your email address with others."
    end
    def placeholder_text
      "you@yours.com"
    end
  end

Here’s the awesome bit. You can create your own custom inputs in the same way. Here’s a few ideas:

subclass NumberInput to create an AgeInput
subclass StringInput to create a jQuery DatepickerInput
redefine DateTimeInput to be way less complicated than it is right now (perhaps as a HTML5 date picker with Javascript fallback?)

This stuff is in the master branch on Github right now. If you’ve got a little app in development, now would be a great time to take it for a spin and give me some feedback — simply bundle Formtastic from the master branch directly with the :git option, have a play, then switch back to the gem.

Perhaps now is a great time to shamelessly plug the Pledgie campaign? I’m doing this for myself, but it’d be great to know I’m also doing it for you, your boss or your clients as well.

Formtastic 2 will drop Rails 2 support

2011-01-12T21:04:29Z

It’s time. I’m getting pretty excited about getting stuck into Formtastic 2.0, and the first step is to free us from the baggage — a bunch of code, documentation and limitations that will slow us down.

Last night I branched off master and got to work in the kill-off-rails-2 branch which I just pushed up to Github.

I’m going to merge this into master really soon, so the edge is about to get bumpy. If you’re bundling Formtastic directly from the master branch using the :git option, now would be a really great time to switch to the 1.2-stable branch (or any known stable commit) using the :branch option.

If you want to help out, please test this new branch against your application by temporarily bundling it in with the :git and :branch options. In particular, it’d be nice to know that the more complex parts of Formtastic (like nested attributes) still work as expected.

If you spot any unnecessary code or tests that can now be removed or refactored, let me know or send a patch!

For those still working with Rails 2 apps (myself included), Formtastic 1.x will be maintained for bug fixes and minor refinements for a while yet in the 1.2-stable branch.

Now would be a great time to make sure you’re bundling or requiring the appropriate version of Formtastic in your application to avoid nasty surprises when beta releases or incompatible versions start shifting!

Silencing Deprecation Warnings in Rspec

2011-01-10T19:48:10Z

If you’re testing the behavior of deprecated code in your Ruby project, the warning messages littered throughout your spec output is incredibly noisy.

You could silence all warnings with ::ActiveSupport::Deprecation.silenced = true, but you might miss out on an important warning in one of your dependencies. It’s tempting to remove the tests altogether (the code will be burned soon too, right?), but I figured out something a little nicer a little while back in Formtastic’s test suite.

Throw this code in spec/support/deprecations.rb:

def with_deprecation_silenced(&block)
  previous_setting = ::ActiveSupport::Deprecation.silenced
  ::ActiveSupport::Deprecation.silenced = true
  yield
  ::ActiveSupport::Deprecation.silenced = previous_setting
end

You can then wrap that block around almost any part of your test suite to temporarily turn off the deprecation warnings. Here’s an example:

describe '#bah' do
  with_deprecation_silenced do
    it 'should be deprecated' do
      ::ActiveSupport::Deprecation.should_receive(:warn).any_number_of_times
      Foo.new.bah
    end
    it 'should return true' do
      Foo.new.bah.should be_true
    end
  end
end

Better still, I recently discovered that ActiveSupport already has method for this, but it’s currently hidden in the Rails documentation (it’ll be fixed in next stable release). So I can change my code to something like this:

def with_deprecation_silenced(&block)
  ::ActiveSupport::Deprecation.silence do
    yield
  end
end

Alternatively, we could just use the ActiveSupport method directly in our tests:

describe '#bah' do
  ::ActiveSupport::Deprecation.silence do
    it 'should be deprecated' do
      ::ActiveSupport::Deprecation.should_receive(:warn).any_number_of_times
      Foo.new.bah
    end
    it 'should return true' do
      Foo.new.bah.should be_true
    end
  end
end

The (lesser) alternative would be to roll your own in RSpec’s before and after blocks:

describe '#bah' do 
  before do
    @old_silence_config = ::ActiveSupport::Deprecation.silenced
    ::ActiveSupport::Deprecation.silenced = true
  end
  #...
  after do
    ::ActiveSupport::Deprecation.silenced = @old_silence_config
  end
end

This is one of the many simple reasons why I love Ruby’s blocks!

Formtastic 1.2.0

2010-11-13T06:55:07Z

I’m really excited to announce the 1.2.0 release of Formtastic. As usual, this was a massive team effort with help from nearly 20 contributors. My thanks to everyone for their help, especially new contributors like Aditya Sanghi, who powered through 29 commits, including a bunch of new HTML5 inputs.

Upgrading

Don’t forget to (re-)run the installation generator to make sure you have an up-to-date formtastic.css with many fixes and improvements.

  # Rails 3:
  $ rails generate formtastic:install 
  # Or Rails 2:
  $ ./script/generate formtastic

New Stuff

Added support for Paperclip’s questionable use of multiple error keys on a single attribute, so errors on Paperclip :file inputs Just Work™
Added ability for the error and hint class to be overridden with :hint_class and :error_class, and configurable defaults app-wide
Added basic support for multiple forms in the same document by allowing the element ids to be prefixed with the :namespace option on semantic_form_for
Added a fallback to Rails’ helpers.label key if Formtastic label translation are not found
Added support for default_text_area_width
Added support for #persisted? over #new_record? (ActiveModel)
Added the ‘required’ logic to attributes with validates_inclusion_of validation, in addition to validates_presence_of
Added new HTML5 :as => :email input (Rails 3)
Added new HTML5 :as => :phone input (Rails 3)
Added new HTML5 :as => :search input (Rails 3)
Added new HTML5 :as => :url input (Rails 3)
Added the ability for the :collection option to accept a string of HTML (like the output from grouped_options_for_select), rather than just Arrays, Hashes, collections, etc.
Added the ability to set your own form class, instead of ‘formtastic’
Added maxlength attributes to inputs if it can be determined via the ValidationReflection plugin or ActiveModel validation reflections
Added the ability to override the form class (Post => “post”) through an :as option on semantic_form_for
Added the ability to customize the order for specific types of inputs. This is configured on a type basis and if a type is not found it will fall back to the default order as defined by the inline_order config
Added :first as a new rendering choice for the errors on each input
Added custom_inline_order to allow inline ordering per input type
Added the ability to override the generator templates in Rails 3
Added :wrapper_html functionality to commit_button() to match what input() does

Fixes

Fixed invalid HTML generated by Rails’ hidden inputs on checkboxes (by rendering our own hidden tag in a more deliberate place)
Fixed a bunch of invalid i18n key defaults
Fixed that ‘required’ classes and logic were not being applied to :check_boxes and :radio inputs
Fixed CSS bugs around Firefox’s quirks with form elements that resulted in overflow/scroll bar issues
Fixed that errors on fields with association were not marking the wrapping tag with the error class
Fixed CSS where FF was displaying extra scroll bars on .check_boxes and .radio inputs (and the choices within them)

Changes

Changed that we were defaulting to a :select input for columns ending in _id, instead of columns with an appropriate associations
Changed the width styling for :text, :string, :numeric, :password and other basic inputs, defaults to 75% unless the size or cols attribute is present
Changed :string, :numeric, :password and other basic inputs’ default text field size config to nil instead of 50, meaning the size attribute will be ommitted from most inputs, makeing styling easier, and custom sizes with the size attribute more deliberate
Changed :string, :numeric, :password and other basic inputs to no longer add the size attribute based on column information (the default config is applied, unless it’s nil)
Changed :text input css behaviour updated to be similar to string etc
Changed :text inputs to no longer include a default cols attribute, specify it with :input_html if you need it, but the value we were using was useless
Removed :label calls from the generated ERB in the form generator (i18n is preferred)
Changed that :select inputs for HABTM associations would ignore the :include_blank option
Changed the default method on collections from Model.find(:all) to Model.all
Removed the deprecated formtastic_stylesheets generator
Changed the minimum Rails version to 2.3.7, which the earliest version which the specs pass with
Changed :password inputs to be sized by percentage (like other string-ish inputs), rather then em-based

Deprecations

Deprecated the :class option on commit_button(), use :wrapper_html => { :class => 'foo' } instead
Deprecated a bunch of aliased method names that should no longer be used
Removed :selected, :checked and :default options deprecated in earlier releases

Activo + Formtastic

2010-10-19T10:21:15Z

I’m thrilled to see this live demo of Activo by David Francisco including support for Formtastic, proving that you can style Formtastic’s markup to achieve great looking forms that look quite different to the basic ones I supply, all using the same mark-up, relying on the same tags, classes and element ids as everyone else.

If you’re working on a web app with Formtastic (come on, there are thousands of you!), I’d love to see how far you’ve pushed the markup with your own styles and scripting. Tweet me!

CSS3's :not Selector

2010-09-24T07:04:00Z

I’ve been experimenting with some of the new CSS3 selectors, admiring IE9’s new selector support (finally!) and tinkering with JavaScript libraries like Selectivizr and IE7.js to see if they can help drag older versions of IE into the future kicking and screaming.

The :not selector helped me solve a pretty common problem today. We had a pretty standard unordered list, and we wanted to place a one pixel border in between each list item. Let’s start with the unsurprising mark-up:

  <ul>
    <li>Cats</li>
    <li>Dogs</li>
    <li>Mice</li>
  </ul>

A common solution is to place a border-bottom on each <li>:

  ul li {
    border-bottom: 1px solid #ccc;
  }

This doesn’t just place a border between each list item of course, it also adds a border after the last item. Something like this:

Sometimes this isn’t what I want, but I have options. I can use the :last-child pseudo selector to remove the border on the last list item:

  ul li {
    border-bottom: 1px solid #ccc;
  }
  ul li:last-child {
    border-bottom:none;
  }

IE6 doesn’t support this selector, so IE6 users will end up seeing that last border. Graceful degradation for the win, right? Sometimes this is acceptable, sometimes it isn’t. In some designs, I can work around this by repeating the same border on the top, left and right borders of the <ul>, creating a border the whole way around the list.

  ul {
    border:1px solid #ccc;
    border-bottom:none;
  }
  ul li {
    border-bottom: 1px solid #ccc;
  }

Which results in something like this:

If that’s not going to work in the design, the next crutch I usually reach for is adding a last class to the last item in the list that I can hook into to remove the bottom border in all browsers:

  ul li {
    border-bottom: 1px solid #ccc;
  }
  ul li.last {
    border-bottom: none;
  }

This bugs me for a few reasons:

We’ve added markup to the page purely for presentational reasons.
I like writing code that’s easy for my co-workers to read and understand. In this case, we had to describe the one presentational goal (“put a border in between the list items”) with two rules. This means the reader needs to consider both rules before they can understand what the styles are trying to do. This may seem trivial, but this is a riciculously simple example — real world examples would probably have margins, padding, typography and hover styles adding noise.
It’s code that’s looking backwards instead of forwards. We’re cluttering everything up to support an older browser which still a big deal for some websites.

This is where :not can help us! Here’s what I came up with:

  ul li:not(:last-child) {
    border-bottom: 1px solid #ccc;
  }

Bam! That’s one simple rule that describes the visual treatment perfectly. No extra markup, no extra styles. Here’s what it looks like in IE9 and all other modern browsers:

Perfect! The trade-off, of course, is that older browsers like IE 6, 7 and 8 don’t understand :not (or :last-child for that matter). How did I decide that this was an acceptable trade-off?

We have a eight of developers, all contributing in the view layer, but only a few of us spend time really testing the interface in all the browsers, and even fewer would spot that extra border on the bottom list item and realize that something wasn’t quite right.
In the design we were working on, the list looked horrible in IE6 with that extra line — It wasn’t a gracefull degradation, it was an ugly line in the wrong place screwing up my design. We have a heap of IE6 users still, so this matters.
The list actually looked pretty good in IE 6/7/8 without the borders.
Less markup and less CSS means there’s less chance of screwing things up, and it just feels wrong to write extra markup or CSS to deal with a browser that was released nearly ten years ago.

So, for this particular design, with this team, with this set of users, with this web app, it turns out that progressive enhancement with a modern browser feature worked better than graceful degradation for an older browser. It might work for you too.

You can have your cake and eat it too! The really great news is that if you add-in something like Selectivizr with an IE-ony conditional comment, most of your IE6/7/8 users can also come to the party with an 8kb Javascript download.

I feel like I’m just scratching the surface with the :not selector. If you have some ideas how it can be used to enhance a design, or know of similar tutorials I should be reading and linking to, let me know on Twitter.

Formtastic 1.1 Ships with Rails 3 (and 2) Compatibility

2010-09-08T06:11:00Z

I’m very pleased to announce that I finally pulled the lever a few minutes ago, pushing up Formtastic 1.1 to RubyGems.org, compatible with both Rails 2 and Rails 3.

My thanks go to every one who contributed patches and actively tested our work.

Special thanks to Morton Jonuschat and Gabriel Sobrinho for their hard work managing this entire process. Between them, they’ve made 113 commits (and signed off many more from the community), making them the 2nd and 5th highest contributors to the project in a just a few short months.

I was able to focus on the 1.0 release, while they quietly worked away in the rails3 branch. It was such a pleasure to be able to just use Formtastic on my Rails 3 projects, rather than have to build it.

There were no code changes between the 1.1.0.beta and today’s release (only documentation changes), so this will be a pain-free upgrade for those running the betas.

If you’re upgrading from 1.0 or earlier, there’s been over 140 significant changes to the code in order to support both Rails 2 and Rails 3, but these were internal changes only — there should be no changes to the API or functionality. Run your tests, check how things are working for yourself, of course.

We’ve had had two major forks in the code for a while (master for 1.0.x and master for 1.1.0), but this will soon change. There’s a 1.0-stable branch for any maintenance work we need to do, and rails3 will be merged into master in a few days.

We’ll be doing some housekeeping for a bit, then jumping into new features and some deprecations for a 1.2 release as soon as possible.

Readme Driven Development

2010-08-23T23:49:20Z

In Readme Driven Development, Tom Preston-Werner advocates writing the README file before any code is written, and indeed, before any tests are written.

I couldn’t agree more. This is exactly what I did with Formtastic. I designed the DSL and how I thought programmers should build forms long before I wrote any code.

I think this has had a huge impact on the success of Formtastic so far. People may dislike the underlying mark-up choices I made, or the underlying code implementation (which definitely needs some TLC), or the lack of in-depth documentation, but for the most part, people love the DSL.

José Valim even proudly choose to replicate the Formtastic DSL in simple_form his own form builder for Plataformatec.

What Tom is really advocating is a small amount of up front design to figure out how people will use your software in order to give it vision and clarity before you start pumping out code. A README file is cheap. Code is relatively expensive.

Here’s a quote from 37 Signals’ Interface First in Getting Real:

We start with the interface so we can see how the app looks and feels from the beginning. It’s constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you’re dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.

It’s ridiculously easy to draw comparisons here. Design your library’s interface first!

Formtastic 1.0 Release

2010-08-11T23:32:02Z

After promising we’re “deliciously close to a 1.0” for about a year, this has been a long time coming.

Formtastic 1.0 is compatible with Rails 2.x. For those of you working with Rails 3, there’s a rails3 branch (aiming to be compatible with both Rails 2.x and 3.x) on Github, and we hope to ship a 1.1.0.beta gem in the next week or so from this branch.

From here on, I’d like to adhere Semantic Versioning.

If you haven’t been playing with the betas and release candidates (shame on you!), here’s a quick re-cap of what’s changed since 0.9.10:

Fixed that :label=>false didn’t disable the label on checkboxes & radio buttons
Added full support of :input_html options for hidden fields
Fixed that :checked_value and :unchecked_value options were being passed down into the HTML tags as attributes
ensure i18n < 0.4 is listed as a dependency in the gemspec
Added :ignore_date option to time inputs
Fixed some issues with the default error proc
Added default escaping of html entities in labels and hints
Added/fixed that :value_method and :label_method were being ignored for simple collections (like an Array)
Added some more compatibility for Mongoid and other ORMs by checking for reflection information before calling it
Fixed deprecation warnings in Rails 2.3.6 and newer
Fixed a bug where :check_boxes and :radio inputs were using the attribute name instead of the :label option
Fixed a conflict where i18n lookups were failing when an attribute and model have the same name
Fixed :radio and :check_boxes inputs so that the legend no longer includes a <label> with a for attribute pointing to an input that doesn’t exist
Fixed that some inputs had invalid find_options HTML attribute
Fixed that we were calling html_safe! when it was not always available
Added the ability for :input_html to now accept an option of :size => nil, to exclude the :size attribute altogether

The really exciting thing for me is that there’s been over 60 contributors to the project. Tools like Github make this easier, but real people donating their time actually makes it work.

The community is almost entirely responsible for the rails3 branch too — I started using it for the first time on a new project last month and it was so great to see how far along we are, and most importantly, how little I had to do myself to make it happen.

So, thank you all for the support, the bug reports, the patches, the testing, the polishing, the feature requests, the rants, the complaining, the praise, the promotion, the donations and the awesomeness.

Pagination Alternatives

2010-07-28T21:58:00Z

Last night on Twitter, the very awesome Daniel Neighman casually asked if any of his followers had experience with Rails 3 and the will_paginate plugin. In true Twitter fashion, I replied with an overly simplified and entirely unhelpful “pagination makes baby dolphins cry”. Dan politely asked “what else should be used?” and Ben Schwarz went all out.

It’s not really about finding a better pattern, it’s about finding the right pattern. Pagination is one of those ubiquitous things on the web. It’s easy to see a pattern like that, apply it to your own “I have too much data to show on one page” problem and take the quick win. Everyone else is doing it, it’s a pattern, you should use it too, right?

Pagination really only has two things going for it:

It’s ubiquitous. Everyone’s seen it before, everyone knows how it works.
It’s a quick win. Too much data? Paginate it!

There’s a lot not to like:

It’s usually presented as an busy set of tiny little links for moving back and forth through the pages, and a series of other tiny links to jump to some (but usually not all) the pages in the set.
It’s an interface that’s optimised for use with a mouse. Mouses suck, especially when aiming for tiny targets placed closely next to each other. Easier navigation systems like scroll wheels, keyboard shortcuts, track pads and touch gestures are typically ignored by pagination interfaces.
Other sites and search engines will link to “page 4” of your result set, but the specific items will shift to an adjacent page as new items are added.
Search engines can penalise your site and ignore many of your pages because you haven’t spent enough time making each page in the set appear different enough.

There’s almost always an alternative design pattern you can lean on if you take a few minutes to think it through. Here’s some questions you can ask yourself and some ideas you might consider before implementing pagination:

Can you render more items per page, or all of them?

Pagination has a history on the web dating back to dial-up connections and 14k modems. Those days are long behind us, even in the mobile space. Why are we still rendering 10, 20 or 50 items on a page like it’s 1996? What would happen if you just rendered a page with more items? What if you rendered all the items?

For example, I recently took a look at my own archive for this website. I changed from 20 items per page to 500, and ensured that the pagination links are only rendered if needed. I have around 200 posts, so the pagination has effectively been removed for now. The resulting page with all 200 posts is around 85k. It took me six years to write those posts, so it’ll take me a few more to write another 100, at which point the page size might be 150–200k.

A few years is a long time on the internet. Bandwidth may triple. I might redesign the entire site and change it’s structure. Anything is possible. This kind of context matters — don’t invent a pagination requirement if there isn’t one.

How big will your dataset be next week? How about next year? What’s an acceptable page download for your target audience? Can you just render everything and revisit this problem later (when it’s actually a problem)?

Can you limit the number of items?

Let’s say you have thousands or even hundreds of thousands of results, like a Google search. Obviously you can’t just send all that down to the browser in one hit. The browser would explode with that many DOM elements and your database is already crying just thinking about it.

I’ve never looked at the 48th page of Google results. I rarely look at the second page and sometimes I don’t even scroll down past the first few results. A search engine is all about relevance, so the second page of results is almost irrelevant by definition, right?

Take a look at your server logs or analytics data. Watch people using your software. Understand what they do. If they aren’t clicking beyond the first page you might be able to ditch everything else, limiting the results and negating pagination. If your users aren’t looking beyond page three or page five, experiment with rendering more stuff on the first page and ditching everything else!

Can you find another way to break up the content?

If there’s too many items to render all at once, and it doesn’t make sense to limit the items rendered, try finding another more meaningful way to break up the items into multiple pages. Pagination is the lazy way, giving your users (and search engines) a fragmented view of your content.

Think about what your users are really trying to do. They don’t enjoy clicking though page after page of stuff looking for something specific in a series of non-specific pages. If you can find a more specific and meaningful way to break up the data, you’ll improve the user experience, you’ll improve your search ranking and you’ll have smaller sets of data to deal with. Smaller data sets give you more design options and reduce the need for pagination!

A chronological list of thousands of events in an activity log is a good example this. If the most important events are the recent ones, then breaking things up into groups like “today”, “this week”, “this month”, “this year”, “2009” and “2008” might work. Sure, you’ll probably still need pagination on the items in the bigger sets, but you should be able to avoid it for the more common use cases like “what happened this week?”.

If you’re working on a financial application, the groups could be relevant to accounting, like “this month”, “last month”, “this quarter”, “last quarter”, “this fiscal year”, “last fiscal year”, etc.

Let’s also keep in mind that lots of data is chronological, but most chronological data isn’t only chronological.

For example, many blog archives are broken down into years and months. If I’m trying to find something on your blog, I’m not going to remember that you wrote it in early June 2009, so a page containing all your posts from that month is kind of useless to me. I’m going to remember that it was related a topic like ruby, karate or bacon. Despite the chronological nature of a blog, it still makes much more sense to me to break up the content by topic (tags, keywords, categories, whatever), resulting in smaller data sets that can probably be rendered without pagination.

Can you implement an endless page?

If all else fails, consider implementing an endless page like the one found in Google Reader and many other modern web applications. When you load the reader, a limited number of articles are rendered on the screen by default. Let’s say it’s 100 articles, enough to fill the screen. As you scroll down the page, more results are added to the page dynamically through an AJAX request. Keep scrolling down, keep seeing more and more articles.

Technically, this is still pagination under the hood, but the end user never sees the pagination interface’s awkward cluster of tiny links.

You may have noticed Twitter also does something similar. You have to click a giant “more” link at the bottom of the page, so it’s not quite as magical as Google Reader’s endless page, but it’s still a whole lot better than all those fiddly links and fragmented pages of related content.

Think for yourself

Pagination is still a valid design choice in the right context, but it’s just one option you should explore. Forget about the data schema, the code and the SQL queries for a few minutes and think about your what your users want to achieve. If you really have thousands of items that can’t be broken into smaller groups, and if your users really want to click through it all page-by-page in small chunks, got for it!

Your turn

What are some alternative patterns and interfaces you’ve used instead of pagination? How did you break the data down into smaller chunks? What’s an acceptable page size these days? What are some examples you’ve seen where pagination really is the right answer? Send them to @justinfrench.

Updates, Tweets, Questions and Answers

@russell tweeted:

Wondering what @justinfrench & @xshay think about ‘next’ and ‘prev’ links without the 1234567… pagination in between.

It depends! Assuming pagination is your only real choice (not convinced, but whatever), and there’s no real need for your users to jump to “page 7” in a non-linear path, then yes, get rid of those numbered links!

@grigi0 tweeted:

you are right about pagination on the searches, but maybe it is the only option on forum thread because pages are “static”

Forums are a good example that probably needs to be paged through. However, forums get over used for a bunch of very different use cases (because they’re “cheap”) — everything from endless unfocused discussion through to questions and answers on a focused topic. It’d be interesting to think about some interface alternatives based on what people really use a forum for. I’ll write a follow-up post on this I think!

@sgruhier tweeted:

If you have a geo-localized data, you can think of displaying all of them on a map

Absolutely, a map is another great example. Geographical information opens many new ways to break up the data, and you can add more data points as you zoom in on a smaller area. Countries and regions are obvious, but there’s bigger opportunities like “near me” or “near the hotel I’m staying at next week”, that can be combined with zooming in for more data.

@CorinCole tweeted his dislike of “endless pages” and Twitter’s Ajax-powered “more” button because they make it hard to directly link to something on the Nth page. This is true if a lazy developer doesn’t provide a unique URL for the “page” you’re viewing, but like I said, this is really just pagination with a slightly different UI (scrolling, or a single button). Pagination is a “if all else fails…” thing. I’m pretty sure you can do better.

Six Years of justinfrench.com

2010-07-26T10:11:23Z

At some particularly nerdy moment, I set-up an iCal reminder for the birthday of this website. A few hours from now, justinfrench.com will be 6 years old!

The first year or two was a whole lot of fun — I was experimenting a lot with web standards, pushing hard for CSS replace the crazy shit we were pulling with tables, wrestling with browsers a whole lot more than we have to now, playing with new text editors like TextMate, shifting away from PHP to languages like Ruby, and waiting for Apple to open an iTunes store in Australia. I also made the most important leap of faith in my career, closing up my freelancing business to help Dean Allen, Jason Hoffman and a bunch of other incredibly smart people build a tiny little hosting company called TextDrive.

So much has happened. TextDrive was acquired by Joyent, RedBubble lured me out of my home office and into my first Australian start-up building a massive online creative community, the guys at Clear asked me to help re-shape the Australian grain market with a trading platform, and a bunch of New Zealanders acquired Clear. I got married! We had a kid!

I pushed myself in a heap of new directions at work (from design and code to agile project management and a five month stint as interim CTO at Clear) and found out a whole lot more about what makes me tick than I ever would freelancing from my home office in the ‘burbs.

There’s a bunch of other stuff, too much to mention, half I which I never wrote about. I’m a bit down that I let this website slide. I still love the design (it’s unheard of for a blog to go so long without a redesign!), but I’ve been horribly lazy when it comes to writing about the things I’m learning every day.

There’s been a few bursts where I tried to kick-start regular writing, but something else always seems to be a bit further up on the priority list. I’d like to say things will change, but we’ll see.

Either way, it’s been amazing six years, and I feel like we’re only just getting started. I love making things, and this is a great time to be doing that.

Formtastic 1.0.0.beta Released

2010-06-07T03:54:00Z

I’ve just pushed up the first 1.0 beta gem!

Your mission

Download the beta, install it in your Rails 2.x apps, run your test suite, then reply to this thread with “all good” if your tests pass. If you encounter problems, please create issues on Github, or discuss on the Google Group.

There’s only one outstanding 1.0 issue (#246, which we’re still pondering on the solution for, so it’ll probably slip out to 1.2).

What’s changed?

Here’s the CHANGELOG entries since 0.9.10:

Fixed :radio and :check_boxes inputs so that the legend no longer includes a <label> with a for attribute pointing to an input that doesn’t exist (#253)
Fixed that some inputs had invalid find_options attribute (#262)
Fixed that we were calling html_safe! when it was not always available
Added the ability for :input_html to now accept an option of :size => nil, to exclude the :size attribute altogether (#267)

Formtastic 0.9.9 & 0.9.10 Released

2010-05-26T00:41:00Z

I was hoping that the next Formtastic release was a 1.0.beta, but the recent Rails ~~2.3.6~~ ~~2.3.7~~ 2.3.8 release spurred us to issue ~~0.9.9~~ 0.9.10 to maintain compatibility.

There were some features added and other changes made since 0.9.8 so here’s the changes:

Changed date/time inputs to default to nil instead of Time.now when the object has no value (due to deprecation warning, #240)
Changed the behaviour of associations with a :class_name option to be more consistent with what Rails expects
Fixed issues relating to Rails 2.3.6 automatically escaping ERB
Fixed issues with Ruby 1.9.1 and Haml
Added the :disabled option to check_boxes input
Added translation support for nested models (thanks to Toni Tuominen)

I’d especially like to thank yabawock for his ridiculously fast work back-porting some of the changes in our rails3 branch into master for this release. I love this community!

Update: We had to push up an 0.9.10 release to fix an i18n incompatibility with Rails 2. Embarrassing, sorry we missed it. If you’re one of the 24 people who installed 0.9.9, please grab 0.9.10!

Formtastic 0.9.8

2010-03-31T20:01:00Z

It’s been a long time between drinks, and I’m really not a fan of releasing this much stuff all at once, but Formtastic 0.9.8 is finally here.

Run ./script/generate formtastic if you want to update the stylesheets and configuration files (you have version control, right?).

There’s a heap of fixes and a few tiny new features, but the most important thing to know is that the behaviour of the :selected option has changed to address some bugs and inconsistencies, and that it’s been deprecated due to many issues you can read about in the wiki.

It’s also (still) not Rails 3 compatible, but you may want to try the formtastic-rails3 gem (based off 0.9.7) by Rodrigo Alvarez, who’s been doing a lot of work in his fork for Rails 3 compatibility.

Here’s the CHANGELOG:

Deprecated :selected/:checked options, see the wiki page
Changed CSS rules for fieldset lists to be more specific
Changed radio and checkbox inputs to no longer associate the legend label with the first choice’s input (#101)
Changed the generators to use |f| rather than |form| (#151)
Changed the behaviour of :selected/:checked options to address several bugs and inconsistencies (#152)
Changed CSS for input width property to max-width, allowing a size attribute to still be set
Fixed an issue where label_str_method not honoured if the object is an ActiveRecord object
Fixed incorrect html class for namespaced objects (”/” replaced with ”_”)
Fixed compatibility issue with SearchLogic (#155)
Fixed an issue where label_str_method was not being overridden with i18n
Fixed a button text issue with Rails 2.x in which human_name on multi-word models returned one word (eg Ticketrequest) (#153)
Fixed the behaviour of select inputs when the belongs_to or has_many association has a special :class_name option
Fixed line numbers from eval’d code, to help when debugging
Fixed CSS issue that hidden fields were not always hidden (Chrome for example) (#209)
Fixed and improved CSS with nested fieldsets and legends
Fixed date/time inputs where :include_seconds => true
Fixed that inline hints were still being rendered on hidden inputs
Fixed broken CSS declaration missing a colon
Added configuration preferences for row and column attributes on textareas
Added semantic_errors helper and CSS (for all errors on an object)
Added :filename to the list of @@file_methods, to support carrierwave plugin (#156)
Added a Formtastic::LayoutHelper with formtastic_stylesheets helper method for linking to all Formtastic CSS files
Added labels option to date/time/datetime fields to customise the label of each part of the set (year, month, etc)
Added many improvements to the README and docs

The next stop from here is a little unknown. I’m guessing a release this big might need a patch or two, but I’m considering this a 1.0 candidate. Far too many people are using this gem in production for it not to be considered a 1.0, despite all the features think should be in there.

Once we jump over that hurdle, I hope we move forward pretty quickly.

Finally, Dennis Major has been doing some amazing work in the wiki, check it out!

Getting started with automated testing in Rails

2010-03-08T04:41:00Z

After my previous post learn to test your code, you might be wondering how to get started with automated testing. Many books have been written on the topic, but I thought it might be interesting to share how I got started.

Testing in the Rails console

One of my favorite things about Rails is the console (a Ruby irb console with the Rails environment loaded into it). If you haven’t checked it out yet, go have a play. You have access to ruby, your models, the database, helpers, ActiveSupport and much more. Here’s a quick example:

$ ./script/console
Loading development environment (Rails 2.3.4)
>> "Hello World!".class
=> String
>> Post.count
=> 100
>> Post.published.last.title
=> "Hello world!"

I found I was playing around in console quite a lot when testing specific logic in my models, like validations. It was far easier to copy-and-paste a few lines of ruby over and over instead of clicking around in my browser and entering data in all those form fields.

Let’s say you want to confirm that a new Post is valid when given an expected hash attributes (that the browser would usually post from a form being submitted):

>> Post.new.valid?
=> false
>> Post.new(:title => "Hello", :body => "World", :user_id => "1").valid?
=> true

While the example may be trivial, that’s actually the point. The tests I was performing in the console were exactly what I should have been automating — small, isolated, repeatable chunks of Ruby that confirm my understanding of what the code does by using it in the same way that I intended it to be used in my application.

In this case, I’m simply confirming that a new Post without attributes is invalid, and that a new Post with a title, body and user_id is valid.

A quick introduction to unit tests

For simplicity, I’m going to stick with test/unit and whatever ships with Rails in the standard testing framework provided in Rails 2.3.x, but you should be able to adapt these to rspec, Rails 3 or whatever you like.

If you used a generator to create your Post model in the first place, you should already have a file ready for your tests, located in RAILS_ROOT/test/unit/post_test.rb:

require 'test_helper'
class PostTest < ActiveSupport::TestCase
  # Replace this with your real tests.
  test "the truth" do
    assert true
  end
end

You should be able to run your unit tests from the command line with this rake task:

$ rake test:units

A bunch of noise is printed onto the screen, but what you’re looking for is something like this:

Started
.
Finished in 0.12 seconds.
1 tests, 1 assertions, 0 failures, 0 errors

My friends, that dot is a passing test. Let’s add a failing test, to check everything is working as expected:

require 'test_helper'
class PostTest < ActiveSupport::TestCase
  test "the truth" do
    assert true
  end
  test "cats are the same as dogs" do
    assert_equal "cats", "dogs"
  end
end

Run the tests, we should see a failure:

Started
.F
Finished in 0.12 seconds.
2 tests, 2 assertions, 1 failures, 0 errors
1) Failure:
test_cats_are_the_same_as_dogs(PostTest)
[/test/unit/post_test.rb:9]:
<"cats"> expected but was
<"dogs">.

Finally, automating our tests

Let’s take a look at our console tests again:

>> Post.new.valid?
=> false
>> Post.new(:title => "Hello", :body => "World", :user_id => "1").valid?
=> true

The automated unit tests for these two are dead simple:

test "should be invalid with no attributes" do
  assert !Post.new.valid?
end    
test "should be valid with a title, body and user_id" do
  assert Post.new(:title => "Hello", :body => "World", :user_id => "1").valid?
end

Run the tests, let’s see the dots!

Started
..
Finished in 0.12 seconds.
2 tests, 2 assertions, 0 failures, 0 errors

Despite being utterly simple and trivial, those two tests document my understanding of what the software does (and should do going forward):

A Post with no attributes should be invalid.
A Post with a title, body and user_id should be valid.

When they fail, either code isn’t doing what I expect, or the test is no longer valid. I’ll adjust one of them accordingly.

And that’s how I got started

What about you? It’ll be tempting to open every model, look at every line of code and write tests for everything. That’s an incredibly ambitious plan, especially while you’re learning how to write good tests, how to structure them, etc.

Instead, start with one of your most business-critical controllers. Maybe it’s the signup process, or the home page, or the checkout. Have a look at how you’re using your models, and replicate that usage with automated tests. Start with the golden path, then add more tests for the edge cases and irregular parts.

Another way to proceed is to start by writing a test to expose any bugs you come across. Write a failing test, fix the bug, watch the test pass, commit the changes.

I’ll cover both of these (and much more) soon.

Learn how to test your code

2010-02-22T20:39:00Z

Recently, I was asked by someone new to Ruby and Rails what advice I had for them. Other than “watch all the Railscasts”, I really only have one piece of advice:

Learn how to test your software through automation.

Learning how to write good tests for my code was the single most important step I made as a developer. I can’t more strongly emphasise this.

You’ll wrestle with it at first. You’ll be perplexed by the choices in testing frameworks and distracted by the subtle differences in terminology. You’ll be frustrated that you’re writing “twice as much code” for every feature. You’ll think you can hold the whole thing in your head and catch yourself making mistakes. Your boss will complain that things are taking too long.

Push through this shit. Sometimes the pay-off isn’t obvious for weeks or even months, but it’s always there.

Your tests are your safety net. You’ll learn to lean on them, to trust them more than you trust yourself. You’ll find you’re no longer terrified by huge changes to the code base, or sudden changes in direction. You’ll see the occasional false alarm too (an “annoying” test that fails, but only exposed a bug in your testing approach).

Eventually (it’s only a matter of time), you’ll change something trivial and confidently commit to your version control system without running your tests. A few minutes later your co-workers (or even better, a continuous integration build server) will catch your mistake with a failing test. Your trivial change just busted another part of the code you weren’t thinking about.

That code you just busted will be hidden somewhere in an obscure path through your shopping cart, and your test suite has just saved your company time, money and a loss of consumer confidence.

The light bulb goes on. You get it, your boss probably gets it, but this is only the start of the journey.

Eventually you’ll forget that you used to spend hours testing your code in a browser, and start complaining that your automated tests are taking minutes to run! You’ll have intense debates with co-workers about what to test and how to test it properly. You’ll start writing the test first to expose the bug or missing feature, then write the code required to pass the test.

This is the moment you realise you care more about your tests than you do about the code.

Moving to Feedburner, please update your feed URL

2010-02-21T19:40:23Z

The new feed URL is http://feeds.feedburner.com/justinfrench. The old URLs should redirect for a while, but please update!

Nested has_many :through associations in Rails

2010-02-03T12:01:08Z

It can’t be done. You’re surprised, so am I. I spent a few hours looking tonight, Rails (2.3.5 at the time of writing) doesn’t do this. Even the rdoc says it:

You can only use a :through query through a belongs_to or has_many association on the join model.

I have no idea about Rails 3 with the Arel changes to ActiveRecord, but here’s everything else I picked up along the way:

The Bad News

There’s an old plugin by Matt Wescott which supported this around Rails 2.1 (I think)
There’s a newer plugin by Ian White on GitHub based off Matt’s, which worked with Rails 2.1–2.2 it seems, but was busted by Rails 2.3. There’s a branch for Rails 2.3, which it looks like they’re still working on (last commit December 2009). I didn’t try it.
There’s an open ticket in Rails’ Lighthouse, everyone +1s the idea, no one has written a patch, Pratik marked it as incomplete, awaiting a patch from the community. You should try to make that patch!

The Good News

There is something close, documented in Simulate Has Many Through HABTM by Alex Reisner.
It worked for me.

Google and IE6: Put the Champagne Away

2010-02-01T21:51:00Z

UXMag have just published a short post with the wonderfully luring and dramatic title Google kills IE6:

Google is officially phasing out their support for IE6. This means we can all start working on more important things rather than debugging for old and quirky browsers. I think champagne is in order!

I wish! Let’s go look at Google’s actual announcement:

So to help ensure your business can use the latest, most advanced web apps, we encourage you to update your browsers as soon as possible.

They’re dropping IE6 support for their most advanced web apps, starting with Google Docs and Google Sites. They aren’t dropping support across every Google product. You can still go to google.com in IE6 and do a search.

The decision to drop IE6 needs to be made by each business individually, based on strong business intelligence and data. Google, of all companies, knows this.

How many IE6 users—the ones that won’t or can’t upgrade to more advanced technologies—do you think actually use Google Docs (an advanced web app) in any significant way? I don’t know, but Google knows, which is why they dropped the support.

The upside to all this is that there may be a few organisations heavily invested in Google that need to upgrade. There may be a few IT departments that finally get of their ass and upgrade their work stations.

This is progress, but it’s not magic.

Testing Rails Plugin Config Preferences

2010-01-28T22:12:00Z

Time to start blogging again, I hope! Most plugins and Ruby gems have configurable preferences, and usually they’re implemented as a Module or Class attribute, something like this:

class AwesomeGem
  cattr_accessor :something
  @@something = true
end

In the case of a Rails plugin or gem, these are then modified with an initializer as Rails boots up:

AwesomeGem.something = false

Despite my best efforts to be opinionated, Formtastic has about 15 preferences today, and I can see another 10 or so on the horizon. They all need to be tested. For a while there, we had some pretty brittle tests that did this sort of stuff:

describe AwesomeGem, "something preference" do
  describe "when true" do
    it "should..." do
      AwesomeGem.something = true
      # ...
    end
  end
  describe "when false" do
    it "should..." do
      AwesomeGem.something = false
      # ...
    end
  end
end

The problem here is that we’ve changed AwesomeGem.something’s configuration from true (the default in the class) to false. Any tests that assume the default preference will fail. Maybe. Who knows. Depends on the order your tests run.

So we need to return the preference to it’s default state at the end of any tests that alter it:

it "should..." do
  AwesomeGem.something = false
  # ...
  AwesomeGem.something = true
end

This is stupid and short-sighted. Next week, someone changes the default value, and everything breaks. What you need to do is capture the value before you change it, then return it to that state at the end of the test:

it "should..." do
  old_value = AwesomeGem.something
  AwesomeGem.something = false
  # ...
  AwesomeGem.something = old_value
end

This works, but it’s shit code, especially if you’re repeating it in dozens of specs. You can DRY it up a bit by moving it to before and after blocks, but it’s a heap of noisy, ugly code. We can do better. How about wrapping the above pattern up in a block that temporarily changes the configuration, like this:

it "should..." do
  with_config :something, false do
    # ...
  end
end

Here’s the implementation, throw it in your spec_helper.rb file:

def with_config(preference_name, temporary_value, &block)
  old_value = AwesomeGem.send(preference_name)
  AwesomeGem.send(:"#{preference_name}=", temporary_value)
  yield
  AwesomeGem.send(:"#{preference_name}=", old_value)
end

Enjoy!

Formtastic 0.9.7 Released (Updated)

2009-12-02T21:06:00Z

Another bunch of really nice improvements and fixes have been added to the latest Formtastic gem:

:selected option now works on all select, radio, check_box and date/time/datetime inputs, including multiple pre-selected values for check boxes and multi selects — huge thanks to grimen on this one!

Localized (I18n) titles now also works for inputs with the :for option set (nested forms). Closes #135.

Added detection of group association method to use when grouping options for selects

You can now supply a custom builder on a form-by-form basis with the :builder option, rather than globally through configuration

Using rspec_tag_matchers instead of rspec_hpricot_matchers (specs run faster!)

./script/generator form can now be passed a—controller option to specify which controller to add the partial to (eg “admin/posts” instead of the default “posts”)

~~We now always call label_str_method (:humanize by default), previously human_attribute_name was also used in some case~~

Thanks to everyone for their patches and support.

In more exciting news, the Button DSL branch is getting close, I’ll be pushing it up to Github as a remote branch and seeking feedback very soon, but I felt it was important to tidy up these bugs and keep the plugin moving forward in the meantime.

Update: Originally titled this post 0.9.5, but there was a tiny bug or two, so it’s now ~~0.9.6~~ 0.9.7!

Formtastic 0.9.2 Released

2009-11-16T21:26:00Z

I’ve just pushed the new Formtastic 0.9.2 gem up to Gemcutter this morning on the train. There’s a few API changes as we edge closer and closer 1.0, so I thought I’d do a quick post to document it all.

Changes

removed the fallback :save i18n key in commit_button and the erroneous deprecation warning — use the :update and :create keys instead
removed the generic method_name class from wrappers (f.input :title will no longer have a title class)

Additions

:radio inputs can now force one of the options to be pre-selected with the :selected option, just like :select inputs can
:select inputs now have a :group_by option to allow option grouping
a new inline error type :first (alongside :list and :sentence) was added, rendering only the first error found

Fixes

fixed up some README examples
added the Formtastic::SemanticFormHelper.builder config to the example config in the generator
added some documentation and beefed up specs for the :selected option on a :select input

Under the hood

made the gem post-install message a little more succinct
huge refactor and reorganization of the specs under the hood
minor refactor of the code base to make it a little easier to follow
deprecation errors are no longer silenced in the test suite

Assuming no serious bugs pop up, the next stop is 1.0. I’ve also started a Pledgie campaign, so if Formtastic is saving you or your clients a bit of time and money, please consider donating.

The current campaign is for $555 by 5pm this Friday, in exchange for which I promise to work on Formtastic’s new button DSL for the entire weekend on RailsCamp here in Melbourne.

RailsCamp Project & Pledgie Campaign

2009-11-08T05:28:00Z

There’s a RailsCamp coming up soon in Melbourne. The whole idea of RailsCamp is to immerse yourself in some Ruby for a few days without distractions, and I’ve been looking around for a project to sink my teeth into.

One option I have is to put some work into Formtastic’s button DSL. I personally haven’t found much need for it, but there’s been plenty of people asking. The basic idea I pitched a while back was something like this:

f.commit 
f.commit :as => :button 
f.commit :as => :link 
f.commit :as => :link, :prefix => "or" 
f.commit :as => :image 
f.commit :as => :image, :src => "save.png"
f.cancel 
f.cancel :as => :button 
f.cancel :as => :link 
f.cancel :as => :link, :prefix => "or" 
f.cancel :as => :image 
f.cancel :as => :image, :src => "cancel.png"

There’s literally hundreds of Ruby projects I’d love to hack on, and hundreds of features I could be working on that scratch my own itch, so maybe it’s time for an experiment:

There’s a Formtastic Pledgie campaign attached to the project on Github, currently sitting at $55. If the campaign reaches $555 by the time I leave for the camp on Friday November 20, I’ll make sure I focus on this button DSL (and Formtastic in general) the entire weekend. The aim is to finish and release this feature. If I’m done early, I’ll focus on documentation.

If we don’t hit the target (or go over), I’ll still make sure that your donations go directly towards improving Formtastic, of course!

So, please tweet this, blog this and spread the word however you can. If you’re able to put some cash towards the project, even better.

Thoughtbot standardizes on Formtastic!

2009-08-16T07:42:52Z

Thoughtbot on the recent updates to Suspenders (the Rails template they use in most of their projects):

We added formtastic (and the validation reflection plugin, which enables automatic “required field” labeling), which – after having spent 18 months or so talking about and never building the “perfect form builder” – we’ve decided to standardize on formtastic for all new projects.

This is huge news for me. We haven’t even reached what I consider a solid 1.0 candidate, and big firms like Thoughtbot are making Formtastic part of their default toolbox, which means it’s going to be in a heap of Rails projects, and probably part of their workshop curriculum.

There’s an astonishing (for me) 700+ people watching the project on Github, 50+ forks, heaps of great feedback and positive buzz on Twitter.

Hopefully there’s a 0.9 gem in the next week or two (I know, feels like I’ve been saying that forever), then we’re going to clean up some rough edges, remove the deprecated stuff and polish this thing up for a 1.0!

After that, I’ll introduce my next Rails plugin for the view layer, which seems to have a few people excited already!

Around the Corner

2009-07-14T11:53:00Z

I expect demos like Snow Stack to pop up more and more frequently as modern web browsers get the sort of CSS support we could only dream of a few years back.

It’s easy to dismiss this stuff because it’s Safari-only, but so many of these cutting edge CSS and HTML features will make it into modern browsers really soon, and we’ll have some amazing opportunities to provide web-native, indexable, linkable, resource-oriented, affordable, maintainable, incredibly rich web experiences with a few lines of CSS and Javascript.

No Flash, no plugins, no alternate or low-fi versions.

Graceful degredation (or progressive enhancement, depending on how you want to look at this stuff) will be a conversation we have with our clients far more often and we’ll spend a whole lot more time designing in the browser.

I can’t wait.

Rails patch: Fixing human_name

2009-06-30T06:06:48Z

This patch just got applied (finally!), which I’m happy about because I won’t have to hack around it in Formtastic any more.

Old: SomeClass.human_name # => "Someclass"
New: SomeClass.human_name # => "Some class"

Small steps, small steps.

Git Aliases Rock

2009-02-17T23:01:00Z

Most of you Git users probably already know about Git aliases. Typically you add a few lines to ~/.gitconfig and you can alias git co to git checkout, etc:

[alias]
   co = checkout
   st = status
   ci = commit

But you can also use it to run shell commands by prefixing the alias with an exclamation mark (!), my first of which was aliasing git df to git diff | mate to pipe the diff into TextMate, which gives me pretty colors and a familiar environment:

df = !git diff | mate

Mostly I’m just lazy. I’d prefer to type git save mystashname instead of git stash save mystashname, and git pop instead of git stash pop, because I find myself stashing a lot of stuff and like to give them proper names, etc etc. It’s totally awesome that I can make Git work for me.

The most crazy one I’ve been experimenting with so far wraps up a common pattern I have, which is…

switching back to the master branch from my generic “dev” branch
pulling from the remote
switching back to “dev”
rebasing “dev” against “master”
switching back to “master”
merging in the changes from “dev”
and finally running git wtf to show me what all my branches look like after the merge before I do a push.

I call this git publish:

publish = !git checkout master && git pull && git checkout dev && git rebase master && git checkout master && git merge dev && git wtf

Get lazy! Go make Git and bash do the hard work for you!

Hello Web Developer, Goodbye Web Designer

2009-01-14T21:30:36Z

John Allsopp in The State of the Web survey results

The day of the web developer has well and truly arrived, with a significant majority of respondents describing themselves as “developers” rather than designers, or a combination of the two. 95% or more or respondents use JavaScript, and over 90% of their sites are database driven.

It’s about time! I can’t remember the last time I built a static website, and more to the point, the average user doesn’t give a shit how your site magically works. It’s just “on the internet”, and we, the web developers, are simply developing some more parts of the internet, like a property developer building some new apartments down the street.

Open-plan offices are making workers sick

2009-01-14T00:44:00Z

Joel and Dan (and probably most of the internet by now) have jumped on this piece on news.com.au:

Australian scientists have reviewed a global pool of research into the effect of modern office design, concluding the switch to open-plan has led to lower productivity and higher worker stress.

It’s fantastic to see some science and numbers to back this up, and I couldn’t agree more with the findings, but whoever funded this could’ve saved a few bucks by spending about 10 minutes in such an environment, which is exactly what management should do before asking their staff to do the same.

If money or space is really tight, at least break it up into slightly smaller spaces. Halving or quartering the noise and distractions by halving or quartering the space will have a huge, positive impact.

Adding Empty Directories to a Git Repository

2008-10-22T21:08:00Z

One of the biggest WTF moments when I started using Git for version control was that it refused to add (or even recognize) empty directories in the repository.

The GitFaq sums it up just fine:

Currently the design of the git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it.

The same FAQ also documents the “hack” that most people choose to work around this limitation:

If you really need a directory to exist in checkouts you should create a file in it. .gitignore works well for this purpose; you can leave it empty, or fill in the names of files you expect to show up in the directory.

Fine, but I get a little sick of adding a bunch of .gitignore files to the many nested empty folders in a Rails project, or having to add the dirs myself when cloning something.

So here it is, a Bash one-liner which recursively adds an empty .gitignore file to every empty directory in the current working directory (with the exception of directories beginning with a dot, like .git for example:

for i in $(find . -type d -regex ``./[^.].*'' -empty); do touch $i"/.gitignore"; done;


	Add it into ~/.bashrc as an alias and save yourself precious minutes in every new project!
	I’ve added it as a gist on GitHub, so feel free to make improvements to it.



The "Remember Me" Rant
2008-10-14T10:14:00Z
The “remember me” functionality, present in most web applications and web services is awesome.  If you want to be remembered (and avoid logging in next time), check the box during the login process and it’s taken care of with a cookie.  Next time you return, it’s like you never left.  Awesome.
	But what’s up with “remember me for 2 weeks”, as found in Delicious, for example.  I don’t get it.  It helps you out for two weeks like a champion, then just when things are going so well, it screws everything up by dropping the ball.  Thanks for nothin’.
	It’s broken because it feels less helpful than forcing me to login each visit — at least regular logins would help me commit the login details to memory.
	If there’s a legit reason to expire the cookie after some period of time (I’m not convinced, but I’m keen to hear why), perhaps an improvement would be to continue remembering me for a period of 2 weeks, resetting the expiration date on the cookie each time I return to the site.
	That feels like a pretty good experience to me.
	Perhaps this is what the original “trail blazers” of this pattern had in mind, and somewhere along the way it got dumbed down and recycled into this awkward anti-pattern.
	Optional listening material: It’s the innocent smiles you get at the start of a relationship before you fuck everything up by Aussie band Laura

 



The Commonalities
2008-09-11T01:27:35Z
I’ve been doing a huge purge of my feeds lately, but The Cooper Journal will be staying put!  I particularly enjoyed The parable of The Homer, posted a few minutes ago: 
	
		The moral is of course that designing for almost any single individual runs a huge risk of building a product around personal idiosyncrasies—the things that are different about that person, which is a lot different than designing for personas or user archetypes where the goal is to make decisions focused on the commonalities between members of the intended audience.
	


 



Absurd Time Extensions
2008-07-01T03:31:00Z
John Barton just made my afternoon 10% more awesome with his Absurd Time Extensions on Github:

class Time
  attr_accessor :white_rapper
  def stop!
    if white_rapper
      "collaborate and listen"
    else
      "Hammertime!"
    end
  end
end

	Update: My contribution, Time.now.coffee? with a 3pm cut-off.

 



Git Commits That Need to be Pushed, Part 2
2008-06-27T02:12:00Z
Update: FETCH_HEAD doesn’t really work the way I hoped, so I’ve reverted to a modified version of my previous solution.

 



Hardware and Software
2008-06-22T23:57:01Z
Last week my hard drive started making those wonderful clicking noises, and I started seeing way too many “spinning beach balls of death”.  A day later, the system wouldn’t start up, so that was that.  Dead hard drive.
	I grabbed one of the ‘emergency’ laptops from work (a black MacBook), plugged in the TimeMachine back-up, and was up-and-running on the new system pretty quick.
	Physically, this is a really different laptop than my MacBook Pro or the Powerbook I had before it – the keyboard is just plain weird, the lid latches differently, the screen is glossy, the ports are all in different places, the resolution of the screen is different, the dimensions are smaller, it’s plastic rather than aluminum, etc.
	Despite this, I felt comfortable on it almost instantly.  It was my computer so fast, adding weight to something I’ve always suspected was true – the software and settings installed my Mac is what makes me feel so at home, not really the hardware or even Mac OS X.  I can jump on a friend’s Mac and feel almost as lost as I would jumping on a PC.
	The system you interact with every day is the one you’re going to feel most comfortable on.  Instinct takes over from logic and familiar UIs are forgiven their inadequacies.
	When people say “I love Macs”, what they really mean is “I love my Mac”, and when they say that, they really mean “I love what I’ve done with my Mac”.
	This is also the reason why I occasionally hear the words “I love my PC”, as strange as it sounds to the rest of us.


 



Formtastic Sneaky Preview
2008-05-29T23:45:00Z
Last night at Melbourne Ruby I gave a quick presentation of the Formtastic Rails FormBuilder plugin I’ve been working on, and thought it was about time I announced it here also.
	The README serves as a pretty good introduction to what I’m trying to do, so please just go and read that instead.
	If you’re too lazy for that, it’s a sweet DSL for authoring forms, a FormBuilder that goes to great lengths to provide semantically rich markup with plenty of hooks for stylesheet authors, and a (work-in-progress) set of stylesheets that make that mark-up look great For Free™.
	Xavier Shay has been bold enough to start using it in the wonderful Enki, and I’m using it on a few small projects for friends, so I hope we might be at a 1.0-ish stable and useful release in a month or two.
	Side note: If you haven’t yet discovered the bliss of Github/Git combo, please sign-up for an account, start following me, start watching Formtastic, start forking some things and it will soon become crystal clear just how well the Github team have nailed the social side of open source software development, and how much sense distributed version control makes.

 



Git Commits That Need to be Pushed
2008-05-27T12:44:00Z
I constantly find myself wondering what the difference is between what I’ve committed to my local Git repository, and what’s been pushed up to Github.  Here’s one way, I’m sure there’s others:

git cherry -v origin/master

	Or, how about a bash alias?

alias push?='git cherry -v origin/master'

	Winner.
	Updated 21 July 2008 to use origin/master instead of just origin, which works far more reliably in my various projects, with thanks to Stefan Naewe who emailed me with this suggestion.

 



Rails, Git, Github, etc
2008-05-25T23:15:00Z
A little collection of things I’ve found useful as I dig deeper into Git, dealing with forks, branches, pull requests, patches, etc.  There hasn’t been one glorious moment where “the penny drops” and it all makes sense to me… Instead, it’s been dropping again and again as I absorb more about people’s workflows and usage patterns.
	
		Contributing to Rails in the Rails Lighthouse system
		Everyday Git with 20 Commands 
		Git Manual Page
		Got Git? How to Git and github by Steven Bristol
		The Thing About Git by Ryan Tomayko
		Using Git within a project by Dr Nic
		Git Cheat Sheet by Err Free
		Git – SVN Crash Course by Petr Baudis
	
	I’ll add more as I find them, feel free to email me


 



MS Walk 2008 – Give Me All Your Money
2008-05-24T01:15:00Z
Every year my wife forces me walk around Albert Park Lake for the MS Walk, and every year I complain about getting up early on a Sunday, later realizing it’s quite fun, and 5km is really not that far at all, and 10:30am isn’t actually that early.
	They have a sausage sizzle, you can see dogs chasing ducks (or vice-versa) and even though you’re paying $22 for the privilege of walking around a lake which is otherwise public property, it’s for a good cause.
	This year Kate’s putting a team together, so if you’re in Melbourne, you can join us on Sunday June 1st if you like.
	Alternatively, they’ve added the extra guilt trip of an (optional) fund raising thing where I can attempt to squeeze money out of all my friends who are too smart to get out of bed on a weekend or don’t think I can actually walk 5kms without a coffee break.  You may give me all your money here.
	Please don’t feel obligated at all, I’m just having a bit of fun!


 



Coffee Chicken
2008-05-21T23:09:00Z
In a small office of people eager for their mid-morning coffee, participants must weigh up their strong desire for caffeine against the burden of being the first to break, becoming the Coffee Chicken.
	The Coffee Chicken must take complex orders, deal with handfuls of loose change, return with trays of coffee and deal with never ending complaints & commentary from those who showed greater strength of character.


 



Geoffrey Grosenbach on mod_rails
2008-05-20T22:22:34Z
This is a nice little write-up worth the read.  I particularly like the idea of automatically restarting the application (in development) when files inside vendor are edited, which is my number one gripe when developing or maintaining plugins or other libraries that are only loaded once by Rails.

 



Crunch Crunch
2008-05-12T06:21:58Z

	Not code at all. Meg & Gus, going to town on some dog biscuits.

 



iPhone with Vodafone in Australia
2008-05-06T23:01:22Z
Good stuff:
	
		Vodafone today announced it has signed an agreement with Apple to sell the iPhone in ten of its markets around the globe. Later this year, Vodafone customers in Australia, the Czech Republic, Egypt, Greece, Italy, India, Portugal, New Zealand, South Africa and Turkey will be able to purchase the iPhone for use on the Vodafone network.
	
	Via Daring Fireball.


 



VCS Agnostic Bash Functions
2008-05-04T23:31:00Z
For the last 2 years, I’ve had a bash alias st which mapped to svn status.  Understandably, I’ve built up significant muscle memory here, and every time I want to know the status of a project, that’s what I type.
	Then Git came along and ruined everything (in the best possible way).  Typing st just resulted in SVN errors.  I made a new alias gst, but my fingers just want to type st.
	Problem solved with a tiny bash function:

 function st() {
   git branch &>/dev/null
   if [ $? -eq 0 ]; then
     git status;
   else
     svn status;
   fi
 }

	I’m certain this can be improved, but it’s a great start.  Xavier chimed in with the obvious next step:

 function ci() {
   git branch &>/dev/null
   if [ $? -eq 0 ]; then
     git commit -m;
   else
     svn ci -m;
   fi
 }

	And pretty soon I’ll have a whole swag of them replacing my old bash aliases with functions.
	Anyone know a better way to test for Git?  What about DRYing up the check so that I can re-use it in each function?  Please email me, I’m such a bash newb.
	Update: Ben Birnbaum writes in again with a simplification and clean-up which seems to work great.

 



A custom Rake task to reset and seed your database
2008-04-29T13:27:00Z
No matter how obvious I think this stuff is now, there was a point when it wasn’t, so I’m trying to share more.  Here’s something I do a lot during the initial development process of a Rails application:
	
		drop the current database
		re-create it
		run all the migrations
		load in some sample data from the fixtures (or elsewhere)
	
	The good news is that Rails provides a Rake task for each of these (run $ rake --tasks | grep 'db' to see plenty more), so if you really like typing you can just run these four commands:
	
		rake db:drop
		rake db:create
		rake db:migrate
		rake db:fixtures:load
	
	No way, typing is for suckers.  What you (should) want to do is encapsulate this thing you want to do over and over as a new custom Rake task.  Let’s go with rake db:seed.
	Create a new file application.rake (or db.rake, whatever) in RAILS_ROOT/lib/tasks with the following:

namespace :db do
  desc "Drop, create, migrate then seed the database"
  task :seed => :environment do
    Rake::Task['db:drop'].invoke
    Rake::Task['db:create'].invoke
    Rake::Task['db:migrate'].invoke
    Rake::Task['db:fixtures:load'].invoke
  end
end

	Give it a try, I’ll wait. Warning: This will totally hose your database!  
	And we can clean this up too.  task :seed => :environment is telling rake to run the ‘environment’ task (it loads the Rails environment) before running the rest of the task.  We can actually pass in s set of tasks as an Array:

namespace :db do
  desc "Drop, create, migrate then seed the database"
  task :seed => [
    'environment', 
    'db:drop', 
    'db:create', 
    'db:migrate', 
    'db:fixtures:load'
  ]
end

	Finally, I’ll sleep better tonight if you make sure this task can only run in the development environment (ensuring you can’t accidentally hose your production data), so let’s add another task ‘development_environment_only’ and include it in the task list:

namespace :db do
  desc "Raise an error unless the RAILS_ENV is development"
  task :development_environment_only do
    raise "Hey, development only you monkey!" unless RAILS_ENV == 'development'
  end
  desc "Drop, create, migrate then seed the development database"
  task :seed => [
    'environment', 
    'db:development_environment_only', 
    'db:drop', 
    'db:create', 
    'db:migrate', 
    'db:fixtures:load'
    ]
  end
end



 



Stupid Bash Tricks: Copy The Working Directory
2008-04-29T11:19:00Z
The Problem
	I have a Terminal window open, I’m doing stuff and I want to open another Terminal window or tab to the same current working directory.
	A Possible Solution
	I recently added this to my ~/.bash_login file:

alias cwd='pwd | pbcopy'

	This might be stating the obvious, but pwd outputs the current working directory, and we pipe that into pbcopy which copies that output to the paste board.  I choose cwd (Copy Working Directory) as the alias, your mileage may vary.
	It’s still a bit fiddly, but better than grabbing the mouse to copy the current working directory:
	
		type cwd
		type Command-T (new tab in Terminal.app)
		type cd 
		type Command-V (Paste)
	
	Can you better?
	Ideally I’d like to get this down to one key-stroke.  Automator’s “Watch Me Do” recordable action was looking promising, but it runs horribly slow.  Applescript maybe?  Email me or go nuts in the comments! 
	Update 1:
	Benjamin Birnbaum writes in with this bash function.  There’s still some lag (AppleScript lag I guess) but I’m suitably impressed!  
	Update 2:
	Chap Lovejoy writes in with this AppleScript which I’m yet to try out:

tell application "Terminal"
  activate
  set wnd to the front window
  set tb to the selected tab of wnd
  -- We don't want to clobber any running process
  if not busy of tb then
    -- Clear the current command line
    tell application "System Events"
      keystroke "a" using control down
      keystroke "k" using control down
    end tell
    do script "pwd | pbcopy" in tb
    -- The make comamnd in Terminal appears to be
    -- broken so generate the keystroke as a workaround
    tell application "System Events"
      keystroke "t" using command down
    end tell
    do script "cd \"`pbpaste`\"" in the selected tab of wnd
  end if
end tell



 



A screen that ships without a mouse ships broken
2008-04-28T07:40:49Z
Clay Shirky has an amazing post/transcript Gin, Television, and Social Surplus of which I could quote pretty much the entire thing, but I’ll just urge you to find some time to read it instead.


 



Timeframe Calendar Picker
2008-04-23T23:55:35Z
Mental note: Start here next time I need to implement a calendar picker UI!

 



Great Review of RedBubble
2008-04-17T03:17:00Z
Zoe Marlowe has a warm review of RedBubble alongside Flickr and others on Devlounge:
	
		What’s great and amazing about Redbubble is that it is a veritable “United Nations” of photographers, fine artists and writers. Everyone there has the ability to create their own personal page or “gallery” full of their work, whether it is art or prose, you have a place to do your thing for absolutely free. What else is fantastic about the “Bubble” is that you have the opportunity to actually sell your work, seriously! You can choose several different format options for your art and sell it as prints, greeting cards, or posters, whatever you want! Heck, you can even design and sell T-shirts of your art work. How cool is that?
	
	And this finalé:
	
		I absolutely can’t say enough about this site, it’s really a ‘home away from home’ inside my computer! This online cybercafé, art gallery and community gets the absolute most rousing, foot stomping, Bic-flicking standing ovation from me ever!
	
	I tend to get weighed down day-to-day by all the things I see on the site that we haven’t done, or that we did in a furious hurry, or that we’re still trying to find time to do, and this serves as a wonderful reminder of what we have done.  Thanks Zoe!

 



Signal vs. Noise: Urgency is Poisonous
2008-04-14T20:31:42Z
Jason Fried nails it once again:
	
		One thing I’ve come to realize is that urgency is overrated. In fact, I’ve come to believe urgency is poisonous. Urgency may get things done a few days sooner, but what does it cost in morale? Few things burn morale like urgency. Urgency is acidic.
	


 



Flickr doing Video?
2008-03-17T23:43:01Z
Via Mashable:
	
		According to a dig by Dan Farber of CNET on the matter, Yahoo, working on the heels of very eager anticipation, is planning to deliver “Flickr Video” sometime in April.
	
	I find this really interesting.  Flickr has a massive, passionate, loyal community that have obviously embraced Flickr’s way of doing things.
	Video feels like a natural progression for that community.  A large percentage of them probably dabble in video already, and they’re probably using another service to host and share that content.
	Most cameras do video, so it makes perfect sense — if you’re going to experiment with moving pictures, you may as well share it with your existing Flickr network of friends and fans.
	The other interesting point is that YouTube (owned by Google) is clearly has the upper hand with video.  Even searching for videos on Yahoo returns more YouTube results than Yahoo Video results (no scientific poll, of course), so Yahoo (owners of Flickr) may see some success leveraging Flickr’s community directly.
	Above all else, I embrace the fact that Flickr had the discipline to go out there and solve one problem really well.  Along the way they amassed a large community, built a platform, learnt a lot and helped define the space they’re in.  They can take all this and apply it to video with ease.

 



When you should keep your ideas to yourself
2008-02-08T02:23:06Z
Rob Haggart points to an interesting article over on Harvard Business titled When you should keep your ideas to yourself.  Take away quote for me is this:
	
		This could well be a case of trying to add “too much value,” and here’s the problem: the quality of the idea may go up 5% with my suggestions, but your commitment to its execution may go down 50%. It is no longer your idea; as your manager, I have now made it my idea.
	
	Or, as Rob puts it:
	
		Taking someone else’s idea and increasing the quality by 5% occurs at the price of a 50% decrease in their commitment to execution.
	
	It’s utterly obvious, and I think we already know this stuff deep down, but having it packaged up in a single sentence like that is always great useful.

 



Balanced Iteration Planning
2008-02-06T00:26:00Z
RedBubble does agile development — it’s our own blend, but I guess it aligns best with the goals of Scrum).
	Both myself (something like a team leader) and Pete (something like a product owner) both independently came up with an interesting proposal for creating a balanced iteration, so we’re going to give it a try.
	Our backlog is overflowing with stories that we’re itching to build, and they each represent real value to the business.  We can’t do them all, it’s hard to stay focused, and it’s hard to say “no” to things we obviously need.
	Typically the backlog consists of three types of stories:
	
		big things that will win the war and align well with our long-term goals as a company
		useful things that the community has been asking for (and which we agree they need)
		shitty things that we aren’t excited about, but we have to do
	
	In any given iteration (in our case, a week) we’re going to try to deliver a balance of the three.
	
		stay on track
		show some love
		do what we have to do
	
	Update: An iChat conversation with James led us to the idea that it’s quite similar to a balanced diet — everyone knows what it is, and everyone knows why it’s a good idea, but occasionally (or frequently for some) the lure of tasty snacks and sugary treats pulls us away from things we know we’re supposed to be eating for our long-term health.
	I’ll let you know how it goes in a few weeks.


 



Floating legends in Firefox. Fail.
2008-02-05T04:02:00Z
So I was trying to get a legend inside a fieldset to float left, so that I could float some radio inputs against it for a pretty standard horizontal form layout.
	Works fine in Safari, won’t do it in Firefox.  Replacing the legend with a div or a p or pretty much any block level element works, but I’m trying to be semantic if possible,
	Finally, I search Bugzilla, and woop, there it is.  The built-in browser stylesheet uses !important in two of it’s declarations:

legend {
  padding-left: 2px;
  padding-right: 2px;
  border: none;
  position: static ! important;
  float: none ! important;
}

!important is the necessary evil of CSS, but I’m pretty sure it has no place in a base browser stylesheet (upon which all author and user stylesheets cascade).
	So I started experimenting:
	
		nesting a span inside the legend and styling that didn’t work out
		nesting a div inside the legend and styling that worked in Firefox, but broke Safari
		wrapping the legend in a div with styling worked in Safari, but no love from Firefox
	
	And then Grant reminds me that you’re supposed to be able to override !important styles with new !important styles if you match (or better) the specificity of the rule.  Tried that, still no love from Firefox.
	So this is about the point where I assume there’s something special going on in Firefox, or something swept under the carpet, turn to the wider internet for help, and probably use something less semantic like a h2 or a p.
	Any ideas?


 



The Leopard upgrade, and the stuff I still can't live without
2008-01-17T01:20:00Z
I finally dusted off that Leopard disc on my desk and installed it yesterday.  Rather than an upgrade, I choose to clone Tiger onto an external drive with SuperDuper!, then installed Leopard on a clean hard drive.
	Much like renting (where you’re forced to contemplate the value of everything you own every year or two as you move around), I really love the opportunity to start fresh with a new OS, ensuring that (at least for a while) everything you install is something you really need.
	The results are pretty interesting after 24 hours.
	
		my Applications folder is just 499mb, down from 2.3GB (!) with at least 20 fewer apps installed
		my Library is less than half it’s original 3GB of bloat
		the system Library is nearly 5GB, but it’s dropped down from 14
		in total, I’ve got an extra 50GB of disk space I didn’t have yesterday
	
	What survived?  With some obvious exceptions, it’s mostly stuff from indie developers:
	Installed within 5 minutes:
	
		Quicksilver
		TextMate
		Little Secrets (it holds all my usernames, passwords and miscellaneous details for pretty much everything in my life)
	
	Installed within an hour:
	
		Things (it now rules my life)
		AppZapper (it was handy for tracking down files on my Tiger install that my favorite apps depended on, like preference files and bundles)
		iLife 08
		iWork 08
	
	Installed within 24 hours:
	
		CocoaMySQL-SBG
		Linotype FontExplorer X
		NetNewsWire
		Adobe CS3
	
	Predicted installs in the next week:
	
		OmniGraffle
		Quinn
		Parallels
		SuperDuper!
		Flip4Mac
	
	Some other things I had to do really quick:
	
		I don’t even use the scroll arrows much, but I still had to move them to the top and bottom (rather than both at the bottom) because even after all this time, they still distract me
		Allan’s tips for getting option-left and option-right to act like the rest of OS X when using Terminal (skipping back and forward one word) is pretty much all need to do to feel at home in Terminal
	


 



Design Police
2008-01-16T23:50:00Z

	(Via co-worker Ben)


 



8 hour school day?
2008-01-15T00:28:00Z
Gruber on an NY Times article about education:
	
		But she also argues that the school day should be expanded from 6.5 to 8 hours, quoting some jackass who says “Trying to cram everything our 21st-century students need into a 19th-century six-and-a-half-hour day just isn’t working.” The last thing kids need is to be cooped up in school for more hours each day.
	
	I have no kids, so I’m probably utterly under-qualified to talk about this stuff, but I was a kid once.  I’d actually be in favor of an 8-hour school day if it meant abolishing homework and/or letting kids explore the aspects of their learning that interest them the most.
	As a bonus, parents wouldn’t have to spend a fortune on child care for those extra hours they were at work, and time spent at home could actually revolve around the home and family, rather than an extension of school.
	No idea what it’s like elsewhere, but in Australia, kids (especially in high school) are absolutely hammered with an incredible amount of work to be completed outside of school hours.

 



I can't believe it took me this long to commit to Rails
2008-01-08T22:02:00Z
... and it’s only a pissy documentation patch.

 



Design, a Beautiful Web Development Bookmarklet
2007-12-20T11:11:48Z
This is seriously great... in-browser rulers, cross hairs, measuring things and grids.  Oh yeah.  For the record, I also love MRI and XRAY by John Allsop/Westciv.

 



Optionally Nested Controllers
2007-12-16T11:55:56Z
I’ve seen this asked a few times in #rubyonrails and #roro IRC channels, so rather than knock up a code example every time, maybe I can just point people here.
	The Problem
	Some people like nested resource URLs like /people/21/images/45, instead of flat URLs like /images/45, and some people like to have both accessible as options.  Rails’ Routing can do this easy.  Some people consider these two different resources, so they’ll have an ImagesController and a PeopleImagesController.  Others think that’s horribly repetitive for what they’re doing with their code, so they want it all to go through one ImagesController with an optional parent object or scoping.
	This is for those people, scratching their heads, wondering how that’s done cleanly.
	A Solution (though most certainly not the only solution)

 class ImagesController < ApplicationController
   def index
     @images = parent.find(:all)
   end
   def show
     @image = parent.find(params[:id])
   end
   def new
     @image = parent.new
   end
   # ...
   protected
   def parent
     params[:person_id] ? 
       Person.find(params[:person_id]).images :
       Image
   end
 end

	But what does it do?
	Given the URL /people/24/images/..., params[:person_id] will be set.  If it's found @parent returns an images collection scoped to that person upon which we can perform our find, new, create (etc) methods on.  If it’s not present, we just do them directly on the Image class.
	It’s scoped to the person if there is one in the URL, and isn’t if there isn’t.
	There are many ways to tackle this kind of problem, and plugins like make_resourceful do similar things and are a great kick in the right direction.


 



Comments are off for a bit
2007-12-16T11:29:50Z
Hooray for spammers.  I’ve never been a big fan of comments anyway, so maybe I’ll accidentally leave them off for good.  Who knows.

 



Fixtures in Rails 2.0
2007-12-04T05:42:26Z
Don’t know how I missed this earlier, but fixtures have had some love in Rails 2.0 — this just feels so much nicer!


 



A small, small announcement
2007-12-02T11:04:00Z
I’m certain hardly any one cares, but I’ve made a decision.  If you want me to buy things from your online store, I should be able to do it without signing up for an account, agreeing to a 3000-word legal document or fighting to ensure you don’t add me to your email lists.
	What is this, the ‘90s?

 



Rituals
2007-11-15T00:41:47Z
Rituals have become a massive part of RedBubble culture over the last few months.  Our build cycles are based loosely around one month chunks of work, with weekly iterations inside them, with daily bursts of work inside each of those.
	Each of them is punctuated by some form of gathering – a 5 minute daily standup, an hour-long weekly demo/review of the work we’ve done, and a longer monthly get together to talk about where we’ve been, and where we’re headed.
	That probably sounds like a whole lot of meetings, but they’re typically not the toxic kind of meeting that everyone hates.  Especially the daily stand-up.
	The beauty of all these rituals is that they add some form of structure to the whirlwind of chaos we’re working in.  You vent, complain, boast, clear your mind, reset your focus and get back to it.
	And the RedBubble community is picking up on these rituals and embracing them wholeheartedly.  We release whatever we’ve done almost every week, so Thursday has become RedBubble Thursday — a celebration of what we’ve delivered, and what we’re doing next.
	The “wow”, “yay” and “thank you” comments flood in just seconds after we announce the changes, and it seems to inject a massive dose of energy into the community.  They see this thing changing and evolving in front of them, they see us responding to their needs and they see us pull out a few tricks and surprises they never expected.
	Most agile development books go into these rituals in much more detail, and I’m almost certain most books about “communities on the web” would have plenty to say about it too.

 



Introducing Meta Serif
2007-11-13T23:21:00Z

		The most influential sans serif of the digital revolution now has a serif companion.

— November Font Shop newsletter
	

 



You Don't Need a Development Manager
2007-11-13T11:31:56Z
Some interesting things have happened at RedBubble over the last year (already?).  One that’s been at the forefront of my thinking over the last few weeks is how we don’t seem to need a Development Manager at all.
	We had one.  It wasn’t me, but I’ve been there before.  It was the typical role, with the usual stuff:
	
		know the system, be sure it works
		lead the team & make sure things get done
		make sure “the business” doesn’t hassle “the developers” with crazy ideas and scope creep
		make sure the dev team is happy and productive
		manage the project timeline and backlog
		estimate and plan out the dev team’s time
		argue over deadlines
		translate requirements into tasks and stories that can be implemented
		manage expectations
	
	Adopting a more agile development process (Scrum, or something like it, if you’re interested) certainly removed a lot of the crap from this role and pushed things in the right direction, but it still didn’t work out.
	Really, this is far too much work for one person to do well, so what’s the point?  The role stinks of big business, it gets in the way of actually doing stuff, it frustrates the shit out of everyone and it’s absolutely destined to fail in a start-up environment.
	None of this is the manager’s fault, by the way.
	What do we do instead?  As a team, we manage the team. We have smart people with a complimentary and multidisciplinary skill set, so we farm out different parts of the role amongst ourselves.
	Pete (the boss) took on all the human resources stuff and assumed.  I took on a lot of the iteration planning & day-to-day leadership.  John and Dave took on the systems architecture.  Grant , Kath and Xavier all pushed in new directions to pick up the slack. The entire team helps with bugs, planning and estimation.  We basically self-organise and keep each other in line.
	No-one stands between the person who needs stuff done and the person who can do it, no one holds everything in their head, no one plays the role of the gatekeeper and no one has the impressive title on their business card.
	We’re getting things done faster this way, no doubt, and that’s incredibly important for a start-up.
	However, this huge pay-off would not be possible without some boundaries and an open, honest dialogue — we know how much work we can do in an average week, so we’re not asked to commit to anything unrealistic, and we’re quite comfortable telling Pete that he’s asking us to build something far too vague, or that his cheeky 1 hour “simple text changes” card was incredibly optimistic.
	There’s an overhead to this of course.  The time we spend managing ourselves is time we don’t spend writing code or pushing pixels around, but I’m convinced we’re still way in front.
	If you’re looking to hire a manager, I can highly recommend sniffing around inside your own team first.  Or if your manager is overloaded (they all are, right?) don’t tell them to suck it up — ask them what they can offload to others in the team to free up some time.

 



DataMapper
2007-11-06T10:35:57Z

		DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
	
	Looks like something interesting to try out alongside Sinatra next time I need to hack together a quick database-backed website and would rather not eat up 60+meg of RAM for each Mongrel.
	
		Found a bug or want a feature? Tired of dealing with the bureaucracy that other ORM maintainers force upon you?
	
	Gee, I wonder which ORM they’re talking about?

 



It Only Takes a Minute
2007-10-19T01:03:00Z
Next week, amongst many other far more interesting things, RedBubble will be rolling out a small change asking our artists to specify the currency in which they wish to be paid.
	We started out just using their browsing preference (“show me prices in USD”), but it turns out that if they change this along the way, it creates major accounting headaches which we’d rather not write software to dance around right now (bigger fish, etc).
	So, the solution is a browsing preference (change it as often as you like) and a payment preference (can’t be easily changed).
	Xavier could have easily pushed it out the door with some dry “cannot be changed” text, but it only took him a few seconds longer to go the extra mile and make that text a little warmer, informative and personal:
	
		“Which currency would you like to be paid in? For reasons only our accountant understands, this cannot be changed after you have set it.”
	
	Copywriting is Interface Design, and I think it’s really important that teams are encouraged to inject a little bit of their own personality and natural language into their work wherever possible.

 



Any?
2007-10-04T00:55:00Z
Behold! Ruby weirdness.  So I was hanging out in our utterly messy views, and thought to myself “what I want is the opposite of Array#empty?, and I’d call it Array#any?”.
	So I fire up the console and have a play.

>> [].any?
=> false
>> [1,2].any?
=> true

	Fantastic!  But wait, Xavier shows me the dark side of any?:

>> [false].any?
=> false

	Gah, so any? returns true if any of the values in the Array are true, not if there’s something (anything) in the Array, as I’d hoped.  I guess someone, at some point, had a reason for that.
	Of course !my_array.empty? is the answer, but I like even better answers.

 



Web Directions 07: The Myths of Innovation
2007-10-01T00:18:03Z
Ah screw it — it’s much easier to just write about all these Web Directions things individually, rather than some mythical mega-post.
	Scott Berkun gave another great presentation on The Myths of Innovation. I’ve placed an order for his book and subscribed to his feed.

 



Web Directions 07: The Mob Rules
2007-09-30T23:37:00Z
The one presentation from Web Directions that remains at the very front of my mind is Mark Pesce’s closing keynote, The Mob Rules.
	I could pull a million quotes from it, or even quote the whole thing, but here’s two:
	
		Google resisted the mashup.  Claimed mashups violated their terms of use.  Mashups come from the mob, the street finding its own use for things.    The mob pushed on through; Google bowed down and obeyed.  The most powerful institution of the Internet era, pushed around like a child’s toy.  Ponder that.
	
	
		Even worse, for those who are raising a hew and cry about the “theft” of their precious content, the more they scream, the more they thrash about, the stronger the mob becomes.  Consider: filesharing has only grown more pervasive despite every attempt of every copyright holder to bring it to heel.  Each move has been met with a counter-move.  There is no safety in copyright, nor any arguing with the mob.  Music and movies are freely and broadly available, and will remain so into the indefinite future.  Sadly, we’re now seeing that same, sorry battle repeated in double-time as advertisers – and those dependent upon them – assert an authority they no longer possess.
	


 



HTTP Errors
2007-09-30T23:01:55Z
HTTP Errors via Dave Cheney, our fearless sysadmin.

 



Well, that sucked
2007-09-27T03:51:57Z
Man, being entertaining and interesting on stage for an hour is hard hard work.  I think I’ll just leave it at that!

 



Write a Blogging Engine
2007-09-22T23:36:00Z
From Want To Learn Web Programming? Write A Blog Engine by Abhijit Nadgouda:
	
		What is the best way learning any kind of programming? Write programs! I sincerely believe that a blog engine is one of the rare pieces which employs all the basics of Web programming but can be simple enough to understand.
	
	Couldn’t agree more.  This is my favorite conversation point for interviewing web app developers.
	
		if you have no idea what the problem domain is (if you don’t know enough about blogging), we can cut the interview short, because it’s clear you don’t “get” the internet at the level I was hoping for
		the problem domain is also small enough that you can hold all the pieces in your head
		you can sketch the model on the back of a napkin in a Fitzroy café
	
	Even better, we tend to interview quite a lot of PHP/Java/Python developers who want to work with the Rails framework, but if they can’t talk about the model or implementation, it’s pretty clear to me that they haven’t spent much time looking into it at all.  From DHH’s 20-minute-video, through to Mephisto, Simplelog and even Radiant, there’s plenty of resources out there.
	“What models would we need for a simple blog?” is almost a freebie, but many stumble.


 



"Mind the Gap Please"
2007-09-07T21:40:24Z
So here we are in London.  We had a one night stopover in Singapore which was great (call me crazy, but it felt just like Melbourne, only bigger), then a 13 hour flight to Heathrow.
	We spent a few days hanging out with Nat (the wonderful Aussie ex-pat who set Kate and me up about 4 years back), looked at lots of old buildings Cantebury and Rochester, and now we’re here in the middle of an absolutely amazing city with so much history.
	We’re here for a few more days (Portabello Market tomorrow, and a bus tour out to Stone Henge on Monday), then we get the Eurostar across to Paris for a few days of awkwardness (neither of us can speak a word of French, which is probably even more confusing given my surname), shortly followed by a flight to Berlin for a few days of sightseeing and RailsConf Europe.
	Yes, the credit card is going to get a work-out.
	See (some of) you in Berlin for beers and geek stuff.

 



Hello, Install This Plugin Now
2007-08-29T12:12:05Z
Courtesy of Robby Russell, I just stumbled upon Josh Goebel’s dev_mode_performance_fixes plugin, which really does seem to work as advertised.
	Clicking around the RedBubble application in development mode feels way faster — 6x faster at least, mainly because we have stacks of image-heavy pages, with each image passed through the Rails stack on every request (yeah, they’re cached in production, but development mode is just painfully slow out-of-the-box).
	So far, so good.  Most changes seem to be picked up without restarting Mongrel (although a few random changes to inherited controllers needed a restart).
	Three cheers!

 



Black Tees are Here
2007-08-23T02:30:00Z
I’m really excited that we’ve finally launched black tees on RedBubble.  We launched just two hours ago and the community has already started pumping out some amazing stuff.
	
	
	
	And since I’m a shameless entrepreneur and want a new car, everyone should buy some of my stuff:
	
	


 



Overheard
2007-08-21T04:53:00Z

		“I reckon we apply the 80/20 rule to this IE bug on writing – it’s 80% working, and we’ll fix it in about 20 iterations”
	
	— Grant Bissett, RedBubble

 



Warm and Fuzzy
2007-08-07T08:13:00Z
Seeing overwhelmingly positive, glowing reviews like this one of our products makes all the hard work really seem worthwhile.
	
		These are, by far, the best quality photo greeting cards I have every seen. I am pleased beyond measure. I am, in fact, tickled pink.
	
	Lessons learned?  We pushed really hard to get those cards right.  They consumed a lot of our resources in both tech, R&D and fulfillment — and it paid off.

 



RedBubble is Hiring a Web Designer
2007-08-02T07:46:00Z
Copied straight from our ad on 37signals’ Job Board:
	

	RedBubble is looking for a standards-based web designer to help create polished user interfaces. We’d really like to meet someone with strong front-end development skills (you’ll know what that entails), as well as the visual design nous required to create usable and elegant screens.
	Standards-based CSS & XHTML, and an eye for visual design are required. Exposure to SEO techniques, Unix command line skillz and source control are all nice to have. Experience with scripting languages is a plus. 
	Our site’s built with Rails, so experience with Ruby would have us doing backflips, though it’s not a requirement. If you’re an experienced designer, and you know your HEAD from your POST, get in touch with Pete at jobs@redbubble.com.
	About us: RedBubble is an Australian company building a web site where creative people can share and sell their work online. 
	Location: Melbourne, Australia.
	


 



Better Assertions
2007-07-05T00:16:00Z
You write tests for your models, right?  Of course.  You probably have quick sanity checks all over your tests like this:

 assert u.valid?

	And when that assertion is false, you get this ultra-helpful error message:

 <false> is not true.

	Uh-huh.  Awesome, thanks.  WTF?
	So then you go back into your code and add in a few lines to debug just before the assertion:

 u.valid?
 puts u.errors.full_messages.join("\n")
 assert u.valid?

	Waste of time, totally boring, don’t do it.  Test::Unit’s assert (and most of the other assertions you see used in Rails) can accept a message when the assertion doesn’t pass.  So replace the awful waste of time hack above with this from day one:

 assert u.valid?, u.errors.full_messages.join("\n")

	When the record is not valid, the assertion will print the error messages along with the standard <false> is not true.  But I’m telling you stuff that you don’t really need to know, because the Rails framework has already wrapped up this pattern as a simple assertion:

 assert_valid(some_record)

	So I guess my point is this… when you’re writing tests, make sure you provide some sort of useful error message, or an inspection of the objection or something with your assertion so that you spend less time debugging.
	Further, if you find yourself doing the same stuff over and over, check out the Rails documentation and see if someone’s wrapped up the pattern as a helper or method.  If they haven’t write your own and share it with the world.

 



Ruby Newbie Night Success
2007-06-28T23:33:00Z
Last night’s Ruby Newbie Night organised by the Melbourne Ruby Group was a great success, and I’m going to try much harder to attend the monthly meetings.
	Thanks (and perhaps sorry!) for letting me speak about rake, helpers and layouts/views.

 



Number 5
2007-06-27T23:24:07Z
Australia is number 5 in the number of Rails developers per capita, according to Aslak and Working with Rails.
	Where are you all hiding?

 



Lilu Templating Language
2007-06-26T23:35:21Z
Wow.  Of all the template languages I’m seeing pop up for Ruby or Rails, Lilu is by far the biggest shift in thinking.
	You define your templates as real, valid HTML ‘mockup’ that can be viewed, validated and used independently of your application (say, by your hard-core HTML/CSS guru that can’t stand fiddling around with Erb), then Lilu kicks in and replaces portions of the HTML as part of the rendering process.
	It’s a really interesting separation of design and logic, if that’s what you’re after.  Your HTML geek sticks to HTML, your programming geek can then apply the business logic and real content to the HTML with Ruby.
	Quick example from the wiki:

 update('#username').with(@user.login) if logged_in?

	There’s also some slides from Yurii Rashkovskii’s presentation.
	Thank you Yurri, and thank you Johan for the heads-up.  I’m definitely going to have a play with this!


 



rbehave
2007-06-21T22:45:48Z

		rbehave
 is a framework for defining and executing application requirements. Using the vocabulary of behaviour-driven development, you define a feature in terms of a Story with Scenarios that describe how the feature behaves. Using a minimum of syntax (a few “quotes” mostly), this becomes an executable and self-describing requirements document.
	
	That maps so incredibly close to the way we talk about our software at RedBubble, so I’m very keen to have a play with this.

 



Multi Safari
2007-06-13T12:28:58Z
In the comments on my previous Safari 3 rant, Michel Fortin points out that he has a bunch of stand-alone Safari builds available for download:
	
		These special versions of Safari use the original Web Kit framework that came with them, bundled inside the application. They will mimic original Safari rendering and javascript behaviours. HTTP requests and cookies however are still handled by the system and may not work exactly the same.
	
	Thank you!
	This leaves me wondering why the Safari 3 Beta couldn’t have been made available as a stand-alone app with it’s own embedded Web Kit, or at least that this was available as an option.

 



What's up with the Safari 3 Beta?
2007-06-13T05:56:00Z
It actually installs over the top of Safari 2, which means without two computers, you can’t compare the two rendering engines side by side or retain Safari 2 as your “browser” whilst checking out the progress of Safari 3.
	It also means that I had to uninstall incompatible plugins (Saft, for example), and I think it crapped on other WebKit-based applications on my system (like Pyro).  And it required a restart (gasp!).
	I’m sure there’s a sufficient excuse, but why couldn’t it be a stand-alone application?
	It’s at least a little amusing that it was easier for me to check out Safari 3 on Windows XP than it was on OS X, and that I was looking at Safari inside Windows inside a Mac via Parallels.
	Oh well.  The Windows version looks pretty damn slick, and I’m pretty impressed they went the whole way on things like font rendering… WebKit for Windows in general is exciting.

 



New Apple Website
2007-06-11T23:56:00Z
There’s plenty of talk in my feeds about WWDC, Safari and iPhone, but nothing much about the new apple.com redesign which I think is utterly beautiful.
	I’ve often looked at the old Apple site for inspiration… the “mini sites” for things like the iPhone or Aperture but I always had to ignore the old-school plastic tabs and sub-navigation.
	Much in the same way that Apple’s experimentation with the iLife UI has led to the new UI for Leopard (very much like iTunes, very nice), it’s clear to see that Apple’s web team has been experimenting with this new layout for a long time, and this “redesign” ties everything together beautifully.
	It’s also worth noting that .Mac and Quicktime have disappeared from the main navigation, and that the new set of tabs maps quite nicely to Apple as we now know them — Apple, Store, Mac, iPod+iTunes, iPhone, etc.  This is a great improvement to the information architecture, and really outlines Apple as a company.
	I’d love to know who’s on Apple’s web team, and what the workflow is like.  I find it odd that I know so little about a team that produces work I respect so much.

 



Per-request Template Paths in Rails Edge (> 1.2.3)
2007-06-06T23:20:00Z
If you’re playing with Rails edge (> 1.2.3) and want to set the template path on a per-request basis, the game has changed a little.
	But first, why would you want this?  Let’s say you’re building a CMS that has to use a different set of views based on something in the request, like the host name:
app
  views
    siteone.com
      posts
        index.html.erb
        show.html.erb
      ...
    sitetwo.com
      posts
        index.html.erb
        show.html.erb
      ...

	Courtesy of the ever-helpful Rick Olsen, this is how we used to do it, but recently ActionPack has been changed to support multiple view paths that act like load paths (first look here, then here, then here).  It’s a great addition to the framework, and really useful for plugin developers (first look for an overriding view in app/views/, then look in vendor/plugin/myplugin/views/, for example).
	But somewhere in the changes “the old way” stopped working, and there’s no “new way” that I can find that works on edge right now, but Courtenay has a proposed fix which is a one-line change in ActionView::Base to change an attr_reader into an attr_accessor, then replace the old way with the new way:

self.class.view_paths = File.expand_path("#{RAILS_ROOT}/themes/#{store.id}/views")
@template.view_paths = File.expand_path("#{RAILS_ROOT}/themes/#{store.id}/views")
 
	I really hope the one-liner (or an officially supported API) makes it into trunk soon, but in the meantime (that’s a great song by Helmet by the way) it’s nice to know the hack isn’t too crazy.

 



Staginated
2007-06-03T23:27:00Z
Stage·in·ated, verb.  Used with object.  The act of pushing a particular code revision or feature out to the staging server with Capistrano.  Origin deep within the RedBubble development team, probably me.