Learning a new programming language

It took me a while to learn Objective-C.

I started at the most basic level, wondering at the language. What are these brackets? What’s with the @ signs? What’s the difference between a – and a +? These aren’t hard things to learn, but understanding the reasoning behind them helps. And then there’s a point where it suddenly makes sense.

But the framework was confusing. How do I do this? Though I was less confused, this one isn’t solved directly. I became competent. And I started to ask the best question: “Why?”

The patterns were still confusing. Why does this work this way? What’s the purpose of this? Why is this done, but not this other thing?

And then there was a point where the patterns became obvious. More, the pattern in the patterns became obvious to me. And now, I look to find more examples of patterns, and patterns of patterns, to better build my knowledge.

It took me a while to get here, and it’s the same for every language. I’m feeling pretty confident about Objective-C now.

Back on the first day, I was confused and lost.

Posted in Articles | Tagged , , | 2 Comments

The secret to enjoying Xcode

One of the things that made me like Xcode more and become more efficient with it is realizing that while all coders are insane, me and Xcode’s designers are insane in different ways.

By that, I mean that aside from the standard keyboard shortcuts (Save, Copy… that sort of thing), none of the keyboard shortcuts made sense to me.

So I duplicated one of the keyboard shortcut profiles and deleted most of the keyboard bindings. I was brutal with it — if the combination didn’t make sense to me OR it was something I’d rarely use it was removed. Then I added keyboard shortcuts that I needed. By using about an hour to customize these settings, I ended up having keyboard shortcuts that I fully understood and rolled off my fingertips.

At this point — and this is where it became a useful exercise — I added my ~/Library/Application Support/Xcode to version control so I could easily sync it between computers. So when I find something that isn’t quite working out for me, I make a change and propagate it to my other system.

Am I going to share what I ended up with? No, because that’s not the point of this. Rather, I want to point out a simple fact of Xcode: Xcode will adapt to how you want to use it, and if you feel like you’re suffering at all with it you should spend the time it to takes to make it enjoyable to use.

And when someone tells me I can do something with a particular keyboard shortcut, I switch back to the defaults and see what it’s bound to.

Posted in Articles | Tagged , , , | Comments Off

iTunes zoom behavior

iTunes prior to 9.0 used a click on the zoom widget to convert to the mini player, leaving people like me who actually like to zoom a window option-clicking it.

iTunes 9.0 finally fixed this. A click on the zoom widget actually zoomed the window!

iTunes 9.0.1 changed it back to the old behavior. Many people were happy, I imagine. But people who wanted to zoom iTunes windows (or, I imagine, valued standard behavior) were left sad.

It turns out you can get the click-to-zoom behavior back:

defaults write com.apple.iTunes zoom-to-window -bool true

Tip of the hat to zadr on Twitter for this tweet.

Posted in Articles | Tagged , , | Comments Off

Minimized iTunes player

Paste this into AppleScript Editor:

tell application "iTunes"

	repeat with b in browser windows

		set the minimized of b to true

	end repeat

end tell

Save it in ~/Library/Scripts. And while you’re in AppleScript Editor, turn on Show Script menu in menu bar and Show Computer scripts. Now you have a command to show iTunes’s mini player at any time.

If you’ve got a good way to launch AppleScripts, you can install it there, too.

Update: Apple has changed this back in iTunes 9.0.1. See iTunes zoom behavior if you liked the iTunes 9.0 way.

Posted in Articles | Tagged , | Comments Off

Ars Technica on Snow Leopard

John Siracusa: Ars Technica review of Snow Leopard. Includes a discussion of some of the file system’s new tricks and QuickTime X’s secrets, which you’ll probably never need to know. But don’t you want to know?

Posted in Link | Tagged | Comments Off

Snow Leopard is built for the future

Wil Shipley (Delicious Monster): Snow Leopard is built for the future. A short overview of what Snow Leopard’s new technologies mean from an application developer’s perspective.

Posted in Link | Comments Off

Adding shadow effects to UITableView using CAGradientLayer

Matt Gallagher (Cocoa with Love): Adding shadow effects to UITableView using CAGradientLayer. Non-obvious and useful.

Posted in Link | Tagged , , | Comments Off

On heuristics and human factors

Wil Shipley (Delicious Library): On Heuristics and Human Factors. This is a big part of what separates great applications from the rest.

Posted in Link | Tagged , , | Comments Off

Installing MySQL on Mac OS X

Hivelogic: Installing MySQL on Mac OS X (from source). Useful if you can’t use a prebuilt package for some reason. (Remember to adjust the instructions for the latest version instead of 5.1.33.)

Posted in Link | Tagged | Comments Off

On skins and plugins

I started this post over six months ago, but never quite got around to finishing it. It might never be finished. But this is a thorn to me, so I’m just going to post it as is.

Should your new application support skins?

Probably not. Skins are often a programmer’s way of saying “Oh, I don’t do UI. We’ll let someone else get it right.” Only nobody ever does, at least not in your product. Your UI just isn’t as compelling as the one it’s replacing.

The corollary to this is that if lots of people are demanding skins, it means your UI sucks. Once you add skins, you’ll never be rid of those skins, and you won’t have fixed your application either.

You’d probably do better to fix your application’s appearance and behavior.

Now, should you do a custom appearance?

If you’re planning a completely custom appearance for your applications, odds are it will suck. Unless you have artists that are beyond simply competent, but brilliant, you’ll probably fail.

First, you need a UI that looks and feels good. Secondly, it probably needs to fit in with the native platform. If you’re planning a full screen game, it’s fine to not fit in. But if you’re building a Windows-based BIOS updater, that custom UI that you think looks so amazing? The truth is, it looks like complete shit.

You’re better off fitting custom UI into the OS rather than changing your whole application to fit them.

Now, finally: What about plugins?

This one is a little less clear. There’s great reasons to do plugins. Integration with another system (whether technical such as a web site or social such as particular requirements for reporting) is a good one.

But you know what isn’t a great reason? Making your product a platform. Do you want to be a product people use, or a platform people struggle with?

Firefox’s plugins make me flinch. They’re usually poor quality, craptacular tools that lunge for a particular nugget of a good idea and fall flat on their faces a few yards away from it. There are a few that are interesting, but they’d benefit from being rolled in, or being a separate stand-along product on their own.

Pick your features carefully. 37signals didn’t become popular by picking an extensive list of features or allowing people to write their own features. Instead, they built something they wanted to use. And they’re not alone. There are a few things I’d love to see (MarkDown instead of Textile, for instance), but even if a hypothetical plugin system could add these things, they’d be overwhelmed by the layer of suck.

Before you build a plugin architecture, put the effort into your application.

Posted in Articles | Tagged , , , , , | Comments Off