Now, not all applications (or, more precisely, important operations of an application) are amenable to parallelization. True, some problems, such as compilation, are almost ideally parallelizable. But others aren’t; the usual counterexample here is that just because it takes one woman nine months to produce a baby doesn’t imply that nine women could produce one baby in one month. You’ve probably come across that analogy before. But did you notice the problem with leaving the analogy at that? Here’s the trick question to ask the next person who uses it on you: Can you conclude from this that the Human Baby Problem is inherently not amenable to parallelization? Usually people relating this analogy err in quickly concluding that it demonstrates an inherently nonparallel problem, but that’s actually not necessarily correct at all. It is indeed an inherently nonparallel problem if the goal is to produce one child. It is actually an ideally parallelizable problem if the goal is to produce many children! Knowing the real goals can make all the difference.

If you’ve ever been invited to an event or group on Facebook by a friend who has lost their phone, and is asking everyone to post their phone numbers so they can recreate their address book, you’ll be pleased to see that Facebook is now prompting these people to do something less stupid.

Don’t know what’s actually triggering this — presumably it doesn’t show up every time someone tries to make an event. Or maybe the problem really is that prevalent, and so it does.

A rather clever fellow by the name of Stanley Frankle realized that it could be done on IBM machines. The IBM company had machines for business purposes, adding machines that are called tabulators for listings sums and a multiplier, just a machine, a big box, you put cards in it and it would take two numbers from a card and multiple it and print it on a card. And then there were collators and sorters and so on. So he decided, he’d figured out a nice program. If we got enough of these machines in a room, we would take the cards and put them through a cycle…

We had done things like this on adding machines. Usually you go one step across yourself, doing everything. But this was different—where you go first to the adder, then we go to the multiplier, then you go to the adder, and so on. So he designed this thing and ordered a machine from the IBM company… but it was delayed, always delayed… we worked out all the numerical steps we were supposed to do, that the machines were supposed to do, multiply this, and then do this, and subtract that. And then we worked out the program, but we didn’t have any machine to test it on. So what we did, I arranged, was a room with girls in it, each one had a Marchant [a desktop mechanical calculator]. But she was the multiplier and she was the adder, and this one cubed, and so we had cards, index cards, and all she did was cube this number and send it to the next one. She was imitating the multiplier, the next one was imitating the adder; we went through our cycle, and we got all the bugs out. Well, we did it that way.

Taken from his talk, “Los Alamos from Below”, as reproduced in the book The Pleasure of Finding Things Out.

Q: How do you close applications when multitasking?
A: (Scott Forstall) You don’t have to. The user just uses things and doesn’t ever have to worry about it.
A: (Steve Jobs) It’s like we said on the iPad, if you see a stylus, they blew it. In multitasking, if you see a task manager… they blew it. Users shouldn’t ever have to think about it.

from the Q & A session after the recent iPhone OS 4 event, as reported by Engadget

So what’s this, then?

(screenshot from MacWorld’s preview of Microsoft Office for Mac 2011)

I link to this mainly because it confirms my own internal reasons for preferring Fireworks, and thus makes me feel like less of a kook when people say, “Fire-what?”

I’ve used Apple’s iCal to manage my calendars for as long as I’ve had a Mac. In the past few months, since I started using two Macs and an iPhone on a regular basis, I’ve been using MobileMe to keep them in sync. This was all grand, except that I couldn’t sync my iCalendar subscriptions since MobileMe doesn’t support that yet.

More recently, I’ve needed to start keeping a separate work calendar to share with my colleagues at Greenvoice, who also share their calendars with me. We use Google Apps at Greenvoice for calendaring, but unfortunately, neither iCal nor MobileMe plays particularly well with Google Calendar.

Enter BusySync. This is a great piece of software that, among other clever syncing things, includes the ability to seamlessly sync your calendars from Google Calendar with calendars in iCal.

So. I have a personal Google Calendar account. I subscribe to iCalendar feeds in this account, and I also subscribe to my work calendars through it. Then, BusySync syncs all of these to iCal on my personal Mac. MobileMe then syncs this to my work Mac and my iPhone.

It’s kinda ridiculous, and took a fair amount of initial setup, but it now runs seamlessly.

For example, here’s an example that worked pre-1.2.0:

route_for(:controller => 'friends',
          :action => 'request_friend',
          :user_id => 1).should ==
'/users/1/friends/request_friend'

This fails under 1.2.0, for two reasons. First, if your route doesn’t accept GET requests, you need to specify the method like this:

route_for(:controller => 'friends',
          :action => 'request_friend',
          :user_id => 1).should ==
{
  :path => '/users/1/friends/request_friend',
  :method => :delete
}

Second, it’s stricter about all parameters being strings; in this example, the user_id parameter was specified as a number, and it wasn’t matching. This is the final, passing example:

route_for(:controller => 'friends',
          :action => 'request_friend',
          :user_id => '1').should ==
{
  :path => '/users/1/friends/request_friend',
  :method => :delete
}

Update: Of course, if I’d bothered to look, this is all pointed out in the ‘Upgrade’ document that comes with RSpec 1.2.0.