November 2009

Switched from Firefox to Safari

For the past week, I've been using Safari instead of Firefox, and I've decided to make the change permanent.

Why? Firefox is just too slow. Remember the good old days when Firefox was the leaner, faster, less-bloated alternative to Netscape Navigator? Those days are in the past. Firefox now takes over ten seconds to show a window after I launch it, whereas Safari is up immediately. Safari is also faster at rendering pages, and at just about everything else. It takes up a fraction of the memory of Firefox, and has not yet started using 100% CPU for no reason at all, as Firefox tends to do.

The thing that Firefox has that other browsers can't match is the huge set of add-ons (extensions, themes, etc.). While many of these are really cool, there are really only two that I consider must-haves:

The lack of Adblock Plus is noticeable right away. Web sites that I visit frequently are suddenly awash in ads. It's very distracting. There are a couple of Safari extensions that supposedly work like Adblock Plus on Firefox, but they don't work as well. Most Safari users seem to be happy with simply blocking Flash ads with ClickToFlash, but I'm not satisfied with that. I've just started a trial of GlimmerBlocker, which seems pretty good so far.

PasswordMaker is a nifty little Firefox extension that automatically fills in password fields with passwords that are unique to each site, generated by hashing a master password with the site's name. This is great, because I haven't had to remember any passwords with Firefox, but it's bad in that I now have to teach Safari all those passwords, and I have to do a lot of manual copying and pasting.

With my new foray into web technologies, maybe I'll devote some time to trying to get these essential Firefox extensions ported over to Safari.

Aside from the missing add-ons, I also miss Firefox's keyword search functionality. There is a Safari extension, Keywurl, that supposedly provides this functionality, but it is not yet compatible with Snow Leopard. (If you search hard enough, however, you can find some unofficial 64-bit builds.)

Unfortunately, Safari does not actually have a supported plug-in/extension mechanism, so most of these extensions are hacks that can crash Safari or which suddenly stop working whenever there is a system update. It's a shame that so many products today are not designed to be extensible or user-programmable.

Aside from those little missing features, I'm happy with Safari. (For now, anyway.)

JavaScript: The Good Parts

As a result of the recent hubbub about web apps, I decided to get myself up to speed on JavaScript and CSS. Knowing Douglas Crockford's reputation as the JavaScript guru, I read his book, entitled JavaScript: The Good Parts.

It's a good book. The basic idea is that while JavaScript is actually a pretty cool little programming language, it has a lot of features that are best not used, and it has many outright flaws, so Crockford presents a recommended subset of the language.

The most valuable parts of the book are appendices A and B, entitled "Awful Parts" and "Bad Parts", respectively. These appendices list the gotchas of JavaScript and present rationale for leaving certain constructs out of the recommended subset.

My only gripe with the book is that, while it is presented as an introductory book, it seems to assume some previous knowledge and experience with JavaScript. I got a bit lost in some parts, particularly those regarding prototypes, the new keyword, and how this gets bound in various situations. (I was able to eventually figure these things out with a bit of Googling.) It also assumes some experience with functional programming, which is OK with me, but which will probably confuse a lot of introductory readers.

So, while I can enthusiastically recommend the book, I think I'd recommend it as a second JavaScript book.

The Houben Case and Facilitated Communication

The media has been reporting that a Belgian man who has been in a coma for 23 years is now able to communicate thanks to "assistance" from an aide who holds his hand while he types on a keyboard (or actually, while they type on a keyboard).

Here are a couple of good articles about what seems fishy about these claims, and why "facilitated communication" is not taken seriously by most of the scientific community:

And, finally, there is video of Houben and his "assistant" typing while Houben's eyes are closed. It's amazing that a man so disabled is able to type with one finger with his eyes closed. I can't do it. I wonder how well he would do if the assistant's eyes were closed.

iPhone Video Output

A common problem for iPhone developers is demonstrating the apps they've developed to others. Showing it on an actual device only works well if you are showing it to one or two people. Showing it in the iPhone Simulator running on a Mac takes a lot of setup, and may not work if the app depends on things you can't do in the simulator.

Fortunately, The Evil Boss shows us how to enable video output for an iPhone application, so you can show it running on a TV screen.

Native Apps vs. Web Apps

This week, there was a lot of chatter in the blogosphere about the prospect of writing web apps for the iPhone instead of developing native apps.

Android: Maybe Not

A couple of days ago, I said I was considering giving up on iPhone development and trying Android instead. Here are my further thoughts along those lines.

Deal on Photoshop Elements 8

If you're one of the people (like me) who needs to occasionally do some image editing, but who doesn't want to spend a few hundred bucks on Photoshop, you may want to check out Photoshop Elements 8.

Adobe has a deal on it right now: $20 off the normal price, and a $20 rebate, so that the final price is about $60. See the Adobe store. Deal ends 11/30/2009.

Switching Away from Apple?

I've enjoyed using my Apple products, but I'm considering a switch. I find myself drawn back to Windows on my desktop, and to an Android mobile device.

Google Wave

Thanks to a former co-worker, I got an invite for Google Wave.

The biggest problem right now with Google Wave is finding other people to interact with. Chances are that few of your family, friends, or co-workers have access to Wave yet. I've set up a public wave for readers of this blog. If you are a waver, feel free to play with it:

(If that link doesn't work, then try entering "with:public undefined value" in the Google Wave search box.)

Sony PRS-500 Upgrade

As mentioned in a recent post, my wife bought me a Sony PRS-500 Reader, and I like it a lot. I've just found out about an upgrade offer: PRS-500 owners can trade in their readers for discount on a Reader Pocket or Reader Touch. The offer expires April 10, 2010.

(Bummer. Turns out that I have a PRS-505, not a PRS-500, so I'm not eligible for the upgrade. So I guess I'll just have to wait for the Apple tablet.)

The Go Programming Language

There's a new programming language out there: Go. There are lots of ways to describe it, but basically it's got Python-esque syntax and C++-esque performance. It's statically typed, but is designed to feel more like a dynamic language. It has garbage collection.

Based on its pedigree, I expect this to be a lot more successful than the various other languages intended to be successors to C++. Play with it while it's still cool, before it starts to suck.

Sorry, Windows programmers, but only Linux and Mac OS X are supported for now. But I'm sure Windows programmers won't mind; to them, "new programming language" means "C# 4.0".

iPhone OS Filename Case Sensitivity

I hit a little snag while adding a feature to an iPhone app today. I added this code to load a logo to be displayed in a view:

UIImage *logoImage = [UIImage imageNamed:@"Icon.png"];

This worked fine in the iPhone Simulator, so I thought I was done. I loaded the app onto my iPod Touch, and it didn't work. Running in the debugger, I discovered that logoImage was being set to nil.

Why would this not work on a device, when it ran fine in the simulator?

It turns out that the iPhone OS filesystem is case-sensitive, while the Mac OS X filesystem is not case-sensitive. The actual name of the image file was icon.png, with a lowercase-i, so it didn't match on iPhone OS.

No big deal, but it's another reminder that you always need to test on an actual device before considering an iPhone development task done.

Introducing Kids to Programming

No time for a real blog entry today, but instead of nothing, here are some links to really cool toys that kids (and curious adults) can play with to learn about programming and multimedia:

Automator Service: Copy Current UTC Timestamp to Clipboard

Yeah, I know, you're probably getting sick of these Automator services. But I really do create a new one of these practically every day to make my life a little easier, and maybe some of these will be useful to others.

This one puts a UTC timestamp on the clipboard. The timestamp is an ISO 8601-format string like "2009-11-09T13:14:03Z". If you'd like a different format, type "man date" in Terminal to see how to change the output format of the date command in the shell script below.

Authenticating with Google App Engine

I've finally got around to doing some work on that iPhone application that I've committed to finishing this month.

On days I do a lot of work on the app, I don't feel obligated to work too hard on the blog, but I will post a little something about whatever I worked on. Today, I got my iPhone app to connect to a Google App Engine-based web site.

Without giving away too much, I'll just say that the iPhone app and the web site work together to provide a service to iPhone users. I put the web site together in a couple of weekends. I decided to use Google Accounts for authentication, meaning that to log into my web site, either via a web browser or via the iPhone app, a user has to provide a Google account ID and password.

If you do things this way, the server-side authentication stuff is easy. However, writing the client side is not easy, because the mechanism for authenticating with a Google account and connecting to a Google App Engine web site is not well documented. Luckily, I found a Stack Overflow question and answer that provided all the clues I needed to get my iPhone app working.

After using Google's API for implementing the web site, I'm growing increasingly frustrated with the Cocoa APIs. What takes two lines of code on the web side takes dozens of lines of code on the client side. Simple operations like connecting to a URL, downloading data, and storing it to a local database requires a lot of boilerplate code on the Cocoa side. It's not difficult, but it's incredibly verbose.

I should note that I'm using the Python API for Google App Engine. If I was using the Java API, then I'm sure it would be as grotesque as the Objective-C stuff.

How Does One Become a Good Programmer?

This is a quote I like:

The really good programmers spend a lot of time programming. I haven't seen very good programmers who don't spend a lot of time programming. If I don't program for two or three days, I need to do it. And you get better at it—you get quicker at it. The side effect of writing all this other stuff is that when you get to doing ordinary problems, you can do them very quickly.

That's from Joe Armstrong, creator of Erlang, in Peter Seibel's Coders at Work (which, by the way, every programmer should read).

This jibes with what I've seen over the years. Really good programmers don't treat coding as a nine-to-five job. It's something they want to do whether they are being paid for it or not.

A very easy way to weed out bad candidates when interviewing is to ask them about their personal programming projects. If they don't have any, then I'm pretty sure I don't want to work with them.

In this respect, programming is little different from other creative pursuits. You become a good writer by writing a lot; you become a good sculptor by sculpting a lot; you become a good musician by playing music a lot.

So go out there and write some code. That's what I'm about to do.

Automator Service: Scale Images by 75%

Here is yet another Snow Leopard Automator service: This one takes an image file and scales it down to 75% of its original size. This is great for screenshots, as all the text is still readable at that size, but you can put it in a web page or document without filling the screen.

Automator Service: Copy File Paths to Clipboard

Here's another Snow Leopard Automator-based service: It takes the Finder selection and puts the file paths on the clipboard, for easy pasting into command lines or scripts.

Mac Software for Software Developers

A fellow developer who is getting his first Mac asked me what software he should get. Here is a list of Mac software that I, as a software developer, find useful.

The "Easy Part" vs. the "Hard Part" of Software Development

In his essay "Where Do You Get Your Ideas?," Neil Gaiman relates a common situation faced by authors:

Every published writer has had it - the people who come up to you and tell you that they've Got An Idea. And boy, is it a Doozy. It's such a Doozy that they want to Cut You In On It. The proposal is always the same - they'll tell you the Idea (the hard bit), you write it down and turn it into a novel (the easy bit), the two of you can split the money fifty-fifty.

Computer programmers often find themselves in similar situations. Some well-meaning person says they have a Great Idea for an application. They'll tell the programmer the idea, and then all the programmer has to do is write the code to implement it. The Idea Person will get the bulk of the credit, but the lucky programmer gets to ride those coattails. After all, coding must be easy: it's just a bunch of stuff somebody has to type. The idea, the design, the inspiration - that's the hard part, right?

Usually, no.

Don't get me wrong: a great idea is a great idea, and a talented application designer is certainly worth more than the average programmer. But most people just aren't that smart.

And even if the idea is amazing and the designer creates a brilliant user experience, the bulk of the work still falls on the programmers' shoulders. If you take all the man-hours spent designing the iPhone, and all the man-hours spent implementing the operating system, frameworks, and standard applications, and making it all work the way the designers intended, I'd bet the latter number would be at least ten times the former. Maybe twenty times.

Programming is just plain hard, in a way that related software-development activities are not. And it is unforgiving. If a programmer makes a mistake, the program crashes or gives incorrect results. In contrast, if the UI designer makes a mistake, the consequences are not so dire; it just means the application is not quite as good as it could be.

It's usually a programmer who has to fill in all the details of someone else's grand design. When it's 2:00 AM, and the architects are snuggled in their beds, and some program is crashing because nobody thought about how to handle a certain condition, it's a programmer who has to decide how to fix it. Programmers make dozens of these kinds of decisions every day, while the Big Picture guys talk about golf.

I don't intend to put programmers up on a pedestal. Developing good software also requires good designers, good artists, good technical writers, good testers, good managers, and a good user community. But, please, don't insult coders by treating them like a bunch of glorified typists. Programming requires as much imagination, inspiration, and perspiration as any other creative endeavour.

Easy Gradient Backgrounds for UITextViewCells

When you create a table-view-based iPhone app, by default you get tables with plain white rows. But all the cool kids are making apps with 3D-ish gradient backgrounds. You want to make those kinds of apps too, right? This article explains how.

"Speak Count of Words on Clipboard" Automator Service

As part of my "write a blog entry every day during November" commitment, I considered imposing a minimum word limit for each entry. I've decided against that, because I don't want to feel pressure to add filler, but before deciding that, I created an Automator service that would help me to count words.

Not Quite NaNoWriMo


I've often dreamed of participating in NaNoWriMo, the National Novel Writing Month, in which people pledge to write a novel during the month of November. Unfortunately, I'm not really a novel-writing guy. I could maybe write a short story or two, but I'm just not enough of a writer to generate 2,000 words of fiction per day.

So, instead of doing that, I'm going to commit to do these things during November:

  1. Publish a blog article every day.
  2. Get a new iPhone application into the App Store.

This article does not count as a daily blog entry, as it is really more of a meta-entry. The real blog entries need to be programming-related or computer-related.

This is why you'll be seeing a lot of blog entries from me this month. Please feel free to call me bad names if I skip a day.