Notes, How Tos, Things To Remember, Things I'll soon forget

Never remember, its as simple as it seems it should be: unzip -P [password] file.zip Or for older versions of info-zip: unzip -[password] file.zip

The callback argument signature wasn't obvious (or is it wrong?) on the YUI documentation page or very readable at the YUI API site. The callback has the following format: function init_for_ondomready(label, args, obj) { } label - string of "onDOMReady" args - empty array (from source doesn't look like its populated today) obj - object passed to onDOMReady event Example: YAHOO.util.Event.onDOMReady(init_for_ondomready, thingy); label = 'onDOMReady' args = [] obj = thingy Therefore you need to include a holder for the empty args array or process the arguments array manually.

Grabbing input elements with my favorite JavaScript libraries What Prototype YUI All inputs $$('input') YAHOO.util.Selector.query('input'); All checkboxes $$('input[type=checkbox]') Sweet with .each YAHOO.util.Selector.query('input[type=checkbox]:checked'); All inputs in table with class .data_display $$('.data_display input') YAHOO.util.Selector.query('.data_display input');

After not running JBuilder 8 for a bit, when I tried to rebuild an applet at $work, I received a very strange set of missing class errors. These classes were right there in the Jar libraries... I swear :) Well after a few hours of looking around I found that I need to remove the whole 'output path' option (under Run -> Configurations -> Path tab). Then it magically worked. Go Figure. I know JBuilder8 is ancient but one applet builds in it and nobody wants to fund it moving to Eclipse...

On the mailing list, Andy Wardey recommended using the URL plugin as the best way to build URLs in Template Toolkit (TT) . Since this is very helpful but sometimes hard to dig out of the TT documentation, I wanted to make a quick note here. The URL plugin will make sure to properly HTML and URI encode your link(s). Here my quick example In your template: [% USE profile = URL( '/profile', show_picture = 1 ) %] <a href="[% profile( slayer = 'buffy' ) %]">Buffy's Profile</a> <a href="[% profile( vampire = 'spike' ) %]">Spike's Profile</a> This will render validly encoded html like: <a href="/profile?show_picture=1&amp;slayer=buffy">Buffy's Profile</a> <a href="/profile?show_picture=1&amp;vampire=spike">Spike's Profile</a> Notice the & not a '&' which makes the html validation much happier. This is much easier than trying to do it yourse...

perltidy has its own mind at times. Most of the time, its mind is better than my hands reformatting code. But I've been writing lots of test code recently and found that I use blocks and labels, along with nested blocks with labels. Stuff that looks like: USER: { my $shared_db_thingy = create_db_thingy( %params ); SKIP: { # create user tests skip 'DB Thingy not created', $test_count unless $shared_db_thingy; lives_ok { $shared_db_thingy->create_user( %user_parameters ) } 'create_user'; } SKIP: { # retrieve user tests } } Frustratingly, perltidy likes to tidy this into: USER: { SKIP: { } SKIP: { } } I had to do some real digging into perltidy to find the -ola that outdents labels. Setting the -nola fixes it. And doesn't having any (seen) side effects. w00t!

When writing tests for Perl objects (or modules), I like to store the name of the module in a named buffer/register in vim. I usually visually highlight the object(or module) name, then put it in the "n" buffer. Yank into n: "ny Paste out of n: "np I guess the m or n buffer might make sense. If you forget like I do what buffer your using you can dump them in vim with: registers So it was...