Archive for the ‘mac’ Category

TextExpander 3

Smile On My Mac released a new version of TextExpander this week. It has some distinct improvements over the previous version and one disappointment.

TextExpander is a utility—it was a Preference Pane, but now it’s a regular application—that expands abbreviations automatically as you type. You define both the abbreviations and what they expand into to fit the type of writing you do. So if you do a lot of writing on, say, Castigliano’s Second Theorem, you could define an abbreviation like “c2t” that would expand out to the full expression. You can also define snippets (that’s what TextExpander calls its abbreviation/full expansion combinations) for the current date and time, as well as snippets that insert the output of AppleScripts or shell/Perl/Python/Ruby/etc. scripts. It’s a great utility, and I use it a lot.

(TextExpander is, I think, not quite as versatile as the snippet facility built in to TextMate, but it’s getting closer with every update. And it can be used in any application.)

The two big improvements in TextExpander 3 are multi-computer syncing of your snippet library via Dropbox and snippets with several fill-in-the-blank fields.

Syncing via Dropbox is pretty self-explanatory. If you work at more than one Mac, you can keep your snippet library in your Dropbox folder and it will automatically sync across your machines. I haven’t been able to test this, for reasons that I’ll explain later, but if it works it will remove one minor frustration: typing an abbreviation defined on your other computer and not seeing it expand.

Snippets with several fill-in-the-blank fields will be great for certain types of boilerplate text. When one of these snippets is triggered, it pops up a window with the text, and you fill in the empty fields, tabbing from one to the next as you type.

Earlier versions of TextExpander had a less useful version of this. You could create a snippet that put the cursor at a spot in the middle of the text after expansion; this gave you the effect of a single fill-in-the-blank field. Multiple fields will let you use a single snippet to the do the work that used to take several.

So I’m generally happy with the upgrade, but there is a sore point: TextExpander 3 requires Snow Leopard, and one of my computers is a iBook G4, and it can’t run Snow Leopard because it doesn’t have an Intel processor. I don’t know if the Smile On My Mac folks have been listening to Brent Simmons, but this restriction is very disappointing to me. I haven’t replaced the iBook with a newer MacBook because I like its form factor and much of what I do on it is text-based, which doesn’t need a lot of computing power. Now, the latest version of one of my workhorse utilities for text won’t run on it.

Of course, TextExpander 2.x still runs just fine on the iBook, so it’s not like I’ve lost anything. But I can’t take advantage of the Dropbox syncing if only one of my computers has that feature. And it’s really annoying to see this update sheet appear on a machine that can’t install the update.

That’s just rubbing it in.


BBC iPlayer site-specific browser

As I’ve mentioned at great length in earlier posts, I use Audio Hijack Pro to record BBC Radio shows that are streamed over the internet but don’t come in podcast form. Until recently, I’d been using Safari to open the stream URL. Generally, this worked out fine, but if I wanted to browse while recording something in the background, I had to follow two rules

  1. Don’t open any sites that play sounds, as these will be recorded on top of the show.
  2. Don’t quit Safari when I was done browsing, as that will kill the recording.

Sometimes I’d forget to follow these rules and ruin a hour or more of recording. Whenever this happened, I’d try to fix the problem by swearing at myself, but that never seemed to work.

What has worked is creating a site-specific browser (SSB) for recording. I used Fluid1 to create an SSB, called BBC iPlayer, that opens a generic BBC page.

BBC iPlayer, then, is the application whose sound output gets hijacked by AHP.

AHP tells BBC iPlayer to navigate away from the generic page to the URL for the stream. Now I can browse in Safari without worrying that something I do will screw up the recording.

Luckily, the various scripts I wrote for getting the streaming URL from the BBC—all collected in this GitHub repository—are browser-agnostic, so they didn’t have to be edited at all. Only the settings in AHP itself needed updating.

I was going to use the current BBC logo as the icon for the BBC iPlayer SSB, but its horizontal layout doesn’t work well as an icon. So I found a screenshot of the old spinning blue globe logo (the one you’d always see during Monty Python’s Flying Circus) on this BBC logo history page and did a bit of editing.

It doesn’t look great at a small size, but it’s instantly recognizable to me.

One more thing: As you can see in the AHP screenshot, one of my upcoming recordings is of an episode of Radio 2’s semi-regular show, The Record Producers. The subject of this Saturday’s show will be Todd Rundgren. Obviously, I have no idea if the show will be any good (personally, I’m hoping they don’t spend too much time on Bat Out of Hell), but Todd fans will probably want to listen regardless.


  1. Fluid is what I used to create my Twitter client, Dr. Twoot


Making a quick email list

I coach my younger son’s YMCA basketball team and use email to send updates and reminders to the other parents. Today my wife needed that list of addresses to coordinate an after-game dinner with the parents of a (friendly) rival team. My first thought was to export the list as a vCard file from my Address Book and email it to her, but importing that into her Address Book would have led to several duplicates and more work for her to weed them out. Also, she had no interest in the phone numbers and other contact information I have for some of these parents; she just wanted the email addresses.

So I went ahead and did the vCard export, and typed up this simple Python filter:

 1:  #!/usr/bin/python
 2:  
 3:  contacts = open('/Users/drang/Desktop/contacts.vcf')
 4:  
 5:  for line in contacts:
 6:    if line[:3] == 'FN:':
 7:      print line[3:],
 8:    if line[:6] == 'EMAIL;':
 9:      colon = line.find(':')
10:      print line[colon+1:]

The name and path to the vCard file is in Line 3. I had the vCard file open in TextMate as I wrote the script. The lines with the important data looked like this:

FN:Ms. Laura Ipsum
EMAIL;type=INTERNET;type=HOME;type=pref:lipsum@gmail.com

Lines 5-10 were written with this format in mind. The output was a list of names and addresses

Ms. Laura Ipsum
lipsum@gmail.com

Ms. Dolores Amet
dolores@ametfamily.com

Ms. Elizabeth Consectetur
liz1729@aol.com

which I copied into a email to my wife. Five minutes of effort, maybe, with some interruptions.

I’m sure the script won’t handle every situation, but that’s OK. It was easy to write and it got me what I wanted quickly. I didn’t even save the script. I ran it within TextMate, using the Run Script command (⌘R) in the Python bundle. When I was done, I kept the script in an open window until I wrote this blog post around it.


Hardware cheapskates, unite!

Once again, Clark of Clark’s Tech Blog has relieved me of the pain of writing a post by putting my thoughts into words for me. In this article, he responds to Brent Simmons’ argument that developers should stop supporting Leopard in new versions of their software.

As Clark points out, the big problem with Simmons’ argument is that Snow Leopard is Intel-only. This punches a hole in Point 2 of his argument:

2. People who don’t upgrade their OS are, in general, the kind of people who just don’t buy software anyway. (Particularly in the case of 10.6, given how inexpensive the upgrade price was.)

I do buy software, and I did buy the upgrade to 10.6, but because one of my computers is non-Intel, that machine is still running 10.5. If you want to call me a cheapskate, go ahead, but at least get your terms right: I’m a hardware cheapskate, not a software cheapskate.


Microsoft’s text-like interfaces

Following a link from Daring Fireball, I read this article by Luke Wroblewski comparing the user interfaces of the iPhone and the new Microsoft Windows Phone 7 Series [sic]. The gist of the article is that the iPhone’s information-dense interface makes the user experience more efficient than that of the MWP7S. I agree with Wroblewski’s comparison, but I think he has the cause/effect relationship backward. The inefficiencies of the MWP7S interface aren’t due to the low density of information MS puts on the screen; rather, the screen is information-sparse because Microsoft has an institutional preference for layered, multi-step, inefficient interfaces. This preference goes back to the DOS days of character-based displays.

Back then, the menu of “user friendly” programs typically consisted of a strip of words running across the bottom of the screen. You’d choose one of these words through a set of keystrokes. If you were lucky, choosing that word would actually execute a command. More commonly, it would lead to a new set of words at the bottom of the screen and you’d choose one of them to execute the command. (If you were unlucky, this second choice wouldn’t execute a command, but would lead to yet another set of choices.) This layered approach wasn’t exclusive to Microsoft, it was a pretty common way of writing menu-based programs.

The Macintosh was a huge departure. Considered in the abstract, it didn’t seem like it should be. After all, its menubar was just a strip of words running across the top of the screen, and you had to choose commands from the individual menus. But somehow in practice, this didn’t seem like a two-step process. After a few minutes, you didn’t think “I’m going to click on the File menu, then drag down to the Save As… item,” you thought “I’m going to choose Save As… from the File menu.” The click and drag on the menu became a single step in your mind and in your hand.

The early versions of Word and Excel for the Mac worked like other Mac programs, with almost all the commands in the menus, but as Microsoft further developed Windows itself and the Windows versions of Word and Excel, the Mac versions began to take on the characteristics of their Windows cousins. More menu choices led to dialog boxes instead of actions. Buttons within dialog boxes led to other dialog boxes. It was the multi-layered, text-based interface all over again, just tarted up with a GUI. By the late 80s or early 90s, two clever Mac programs had been converted into clumsy oafs.

And the conversion was Microsoft’s choice. They’d already written programs that were Mac-like, and they could have used that experience to make efficient Windows programs. Instead they made awkward Windows programs and backported the awkwardness to the Mac side.1

That great advance in user friendliness, the Windows wizard, is another example of Microsoft using what is essentially a text-based interface in a graphical environment. At heart, a wizard is a series of multiple choice questions, something every beginning programmer learns to accomplish with write and read statements. The wizard just puts these questions in a dialog box with a (sometimes animated!) picture next to them.

Obviously, Microsoft has hundreds, if not thousands, of really smart programmers and designers on staff. I can’t believe that such talented people would make such poor decisions over such a long period of time if it weren’t an institutional requirement.

Update 2/17/10
I forgot to add that Apple is not immune to clumsy, over-layered interfaces. For example, if you manage two or more email accounts on your iPhone, you know how inefficient it is to go from the Inbox of one account to the Inbox of the other: climb two levels up, then two levels down.


  1. I’m pretty sure Apple’s “look and feel” lawsuit was under way, but I doubt that’s the reason Microsoft took the clumsy route. “Judge, if we had copied Apple, we wouldn’t have such a shitty interface.” 


PNotes

Here are a few miscellaneous paragraphs about my no-server personal wiki system.

I’m tired of calling it “my no-server personal wiki system.” From now on it’ll be called PNotes, which will at least save me some typing. Its GitHub repository will remain the same.

PNotes is missing two things most wikis have: a history of edits and a search field. But it’s easy to overcome both of these limitations.

When I need to create a set of notes for a new project, I copy the PNotes notes folder—my local version of what’s in the GitHub repository—to the new project’s folder and delete the .git subdirectory inside it. I then issue a

git init

command from within notes. This starts up a new git history that will focus not on the programming, which probably won’t change at all, but on the content files. From this point on, I use git add and git commit whenever I think it’s warranted. I’ve thought about putting git commit into the PNotes makefile, forcing a commit whenever I modify or make new HTML pages, but so far I haven’t done so. I prefer the freedom of committing only when I can think up a good commit comment.

Searching hasn’t been as big a deal as I first thought it would be. Normally, I know exactly which note page will have the information I’m looking for, and finding it is simply a matter of scrolling or using the browser’s Find command on that page. For those few occasions when I couldn’t remember where a piece of information is, I just opened a Terminal window in notes and used grep to find what I was looking for. This is not as smooth a solution as having a folder-wide search field available from the browser, but given the rarity of these searches, an in-browser solution just isn’t worth the effort.

One other thing I typically do when I create a new PNotes folder for a project: I replace the generic folder icon with a Moleskine notebook icon like one of these:

I found one of these, at a larger size, by doing a Google Image search and made the others by fiddling with the band color in Acorn. It’s nice to have the PNotes folder stand out.

A reminder on how to change the icon of a folder:

  1. Open the image you want to use and copy it to the clipboard.
  2. In the Finder, do a Get Info on the folder you want to change.
  3. Select the folder’s icon at the top of the Get Info window by clicking on it.
  4. Paste. The generic folder icon should be replaced by the image on the clipboard.

This post has turned out to be a bit more miscellaneous than I’d planned.


S5 and Firefox 3.6 on the Mac

Following up on my S5 post earlier this week, I should mention that the recently-released Firefox 3.6 for the Mac has a full-screen mode that’s perfect for presentations. It’s not just that the window grows to the size of the screen, the content area takes over the whole screen—no window chrome, no Dock, no menubar, much like DVD Player. Firefox has had this on Windows for a while, but not on the Mac. Safari has never had it either, unless you installed a plugin like Saft.


The no-server notes wiki

I’ve just pushed a new version of my unnamed no-server notes wiki to its GitHub repository. Notes can now be organized in subdirectories instead of all being at the top level. Here’s the README.


This is a no-server personal wiki system that I created to keep track of project notes for work. I’ve put it here because it may be useful to others.

Goals

This is what I want:

  1. A self-contained file or folder of files that includes everything needed to write and view the notes. I want it to be easy to copy from one computer to another and to archive to DVD. This eliminates most of the available wiki systems, which store everything in a central database.
  2. The notes themselves to be written in Markdown rather than some specialized wiki markup. I write everything in Markdown and don’t want to shift context when switching from notes to a report. In fact, I’d like to be able to copy directly from my notes—markup included—when writing a report.
  3. To write the notes in my text editor of choice rather than in an HTML text input box or a word processor. Currently, that editor is TextMate, but TextMate itself isn’t the point. The point is to take advantage of the comfort I feel working in my normal editor. There’s a reason old Unix hackers like to do everything in Emacs or vi; it’s just more efficient to do all your text work in one environment.
  4. To be able to change the visual style of the notes as my needs or tastes change.
  5. To create new notes quickly and easily.

Requirements

Apart from what’s in the repository, you’ll need

If you need to include mathematical formulas in your notes, you should consider installing Davide Cervone’s jsMath. Once you’ve installed it, you can activate jsMath in the notes by uncommenting Line 10 of the header.tmpl file and adjusting the jsmathpath variable in the project.info file to point to jsMath’s easy.js file.

File structure

The top level of the notes directory contains all the support files, that is, all the files that are distinct from the notes themselves. These files are:

Notes files contain the actual content. These files should all have the extension .md and can be in both the top-level directory and in subdirectories. Two sample notes files are included: aa-overview.md in the top-level directory, and testing1.md in the Lab subdirectory.

Creating notes

As mentioned above, notes are just plain text files written in Markdown and saved with an .md extension. The first line will be the note’s title and will appear in the sidebar.

I use ATX-style headers, with hash marks indicating the header level, and I start each file with a first-level header, like this:

    # Overview #

The build system is smart enough to get rid of the hash marks when making up the sidebar.

Notes files in subdirectories appear with greater indentation under the name of the directory—like an outline. Within each directory, the notes are ordered alphabetically according to their file names, so you can rearrange the order in which the notes appear in the sidebar by changing the file names without changing their content. At present, there’s no way to change the order of the subdirectories.

Executing make from the top-level directory will generate all the HTML pages, which can be opened with any browser. Subsequent executions of make will generate only those pages whose .md files are new or have been modified. Executing make clean will erase all the HTML files, but will not touch the .md files.

Editing notes

You can, of course, open any .md file in any text editor to make changes. If you’re using TextMate on a Mac, there’s a faster way: click the Edit in TextMate link in the side bar to instantly open the .md file in TextMate—no need to switch to the Finder, open the folder, and double-click the file icon. If you’re a BBEdit user, you can do the same thing, but you’ll probably want to change the name of the link. It’s on Line 33 of header.tmpl.

More details

I wrote a three-part series of blog posts describing this system and its scripts, here, here, and here. The scripts have changed since then, but the basic ideas are the same.

License

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. Do what you want with it, but provide a link back to either my blog posts or to my repository.


Misty water colored memories

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.


  1. 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

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.

Email

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

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.


  1. 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.