If you read a site and care about its well being, then you should not block ads or you subscribe to sites like Ars that offer ads-free versions of the site. If a site has advertising you dont agree with, dont go there. I think it is far better to vote with page views than to show up and consume resources without giving anything in return.

Let's be clear here: I don't run an ad blocker. I do run a Flash blocker, because Flash is unstable and insecure. And no, I will not white-list you to let you load Flash automatically.

And before you ask, you can't have my root password either.

I also don't keep a list of sites I'm not welcomed at. For the half dozen times a year I read a story on Ars (at most), I'm not going to feel guilty either.

Look, in the comments you have admitted you don't control the content of the Flash:

We don't allow ads with non-user initiated sound. So unless you interact with the ad you shouldn't hear a thing. If you ever do then let us know so we can fix it/nuke it.

If ads make sound uninvited, tell you?!? Are you serious? What if they use some new Flash exploit to root around and steal my private key, or otherwise execute arbitrary code on my computer?

Should I tell you then, too?

The first step to getting on my white list is to write your own Flash, not just serve someone else's. Taking people's security that cavalierly probably should be criminal.

You can't just say "Oh, that's on Adobe." By now you know what an insecure mess Flash is.

If you serve me HTML ads, I'll be happy to view them. I'm not sure if you've heard, but it turns out that you can do a lot of cool things with HTML.

Also I just checked, and Javascript can (indirectly) detect my Flash blocker. There's no reason you should try to blame users like me rather than take the responsibility on yourself. The difference between my Mac and an iPhone is that you're able to detect the latter without much effort, but the former would take a little more effort on your part.

Look, I'm sorry I cost you a fraction of a penny. But the potential pain for me in choosing to run Flash is far, far greater. And if you really cared about your users, you'd know that and have moved on from Flash already. Don't try to lay a guilt trip on me!

I'll see you in six months. Not intentionally, that'll just be the next time I have reason to visit Ars. Maybe you'll have this sorted out by then.

• Presentation
  • Helvetica Neue. Because no other font comes close.
  • A streamlined and less boxy design.
  • Removal of side bar. Most of its functionality will be merged into the footer, and the search into the header.
• Content:
  • More frequent posts, as I attempt to kill my fear of sucking by doing so more often.
  • More focus on iPhone and Mac development.
  • Less focus on Windows development, since I don't have to do it anymore.

Looked at one way, that's a 200% estimation overflow. But more realistically, it means it was pretty small and I tackled it in the wrong way. I had to refactor some code early that I left alone for too long. I should've written in the right way to begin with, and I should have realized it was wrong sooner, and I should have stopped trying to make it work.

More pragmatically, maybe I should have known better. But, of course, I didn't. And that's okay! I know better now.

What's my point in posting this?

Mostly, it's this: iPhone development isn't nearly as hard as I've made it out to be. Useful applications can actually be quite small and still be useful. Simple things are simple. When they're not simple, it's time to fix something.

I'll post a link here when I finish the project. It'll be a bit before I can devote another day to it. But I'm excited by its usefulness, its simplicity, and the idea of having an app in the App Store of my own.

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.

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.

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.

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.

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.

Xcode will automatically recognize iPhone OS 3.0.1 and look for a new SDK at a set path. The problem is that SDK doesn't exist. The good part is that the iPhone OS 3.0 SDK works perfectly for developing 3.0.1. The only apparent change is the SMS fix.

Assuming you've installed to /Developer, the iPhone OS 3.0 SDK is here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0 (7A341)

When using Xcode with iPhone OS 3.0.1, Xcode looks for the iPhone OS 3.0.1 SDK here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0.1

The trick, then, is to build a symbolic link that connects what Xcode is looking for with what it needs to find.

So what do you do? Assuming you've installed Xcode in the standard location, this is a Terminal command to fix the problem:

ln -s /Developer/Platforms/iPhoneOS.platform/DeviceSupport\

DeviceSupport/3.0.1

(I've split this into three lines to make it easier to copy and paste with the \ line continuation character.)

This will not add a SDK to Xcode's list, it will just teach Xcode to map your device to the 3.0 SDK.

A few other tips:

• If you still can't debug restarting your iPhone may help. Most of the iPhones I've tried to debug on, I've had to restart first.
• If you get an error regarding code signing, try downloading your provisioning profile again and re-installing it. Also, select it again in your build settings.

Based on information from iPhone OS 3.0.1 Advisory.

I haven't written any code against it yet and I'm not up to reviewing it, but I will say this: The controls seem to fully work. They're pretty, and the code is clean.

Possibly the piece that will save me the most time going forward is the photo browser. I'm not sure yet when I'll need this, but doing it myself would be a lot of effort at my current knowledge of Cocoa Touch:

Less visually impressive, maybe, are the buttons:

But it's worth pointing out that in addition to having more varied styling, these are built on UIView not UIBarItem. These are going to be very useful. I'm not exaggerating when I say they'll make it possible to write better applications.

Three20 also has some tab controls. The top one in particular has a great sideways scroll to it, and I think look and behavior adds up to great UI device, which I can use immediately:

Next, some styled views:

Not pictured:

• Three20 includes "disk" based caching for network images.
• Three20 provides easy tools for building a text representation of the application state. This will make restoring state between runs much easier.

Some of what's in the library has been rendered unnecessary by iPhone OS 3.0, but there is enough added to make it very compelling. I plan on putting it to use soon.