In the meantime, you can keep MultiClutch working by running your apps in 32-bit mode.  For example, to use it in Safari, use the Finder to ‘Get Info’ on Safari and then check the “Open in 32-bit mode” box as shown.

Thanks for all the kind words and supportive emails.

Update: User Prashant has a fork of MultiClutch running in SnowLeopard using SIMBL. I have not tested this but several users have commented that it works as intended in 64-bit apps. Thanks, Prashant!  SIMBL has all the limitations as input managers plus you have to install the thing, so I’d still like to see a version that doesn’t use SIMBL. I’ve made some progress to that end, but no promises and nothing to report yet.

javascript:var%20meta1=document.createElement(%27meta%27);meta1.setAttribute(%22name%22,%22apple-mobile-web-app-capable%22);meta1.setAttribute(%22content%22,%22yes%22);document.getElementsByTagName(%22head%22)[0].appendChild(meta1);

To use, drag the above code chunk to you bookmark bar and give it a name (sorry I can’t post it as a simple link. That’s due to reason #37 I never should have switched to WordPress).  Once you sync, you’ll be able to select the bookmarklet while viewing any page to make it ‘fullscreenable’.

A few other exciting things that have been in the works. First of all, I’ve been interviewing with Apple for quite some time and they recently offered me a job. I have accepted the job and will be starting early next month, just in time for WWDC! I’ve always dreamed of working at Apple, so this is an amazing opportunity and I can’t wait to start. This also means I’ll soon have a replacement for my stolen MacBook Air, and so MultiClutch can get some much needed love (I’m currently writing this post on a G4 Cube which, besides lacking Multitouch support, is a quite beautiful but painfully slow machine to develop on).

Speaking of MultiClutch, check out the video coverage it recently got from Macworld’s Dan Frakes. Great demos, Dan! I’d love to put video demos of the gestures like those in Apple’s pref pane into future versions of MultiClutch. The response to MultiClutch has been really great, if a bit overwhelming as I finished my thesis and exams, but I’m really looking forward to making MultiClutch shine now that those things are behind me.

The next couple of weeks will be my last in Portland, Oregon while I take some much needed R&R before the move down to SF. I’ll also be catching up on the mountains of emails, ‘gnat tasks’ and paperwork that built up over the final stretch of things. See you at Railsconf!

Update: 3 days left.  Follow the action here.

MultiClutch works by installing a simple input manager that will catch a gesture events, looks to see what shortcut you’ve defined for it in the frontmost app (if you haven’t defined anything, it behaves in the standard manner), and performs that shortcut. You use a System Preference Pane to customize gestures with an interface similar to the shortcut-customization table in the Keyboard & Mouse pane. You can ‘bind’ gestures in a given Cocoa app (due to the nature of input managers, Carbon apps are not supported) or globally. In addition to zooming in and out, and rotaing in either direction, and the four swipe directions, I’ve been experimenting with ‘combo’ gestures. Right now, I’ve added the ‘zoom in, zoom out’ gesture (i.e., in one fluid motion) and vice-versa, with more perhaps to come if I find them to be intuitive and useful enough.

This app is currently in beta, so it should go without saying that you should use it at your own risk and have a backup before you install it. That being said, I and several other testers have been running the app smoothly on our systems for quite some time, and MultiClutch is very careful to be safe in the way that it supports gestures. Please get back to me with feedback if you have ideas or run into issues.

If you’d like to donate to help support the time I took developing MultiClutch (which was not insignificant), you may do so by following this Paypal link.

Download Multiclutch [255kb]
Dig this!
Use this app on iusethis

Update: There was a rare issue where binding certain key combinations could cause the preference pane to hang. A new beta fixing this issue is up and it is a recommended upgrade. MultiClutch will prompt you to install the new input manager when you install the preference pane.

Update 2: Fixed donation link =).

Note: Multiclutch uses a modified version of a bit code from shortcutrecorder to help display custom shortcuts to the user, and I thank those developers for their hard work in the frustrating area of converting keycodes to characters.

\newtheorem{mydef}[equation]{Definition}

How to get predifined enviornments – figures, for example – to share counters is a bit trickier. I tried to use \newcounter’s optional command to link the figure counter to the equation counter but no dice. It did, however, tell me the name of the command that is actually used to refer to the figure counter: c@figure. Thus, I was able to get what I wanted by simple overriding the c@figure command:

\renewcommand{\c@figure}{\c@equation}

 Extensive googling on the subject revealed nothing. Hopefully this is of help to someone…

1. Ubiquitous data. This is obvious but cannot be overemphasized. Synching is the way of the past. The iPhone is great for making computing truly ubiquitous. The fact that our data is not seems almost an anachronism.
2. Synching is constrictive. Not only does syncing suck for tying you down, but its harder and more closed as a technology. Say Apple comes up with an SDK that allows developers to sync arbitrary data from Macs (and PCs!) to their iPhone – this would be truly impressive. Yet even in this best-case scenario, developers would then have to write an iPhone client AND (presumably) a Mac/PC client to sync via.
3. Cocoa programmers are hard to come by. It will be a lot harder for Apple to take over the smartphone market if its apps are difficult to write and require rather specialized knowledge of a huge framework and rather obscure (but awesome) language. Everybody, on the other hand, knows AJAX.

Now, you might object to reasons 1 and 2 on grounds that perhaps Apple will allow apps to transmit data via the EDGE/WiFi connect and syncing could thus be done in that manner. We’ll see. And yet this seems like reinventing the wheel to me. What I’d really like to see, and what I think would be easier and more fruitful in the long run (much as I hate to say it as a dedicated Cocoa programmer thrilled at running Mac OS X in my pocket) is Apple’s SDK turning out to be a much deeper and more thorough implementation of the things they released last summer. For example, a Google-Gears (update: thanks to an astute reader for reminding me about this) type component for allowing offline access and better application responsiveness. In addition, it’d have better integration with some of the phone’s unique features (special javascript functions for detecting and handling multi-touch input springs to mind). Of course, those alone are some serious hurdles – its likely that javascript support on the phone would have to be greatly improved to achieve this, etc. Nevertheless, some of the much more difficult issues (as it seems to me) like distribution, syncing, and security would be trivialized. Perhaps we’ll see something akin to this when the SDK announcement happens. Perhaps it will be a Cocoa-based SDK after all. Perhaps both (I’d love that). Whatever the case, I’ve changed my tune on what I think would be the best single solution, and now I’m hoping Apple’s agrees. Their recent introduction of Webclips gives me hope – they’re giving developers the tools they need to close the gap between web app and native app. On the other hand, revisiting the WWDC keynote doesn’t give me an inkling of faith that Apple had such revolutionary plans: it just seemed like they didn’t have an SDK ready. Time will tell, but I for one won’t be among the moaners if it ends up being a (solid) extension to the web apps strategy.

Day 1: Getting started with Ruby – in this class we learned about some of the basic features of Ruby. We learned about test-driven development, and dove right into TDD with some simple code and concepts. Update: Link fixed![20.9MB]

Day 2: Rails – in this class we talked about the structure of a rails app and looked at a sample rails app. I didn’t think to record the demo of the app and talk about the code – maybe next time with Snapz Pro? We also talked about some of the flaws in the sample and improved it by moving controller code to the model. See skinny controller, fat model. Finally, we started created a new class scheduling app (again, not in video – sorry!) which I will post a solution to tomorrow. [Video: 16.7MB] [Sample App (unimproved version): 124kb]

Day 3: Ride On – Today we improved our class scheduling app, using each improvement to talk about some features and ideas in Rails. First, we talked about migrations – including populating new table columns. We also talked about fixtures. Next, we talked about validators, and fixed bugs using TDD. We talked a bit about views. Finally, we talked about using svn for version control and collaboration.[11.8MB]

Day 4: REST – Today we talked about RESTful developement. The slides largely focus on the high-level concepts, with a bit of code to ground. Thanks to Greg after for his killer presentation of Grabb.it and talk about routes. Unfortantly, we didn’t get a recording of that. [Video: 16.7MB]

Thanks to all who showed up for the class! Thanks especially to Greg and Chris of Grabb.it for coming and sharing wisdom and code. Please send me feedback about my teaching skills and topics – either via email or anonymously as comments.