the boolean virtual attribute's gotcha (a checkbox in a rails form)

I am not sure where to post this, suggestions are welcome.

Whenever you create a virtual boolean attribute in your model, e.g.

attr_writer :some_boolean
def some_boolean; defined?(@some_boolean) ? @some_boolean : true; end  # defaults to true
attr_accessible :some_boolean

And make it a checkbox in the model's input form, e.g. (simple_form, haml)

!= f.input :some_boolean, :as => :boolean

And try to do some reasoning with it, e.g...

after_create { ... if @some_boolean }

You may be surprised as @some_boolean will always resolve to true (actually to 0/1, but both are true in Ruby).

A quick and dirty workaround would be... well... getting your controller dirty quickly:

before_filter :boolean_fix
...
def boolean_fix
  params[:some_model][:some_boolean] = false if params[:some_model] && params[:some_model][:some_boolean] == '0'
end

acts_as_taggable_on meets thinking_sphinx on rails (and nearly misses it)

Beware, for reasons unknown, instead of
indexes tags.name, :as => :tags
you have to write
indexes taggings.tag.name, :as => :tags
or you'll get too many results.

jQuery autoSuggest vs rails (and acts_as_taggable_on)

While AutoSuggest is quite wonderful as it is, there's also a lot of room for improvement (e.g. I've started using this fork since the original author doesn't seem too community-friendly).

Here's one tip on how to use it with rails (and simple_form) — or rather how to workaround the following issue.
When you write something like $("#post_tag_list").autoSuggest(...); for the first time, you'll expect AS to do all the wow stuff on the client side and have the original input field with the values as a parameter back on the server side, right?
Well, I did.
Unfortunately, you have to work harder: not only you must include the asHtmlID: "tag_list" option in the autoSuggest parameters, but (since that option actually defines the id's suffix only) you'll have to patch your controller allong the lines of:
before_filter :autosuggest_fix
and
def autosuggest_fix
params[:post][:tag_list] = params[:as_values_tag_list] if params[:post]
end

a jQuery templates tip: checking for optional fields

One tip regarding the templates

“Comments for this page are closed.” for some reason, so here:
When rendering an optional numerical field, the safest way to check on its existence is:
{{if typeof $item.data.optional_field == "number"}}...{{/if}}
(for other types, change the right side of the == accordingly)

The main problem with the way described in the doc is possible accidental name collision of the field's name with some other variable in the scope.

Arrayize

Array(x) is syntax cool, it will return an empty array for nil, a one-item array for an item, and a copy of the array for an array.

google woes again

now this has exceeded all possible definitions of a suck, it's a deepthroat we have here!

after kindly suggesting to “Get Gears now” — while in calendar (@Chrome), google gives me “Gears for Mac OS Snow Leopard: Your browser is not supported”. And it's their Microsoft-inpired browser! And still no HTML5 in sight (see the date of the post linked above). Bummer!

Well, I guess it's the google's support for Apple's iCal.

winter tea

I do a lot of tea. I love tea.

The tea mix I've been drinking the last (freezing-ass) weeks is ordinary green or jasmine tea, rooibos with orange, camomile, verbena, and some sage.

p.s. and yes, you can steep a single load 2-3 times (~3 minutes).

ruby-openid's AX response returns arrays

As janrain gone mad and removed the openidenabled.com domain recently, along with ruby-openid gem rdocs (confusing the shit out of google and breaking links all over the internets), my ordoc command helps me out (bash on osx):

function ordoc() {
    open -a Firefox `gem environment gemdir`/doc/$1-*/rdoc/index.html
}

But this alone is not probably worth a post, while the following undocumented feature of the gem probably is.

When examining a (very successfully named) FetchResponse instance, as after:

ax_info = OpenID::AX::FetchResponse.
    from_success_response(request.env[Rack::OpenID::RESPONSE])

ax_info['http://axschema.org/whatever'] may actually be an array! Which may either be empty or contain one item — in my practice with google accounts.
Perfect ruby no-surprise thinking.
My solution is to convert the attribute value to string (ax_info[...].to_s) and then test it for blankness. I hope this will hold in any case.
Cheers, janrain.

International Contest of Seamanship @ Midland, ON, Canada

Why the photos are so few? Heck, I cannot shoot.
Videos coming soon?

they do indeed!

lvalue tip

while — very unfortunately — this

irb(main):042:0> x,y=0,0
=> [0, 0]
irb(main):044:0> if nil then x else y end = 1
SyntaxError: compile error
(irb):44: syntax error, unexpected '=', expecting $end
if nil then x else y end = 1
                          ^
    from (irb):44
    from :0

does not work, this

irb(main):048:0> x,y=[],[]
=> [[], []]
irb(main):049:0> if nil then x else y end << 1
=> [1]
irb(main):050:0> x
=> []
irb(main):051:0> y
=> [1]

performs nicely.

i know the difference, but it's still controversial to me.

dead code is nothing compared to zombie code!

priority-posteriority

As I'm conceiving the next generation ass-kicking artefact-based task management system, I have to make a statement on so-called task priority.

One can argue about the variety of psychological models on the subject, but to me, there's no such thing as task priority in the real world.
A task – sooner or later – is being done or discarded, or better, it starts consuming resources right from its definition, and those resources are real, the time spent is real.
That's why, the only questions how (= when + how much) those resources are spent.
Thus, the most natural thing to do is to define a period of time this task can "wait" – until the next action.

So I propose always to use time-to-action as the basic measure of task precedence.

Of course, deadlines, dependencies, schedule and resource constraints might be additional parameters to the planning equation, but even that basic attribute on each of your tasks is good enough to answer the core question "What in the bloody hell should I be doing right now?"

test report - embedding bzipped tar in a bash script (with uuencode)

Just a quick note on the cunning technique used in the making of tag_test.sh.

The utility's both data store and main interface is file system - which makes it easy to think of diff'ing directory trees (actual to golden) as a means to test the former.

Now, I would generate a golden test directory tree, test it manually all I want, tar-bzip2 it, and uuencode the data for pasting as an in-place redirection block (<<EOF) - which is fed to uudecode and untar in the script, of course.
And I'd also repeat this operation for every test I wanted to perform.

The resulting bash code is rather fatty, but it is totally self-contained.

tag: the bash utility's major update

Although I have properly realised the truly versatile filesystem-based tagging-enabled environment is much further away than I originally thought, I've updated my simple bash mini-utility, and it is now as useful as ever. I've even creatively wrote some tests for it.
Dowload/Clone Here

p.s. Some thoughts on the ideal filesystem interface left out for a while.