Busy packing my stuff to travel to Berlin where I’ll play lobbyist at RailsConf Europe 2008 (i.e. I don’t have a ticket.)
Please contact me if you want to meet up, I’m there until early Friday morning and have lots of free time.
I’ll be taking my EEE PC with me, so mail and IRC ought to be available, given I find some free WLAN (no deal).
I’m staying with Jarkko Laine, Cristi Balan, Andrei Bocan, Manfred Stienstra, Eloy Duran, and Lars Pind. Gonna have a good time.
Anarchaia will resume publishing Friday, September 5.
NP: Queen Adreena—Medicine Jar
It’s been increasingly popular to add rel="next"/rel="prev"
link tags
to web sites, but users of most popular browsers (and that includes me,
as Safari and Firefox user) don’t have a way to access them out of the
box.
Yes, there are Firefox extensions to add them, but I’d prefer not to have another toolbar sticking around. I already have a Bookmarks Toolbar, and thus decided to implement this feature as a Bookmarklet.
To test them, go for example here. And no, my site doesn’t support them (currently).
It rocks for dashing through blogs.
NP: Fiona Apple—Not About Love
For the following, I assume: a non-small monitor (19" or more), use of a convenient mouse.
Desktop icons are dead. Why hide the important stuff behind all the windows?
For efficiency, every regularily used application has a fixed position that is accessible with a single click. (E.g. a window corner, or an icon in the dock.) Optional keyboard shortcuts are beneficial.
Layering windows does not hurt. Expose and similar features allow to get an overview, but (2) ensures we never need to dig for deeper windows.
Windows rarely get resized or moved once they have found their own position and size. Applications need to save their size and position.
Manual, effortless window managment is superior to automatic, but wrong arrangements.
It follows from (2), (3), (4), (5) that tiling has no real benefit.
There should be no distinction between starting an application and switching to it.
It should be possible to group windows into task-related, possibly overlapping positions. I may have a “web development” set that contains my editor and my browser. I may have a “typesetting” set that contains my editor and a PDF viewer. I want to cycle between applications in the current set easily.
Multiple sets should be combinable. I may want to typeset something while having my music player open. My window arrangement ensures I see enough of the music player without disturbing my writing. I want to toggle visibility of my instant messenger, nevermind what I do.
When switching between multiple sets is easy enough, the need for “multiple desktops” vanishes.
It should be possible to hack dwm (and maybe a bit dzen) into something like this. This is probably how dwm is meant to be used.
NP: LCD Soundsystem—Get Innocuous
The twenty-first year of my struggle against entropy went by. Swoosh. Tempus fugit. Ars longae, vita brevis. Memento mori.
How’s life? Homeostasis, check. Organization, check—at least organically. Metabolism, sure. Growth, done. Adaptation, check—still possible. Response to stimuli, ‘course. Reproduction, rather not.
Maybe that’s what life is… a wink of the eye and winking stars.
when asked t’ define yourself exactly, say you are an exact mathematician.
On related news, congratulations to Madonna and Debian.
NP: Ernest Phipps & His Holiness Singers—Shine On Me
Ok, I’m fed up. Writing a good package manager for Ruby is a fight against windmills.
So let’s do the easiest thing that could possibly work. Redefining
Kernel#require is a no-go, for it will lead to the gates of
hell.
Installing multiple projects to the same location is error-prone,
requires non-trivial amounts of code and introduces packaging effort.
Luckily, most packages these days run directly from a checkout or
their released archives (and if you provide neither, you’re doing it
wrong).
Essentially, all you need to make it convenient setting and
manipulating $RUBYLIB, “A colon-separated list of directories that
are added to Ruby’s library load path ($:).” The Z shell
(1,
2) to the
rescue!
Add this to your .zshrc (or .zshenv, if you want it in non-interactive
shells as well):
# unique, exported, tied array of $rubylib to colon-seperated $RUBYLIB
# 08aug2008 +chris+
typeset -T -U -gx -a RUBYLIB rubylib ':'
rubylib-add() { rubylib+=("$@") }
rubylib-del() { for i ("$@") { rubylib[(r)$i]=() } }
rubylib-reset() { rubylib=(); [[ -f ~/.rubylib ]] && source ~/.rubylib }
rubylib-reset
This creates a zsh array rubylib which value reflects $RUBYLIB and
vice versa (zsh does the same for $PATH and $MANPATH, for example),
and defines three functions to add and remove paths as well as reset
the variable.
Also, create a file ~/.rubylib where you set the defaults.
I simply use:
rubylib-add ~/projects/{testspec,bacon,rack}/lib
rubylib-add ~/src/{camping,markaby}/lib
Remember, you can use the full power of zsh to set this:
rubylib-add ~/src/rubystuff/*/(lib|ext)(/)
You need to use (x|y) instead of {x,y} here to only expand to
existing files. The final (/) ensures these files really are directories.
Reload your .zshrc, and voila, your packages are accessible from every
Ruby script. Now, if a project has different requirements, just
create a script there to adjust $RUBYLIB. Or use vared to
interactively change the load path.
[Thanks to et for improving rubylib-del.]
NP: Curve—Dirty High