CWOB without tweets
February 7th, 2010 at 8:49 am
Looking through my RSS reader this morning, I noticed that Andy Ihnatko has installed a WordPress plugin that collects and summarizes his Twitter stream from the previous day and publishes it as a blog post on the Celestial Waste of Bandwidth.1 Since I
- subscribe to his RSS feed
- follow him on Twitter, and
- don’t feel the need to read everything twice,
I’ve used Yahoo! Pipes to create a customized feed that filters out the Twitter summary posts.
The URL for the feed is at this link.
Regular readers of this blog may be arching their eyebrows. Didn’t Dr. Drang inflict exactly the same sort of redundancies on us last year? Yes, I did, and I’m sorry for it. In my defense, I’ll point out that I
- linked to Pattrick Mosby’s Pipes filter, which filtered out the posts with my tweets;
- later provided my own Pipes filters that did the same thing; and
- eventually dropped the Twitter posts entirely.
I wouldn’t be surprised to see Andy go through the same steps.
-
Ah, I remember when it was just a Colossal Waste of Bandwidth. ↩
A new pocket pen
February 6th, 2010 at 1:02 pm
This morning I dropped our van off for a brake job and was killing time at a nearby Staples while my wife came to pick me up. While I was there, I found these house brand mini gel pens (item #636172) and picked up a box of twelve for about $5.
When closed, the pen is about the same length as a Fisher Space Pen, which is a convenient size for keeping in my pocket. When open, it’s a little shorter than the Fisher, but still easy to write with.
Why do I want to replace the Space Pen? Mainly because it doesn’t leave a smooth line. I’ve stuck with it because of its size and because its ink doesn’t smear. Generally, I prefer gel pens like the Pilot G2, but
- Their ink is a little smeary, which isn’t a big deal in the office, but can be a real pain out in the field.
- Their mini pens are hard to find nowadays.
The Staples pen leaves a smooth line that dries instantly on the paper I typically use. I can run my finger across something I’ve just written and get no smearing whatsoever.
Another advantage of the Staples pen over the Fisher is pocket clip. I doubt I’ll be cliping it in my pocket very often, but it will keep the pen from rolling off slanted surfaces, a constant problem with the Fisher.
The biggest downside of the Staples pens is that they feel cheap—mainly because they are. At least I won’t worry much about losing them. If I remember right, the Space Pen cost as much as four dozen of these.
More Avery labels
February 4th, 2010 at 4:02 pm
This week I had to create lots of small labels to attach to laboratory samples. To make this easier, I modified my file folder label script to handle the smaller Avery 5167 labels, the kind usually thought of as return address labels.
The new program, called ptlabels (“print tiny labels”), follows the same logic as the old one and uses the same command-line options. You can tell it which row and column to start on through the -r and -c options. The input format is also the same:
- Individual labels are separated by a blank line.
- Header lines, which get printed in bold, are designated by a leading hash mark.
- Header lines can have a left-justified and right-justified part; they’re separated by a vertical bar.
- Headers apply to all subsequent labels until a new header line is encountered.
As an example, this input
#Lorem project|1234
Sample 1
Sample 2
Sample 3
Sample 4
Sample 5
Sample 6
Sample 7
Sample 8
#Dolor project|9876
Sample 1
Sample 2
Sample 3
Sample 4
passed to
ptlist -r 3 -c 2
generates this output
As with the file folder label script, I find it easiest to run the script in TextMate via Filter Through Command… (⌥⌘R).
The script is in Perl, because that was my main language back when I wrote the original version. Rewriting in from scratch in Python would have been a waste of time.
1: #!/usr/bin/perl
2:
3: use Getopt::Std;
4:
5: # Usage/help message.
6: $usage = <<USAGE;
7: Usage: ptlabels [options] [filename]
8: Print tiny labels on Avery 5167 sheets
9:
10: -r m : start at row m (range: 1..20; default: 1)
11: -c n : start at column n (range 1..4; default: 1)
12: -h : print this message
13:
14: If no filename is given, use STDIN. A label entry is a plain text
15: series of non-blank lines. Blank lines separate entries.
16:
17: The first line of an entry is special. If it starts with a #, then it's
18: considered a header line. Everything in the header line up to the | is
19: printed flush left in bold and everything after the | is printed flush
20: right in bold. Subsequent lines are printed centered in normal weight.
21: If the first line of an entry doesn't start with #, it uses the header
22: of the previous entry.
23: USAGE
24:
25: # Set up geometry constants for Avery 5167.
26: $topmargin = 0.55;
27: $pocol[1] = 0.45;
28: $pocol[2] = 2.50;
29: $pocol[3] = 4.55;
30: $pocol[4] = 6.60;
31: $lheight = 0.50;
32:
33: # get starting point from command line if present
34: getopts('hr:c:', \%opt);
35: die $usage if ($opt{h});
36:
37: $row = int($opt{r}) || 1; # chop off any fractional parts and
38: $col = int($opt{c}) || 1;
39:
40: # Bail out if position options are out of bounds
41: die $usage unless (($row >= 1 and $row <= 20) and
42: ($col >= 1 and $col <= 4));
43:
44: # Set initial horizontal and vertical positions.
45: $po = $pocol[$col];
46: $sp = ($topmargin + ($row - 1)*$lheight);
47:
48: # Pipe output through groff to printer (manual feed).
49: open OUT, "| groff | lpr -o ManualFeed=True";
50: # Change to PDF before sending to printer.
51: # open OUT, "| groff | ps2pdf - - | lpr -o ManualFeed=True";
52: # Preview output instead of printing directly.
53: # open OUT, "| groff | ps2pdf - - | open -a /Applications/Preview.app";
54: # Print raw troff code for debugging.
55: # open OUT, "> labels.rf";
56: select OUT;
57:
58: # Set up document.
59: print <<SETUP;
60: .vs 12
61: .nf
62: .ll 1.50i
63: .ta 1.50iR
64:
65: SETUP
66:
67: # The troff code for formatting a single entry, with placeholders for
68: # positioning on the page. The magic numbers embedded in the formatting
69: # commands make the layout look nice.
70: $label = <<ENTRY;
71: .sp |%.2fi
72: .po %.2fi
73: .ps 10
74: .ft HB
75: %s
76: .ps 10
77: .ft H
78: .ce 2
79: %s
80: .ce 0
81: ENTRY
82:
83: # Slurp all the input into an array of entries.
84: $/ = "";
85: @entries = <>;
86:
87: $bp = 0; # we don't want to start with a page break
88:
89: foreach $body (@entries) {
90: # Parse and transform the header and body.
91: if ($body =~ /^#/) { # it's a header line
92: ($header, $body) = split(/\n/, $body, 2);
93: $header = substr($header, 1);
94: $header =~ s/\|/\t/;
95: }
96: $body =~ s/\s+$//;
97:
98: # Break page if we ran off the end.
99: if ($bp) {
100: print "\n.bp\n"; # issue the page break command
101: $bp = 0; # reset flag
102: }
103:
104: # Print the label.
105: printf $label, $sp, $po, $header, $body;
106:
107: # Now we set up for the next entry.
108: $col = ($col % 4) + 1; # step to next column
109: $po = $pocol[$col];
110: if ($col == 1) { # we just went down a row
111: $row++;
112: if ($row > 20) { # we just went off the bottom
113: $bp = 1; # start a new page
114: $row = 1; # at the top
115: }
116: $sp = ($topmargin + ($row - 1)*$lheight);
117: }
118: }
The geometry constants in Lines 26-31 were initially set by making measurements of the labels and then adjusted through trial and error until the printing was nicely aligned with the die cuts on the label sheets. The final values are based not only on the sheet geometry, but also on how the labels pass through my printer via the manual feed slot. For good alignment on another printer, the values might need adjusted by a few hundredths.
Line 49 was also written with my default printer in mind. Because it’s a PostScript printer, I can take the PostScript output directly from groff and pipe it to lpr—no need to convert it first to PDF and no need to use lpr’s -P option to tell it which printer to use. (The -o option should be self-explanatory.)
Line 51 (commented out) is an example of what you may need to do if you don’t have a PostScript printer.
51: # open OUT, "| groff | ps2pdf - - | lpr -o ManualFeed=True";
Ps2pdf is part of Ghostscript, an open source suite of PostScript utilities that doesn’t come with OS X, but which I find invaluable. The two hyphens after ps2pdf tell it to use standard input and output instead of files on disk.
A more Mac-like possibility is shown in Line 53:
53: # open OUT, "| groff | ps2pdf - - | open -a /Applications/Preview.app";
This generates the PDF and opens it in Preview so you can see it before printing. I’m a wild and impetuous sort of guy, so I just send it off the printer and let the ink fall where it may.
The Toyota pedal problem
February 3rd, 2010 at 9:59 pm
I’m not a big fan of the Chicago Tribune,1 but I have to say it did a pretty good job yesterday explaining the Toyota pedal recall that’s been all over the news lately. The article is only so-so, but the graphic that accompanies it, by Phil Geib and the improbably-named Max Rust, answered many of the questions I had.
[Click on the graphic to get a slightly larger version.]
Comparing the drawings to a photo of an actual pedal (on my 2007 Camry), we see that the parts in question are all inside a plastic housing near the pedal’s pivot.
I couldn’t shoot a photo with the same point of view as the drawing because its a little cramped down there, but I think you get a sense of where everything is. In addition to the gas pedal, you can see the brake pedal (lower left foreground) and part of the steering mechanism (the shaft with the yellow-orange stripe at the upper left corner).
The gas pedal is a “drive-by-wire” system. There is no mechanical connection between the pedal and the engine; the pedal sends electrical signals that describe its position to a controller which runs the fuel injectors. (In my photo you can see the wires coming up off the top of the pivot housing and leading into a black corrugated conduit.) This is very different from the way cars used to work, and to give the pedal the traditional “feel,” Toyota has incorporated two sets of plastic teeth that rub against one another and provide some of the resistance felt by the driver’s foot.
Additional resistance comes from the pedal’s return spring, which, for clarity, isn’t included in the drawing. The return spring is what, under normal circumstances, pushes the pedal back up when you take your foot off the gas.
The toothed portions of the blue and tan parts slide on one another, the blue part rotating with the pedal and the tan part remaining stationary. The friction between the teeth is what generates the resistive force. Apparently, moisture on these plastic parts can increase the friction between them, and if the friction gets large enough, the return spring can’t overcome it and the pedal won’t return to the up position when you remove your foot. You may have heard this called “sudden acceleration” in news reports, which gives the impression of the gas pedal moving down on its own. “Stuck throttle” or “stuck accelerator” would be a more accurate name for the problem.
[Aside: Friction is an interesting force because it always opposes motion. When you press down on the gas, the friction and the return spring are acting in concert, both pushing up to resist the downward motion. When you take your foot off, the return spring continues to push up, but the friction suddenly changes direction to push down, resisting the spring.]
Toyota’s page for the pedal recall mentions wear of the plastic as another factor in the sticking pedal problem, so it’s not clear whether the problem is caused by an increased coefficient of friction, surface damage from galling, or some combination of both. Regardless, Toyota’s solution is to change the relative positions of the plastic teeth and reduce the friction.
Dealers will be installing what Toyota is calling a “reinforcement bar” (but should really be called a “spacer” or “shim” because it isn’t changing the strength of the parts, it’s changing their position) behind the tan part. The Tribune drawing does not do a good job of explaining how that shim is going to reduce the engagement of the two sets of teeth, but it seems clear that that’s the intent.
One thing I still don’t understand, and something I’ve not heard Toyota address publicly: How will the new, reduced friction affect the feel of the gas pedal? Presumably, the pedal resistance I get now will be lessened after I take my car in for the recall fix. Will it feel too floppy? If not, why did Toyota have the higher resistance to begin with?
Frankly, I’m curious why a friction mechanism was chosen in the first place. Toyota obviously wanted to get a particular relationship between the resistive force and the pedal deflection, but I don’t see why that couldn’t be achieved with a spring package of some sort. Mechanical engineers have been designing spring mechanisms for a long time and can get all kinds of force-deflection relationships.2
Maybe I’m just out of date and friction mechanisms like this are common in brake systems nowadays. If you know what other manufacturers do, I’d like to hear about it in the comments.
Update 2/4/10
I’ve known for a few days that there are “good” pedals and “bad” pedals, but it wasn’t until this morning that I learned who their manufacturers are. The good pedals, not subject to the recall, are made by Denso, and the the bad pedals, which are going to have the shim fix described above, are made by CTS.
It turns out that my pedal is a Denso. The Denso name is molded into the pivot housing, something you can’t see in my photo. Also, the housings of the two designs look very different; the CTS doesn’t have that circular area with radial spines sticking out of the side. You can see photos of the two designs at this site. Note: I am not endorsing anything said on that site, as I have not read through it in detail. I’m just linking to it as a source of photos showing the difference between the two types of pedal. It also has some nice photos taken with the housings opened.
-
What’s wrong with the Trib? To start: its editorial position, its choice of columnists on the op-ed page, its placement of John Kass in the old Royko spot, and its many years of owning the Cubs. ↩
-
If your experience with springs is limited to what you learned in physics class, you may think that all springs are linear. Ut tensio sic vis, and all that. But if you expand your concept of “spring” beyond helical coils of uniform wire many more things are possible. ↩
Iraq and Afghanistan, January 2010
February 2nd, 2010 at 6:35 pm
Military deaths in Afghanistan ticked up last month; military deaths in Iraq stayed very low.
The war in Afghanistan is now well into its ninth year. We’ve been there longer than the Soviets were in the 80s.
Misty water colored memories
January 30th, 2010 at 4:12 pm
Among the many disadvantages of middle age are: the loss of suppleness in both your mind and body; the simultaneous loss of hair where you want it and growth where you don’t; and the recognition that people in Cialis commercials are meant to represent you (albeit much better looking). One of the few advantages is the pleasure you get from complaining about how the world is going to hell in a handbasket and how much better things were in your day.1 I’m sorry to say that an unfortunate side effect of this week’s iPad announcement is that pre-middle-agers are now horning in on nostalgia, a pastime that should be restricted to their elders.
For example, both Mark Pilgrim (37) and Alex Payne (26!) have written little essays on how the iPad is going to destroy the idyllic world in which they grew up and blossomed, replacing it with a harsh dystopia in which turtlenecked priests in Cupertino decide who may learn to program and who may not. The essays have struck a chord with other wet-behind-the-ears programmers who are worried that the rise of appliance computers will push out the kind of open, tinkerable computers they grew up with.
Maybe they’re worried because they’re so young they’ve never seen change before. I have no doubt that iPad-like devices will change the way computing is done, and I have no doubt that this will make the practice of programming very different 10-15 years from now. But it doesn’t worry me, because I’m old enough to have seen changes at least as drastic.
When I took my first programming class— Well, let’s stop right there. When I started programming, almost everyone learned to program by taking a college-level class. This was the late 70s, and although the personal computer revolution was under way, PCs were by no means common.
The first order of business in my introductory programming course was learning how to use a keypunch machine. That’s how we made the stacks of cards fed into the computer. We almost never saw the computer itself. Computer operators—talk about a priesthood!—would come out of the machine room, pick up the stacks of cards, and do God knows what to them. Some time later (often hours later), the cards would be returned to us along with a printout of the results, which were usually a set of compiler errors.
A year or two later, when I first sat down to work at an interactive terminal, it was an absolute revelation. I could correct my typing errors by backspacing!
The march of computing history has been toward greater accessibility. More computers, more people using computers, and more people able to program their computers. I don’t see this changing.
The nature of programming will definitely change, just as it has in the past. My first computer programs were compiled, and hardcore programmers wrote in assembly language. Nowadays it’s more common for people write in interpreted (or perhaps semi-compiled) languages. No one seriously considers this to be a sign of the death or programming.
I was particularly struck by one part of Mark Pilgrim’s essay. He talks about starting in BASIC on an Apple ][e and then moving on to a Mac, where he played with MacsBug and ResEdit. The thing is, in 1984 much of what is now being said about the iPad was being said about the Mac. You couldn’t write programs on the first Macs, development was done on a Lisa. It wasn’t until HyperCard that the Mac had a simple, free, Apple-supported development environment that kids could play around with.
I’m not predicting a native development environment for the iPad, but I wouldn’t be surprised to see Apple loosen its restrictions as time goes on. And in the meantime, the iPad will come with a JavaScript interpreter, which clever people will be able to use for some elementary scripting. And Apple will be violating the letter of its own “no interpreters” policy when it ships Numbers. I’m not saying spreadsheets are the best way to learn programming, but then again, neither was BASIC.
So buck up, Gen Xers and Gen Yers and whatever other Gens there are! Things won’t be as bad as you fear.
And get off my lawn.
-
This does not, of course, prevent you from also lecturing the young on how tough the world used to be and how easy they have it. Memory loss allows a certain inconsistency. ↩
The iPad checklist
January 28th, 2010 at 12:03 pm
Early on in yesterday’s presentation, Steve Jobs listed seven tasks the new iPad had to be better at, when compared to either a smartphone or a notebook computer, to justify its existence.
Every task on the list had its own little section of the presentation, and at the end Jobs basically said “We think we’ve done it.” Generally, I’d agree, but not with every item on the list.
Browsing
I give this one to the iPad. For what most people do all the time, and what everyone does most of the time (thank you, Mr. Lincoln), the iPad will be better than a notebook computer because of its direct manipulation of the items on the screen and its greater portability. There will, no doubt, be sites that won’t fit nicely into its 1024×768 screen, but those are few and far between. (I can say this with some authority. My notebook computer is an old iBook G4 with that same screen size; horizontal scrolling is very rarely needed, and when it is it’s mainly because I have my Dock on the side, eating up 50 pixels or so.)
That the iPad will be better for browsing than a smartphone should be obvious. The larger screen more than makes up for the reduced portability.
For many people, the iPad will beat the smartphone and the notebook, but I’m not one of those people. Nor, I suspect, are most of the people who’ll be writing reviews of the iPad, so don’t be surprised to see the iPad’s email client get low marks. If your emails tend to have a lot of writing in them or tend to have multiple attachments, the notebook will always be a better email machine. The prospect of using a real external keyboard with the iPad doesn’t change this; adding a keyboard nullifies the iPad’s portability advantage.
There are, however, people for whom email is mostly a matter of reading and categorizing, with writing that is seldom more than a paragraph or so. For these people the iPad’s combination of portability and size will make it superior, although they may be scared off by reviews of the virtual keyboard written by people who type for a living.
Smartphones are probably still the best email machine for the constant traveler, but I wouldn’t be surprised to find the iPad beating out the smartphone for many of these folks. I often see these people eating lunch at WiFi hotspots, and if the iPad can take over for their Filofax/DayRunner it will also turn into their email machine.
Photos
To me, this isn’t even close. Smartphone screens are way too small and keyboards make notebooks too clunky. Unless its software is extremely badly written, the iPad will be almost perfect for viewing photos.
A sidenote: I like the idea, mentioned in the presentation, of having the iPad act as a digital picture frame when its not otherwise in use. But because the dock connector is on one of the narrow sides, the picture frame will always be in portrait mode, which
- isn’t ideal; and
- isn’t even the best compromise, as most photos are taken in landscape mode.
Maybe a third party will come up with a better way to use the iPad as a digital picture frame.
Video
Let’s start by stating the obvious: watching video on the iPad will not be better than watching it on a big screen TV or in a movie theater (if you can find a theater with a reasonably quiet audience). But the iPad isn’t supposed to be better than a TV or a theater, it’s supposed to be better than a smartphone or a notebook computer. And I think it is, because it has a better balance of size and portability.
The 4:3 aspect ratio has some people puzzled, and some are scoffing at the letterboxing of wide screen movies. But let’s say Apple was limited to 1024 pixels in the long direction, perhaps by the economic constraint of delivering a $500 product, perhaps by the geometric constraint of making a handheld device that’s less than 10″ in the long direction. Either way, your movie isn’t going to be more than 1024 pixels wide. Should Apple make a skinny device with fewer pixels in the short direction—1024×576 would give a 16:9 aspect ratio—or should it fatten up the device to be more usable for other applications and letterbox the movies? I think the right answer is obvious, and that’s what Apple did.
Update 1/29/10
Take a look at the specs for the 16:9 JooJoo (née CrunchPad).1 Yes, it’s 1366×768 pixels, but it’s also nearly 13″ long, more than three inches longer than the iPad and nearly a pound heavier (2.4 lb vs 1.5 lb for the WiFi-only models). That’s a big reduction in portability, a reduction that Apple clearly didn’t want to make.
Music
As with photos, I think this one isn’t even close, except this time I’d say the clear winner is the smartphone, and there’s no way a larger device could be better. A music player needs only enough screen space to help you navigate your collection; everything beyond that is a waste. The 250 million iPods Apple has sold so far is proof of that. Are you going to walk around town or work out at the gym listening to music on your iPad? Of course not.
Games
I’m not the right person to judge this one, because I’ve never really gotten into playing electronic games. I was in college before video games took off, and I think the mania has to take hold of you when you’re in your early teens at the latest.
I’m not even sure a winner can be declared in this category, because games can be designed—and are designed—specifically for the platform on which they run. For games that fit perfectly on the iPhone screen, the extra real estate of the iPad will mean nothing. The iPad, in turn, will certainly be able to play games that wouldn’t fit on an iPhone. I tend to think the direct manipulation available on touchscreen devices makes them superior to notebooks, but there may be games where the clicking of a few tactile buttons is essential to the experience.
eBooks
The iPad wins this category in a rout. It is the same size and shape as a book (in fact, its height, width, and weight are a very close match to a particular book on my shelf: the first edition of Matt Neuburg’s AppleScript: The Definitive Guide from O’Reilly), which will make it very comfortable to read. I use Stanza on my iPhone, and I like having a few books in my pocket at all times, but there’s no way it can compare to the iPad.
Final score
For me, the iPad would be the winner in 5 of the 7 categories. For a lot of other people, it would win in 6 of the 7. Given that there was really no chance of it being a better music player (what was Apple thinking when they added that category?) this is a damned good score.
Does this mean I’ll be running out to get an iPad in a few months? No. The 7 items on Apple’s list aren’t everything I’m looking for. But they did make a pretty good case.
-
No, I don’t expect the risible JooJoo to actually be released. My point is that even its vaporous specs don’t look so good when compared to the iPad. ↩
My script hall of fame
January 27th, 2010 at 1:25 pm
Many of my posts here have been about the writing—or rewriting or rerewriting—of scripts to automate the dull, repetitive, clicky-click tasks so common to computer use. While almost all of these scripts have been worthwhile, a few have proved so useful that I use them on a weekly or even daily basis. These are the member of my personal scripting hall of fame.
Folder labels
I like the project file folders in my office to have crisp laser-printed labels. There are plenty of templates out there for Avery labels and their clones, but they’re usually made for MS Word or some other program I don’t use. Also, there’s a lot of repetitive typing associated with those templates, and I obviously want to avoid that. So I wrote a script called pflabels that takes plain text input in a simple format and generates output for printing on a sheet of 1″×4″ labels (Avery 5261 or the equivalent).
The input looks like this:
#Kernighan Building|4215
Drawings
Contract
Correspondence
Photographs and
videotape
#Ossanna Residence|4332
Report
Correspondence
The headings, which have the project name and number separated by the pipe character (|), are denoted with an initial hash symbol (#), and individual labels are separated by blank lines. If I’m going to make several labels for the same project (which is usually the case), I need only enter the heading once. The script takes two options, -r and -c, which tell it which row and column to start on, so it can print on label sheets that have been partially used.
I generally type up my label input in TextMate and then run pflabels on that input via the Text>Filter Through Command… (⌥⌘R) command.
Screenshot uploader
This script, called snapftp:
- Takes a snapshot of some portion of my computer screen.
- Names it.
- (Optionally) resizes it.
- (Optionally) uploads it to my blog.
- Puts the URL of the uploaded image on the clipboard for pasting into a post.
I’ve configured FastScripts to run snapftp with the ⌃⌥⌘4 key combination, a minor variation on the Apple-standard ⌘⇧4 key combo.
There are certainly commercial products that do some or all of these things, but none are so perfectly tuned to my way of working. I can’t imagine going back to writing posts like this without it.
Markdown links in TextMate
I write almost everything in Markdown, mainly because I can forget about the formatting and just type, but also because it’s so easy to read. To keep the visual clutter to an absolute minimum, I use reference-style links, which puts all the URLs at the bottom of the document, out of the flow of the text.
I use three TextMate command/snippet/macros to do this:
- One for inserting links as I type, triggered by ⌃L.
- One for inserting links after I’ve already typed out the text, triggered by ⌃⌥L.
- One for inserting Google’s I Feel Lucky link on text already typed, triggered by ⌃⌥⇧L.
The first two are described here, and the third is described here. They’re a bit complicated to set up but are wonderfully simple to use. I should probably turn them into a Bundle for easier installation.
URL getters for TextExpander
This started out as a set of scripts for getting the URL (or a shortened version of the URL) of the page showing on the visible tab of the frontmost Safari window, and the scripts were triggered by key combinations defined in FastScripts. Then, after seeing this tip by Jeff Gamet, I turned them into a set of TypeIt4Me snippets. When I switched from TypeIt4Me to TextExpander, I moved the snippet over and that’s what I use today.
The two workhorses are:
- The snippet triggered by
;furl, which gets the aforementioned URL and inserts it. - The snippet triggered by
;surl, which gets the URL, shortens it through the Metamark shortening service (run by perl.org), and inserts it.
I tend to use the first when writing posts like this or email and the second when using links on Twitter. The great advantage is that I can add a link to a page I’ve been reading without having to switch back to Safari to get it.
More recently, I added a few more snippets for getting the URLs of the first, second, third, and fourth Safari tabs, regardless of whether they are frontmost.
BBC Radio recording scripts for Audio Hijack Pro
These scripts, written in Python and AppleScript, differ from those described above in that I never actually run these scripts myself. They’re run automatically on a schedule set in Audio Hijack Pro, and they record and tag certain BBC Radio 2 shows and put them into my iTunes library for syncing with my iPod. In effect, they turn shows that aren’t podcasts into podcasts for me.
The scripts are described here and they’re also available in this GitHub repository.
Library loan tracking
This script, like the set of BBC scripts, is run automatically—in this case, by a launchd process. Every morning, it logs in to my local library and gathers information on all the items my family has checked out or on hold. It then sends that information to my wife and me in a nicely formatted email.
Now it’s true that my library emails us a notice shortly before an item is due, but the advantage of this system is that we see everything at once and can gather up all the books that will be due in the next several days before going to the library to make a return. And we don’t have to remember to sign on to the library’s web site; the information is delivered to us every day.
Suspend and sleep screen
This is a pretty recent script, but I’ve come to love it. Without logging me out, it suspends my user session and puts the display to sleep. Seeing the Desktop swing around in that cube animation (which I’ve been a fan of since Andy Hertzfeld used a simplified version of it in Switcher) has become the visual signal that my day at work is over.
Exploring the Simplenote API
January 20th, 2010 at 4:25 pm
I’ve been meaning to work with the Simplenote API ever since it was announced, thinking it would be a good way to keep my plain-text todo lists1 synced between my computers and my iPhone. I haven’t done any syncing yet, but I have written a utility script that will get me started.
There are, as you may know, already several ways to sync your Simplenotes. Most of them, unfortunately, are tied to special note-taking apps that I don’t want install. One, Fletcher Penney’s SimplenoteSync, is more general, but works by syncing all the notes to a set of files in a single directory on your local computer. I’m looking for something a little more fine-grained than that—a way of syncing individual notes to individual files that can be anywhere on my computer.
As a first step, I wrote the following script, simplenote-index, which gathers and prints out information for all the notes on the Simplenote server.
1: #!/usr/bin/python
2:
3: from urllib import urlopen # standard Python library
4: from base64 import b64encode # standard Python library
5: import simplejson # http://code.google.com/p/simplejson/
6:
7: # Login credentials.
8: email = 'someone@example.com'
9: password = 'seekret'
10:
11: # Get my authorization token for later calls.
12: loginURL = 'https://simple-note.appspot.com/api/login'
13: creds = b64encode('email=%s&password=%s' % (email, password))
14: login = urlopen(loginURL, creds)
15: token = login.readline().rstrip()
16: login.close()
17:
18: # Get the note index.
19: indexURL = 'https://simple-note.appspot.com/api/index?auth=%s&email=%s' % (token, email)
20: index = urlopen(indexURL)
21: noteList = simplejson.load(index)
22:
23: # Print the first line of each note along with its key.
24: baseURL = 'https://simple-note.appspot.com/api/note?key=%s&auth=%s&email=%s'
25: for i in noteList:
26: noteURL = baseURL % (i['key'], token, email)
27: title = urlopen(noteURL).readline().decode('utf-8').rstrip()[:40]
28: print '''Title: %s
29: Key: %s
30: Modified: %s
31: Deleted: %s
32: ''' % (title, i['key'], i['modify'], i['deleted'])
I think the comments explain it pretty well; there’s not much to it. It logs in, gets an authorization token, then collects the information on each of your notes on the server. Here’s the sort of output to expect:
Title: Hardware store
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRiF5BsM
Modified: 2009-09-08 00:24:13
Deleted: False
Title: Metra Eastbound Mon-Fri
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRij5h4M
Modified: 2010-01-01 17:51:59
Deleted: False
Title: Metra Eastbound Saturday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRjC3h4M
Modified: 2010-01-01 17:52:33
Deleted: False
Title: Metra Eastbound Sunday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRi35h4M
Modified: 2010-01-01 17:52:46
Deleted: False
Title: Metra Westbound Mon-Fri
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRik5h4M
Modified: 2010-01-01 17:53:05
Deleted: False
Title: Metra Westbound Saturday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRjL3h4M
Modified: 2010-01-01 17:53:20
Deleted: False
Title: Metra Westbound Sunday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRjT3h4M
Modified: 2010-01-01 17:53:37
Deleted: False
Title: Swimming City Times 2009
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRiG5BsM
Modified: 2010-01-01 17:54:33
Deleted: False
Title: Swimming Meet Event Order
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRiH5BsM
Modified: 2010-01-01 17:54:59
Deleted: False
Title: Weight
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRiTii8M
Modified: 2010-01-20 12:35:52.611425
Deleted: False
Like Simplenote itself, the script treats the first line of each note as its title (the script prints only the first 40 characters of the title so the formatting doesn’t get screwed up). The important thing for the work I intend to do later are the keys. These are character strings that uniquely identify each note and are essential for scripts that read and write notes. The goal of simplenote-index is to give me those keys so I can hard-wire them into my syncing scripts.
With lots of notes, simplenote-index will give lots of output. Grep is a great way to filter the output down to a reasonable level. For example,
simplenote-index | grep -i -A 3 metra
will give me just the notes with the local train schedule
Title: Metra Eastbound Mon-Fri
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRij5h4M
Modified: 2010-01-01 17:51:59
Deleted: False
--
Title: Metra Eastbound Saturday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRjC3h4M
Modified: 2010-01-01 17:52:33
Deleted: False
--
Title: Metra Eastbound Sunday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRi35h4M
Modified: 2010-01-01 17:52:46
Deleted: False
--
Title: Metra Westbound Mon-Fri
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRik5h4M
Modified: 2010-01-01 17:53:05
Deleted: False
--
Title: Metra Westbound Saturday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRjL3h4M
Modified: 2010-01-01 17:53:20
Deleted: False
--
Title: Metra Westbound Sunday
Key: agtzaW1wbGUtbm90ZXIMCxIETm90ZRjT3h4M
Modified: 2010-01-01 17:53:37
Deleted: False
The -i option to grep makes the search case-insensitive, and the -A 3 option prints not only the line containing the search string, but the three lines after it as well.
With this easy one under my belt, I can start working on the more complicated syncing scripts.
-
No, I don’t use OmniFocus anymore. It was just too much work for the good I got out of it. I’m back to my TextMate-based LGTD system, which I’ve updated a bit and really should do a short post on. ↩
All you need
January 18th, 2010 at 10:02 pm
This page has some huge Beatles nerdery charts. The authorship/collaboration timeline is probably the best1,
but I also like the one that shows the song keys per album.
Least interesting, I think, is the self-reference chart because it’s so heavily dominated by “Glass Onion.”
There’s also a Charting the Beatles Flickr group, which I’ve just started to explore isn’t as big or as interesting as I thought it would be when I first saw it.
-
I’m a little surprised that “While My Guitar Gently Weeps” is credited solely to Harrison. Surely Clapton had some creative input on the guitar solo. ↩