Month: June 2012

Caveat-Slash-Manifesto

It has occurred to me, since I started writing and podcasting in more depth about Xcode 4, that a caveat is in order.

It’s not a secret that I worked at Apple for a bunch of years. It’s been in my About page on this blog since the beginning.

What I haven’t said publicly is that I worked on Xcode itself—the application—for all those years.

Is that a conflict of interest? Am I going easier on it because some of my code might live on somewhere in the newest version? Am I criticizing it more harshly as an ex-employee?

Hopefully, none of the above.

I did ship some features in Xcode 3. But I can say that, with one or two very trivial exceptions which I’ll avoid talking about here, there are none of my fingerprints on Xcode 4.

In my mind, that frees me to discuss it like any of you would.

Well, maybe not exactly like you would; I’ve been thinking a whole lot about developer tools, so I have more of an interest in exploring in detail the highs and lows of Xcode 4 than most other folks. And, unfettered either by personal involvement or Apple’s shroud of secrecy, I intend to continue doing just that.

But I figured you should hear about my…particular background now rather than later.

Why Did It Have to be Mimes? (Shakes Fist)

I’ll freely admit the the first reason the Edge Cases podcast isn’t on iTunes is because I forgot to submit it on Sunday night.

But the second reason is more interesting. When we first tried to submit our Feedburner feed1 to iTunes, Apple sent us an email a few minutes later saying, sorry, there had been an error. But they didn’t tell us what error.

Feed Validator was more helpful, but only to a point. It told us that we should use UTF-8 encoding if we wanted to submit to iTunes. But we were specifying UTF-8 in our RSS file. It turned out, FeedBurner would only respect that setting if the RSS file MIME type was properly set to text/xml, which ours was decidedly not. Instead, it was—oops!—set to image/jpeg. (Hilarity did indeed ensue.)

So we fixed that, and Feed Validator said we were good, and we submitted again. Bzzzt. Another email from Apple saying there was an unspecified problem.

After another hilarity break, it occurred to us that if there was a problem with the MIME type for one of the files, maybe there were problems with some of the other files as well. Y’know, unimportant ones, like the MP3 files.2 Yup, they were also set to image/jpeg. Once we changed them, the feed was accepted by Apple.

And now it’s in…moderation, I guess? I wonder if it’s the same folks who review the apps….

 

1. Which in the meantime you can use directly in iTunes, by the way. Advanced -> Subscribe to Podcast… -> paste in the feed URL.

2. I suppose it could have been the logo file, which was a PNG file, not a JPEG file, but I’m dubious. And I’m not resubmitting in order to find out.

Livin’ on the Edge

Back from WWDC? Great!

That means it’s time for you to subscribe to Edge Cases, a weekly podcast about (mostly Apple-related) software development, by myself and Wolf Rentzsch:

http://www.edgecasesshow.com

Just like WWDC, WWEC (Whole Week of Edge Cases) will last Monday through Friday, one episode each morning from our 5-episode backlog, including such gems as “Dot-Mom and Apple Pie” and “Would They Call It iCode?”

Then, once you’re all caught up, we’ll release an all-new episode over the weekend.

We hope you like it!

Fleeting

I had a problem recently with Core Data transient properties, my own fault.

What I hoped they would be was full-fledged members of the database which just happened not to be saved to disk.

What they actually are is glorified instance variables. The trouble with using a custom subclass ivar is that its value is only present in the specific object you set it on. If you get a different object representing the same entity, say from another context, it won’t have that value. These can lead to lots of problems.

I wrote a sample Mac app, available on github, that demonstrates the problem. Here’s me setting the “name” property for a couple of entities:

Here’s me using the “Refresh” button to use a second managed object context to retrieve those same entities:

Names are gone! (And pointer values are different.) If I change the name attribute to not be transient, the names are preserved, even though the pointer values are still different:

I’m sliding over a lot of details here. This post by Jakob Stoklund Olesen has more information, but since it’s from 2007, it may be out of date. (It’s still the first google hit for “Core data transient properties”, however.)

This

From Brent Simmons’s blog inessential:

So here are my two pleas:

  1. Use dot notation for properties.
  2. Do not use dot notation for non-properties.

This. So much this.1

I am in the process of imposing these rules, property by property, in a codebase I have recently inherited, for exactly the reason Brent suggests:2 avoiding the need for multiple searches in order to find all the usages of a single thing.

Future versions of Xcode could help with this, but in lieu of clang-y goodness, it’s amusing to me that Brent and I hit on exactly the same way of threading the needle.

Are there more of us out there, muttering under our breath during our find/replace sprees?

 

1. My first thought here was, “But an Objective-C blog post should be called Self, not This.” So I am sharing that thought with you.

2. Well, also because I love organizing things.

How I Learned to Stop Worrying and Love the Podcast

There are three ways I interact with y’all on the Internet.

The first, Twitter, is delightfully immediate and informal, and I use it many times a day. (It’s really gonna suck if Twitter goes evil.)

The second, blog posts, seems like it should be close to Twitter in terms of immediacy and informality. But the more I write, the less this seems to be the case.

The blog posts I enjoy most are the ones that get to the heart of the matter quickly and simply. They give me the desired Ah-ha! moment and, boom, they’re done. (With, however, a level of detail that Twitter can’t provide.)

But writing posts like that…the good bloggers make it look easy, but it’s not. I myself have only written a smattering of random posts. But it’s never really felt like I’ve gotten better, or that I’ve developed a theme. Like my blog is really about something.

The third, podcasts, is something different again. Quite different.

It’s the only one with a schedule, so there’s a more of a rhythm to it than tweets or posts. (More practice.)

It can feel more immediate, more lively than a blog post, because you hear the host’s intonation. More emotion comes through. It’s easier to incorporate listener responses, like a Twitter thread. It’s fun.1

And because it’s an actual chat, rather than text on a page, the same rules don’t apply. You can go on long-winded tangents. You can get to the heart of your topic sideways, or even miss the critical point and fill it in the next week. You can make mistakes and laugh about it. If you’re enjoying yourself, your audience will too.2 And week by week, you can get a little better, hone your presentation skills, discover the topics you really shine at.

Basically, it’s one route to becoming a good blogger, if blogging alone isn’t cutting it.

 

1. And did I mention show notes? I really like putting things into the show notes.

2. Or they’ll stop listening. Same diff.

Build So Good

Continuing in my series of posts praising Xcode 41, I’d like to talk about the build confirmation sheet. This one:

If you press Command-B while Xcode 4 is already building, Xcode will bring down a sheet over the project window, saying “Stop build? A build action is already running”. There is also an option to not show the alert again.

Now, if I ever actually had to press that Stop button, this would not be a praise post. This would be the other thing. But in fact, under normal circumstances2, I never press that button. What happens instead is that Xcode chugs away on the current build, and then when that build is done, the sheet goes away, and a new build automatically starts.

This is so exactly what I want Xcode to do, it almost hurts.3

The sheets becomes a little UI reminder: Hey, you may have to wait a little longer for the build you just scheduled. And it’ll be easy to tell when it actually starts, because the sheet will animate away. I almost always want to wait for the build to finish anyway before doing anything else; I want to see whether the code I just wrote compiles without error and warning. So the sheet doesn’t impede me at all. It fits in with my workflow exactly.

And it’s been in Xcode 4 since the very beginning, as far as I remember.

1. If, on the other hand, you want to hear me complain about Xcode 4, follow me on Twitter. Or just read the second footnote. ↩︎
2. Under abnormal-but-still-frequent circumstances in Xcode 4.3, alas, the build never finishes, and I eventually have to force-quit Xcode to complete a build again. ↩︎
3. While it might seem logical to want a toggle, in practice, that’s not the case. Incremental builds never take long (if they don’t take forever, see above), so waiting isn’t hardship, and a toggle would always require two taps of Cmd-B, and having to be sure you get the timing right, or you’ll stop your own build. ↩︎

Xcode SDK Reminder

Even though Clark Cox hasn’t updated his blog in a while now1, he still has one post I don’t want to forget: “SDKs and Deployment Targets”, which walks through the Base SDK vs. Deployment Target Xcode settings. They can be confusing, but they’re vital to understanding how to build your app correctly.

Blogged it! Now I won’t forget.

1. And so in a bit of housecleaning, I’m unsubscribing. Sorry, Clark! ↩︎