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.
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.
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?
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.
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.
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.
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:
- Publish a blog article every day.
- 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.
I know some people who are interested in getting into iPhone application development. There is a lot of advice out there. Here's my advice for experienced developers who start out knowing nothing about iPhone or Cocoa development:
- If you don't know the C programming language, learn it.
- Read Matt Gemmell's "iPhone Development Emergency Guide".
- Buy and read iPhone SDK Development by Bill Dudney and Chris Adamson. Also buy and watch the Xcode- and iPhone-related screencasts available from that web page.
After that, you'll be able to delve into the other things you need in Apple's documentation. I'd recommend learning all you can about Core Animation and Core Data, but it depends a lot on exactly what kinds of apps you want to write.
Finally, write lots of little iPhone apps before you start on that big important app you really want to write. The language and tools are a little strange at first, but the more you use them, the better they feel.
To make it easier to put content on my Sony Reader, I've created a service, using Automator, that will invoke calibre's
ebook-convert tool on files selected in the Finder.
There are a few binary Emacs packages for OS X floating around out there, but I always build it myself from the sources. This usually results in an Emacs that works the way I expect, rather than the way some "helpful" distributor thinks it ought to work.
I'll assume you have the developer tools and
bzr installed, and know how to open Terminal and type some commands. Here are the commands you need to type:
bzr init-repo --2a emacs/
bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk/
When this is complete, you'll end up with
Emacs.app in the
nextstep subdirectory. You can run
Emacs.app from there, or copy it to your Applications directory.
Update 2010/10/29: Discovered that the Emacs team now uses Bazaar (
bzr) rather than CVS. Updated the instructions accordingly, following advice from http://www.emacswiki.org/emacs/EmacsForMacOS and http://www.emacswiki.org/emacs/BzrForEmacsDevs. Also, found what appears to be a faithful binary distribution at http://emacsformacosx.com/.
I like most of Apple's products, but iTunes is a very dark corner of the Mac universe.
For example, here is what you have to do to download updates to your iPhone apps:
- Click the Applications link in the upper-left corner of the navigation pane.
- Move the mouse over to the lower-right corner and click the tiny, tiny Check for updates button.
- Move the mouse to the upper-right corner and click the Download All Free Updates button.
Three steps, requiring moving the mouse pointer all the way across the screen between each. There is no automatic-update feature.
There is probably some way to write an AppleScript to automate this, but AppleScript sucks too.
Do a web search for "iTunes sucks", and you'll find a lot more examples.
To paraphrase Bjarne Stroustrup: There is software everyone complains about, and software nobody uses. One could chalk up the iTunes hate to the simple fact that so many people are forced to use it whether they like it or not. But iTunes really does suck. I wish Apple would do a complete re-design of its UI, and make it act like an Apple product.