distraction in action
If you’re building an iPhone app that uses Facebook Connect you’re eventually going to need a session proxy. The session proxy acts as a middleman between your iPhone app and Facebook’s servers, so that you don’t have to distribute your Facebook app secret with your app, where it can easily be extracted by someone knowledgeable with a hex editor.
I recently had the pleasure of being invited to give a talk about Backup Bouncer to the University of Utah Mac Managers Meeting. I spoke a bit about Backup Bouncer’s history, gave a brief tour of the HFS+ filesystem, and gave a demo. If you’re interested in the topic you can download the slides, audio, and video from iTunes U:
Or you can just search the iTunes Store for “Backup Bouncer”. Surprisingly enough, my talk is the only hit.
It was nice to get a chance to talk about my work, but a bit strange to give a talk over Skype. I was expecting a video feed from the other end but there wasn’t any, so for all I know I was giving the talk to an empty room. This had the beneficial side effect of totally eliminating any stage fright I might have felt, so maybe it was a net win.
Skype doesn’t support screen sharing and webcam video simultaneously, so the poor attendees were stuck looking at my (very static) slides while listening to my disembodied voice. Furthermore, judging by the stuff on iTunes the sound quality of my bluetooth headset let a bit to be desired. (Geez, you sink a whole $5 into a bluetooth headset and you get junk! Where is the love?)
Some of you have probably noticed that I’ve been neglecting some of my other projects and complaining about being busy a lot lately. Well here’s what I’ve been working on. I’m pleased to announce HexaLex, a new angle on crossword games! The first platform for HexaLex is iPhone and iPod Touch, but I’m planning to expand to Facebook in the near future.
If you want to get a quick overview of the game and a list of features go ahead and visit the HexaLex.com website. If you want to read some great 5-star reviews or buy the game just pop on over to the App Store. Continue reading for a little more detail on the core concept of the game.
HexaLex is an idea I came up with a little over a year ago as a grad student. The core gameplay is a lot like Scrabble, Words With Friends, or Lexulous, so if you’ve played one of those games you’ll get the idea right away. You use tiles to build words on a game board. But HexaLex has a big difference — it’s played with hexagonal tiles. Looks interesting, right?
Playing a crossword game with hexagonal tiles sounds like a simple idea but it actually requires a bit of creative thinking to make it playable and fun. (This is probably why it hasn’t been done a million times already!) You see, when two words cross with square tiles they only interact at one tile — the tile of intersection. With hexagonal tiles, that’s not the case. Hex tiles cause interactions at the tile of intersection and its neighbors! This means that playing one word across another word also forms two new two-letter words. This is sort of hard to describe, but easy to see as a picture (like the one below).
Traditionally, in crossword games you have to make every word on the board valid. If you just take the standard rules and try to use them with hexagonal tiles you’ll quickly discover that the game is unplayably hard. It’s just frustrating to have to work out two valid two-letter words for each and every crossing play.
The way I solved this in HexaLex was to introduce the idea of junk words. A junk word is a two-letter word that’s not a valid word. So XR, TQ, and ZA are examples of junk words. (Oops, ZA is actually a valid word, at least in the strange world of crossword games.) In HexaLex you are allowed to play junk words subject to a few restrictions:
With junk words, a simple play of one word crossing another is always possible provided the two words share a letter. The game is playable once again and balance is restored!
So now you know that when you look at a HexaLex game it’s OK that some of the two-letter words are bogus, but all of the longer words have to be legit.
Junk words aren’t the only break from Scrabble tradition in HexaLex but I’ll leave the rest for another post.
HexaLex is available now in the App Store. Give it a shot! Initial App Store reviews have been overwhelmingly positive, with fourteen unanimous 5-star ratings and reviews so far. If you enjoy HexaLex please let me know! You can also become a HexaLex fan on Facebook and/or follow HexaLexGame on Twitter. Also, please help spread the word by clicking the digg button!
As QLColorCode fans are aware, Snow Leopard’s version of Xcode has caused some trouble for me. To wit, Xcode 3.2 shipped a Quick Look plugin that registered for the public.source-code uniform type identifier1 (UTI), which is the primary UTI that QLCC registers for so it can do it’s magic. In the world of applications it’s possible to bring up the Finder’s Get Info dialog on a file of a given type and assign it and it’s kin to some application, but there’s no such interface for Quick Look plugins. Thus, there is no way to express a preference for QLCC over Xcode without removing or renaming the Xcode plugin.
To make matters worse, the system’s top-secret non-configurable algorithm for resolving conflicts appears to work backwards from what users might hope for. The Xcode plugin lives inside an Apple-supplied app bundle in a system directory. It’s installed automatically if you choose to install Xcode itself, so it can easily up on your system without you even knowing it. Compare this to QLCC. You, the user, have actively downloaded it and installed it for the express purpose of handling source code files in the Quick Look system. You can easily remove it if you decide you don’t like it anymore. Which plugin do you think should win if they conflict? Apple thinks different. The system always picks the Xcode plugin over QLCC.
But come on, if you’re going to have a system like this there ought to be a way of saying “I want plugin X to handle UTI Y.” This could be a nice shiny user interface somewhere or a down-n-dirty terminal command, but it needs to exist. I sent a bug report to Apple saying as much (rdar://7240036, mirrored here). I described my problem and made it clear that the solution ought to be a preference system for Quick Look. At the very least, I said, user-installed plugins should rule supreme.
Apple engineering’s response? You can register for more specific UTIs than public.source-code. Nothing about why they don’t want to have a preference system or let user-installed plugins override others. Just “register for more specific UTIs.” The idiocy of this suggestion is staggering. The whole purpose of the hierarchical nature of the UTI system is to allow folks like me to say “I handle source code” without having to list every type of source code. Highlight, the library that QLCC is based on, can colorize about 140 programming languages. Apple engineering, with a straight face, is telling me that I should be registering for 140 UTIs because Xcode decided to register for the one I actually need.
It gets worse. Even if I decided to take Apple’s advice, it’s impossible to say what those 140 UTIs should actually be, because there’s no central authority for registering UTIs. (This is another glaring flaw with the UTI system as implemented by Apple.) UTIs like
So let’s go back to my hypothetical 140-UTI plugin. Imagine the confusion and headaches when a user’s
But really, this is just an example of brush-off via bug report. Despite my slagging I do believe the engineers at Apple are generally quite talented and bright. They must know that the problem exists, but for whatever reason they’ve decided it’s not worth solving. Furthermore, they’ve decided it’s not worth telling some no-name hacker why they think it’s not worth solving. But the most insulting thing is that they didn’t even bother to mark my issue as a duplicate of some other issue requesting a prefs system for Quick Look. (You’d better believe that one exists.)
“Go register for more specific UTIs, kid, yer bothering me.”
1 If you’re unfamiliar with the UTI system, John Siracusa’s encyclopedic review of Tiger has a detailed description.
This is a quick note for any iPhone devs out there who are having problems getting their stack traces to show up with symbols in the Leaks instrument when running on the simulator. It turns out that this is an issue with using the iPhone SDK 3.0. If you switch your active SDK to 3.1 in Xcode then the symbols will appear again. Apple says they’re “aggressively” working on the issue.
For history’s sake, I’m observing this on Snow Leopard 10.6.1, Xcode 3.2, Instruments 2.0.
Update: Thanks to a misconfiguration on my part, QLCC 2.0.0 didn’t work on Leopard. The problem is solved in QLCC 2.0.2.
Continuing on my “update side projects for Snow Leopard” theme, I’ve just rolled a new release of QLColorCode. I added support for a few new languages, including Scala, which is a personal fave. I also fixed a bug or two and finally upgraded the bundled version of Highlight from 2.6.6 to 2.12, which was long overdue.
On the ‘meta’ side, I moved the project’s source code from google code’s subversion to github. I’ve been using git a lot lately so I expect I’ll do the same for my other projects as well. Once you’ve gotten used to firing off branches for every little thing that crosses your mind and seamlessly switching between them at a moment’s notice it becomes hard to work in the SVN mindset again.
Unfortunately, QLCC has hit a bit of a roadblock with Snow Leopard. More specifically, it’s not SnoLep that’s giving me a headache, it’s Xcode 3.2. With the new Xcode Apple decided to include their own QL plugin for source code. That’s great, I say, more choice is good! QLCC will render everything that Xcode renders plus OCaml files, Scala files, and all sorts of other interesting languages that Xcode can’t handle. I’m not worried about QLCC losing in a fair fight. But no, Apple doesn’t fight fair.
It turns out that Quick Look always picks the Xcode plugin when rendering source code files (on my machine, at least). I don’t think the Xcode plugin gets special treatment, it just happens to win in the algorithm QL uses to resolve plugin conflicts. What is that algorithm? Nobody outside of Apple knows. It could be a coin-flip for all we know. Heck, after a reboot it’s possible QLCC will always win! In any case, when there are two plugins that both want to render files of type
Except it’s not all fine. Because let’s say a user decides that they prefer QLCC over the Xcode plugin. Their only option for getting QLCC consistently and predictably is to somehow disable Xcode’s plugin. They could remove it, rename it, or move it somewhere that
Update: After further research, it appears that disabling the plugin will not invalidate the signature on Xcode itself, so there shouldn’t be any terrible consequences if you choose to do so. The plugin is located at:
So anyhow, QLColorCode 2.0 is out. It works with Snow Leopard. If you have Xcode 3.2 installed you’ll probably never get to see it do its thing, but maybe one or two of you will still get something out of it.
For what it’s worth, quick look still sends .plist files to QLCC. Xcode’s plugin won’t touch those things.
I just wrapped up Backup Bouncer 0.2.0, with the major change being that it now builds on Snow Leopard. Get it at the usual place. BB used to include a program called ctool that I had thought about using but never actually used. This ctool program was unmaintained and didn’t build on SnoLep, so I finally just wiped it out.
All is not quite well on the Snow Leopard front, however. The rsync that Apple ships (at least the one in 10.6.1) has a bug. When copying a FIFO it attempts to copy the contents of the FIFO. If you know what a FIFO is, you know why this is bad. So rsync hangs in the
Oh, and I also fixed a bug with the BSD flags test. If you care about that stuff you should re-test.
One other interesting tidbit — I changed the “lots of metadata” test to lock the file. This trips up some copiers that duplicate the “locked” status before setting up other metadata, causing the other metadata to be lost.
Much to my shame, I had an e-mail upheaval and I can’t find the names of the individuals who reported the BSD flags bug and the “early locking” phenomenon. If that was you, please drop me a message and I’ll give you the credit you deserve.
UPDATE: It was Rob Kennedy who reported the BSD flags bug and the “early locking” phenomenon. I hadn’t thought to search through my blog comments. Silly me! Thanks a lot for those tips, Rob!
I get a lot of mail from people wishing Forget-Me-Not worked in Leopard. For them, I’m happy to report some hopeful news. A while back I was contacted by a senior Apple representative who expressed interest in helping me revive Forget-Me-Not. In the end, after consulting with Apple engineers, it was decided that the way to go forward would be to provide a new API suitable for FMN. This conclusion was slightly surprising to me, because it seems like the API we’re using should be suitable, but then again I’m not an Apple engineer. In any case, if you want to revive FMN, please file a bug report at http://bugreport.apple.com (requires a free ADC membership) and say you want to support the enhancement in bug report 6018339. You don’t have to say much of anything, just make sure to reference that bug number — Apple considers duplicate bug reports “votes”, so you want to make dead sure they know it’s a duplicate.
Before you get your hopes up, please understand that this contact was made back in the early summer and nothing much has come from it. Hopefully a few “votes” for the issue will get the ball rolling again.