>>~/.bashrc (update)

An update of mines!: >>.bashrc:

This is a drop-out replacement for cd:
0) pd DIR == cd DIR (plus push to the shell's dir stack, plus store DIR as LAST_DIR)
1) pd == pop a dir from the stack (the shell's BACK button)
1.1) if none, pd LAST_DIR (useful for new shell sessions after pd DIR or pd . in an old one)

p.s. Thanks to Vitaly@astrails for the idea on improvement.
p.p.s. fixed!


Time-buffered WUI update /javascript

When it comes to UI (and it naturally comes to js), there often are routines that you would like to perform on a certain event, but not necessarily on each such event, that is, just enough to keep a view updated at most times.
For instance, there are items being added to a sorted list: you'd like to sort the list whenever a new item arrives, but when a bunch of items arrive at once (over a short period of time), you'd like to postpone sorting to the last item in the bunch (for obvious reasons). And you want to keep things simple and refrain from event queuing, optimizing the sort routine and other complex stuff.
Well, in that case, something I call time buffering may help you. If your event handler looks like this:

function _onNewItem(item) {

With time buffering it'll look like this:

function _onNewItem(item) {
_timeBuffer("sort_list", _sortList, 500, 2000);

Not much of a change, eh? And the killer routine?

I'm sure you can fix my style (you're welcome) and add support for removing such list elements -- and associated actions -- cleanly (with something like function _timeBufferNoMore(act)), but you get the idea.


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'


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
def autosuggest_fix
params[:post][:tag_list] = params[:as_values_tag_list] if params[:post]

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.



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.
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.