Idle Time

UPDATE: NO BUG! Serves me right for not testing a programming challenge before posting it. Thanks, Evan.

a = 42, b = 100;

Before you type “error on line 1”: No, it’s not a compilation error. The above code is legal, just wrong. The task before you is to explain how. ☺

(Experienced DOTB readers know that when I say RaABF, it was filed today, whereas when I say only ABF, it was filed previously.)

This bug is QuickTime Player, QuickTime, or QTKit should put off sleep during playback. It was filed on 2007-03-30 at 11:45 PDT.

(more…)

Here are three of my favorite Mitch Hedberg quotes.

• Hey, if you find yourself lost in the woods, fuck it—build a house. “Well, I was lost, but now I live here! I have severely improved my predicament.”

• Imagine being killed by a bow-and-arrow. That would suck; a arrow killed you? They would never solve the crime. “Look at that dead guy!—Let’s go that way.”

• [A commercial] says “You can have this product for four easy payments for $19.95”. I would like to have a product that was available for three easy payments, and one fuckin’ complicated payment. “We can’t tell you which payment it is, but one of these payments is gonna be a bitch!

  “The envelope will not seal,
  the mailman will get shot to death,
  and the stamp will be in the wrong denomination.

  “Good luck, fucker!”

  The last payment must be made in wampum!

All these are from MacCentral—not because I have any particular hatred for MacCentral; it’s just that I have MacCentral on My Yahoo! and I’m too lazy to seek out more stories. It’ll just be a bunch of quick hits—one or two comments per story.

So, CS3 is finally here. I, for one, intend to continue using CIFH and Lineform.

Just out of curiosity, though, I’m serious about the Rubber Band question. Have they finally added that to Illustrator yet?

Those of you with multiprocessor Macs may have been eagerly awaiting this, and now it’s here. CPU Usage version 0.4 makes the meter work correctly for multiple CPUs. (Obviously, actually having a multiprocessor Mac helped me test it. I went through 25 alphas back when I was on the Cube; thanks go out to my three testers for banging on those.)

The other big thing in the 0.4 release is that you can now have your CPU usage meter in the Dock tile. You can have the floater or Dock tile or both. I prefer having a floater up the right side of my screen, but if you’d rather have it in the Dock, now you have it.

Not too long ago, I was at the bank and decided to take this photo of a couple of magazines sitting next to each other. As you can see, I edited out the bank’s address.

I did this using Lineform. The problem is, Lineform is a vector app, so it doesn’t keep any EXIF data from the original image (most of the time, that would not make sense). In my situation, I did want to keep the EXIF info, but there’s no way to make Lineform do that.

So I wrote a command-line tool to bring EXIF properties over from one image to another image. I call this image exif-confer. Enjoy.

This bug is Apple applications use a modal window for print progress. It was filed on 2007-03-09 at 14:06 PST.

(more…)

I just updated the two paper images from my How to draw Beads article.

Brief recap: Each bead in the application has a sheen. The how-to includes two mock-ups that I drew on paper so that I could more easily write the Quartz code to draw them in the computer.

Those who saw the article before may remember how awful the mock-ups looked. In case you didn’t or you don’t, here’s how awful they looked:

Yowch. I didn’t have a scanner back then, so I did the best I could with my Zire 71‘s built-in camera. Mainly, it suffered from poor lighting: the Zire 71 is very sensitive to having or not having Just the Right Amount of light. In this case, I was on the not-enough side, so I had to use Photoshop to try to make up the difference.

I said to myself that when I got a scanner, I’d redo the images. I got one last week, so now I’ve done it and you can see the glorious results:

If you’ve never seen the how-to before, have a look. There’s some good info there on drawing and Quartz.

A list of things that you must do for every app. Most of these should be done up front; some can be put off a little bit; some can be put off a long time, but ought to be done at some point rather than put off into the indefinite future.

Also available in TaskPaper format, in case you’re a TaskPaper user.

1. Version control is mandatory. I recommend Subversion (which is free and open-source). The advantage of version-control is time travel: You can easily go back to any previous version of your code, or even certain files. This lets you delete with confidence. Be sure to follow the trunk+branches+tags layout for your repository; you can create branches for experimentation and tags for released versions. Both these operations are cheap in Subversion. The easy way to install Subversion is to use Martin Ott’s Subversion Installer package.

2. Resolution independence. In particular, shun raster images (except for your Finder icons). Use vector graphics, either created in an app like Lineform or written in PostScript or Cocoa.

3. Contextual menus. Much like AS support (listed below), effective contextual-menu support is a great way to make your app more efficient for its power users. In IB, create a top-level menu by dragging it from the palette into your nib, then ctrl-dragging from the view to the top-level menu and connecting to the menu outlet. If you create your views programmatically, you’ll need to override -menu (either returning a programmatically-created menu, or adding support for a -setMenu: method that you provide).

4. Localize everything. Localize every string you show to the user, even if it’s only in English for now. If your app achieves any popularity (and you should hope it does), people will volunteer to localize it into their preferred language. If you use NSLocalizedString on every hard-coded string as you write it, your localizers will be able to localize your entire app, without having to ask you for app-side support because it will already be there.

5. Maintain a bug- and feature-tracking system. Ideally, something like a locally-hosted Trac (don’t open it to the users, or you will be fighting lots of duplicates), but even a simple OmniOutliner or Opal document will save you having to remember all those things you need to fix/add.

   Its benefits aren’t as immediate as version-control: Version-control pays off the moment you want to bring back something you deleted, whereas a bug-tracker pays off months down the road, when you’re trying to remember what that last feature you wanted for 1.0 was, or what that one guy reported with the bug that only happened when he clicked on one of the windows with his left hand. But it’s the same kind of time-saver.

6. Sell your shares in __MyCompanyName__. Especially important for open-source projects, since other people will be reading your code. Do this now, so you don’t need to do it after you create the project.

7. Burninate NewApplication. The template nibs (including those in a new project) use “NewApplication” throughout the menus, where your application name is supposed to go. Make sure you replace “NewApplication” with your actual application name. (Even better, use Daniel Jalkut’s app template instead of Apple’s.) Take it from me, it’s embarrassing to ship an app whose menus still use the name “NewApplication”. ☺

8. Thoroughly test everything in the stock menus. Especially the application menu (edit: used to say ; thanks Jesper) and Help menu. Services should work in any text view or text field, and ideally should work in any view that has data that your users may want to run a Service over. The Preferences menu item should be hooked up or deleted. Same for “Application Name Help”.

9. Edit the credits. (No pun intended.) These are stored in the “Credits” file in Contents/Resources. The default Credits file is an RTF file; TN2179 says that the About panel looks for Credits.{html,rtf,rtfd}, in that order.

10. An application icon. If you can’t draw a good icon, hire someone to draw one for you. (If yours is an open-source project and it becomes popular, somebody may volunteer.)

11. Document icons. (For doc-based apps only, obviously.) One document icon for each document type you can write out, with different classes of type (e.g. movie vs. audio vs. text) being depicted in significantly different ways (e.g. QuickTime Player’s icons having sprocket-holes for video files vs. a waveform for audio files).

12. Pick a creator code and register it. This still matters, especially for associating a specific document file with your app. (Say you’re writing a multi-track video editing app—please—and you want to have movie files that you save be owned by your app rather than QTP. That’s what a creator code is for.) Your creator code goes in the Properties tab of Target Info in Xcode. Keep in mind that creator codes are limited to MacRoman characters.

13. Make sure your bundle ID, version, short version, and Get Info string are correct.

    • Your bundle ID should be something unique to you, and should use your domain—not Apple’s, not anyone else’s, yours. If you don’t have one, make one up. Be sure to use the domain that you’ll eventually actually own; when you finally register that domain (even if you don’t do it for years, but you should do it as soon as you can, IMO), you won’t have to change all your bundle IDs.
    • Dave Dribin discusses what to put in CFBundleVersion.
    • The short version string is the version that appears in Finder’s List View; it should be a simple major.minor.maint version-number string (e.g., 1.0), and nothing else.
    • For Get Info strings, include a copyright statement and your version—for awhile, Apple said to leave out the version, but they’ve since reverted that, as users (well, at least former Mac OS users like me) expect to see a version number there. The version number you have here should be the same one you have in the short version string.

14. Run it with no prefs. The goal here is to see how your app looks and works the very first time it is run. In particular, anything fed by NSUserDefaultsController needs to handle nil values correctly if you didn’t put some default values into it in main.

15. Do at least one private beta or release-candidate. This is your final attempt to discover any bugs that you haven’t found yourself. Maybe it’s a byte-order bug, or something that only happens in certain network situations, or a crash that doesn’t happen on your machine because xyz. Regardless, you’ll find the bug only when somebody else runs your program, and hopefully you’ll do that in a private beta or release-candidate phase rather than in your actual public release. (You’re welcome to do a public beta as well, but don’t stall—get to release quickly.)

16. Include a license and a ReadMe. For open-source projects, picking a license is easy: Use new-BSD, MIT, LGPL, or GPL. I don’t know what you would do for a closed-source project—I suggest consulting an intellectual-property lawyer. And definitely include a ReadMe. Your ReadMe should cover the following points:

    • What does the app do? (This is in case it was delivered on a CD or other compilation. In that case, they didn’t read the description on your webpage.)
    • How would I use the app in its most basic operation?
    • Who owns this app? (Copyright statement.)
    • Where can I get a newer version of this app? (Link to your website for the product.)

    Also, if you present your ReadMe as an RTF file, make sure you choose “Prevent Editing” from TextEdit’s Format menu, so that your ReadMe file is read-only. This prevents your users from accidentally deleting important swaths of the file.

17. Maintain a detailed version history. Include the version number, release date, and list of changes. Version control will help you here: It’s tedious, but not hard, to build a complete list of changes from an svn log. The version history should be on a page of your website.

18. AppleScript support. This isn’t something you need right away, but it’s a definite plus, especially if you’ll be selling your app. Daniel Jalkut has good info on adding AppleScript support. Even just being able to script the preferences is a good start.

19. Check for leaks. The leaks(1) utility will scan your app’s heap looking for memory that isn’t pointed-to anymore. It’s very easy to leak objects, especially when your autorelease-fu is not strong. Be sure to use MallocStackLogging, so you can see what allocated the leaked memory; this may give you a hint as to where the leak lies. You may also find heap(1) useful.

20. Get a real website. No, your GeoCities website won’t cut it. Expect lots of traffic, and be on a server that can handle it. No such server is free. (Also, don’t host it yourself—most ISPs won’t allow you to run a server on a consumer account, you don’t have the bandwidth anyway, and professional hosting is cheaper than an ISP server-grade account.) I recommend TextDrive, though others[1] [2] [3] have their own recommendations.

Feel free to suggest more items in the comments.

UPDATE 2007-04-02 15:15 PDT: The old #5 was controversial, and I concede that it’s too early to give that advice yet. I’ve replaced it with one that I posted in a comment. For posterity, here’s the old #5:

Test on both architectures. If you can’t do this, make your app Intel-only. Testers with ICBMs are easy to come by. Testers with PowerPC Macs aren’t so much, and they get harder to find every day. So if you have only a PowerPC, you can recruit somebody with an ICBM to test your UB, but if you have only an ICBM, it’s easiest to just make it Intel-only.

UPDATE 2007-04-02 20:17 PDT: Added a link to Martin Ott’s Subversion Installer package.

UPDATE 2007-07-23 20:15 PDT: Added discussion of the short version string to point #13.

UPDATE 2007-07-23 20:27 PDT: Formatted point #13 and clarified its discussion of Get Info strings.

UPDATE 2007-08-06 04:30 PDT: Added links to OmniOutliner and Opal.

UPDATE 2007-08-08 17:15 PDT: Added TaskPaper version.

UPDATE 2007-08-08 21:51 PDT: Added suggestion to Prevent Editing on your ReadMe.rtf file.

From time to time, I check a Technorati search for my blog, which I have bookmarked, to see who’s linking to me and what they have to say.

Today I find that chucker has installed NTT. Cool!

chucker: I invite you to email me about you getting spam every few minutes. I’m interested to hear more specifics. My address is on the front page. (Initial hunch: Try turning off Akismet. I gave up on Akismet after all the false positives we had when we tried using it on Adium Trac; as such, I’ve never used it here.)

the show with zefrank has ended.

And he went out the way he came in.

Blinking.

There’s been some discussion of LMX on the web since I announced LMX 1.0’s release. As I mentioned then, LMX is the library that powers Adium’s message history feature. Mostly, people have questioned whether XML was the best choice for logging given the message history requirement.

I recommend first reading my post on the Adium blog about message history. (If you came here from the Adium blog, sorry for the bouncing back and forth—that’s the last bounce, I promise. ;)

Welcome back. Let’s begin.

The questions and objections listed here are drawn from the comments on my LMX 1.0 announcement post, this article on the O’Reilly XML blog, the reddit post about LMX, and Tim Bray’s mention of LMX.

• Why not just store the messages in reverse order? Then you wouldn’t need a backward parser; you could retrieve the n most recent messages from the top with an ordinary parser.

  Because file I/O doesn’t have an insert mode; you can only overwrite. That means that Adium would have to rewrite the entire rest of the file every time it inserted a message (which is when the message is received or sent). That would get very expensive for long transcripts, and some Adium users leave their chats open all the time, so their transcripts would indeed get very long.

• How do you append to the transcript? You must have to leave off the end tag, which means that the file is not a valid XML document until you close it, which would be bad if Adium crashed, since the end tag would never get written and the transcript would be broken XML.

  Not so. This time, overwrite behavior is our friend: Adium simply overwrites the </chat> tag each time it writes a message, and appends a new </chat> tag in the same write. The file is always a valid XML document, thanks to overwriting.

  Yes, this is slightly wasteful, but the waste here is constant (that is, it does not go up over time) and insignificant. The upsides vastly outweigh the downsides.

• Why go with XML if you have to perpetrate such hackery as a backward parser? Why not use SQLite or a plain-text format?

  SQLite: We would have had to include it with Adium, since Adium 1.0’s minimum requirement was OS X 10.3, and SQLite has only been bundled with Mac OS X since 10.4. LMX is much smaller than SQLite. Also, we’re not big on formats that aren’t directly human-readable.

  Plain-text format: A simple format (e.g. TSV) would have some growing pains if we ever wanted to grow (or shrink) the format, and a more complex format would require a new parser from the ground-up just like XML does. For this purpose, we like XML’s trade-off between readability and extensibility, and LMX fills in the gap for reading from the end.

  For more on formats we didn’t elect and why not, you can read our LogFormatIdeas page on the Trac (deprecated since we chose a format, but still around for posterity).

• How will you determine the encoding of the data, or read entity declarations? Those things are at the start of the file, and you’re parsing from the end.

  LMX naïvely assumes that the data is UTF-8 and that the application knows about any entities it will need. Yes, this is wrong, but Adium didn’t need anything different.

  Either 2.0 or 3.0 will do a forward parse until the opening tag of the root element, in order to discover the actual encoding and any entity declarations. (I’m not doing it in a 1.0 version because 1.0’s parser is a hedge of thorns, and I’m not willing to touch it for something that most people won’t need anyway. And I’m tempted to leave this out of 2.0 as well, since 2.0 will be a big enough version with its rewrite of the parser in pure C.)

• How does LMX tell whether –> is the end of a comment or simply an unescaped > following two hyphens?

  Simple: It assumes it’s the end of a comment.

  There’s no way to definitively find out one way or another without scanning all the way to the start of the data and backtracking. This is one of the pitfalls of a backward parser. It’s the nature of the game, so all I can do is say “make really sure you’re feeding good XML to the parser”. That includes not having unescaped ‘>’s in your text.

• What about storing one message per line and scanning through the file line-by-line?

  Because you can have a valid XML log file without that constraint, and constraints like that are the sort of detail you don’t want to rely on, because other apps can break them. (To Tim Bray: Part of the point of the Unified Logging Format is that we want other IM/chat clients to use it, which means that we should be forgiving when their output doesn’t exactly match ours.)

• Can I grep these logs?

  Mostly. You can grep an XML log in the usual way, but your expression can’t contain non-ASCII characters, <, >, or & unless you replace them with the appropriate entity references. We recommend using the search field in the Chat Transcript Viewer anyway.

I’m glad I finally announced LMX 1.0—not just because it is now, finally, out the door, but also because people have suggested new alternatives that we on the Adium team never thought of. For example, this reddit comment suggests saving one file per message (in a directory per chat), and this other one suggests inserting a fake start tag before the –nth message element, and the O’Reilly article suggests a hybrid XML+binary format. We never thought of any of these.

To be totally clear, we’re not switching—this post is a clarification, not an announcement. Two of those ideas won’t work for various reasons; the problem with the one-file-per-message idea can be overcome by tarring old chats. But LMX is not a future plan—we’ve written it and it’s here, and the same goes for the Unified Logging Format.

Call it inertia, but replacing either one with something else will require either the existing solution to break or the proposed replacement to exhibit massive, world-changing superiority. These things are done and they work, so at this point, we’re not going to rock the boat. It ain’t broke anymore, so we’re not fixing it.

This bug is System-wide AXUIElement’s role desc is “need to implement”. It was filed on 2007-03-09 at 13:39 PST.

(more…)

My programmer friends and I frequently observe that “polling behavior is evil” (it wastes resources when the polled query finds nothing). Here, I shall define polling behavior, and three alternatives.

Polling (or “pull” when talking in comparison to “push”)

Periodic querying of a source by the destination for objects. Example: POP email.

Push

The source blindly delivering objects to the destination (or at least trying to), regardless of the destination’s existence, presence, readiness, or capacity. Example: SMTP email.

Request

The destination asking the source for objects when they are needed, and no earlier. Example: Web browser.

Subscription

(Not in the RSS sense, which is polling.) The destination notifying the source—usually just by opening a connection—that it is ready for objects to arrive, and continuing to wait for further objects. Combines a request at the start of the subscription with push for the rest of the subscription. Example: IRC; instant messaging.

1. Don’t push your CPU too hard.

   This means not using codecs like H.264 and MPEG-4. Do your compression after you record the screencast. While you’re recording, you want frame-rate—don’t worry about size on disk.

2. Don’t push your disk too hard.

   There are two ways to make this mistake:

   1. Try to record too many pixels.

      On my Mac Pro with the stock SATA drive, I can’t record full-screen at more than 20 fps. Can’t do it. The bandwidth just isn’t there.

      Two good baselines are 800×600 and 640×480. The latter is iPod size (actually, twice the resolution of an iPod, but whole factors scale better), but it’s hard to use OS X that way, so it’s generally best to only record part of the screen if you want to record 640×480. If you don’t want to do that, you’ll be using 800×600. That’s what I do in the Adium screencasts.

      The other advantage is that—until Resolution Independence comes—your UI elements will show up bigger in the final product if you record the screen at smaller dimensions.

   2. Try to record too many bytes.

      Even once you get your screen resolution right, it’s still possible to push too many bytes to disk. The easiest way to do this is to use the Raw compressor, identified by iShowU as “Apple None”. The Raw compressor does no compression, meaning that all those frames coming in practically all at once can swamp your disk’s bandwidth.

Solutions

1. Use the Animation compressor.
2. Record at 800×600 and use the Animation compressor, or use a RAM disk (or both!).

The Animation compressor is easy on your CPU, so it won’t swamp that, and a fairly significant amount of compression, so it won’t swamp your disk either. And it’s lossless, so you won’t be sacrificing quality. (Use the highest quality setting. Lesser quality settings are lossy, without a significant gain in compression. Again, do your compression afterward—you want picture quality and frame-rate at the time of recording.)

UPDATE 2007-09-29: Added link to Make RAM Disk. Alternatively, if you feel like creating your RAM disk the hard way, here’s the hard way.

LMX 1.0 didn’t really have much design to it. I set out to clone NSXMLParser‘s API, which I did, but didn’t give a whole lot of thought to how I would actually implement the parser.

As a result, the parser itself is one humongous method that takes a lot of effort to read. It is only navigable at all because I had the foresight to put in lots of #pragma marks.

LMX 2.0 will not make that mistake. This time, there’s a design, and the parser will not all be in one function. Here’s the design, which I drew on a quadrille pad:

To be explicit, these are all implementation details which will not be exposed to clients of the API.

And the scanner I used to import this from dead tree format is the CanoScan LiDE 600F I mentioned in passing in my post about my HP M425 camera.

One of Negative Turing Test’s most recent features is a counter of how many spams it eats. I added this feature last month, and made a note to reveal today what it got up to.

The number of spams blocked by NTT from 2007-02-12 to 2007-03-12 is:

6,220

I should probably get around to making it delete those…

This post makes for a fascinating display of how a thread can evolve.

Simone, in the comments for my post about the HP M425 camera’s drivers, links to his own experiences with the HP PSC1210 printer+scanner+copier+paperweight. In that post, he says:

This is one thing that really annoys me about technology. Companies try to make their products do so many things that it just makes them do everything crappily. No, I do not want a cell phone that plays games or does web browsing or plays MP3s or takes SHITTY-ASS PICTURES. If I want a cell phone, I want to be able to store contacts (and sync with my Mac), I want to be able to make calls, and receive calls and voice mails. That’s it! (Oh, and I DON’T WANT TO HAVE TO SIGN UP FOR A MONTHLY CONTRACT — NEWS FLASH TO CELL PHONE COMPANIES IN THE U.S.: HAVE YOU HEARD OF THE WORD “PRE-PAID”?!)

I suspect that many other people in the US don’t know about prepaid cell-phones. Hopefully I can make a dent in that.

Prepaid cell-phones have been around in the US for years and years, and they’ve proliferated lately.

First, all cell providers have prepaid service and they’ve pretty much always had it, though they don’t make a very big deal about its existence. Verizon Wireless currently has two prepaid plans called “InPulse” (sic) and “EasyPay”; they used to have only one and they’ve gone through at least three different names for it. Cingular calls it “GoPhone”. I’m not sure what T-Mobile and Sprint call it. Nextel (now part of Sprint) calls it Boost Mobile (which used to be a separate company reselling Nextel service, but which Nextel bought out and now runs itself).

Tracfone was always the one lone company puttering around offering crappy prepaid service while all the actual cell phone providers (Tracfone is a reseller, as Boost was and as most of the prepaid-only companies are) made big profits using regular billing plans, just like landline companies. But now there are several other companies offering prepaid service, including:

• Tracfone
• Boost Mobile (branded separately from Nextel, so I’ll go ahead and still count them)
• Virgin Mobile
• Amp’d Mobile

Usually, these phones are aimed at younger demographics: kids and teenagers, with lots of subtle hinting toward the parents. The appeal for the parents is that since a prepaid phone makes you define a hard limit ahead of time (put $x on the phone and you only have $x‘ worth of airtime+SMS), the kid is limited in how much time he can spend irradiating his brain.

Prepaid service—especially Tracfone—used to be vastly inferior to the regular service: you had a black-and-white screen, and you couldn’t get a flip-phone, and you couldn’t play games. Now, except for videos (which only Verizon and Sprint have, and which are not available on their prepaid phones AFAIK), prepaid service is on par with regular service.

So yes, Virginia, there are prepaid cell-phones. I, for one, have Boost Mobile (having had Verizon previously), and am happy with it.

Also, 7-Eleven sells refill cards that you can bring back to the store to put more money on—after you use it the first time, it’s tied to your phone, so putting more money on it forwards it directly to your phone without you having to go through the “please enter your ten-digit phone number” bit again.

1. Get out the HP drivers CD.
2. Put it in one of these.
3. Push the button.

Silly me, trying to use a device with the Mac drivers that come with the device. Turns out it works just fine with the built-in Mac OS X drivers, either via PTP (whatever that is), or as a mass-storage device. In fact, Image Capture works the same either way.

With the HP drivers, a program called “HPCamera_PTP” would crash whenever I plugged in the camera, whether I did this in Image Capture or iPhoto. I found that switching the camera to mass-storage mode (“Disk Drive” in the USB Configuration menu) worked around that problem nicely, and Image Capture (and iPhoto) even work transparently in this mode.

Later, I was tinkering with Image Capture in some way (I forget why) and noticed that it has its own PTP driver. This gave me an idea, and having long ago uninstalled the HP uselessware, I switched the camera back to PTP mode (“Digital Camera” in the USB Configuration menu) and plugged it back in. Huzzah! It worked exactly as it did in mass-storage mode.

Kudos to Apple for making it do the Right Thing either way. Antikudos to HP for making non-functional drivers.

I also got a new scanner yesterday, a CanoScan LiDE 600F. Unfortunately, it doesn’t work without drivers. Fortunately, its drivers work. (Both devices let me use Image Capture without touching any of the apps that come with them, which I consider mandatory given the nearly-consistent asstasticity of the UIs of such apps in general.)

This bug is Setting a non-opaque window’s hasShadow to NO does not completely un-shadow it. It was filed on 2007-02-16 at 20:23 PST.

(more…)