There are a lot of things in a standard rails app, which is nothing more but repetition. You don’t have to search too much to find a RESTful controller. It usually does the same as all the others. The same stuff gets copied over and over. Of course you think TDD just slows you down: you’ve already done that a thousandth time, why should you pretend this is something new?

While this is totally understandable, we should not blame TDD. The problem is we’re writing copypaste code. Sure, we can add services and presenters to make our CRUD code a bit more interesting, but this is just another way to slow us down. No, the good solution is to move repetitive code to a single place. Use services and presenters when they add value (read: if your code doesn’t worth a dime, why do you want gold plating?).

ActiveRecord models are different. According to David, don’t test standard AR associations, validations, or scopes. What else a model contains, might I ask? Oh, come on, don’t bring up stuff you’ve moved from the controller, or are needed by views. Those belong to services and presenters. This basically says you should not test AR classes. This makes the decision much easier: is the model worth being tested? Do we really need this model after all?

Ah, and there’s cucumber. I’ve started with rspec + cucumber. RSpec just felt right, and Cucumber… well, it added BDD spice. Then I figured Cucumber is just a burden, an artifical layer over integration test, the end user usually just doesn’t care, and anyway, the whole stuff was just brittle.

I’ve switched to Steak, and then to Capybara, and it was good. Then, I even made my switch to MiniTest / MiniSpec, but then I had an epiphany. Running acceptance and unit tests at the same time is counterproductive. Now I’m using RSpec / Cucumber again.

Take a BDD session. You describe your feature (don’t you?), you lay out your scenarios (tag them with @wip), and start implementing the first one. When it fails, you go to the inner TDD circle, and start implementing the first step which brings you closer to the goal: write a test, watch it fail, implement it. Then you can commit your code. You can switch back to the BDD circle to see whether your changes have made the first step pass. When you have finished with a scenario, remove the @wip tag.

You can see, TDD tests should always pass, but BDD should pass only when a scenario has been completed. Seeing errors in test run is discouraging, no matter they come from unfinished integration tests.

There is nothing wrong with Capybara, but you should run integration tests separately. In my case, returning to Cucumber was a late recognition I’ve been cuking it wrong. I have no problems describing the customer needs in a higher abstraction level.

All in all, DHH says you should not test your boring code. Take a step further: make your code interesting, and remove boring stuff. You might raise test coverage dramatically.

Recently I had to work from home for a week, and I decided my neck, back and bottom should be treated better. Fortunately my desk at home is an IKEA Fredrik, and I have a Dennis stool (you can see a picture of a similar one here), which now has a successor in IKEA called Franklin (buying advice: choose the 29 1/8” or 74cm tall one).

My only problem is getting an anti-fatigue mat. I have flat feet, and standing is not one of my strengths. However, while a Genuine Joe’s Air Step is just a click away in the US for $20-30, this kind of stuff is completely unknown here. I’m testing a roll-up workout mat folded in half, with moderate success.

How fantastic, DIY, inexpensive, yadayadayada. I was curious, and I asked whether we can do the same at my workplace.

First off, I asked the local Ergo team whether they can help. They could: I got a mail a couple of days later from the furniture supplier company, telling that they can set me up a standing workstation for $2-3k, I just have to ask my manager for funding.

Of course we don’t have a budget for something like this, but if I make a case with a note from my doctor, we can push it through. Ookay, doctor’s recommendation, sounds reasonable.

Anyways, the supplier’s suggestion was a Steelcase Activa Lift 2 with gas struts (AFAICT Steelcase Series 5 is more or less the same), mentioning it’s cheaper than the electric motor version. They also mentioned gas struts can be set every day. How nice. Still, GeekDesk version 2.0 is $200 cheaper, and when you adjust its height, your cup of water will stay there.

Can be set every day… read: you have to put everything off of your table before operating. I’m sorry, but I already have a lot of stuff on my table when I arrive: a laptop with a stand, a keyboard and mouse, my coffee mug, my Aeropress. Then I put other stuff on it, like my own laptop, a couple of USB drives, keys, wallet, badge, and the like. I want to sit whenever I’m tired, therefore I want to move the table up / down every single time.

At this point my unconscious interrupts. Why do I need all these stuff? Why I need a height-adjustable desk? I don’t! All I want is to raise my external monitor and my input devices. Raising a monitor is not a big deal, every furniture shop has adjustable VESA standard monitor stands. Raising my keyboard however is not something furniture designers figured out: they tend to forget good tilt and palmrest. My old natural keyboard had negative tilt and a wide palmrest, the way it should’ve always been.

My revenge will come on Monday: I’ll go to the closest DIY retailer, and I’ll buy a 11” x 32” x 1” ash board, and four 15” long table legs (eg. 30x80cm 2.5mm wide board, and 40cm table legs). It will beat the supplier’s $3000 setup.

News at 11.

I’ll write every user-faced webpage in SproutCore sooner or later, it’s inevitable. However, old habits die hard, I still want to use Formtastic, and stuff Slim gives to me.

The first common denominator is the template usage. All righty then, let’s start somehow.

Interestingly, building your own handlebars.js is the hardest part (and if you’re already used to it, you can imagine the rest). First off, you need node.js and npm installed:

1
2

brew install node
curl http://npmjs.org/install.sh | sudo sh

I really hope you already use homebrew.

1
2
3
4
5
6
7

cd /tmp
curl https://nodeload.github.com/wycats/handlebars.js/tarball/master | tar zxvf -
cd wycats-handlebars*
# (at this point you might want to remove therubyracer gem from Gemfile)
bundle --path vendor --binstubs
npm install jison
bin/rake release

Now wipe the sweat off of our forehead, and grab the newly created handlebars.js and handlebars.vm.js files, and copy them to our project’s lib/assets/javascripts directory (some of you might want to put them to vendor/assets/javascripts rightfully, I’m just lazy).

I’m not about to go into the details how to implement nested forms. That part hasn’t changed after all. You can get a very good insight on what it is and how to implement it watching Ryan Bates’ always amazing RailsCasts episode #196, and the following RailsCasts episode #197.

OK, 3rd party stuff is in place, let’s wire it into our app:

1
2
3
4
5

// app/assets/javascript/application.js
//= require jquery
//= require jquery_ujs
//= require handlebars
//= require_tree .

Now handlebars.js is picked up. Let’s create a view:

1
2
3
4
5
6
7
8
9
10
11

/ views/pages/_form.html.slim
= semantic_form_for @quote do |f|
  script#add_form_fragment{type="text/x-handlebars-template"}
    = f.semantic_fields_for(:fragments, f, :child_index => "{{new_id}}") do |builder|
      = render("fragment", :p => builder)
  = f.inputs
  = f.inputs :fragments do
    = f.semantic_fields_for :fragments do |p|
      = render 'fragment', :p => p
    = link_to t('.add_form_fragment_link'), "#", id: "add_form_fragment_link"
  = f.buttons

UPDATE: It looks like I forgot to show you my fragment. Here you are:

1
2
3
4
5

/ views/pages/_fragment.html.slim
= p.inputs :name => 'fragment' do
  = p.input :param1
  = p.input :param2
  = p.input :_destroy, :as => :boolean, :input_html => { :class => 'destroy_fieldset' }

As you can see, we put a rendered fields_for + render 'fragment' into a script field, but with a child index which can be replaced by handlebars. Remove links are not handled here, that part hasn’t changed. I suppose we might want to place more fragments into a page, and in that case we can hook to more DOM events:

1
2
3
4
5
6
7
8
9
10
11
12

# app/assets/javascript/form_fragments.js.coffee
template = []

add_fields = (e, link, association)->
  new_id = new Date().getTime()
  source = $("#" + association).html()
  template[association] ||= Handlebars.compile(source)
  $(link).before(template[association]({new_id: new_id}))
  e.preventDefault()
$ ->
  $("#add_form_fragment_link").click (e)->
    add_fields(e, this, "add_form_fragment")

In this point if you look at the source it generates, you’ll see {{new_id}} gets replaced with __new_id__ at a couple of places. It’s because Formtastic naming settings replace everything which is not a letter, number, and some punctuation marks like dash, colon, or period. Let’s fix it:

1
2
3
4
5
6

# config/initializers/formtastic.rb
module Formtastic::Inputs::Base::Naming
  def sanitized_object_name
    object_name.to_s.gsub(/\]\[|[^-a-zA-Z0-9:.{}]/, "_").sub(/_$/, "")
  end
end

You can also fix in ActionView:

1
2
3
4
5
6
7

# config/initializers/actionview.rb
class ActionView::Helpers::InstanceTag
  private
  def sanitized_object_name
    @sanitized_object_name ||= @object_name.gsub(/\]\[|[^-a-zA-Z0-9:.{}]/, "_").sub(/_$/, "")
  end
end

You can always smooth off wrinkles, like hiding the add link if you don’t catch it:

1
2

/* app/assets/stylesheets/form_fragment.css */
no-js #add_form_fragment_link { display: none; }

You use Modernizr, don’t you?

That’s it, enjoy your new templates put into a <script> tag, instead of a long onclick event with full of escaping.

YMMV, but I have a couple of rails projects in my development directory. These are not necessarily on the same rails version. I have a 2.3, some 3.0, and some 3.1 rc used in my projects. Therefore I just can’t put all these gems into a single place. How my project selects the correct version of rails command? Hint: gem versioning is not a solution.

For my first problem, I found vendoring gems with style pretty useful.

In my opinion, rbenv fits perfectly to Ryan McGeary’s solution. Please put your project .rbenv file into source control.

Of course, from time to time I want to fire up a clean rails app for prototyping, and this is when I use gemsets. I could use rbenv-gemset from Jamis Buck too, but it’s just too much for my taste either.

My answer here is rails nursery (of course this applies to every ruby-related package, which requires some code generation):

1
2
3
4
5
6

gem install bundler
mkdir ~/Code/rails-nursery-3.1.0.rc6
cd ~/Code/rails-nursery-3.1.0.rc6
bundle init
echo 'gem "rails", "3.1.0.rc6"' >> Gemfile
bundle install --path=vendor --binstubs

That’s it. You switch to the nursery directory (in my case it’s ~/Code/rails-nursery-3.1.0.rc6), and you’ll have the minimum requirements for creating a new 3.1.0rc6 rails app:

1
2
3
4
5
6

cd ~/Code/rails-nursery-3.1.0.rc6
bin/rails new ~/Code/<project> --skip-bundle
cd ~/Code/<project>
echo 'vendor/ruby' >> .gitignore
echo 'vendor/rbx' >> .gitignore
bundle install --path=vendor --binstubs

Now you have a separate directory for all the gems you might not want in the future, and be honest: it’s much easier to get rid of this directory, than cherry-picking your installed gems.

It handled a database to store basic things like comments or indexes, but it was way before SQLite: I used db4 as a key-value store to do this.

Time passed, and every single PHP upgrade broke something in the code. I felt the whole system to be a burden. After a while I created a last flavour for Blosxom.PHP to export all blogposts and comments to Wordpress with a tailored rss feed.

Fast forward to now. I turned away from PHP and started writing Rails applications. My priorities have shifted. My cornerstones, however are still around: a good ol’ zsh prompt and my TextMate (I fire up vim more often though). Now I feel WP is a burden.

Make no mistake, I believe Wordpress is a very good platform for personal blogging and even for a simple CMS, but it makes things difficult, and doesn’t allow the HTTP server where it excels: static page serving.

Most of a web page is static on a blog like this: archives, indexes, pages and syndication feeds can be generated, and only results should be put to document root. Moving parts can be deferred: comments, tweets, Google +1’s come from remote services. In fact, every local service can be replaced by some unobtrusive javascript magic, and a remote service.

But why the fuss? I don’t think I’ll ever be fireballed, but I strongly believe we should do better, with less resources, fewer database dependencies. I also don’t want to be a victim of an expired http session, crashed browser. Oh well, and I’ve fed up with web-based WYSIWYG editors.

Thus, I move back to js.hu, where I already have a ton of legacy stuff: some old Updike translations from a Hungarian magazine, even the first chapter of Rick Cook’s Wizards’ Bane. I led a guerrilla translation project of Joel on Software. I will keep serving these in their original (eg. ugly) format.

Therefore, expect new blog entries appearing here, mostly from my professional life.