Archive | October, 2009

unix permissions

26 Oct

$ find . -type d -print0 | xargs -0 chmod 0755
$ find . -type f -print0 | xargs -0 chmod 0644

feeling like a certain big brother contestant after much ie6 #cookie hassles

23 Oct

interesting – fixed an IE6 bug by changing css({overflow: “visible”}) to css({“overflow”:”visible”}); #ie6moments

22 Oct

scrumptious trails bookmarklet

22 Oct

see also

I’ve just checked in a bookmarklet for Scrumptious Trails, a URI/URL
Trails engine (
powered by TiddlyWeb.

Such a bookmarklet has interesting security issues, which cross over
into UI issues due to maintainability and cross-browser security

When the user clicks on the bookmarklet, the following happens:

* The bookmarklet code itself uses On-Demand Javascript to pull down
the real script. The web page providing the “add this bookmark” prompt
is generated from the server, with the URL for the real script
dynamically generated; TiddlyWeb is a redistributable web app, so the
location can’t be hard-coded by me. (visible at; in the source
at templates/ RATIONALE: Keeping the real script on the
server lets the developer keep it up to date, without having to ask
users to reinstall the bookmarklet (AKA “not gonna happen”). Also,
it’s cleaner from a maintainability perspective to keep the “big code”
in its own script, away from the bookmarklet.

* When the real script loads, it creates a modal dialog containing an
iframe which will show the “add trail” form; the iframe source is the
scrumptious server. (the real script resides at
The “real script” comes from the scrumptious server, *but* it runs
inside the new, random, interesting, site’s domain. So it has no
permission to read or write trails, due to the very sensible browser
cross-domain policies. That’s why it needs to open up an iframe.
However, we do need to open up the modal in the “real script”, since
the web app running in the iframe would have no way to create a modal
across the entire page; iframes can’t affect the display of their
parents’ UIs. (Though the converse is not true, leading to security

* Inside the iframe is an HTML file on the scrumptious server (visible
at, though you
wouldn’t normally visit it directly; and sourcing
/static/js/addResource.js). It shows the current trail and URL for the
page you’re adding, and lets you enter a title and note for it
(optional). When you submit, it PUTs to the server.

With all this, there’s some complicating message passing going on to
pass through the trail title, trail owner, server root, and
interesting page URL. The bookmarklet script sets some global
variables which the real script picks up (it could also try polling to
see when the real script – addResourceBookmarklet.js – has loaded, and
then pass them in as parameters). The real script then creates the
iframe, passing in those variables as URL parameters. When the user
submits, the iframe app uses HTML5 cross-frame, cross-domain messaging
to close the URL. (the
cross-frame tricks don’t work so well here, because the ones that are
still possible rely on special web pages at both ends, and we can’t do
that in this case; we can only pull in Javascript to the interesting
page, not create a page on that domain). In the event HTML cross-frame
messaging doesn’t exist, we resort to reloading the entire page. Ho

Yeah. All great theory. Now I’m going to the gym and when I’m back,
I’m gonna actually deploy this bad boy on *another* server, a server
that’s not my laptop. Then we’ll see what’s up.

Webwait Ottimizzare il sito ottimizzando il caricamento

22 Oct

Italian webwait screencast

make comments plugin observe frag ID

20 Oct

We’re doing a new ideas hackathon today in the osmoplex. I’ve been
working @buddenisms on the profile. Normally tiddlyweb instances just
have users, but in this app, we have a “profiles” bag with info about
the users.

As well as votes and ideas submitted, we’re showing comments the user
has made. This works fine simply by searching for all tiddlers in the
comment bag with “modifier” field set to the user whose profile we’re
showing. But I wanted to link to the idea they commented on, not the
comment itself which has no real UI. Easy enough – link to
/ideas/{{comment.topic}}. But I want it to jump down to the actual

Normally, this would be a frag ID, so
/ideas/{{comment.topic}}#{{comment.title}}. I thought that would work,
since the comments do include permalinks. But it didn’t, because the
comments are loaded dynamically, so they’re not present when the page
loads. So I modded comments.js to run the following on startup:

plugin.jumpToFragmentID = function(context) {
var hash = document.location.hash;
if (hash.length document.location.hash = “#_”; // dummy
setTimeout(function() { document.location.hash = hash; }, 100);

(While I remember, the other change is to link from the comment to the
profile. Since we’re not using openID, but a profile inside the
system, it required a hack of the part that generates the user’s URL.
I’ll need to make that an option to the comments plugin in the

Helpful Error Message #Fail from SVN

16 Oct

svn: The version resource does not correspond to the resource within
the transaction. Either the requested version resource is out of date
(needs to be updated), or the requested version resource is newer than
the transaction root (restart the commit).

I will shortly be googling for the fix…the likely fix could have
been included in the error message above.
Tell the user what happened, explain the consequences if it’s not
obvious, outline how to fix it, explain what to do if they can’t fix

This kind of stuff *can* be done in a command-line tool, especially
one as widely used as SVN. For comparison, this is how Rails
does it right: