It's Blog Action Day, and 2009's topic is climate change. With the most enlightening read on my 2008 list being Earth Policy Institute's Plan B 3.0, I was really glad to see Plan B 4.0 released a while ago -- it is available in its entirety in both HTML and PDF formats online, which happily means we can augment the material using tools like Greasemonkey and MashLogic (I am one of the developers and maintainers of both extensions).
Both extensions, in different ways, allow us to easily improve our reading experience by running code that someone else already wrote once, for material that was published by yet another unrelated person or organization, without any sort of organized cooperation among either of us. I find that notion incredibly powerful, and an uplifting thought about where decentralized cooperation is taking us online.
When I read Plan B 3.0 (the paper copy I bought at the release party of the Swedish translation, as it were), I found myself wishing I could more effortlessly look up the many high quality source references that are strewn about the book for the immense amount of facts about recent macro events affecting our planet, on all sorts of levels, instead of flicking back and forth as soon as I got curious. Footnotes work really well in hypertext. The online versions actually don't yet do that for footnotes.
So I wrote a handy user script that not only adds bidirectional footnote hyperlinks, but also pulls them into the end of the paragraph that references them, the first time you click them. Try it (direct install link); it's a very comfortable reading style.
If you run MashLogic too, you get essentially the same feature for bringing in content from Wikipedia (and sometimes references to people from LinkedIn), without losing more focus on the material than you find you want to, getting up to date about relevant data about, say, the World Food Programme's operations, or where the Xinjiang Province is. I find it a rather rich and low-effort way of broadening your general knowledge about everything.
It would be delightful if Google Books would export an index of their entire repository of books, and provide a linking scheme so we could turn those book and page references in the footnotes into actual hyperlinks too, the way we currently do with Wikipedia article names. Take the first reference in the introductory chapter, for instance (full precision of the deep-linkage only available after you install the above mentioned Greasemonkey script :-) -- with a catalog of all book titles to book id:s available, we could turn that into a link like "[1] Sandra Postel, Pillar of Sand (New York: W. W. Norton & Company, 1999), pp. 13–21.]" -- just like that.
The web is a very exciting medium, only just starting to show its potential. And as for Plan B 4.0, I can warmly recommend sinking into it, letting yourself fascinate with richer understanding of where we're heading, and all the fascinatingly intricate ways our global economy and ecology connect, affect each other, consequences and solutions.
There's even a good number of tips for ways we can all join in making the world a better place on the Earth Policy Institute's site. Happy Blog Action Day, and do spread the word!
2009-10-15
2009-09-04
How to convert a FAT32 disk to NTFS
I had a near-Windows experience today.
I have had an old 500GB USB disk sitting around, that I used for manual backups in pre-Time Machine times, back when I deemed FAT32 to be the comfy file system choice for hooking up a disk with any computer I might want to reach it from. Today, I think that sweet spot is NTFS.
Especially as Time Machine doesn't want anything to do with FAT32 devices as backup targets.
I figured the easiest way to convert the filesystem in place (as I didn't have any other disk around) was to boot up a Windows XP virtual machine in Parallels and let Windows do it.
That procedure was perilous. If you ever embark on doing it yourself, here is how you probably want to do it:
If you skip that first step, you are wise to remember that a Windows machine needs baby sitting not to do bad things to itself. Like deciding it has found and applied security updates that it really wants to restart to complete in ten, nine, eight, ...all the while that long file system conversion pass is humming about in the background.
I have had an old 500GB USB disk sitting around, that I used for manual backups in pre-Time Machine times, back when I deemed FAT32 to be the comfy file system choice for hooking up a disk with any computer I might want to reach it from. Today, I think that sweet spot is NTFS.
Especially as Time Machine doesn't want anything to do with FAT32 devices as backup targets.
I figured the easiest way to convert the filesystem in place (as I didn't have any other disk around) was to boot up a Windows XP virtual machine in Parallels and let Windows do it.
That procedure was perilous. If you ever embark on doing it yourself, here is how you probably want to do it:
> net stop wuauserv
The Automatic Updates service is stopping....
The Automatic Updates service was stopped successfully.
> convert E: /fs:ntfs
The type of the file system is FAT32.
Enter current volume label for drive E: [...]
> net start wuauserv
The Automatic Updates service is starting.
The Automatic Updates service was started successfully.
If you skip that first step, you are wise to remember that a Windows machine needs baby sitting not to do bad things to itself. Like deciding it has found and applied security updates that it really wants to restart to complete in ten, nine, eight, ...all the while that long file system conversion pass is humming about in the background.
2009-08-07
Fixing $(document).ready() to work for any document
The first time I saw jQuery's
The first time I used it in the latter capacity I was a bit saddened to find that it was not quite that good yet; it always tests the same document that jQuery itself was loaded into. (At present time, meaning jQuery 1.3.2 and earlier.) The document object you pass isn't actually even fed to all the code that together implements the ready function.
As we needed it to do that at MashLogic though, my colleague Dave took to fixing it so it does indeed work that way, as per the jQuery ticket that has been sitting around for two years (from someone else that apparently wanted and expected the same thing), and I submitted a patch upstream. I'm hopeful it gets accepted for next jQuery release.
We even prepared a little test case that loads jQuery in an iframe and puts document ready callbacks on both itself and its parent window, which seems to work fine in all browsers and OSes we have tested it in so far.
I think the original ticket may have gotten closed over it often being a bit tricky to get a reference to the document object of an arbitrary frame or iframe for some frame you want to track -- the javascript security model forbidding DOM access to content in documents loaded from a different domain, for instance, and timing issues with grabbing a reference to the document object of a frame that is inlined in a document's source -- before we can get a handle to the document, it is a little difficult to have that parameter to pass to jQuery for listening in the first place, after all. But I hope such issues don't prevent the fix from landing, for the cases when we do have one.
$(document).ready(callback) idiom, I thought it was a great idea: not only is it readable as plain English, grep(1)able (it is available as $(callback) too, but I advise against using that in larger code bases, where you might need to dig up all references to it, at some time) and intuitive, it also lets you provide a different document object you are waiting for.The first time I used it in the latter capacity I was a bit saddened to find that it was not quite that good yet; it always tests the same document that jQuery itself was loaded into. (At present time, meaning jQuery 1.3.2 and earlier.) The document object you pass isn't actually even fed to all the code that together implements the ready function.
As we needed it to do that at MashLogic though, my colleague Dave took to fixing it so it does indeed work that way, as per the jQuery ticket that has been sitting around for two years (from someone else that apparently wanted and expected the same thing), and I submitted a patch upstream. I'm hopeful it gets accepted for next jQuery release.
We even prepared a little test case that loads jQuery in an iframe and puts document ready callbacks on both itself and its parent window, which seems to work fine in all browsers and OSes we have tested it in so far.
I think the original ticket may have gotten closed over it often being a bit tricky to get a reference to the document object of an arbitrary frame or iframe for some frame you want to track -- the javascript security model forbidding DOM access to content in documents loaded from a different domain, for instance, and timing issues with grabbing a reference to the document object of a frame that is inlined in a document's source -- before we can get a handle to the document, it is a little difficult to have that parameter to pass to jQuery for listening in the first place, after all. But I hope such issues don't prevent the fix from landing, for the cases when we do have one.
Subscribe to:
Posts (Atom)