Untıttled

Where we went wrong – a post by Charles Stross about the decisions and strokes of luck of (recent) history that have landed us in a world where ‘computer crime costs US businesses $67 billion a year’.

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.

Richard Feynman, talking about speeding up calculations during the Manhattan Project:

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?

Your interface needs a ‘Home’ button.

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

“Seven Reasons why Fireworks Works for Screen Design” — and, in particular, why it’s better than Photoshop or (heaven help you) Illustrator for this task.

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 post this here so that future generations may laugh.

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.

I just updated the Greenvoice codebase to use Rails 2.3.2 and RSpec 1.2.0, and got a flurry of failing examples from our routing specs. It turns out the routes_for helper in RSpec 1.2.0 is a bit stricter when it comes to request methods and parameters.

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.

Ben Ward has written an excellent post about Cappuccino, the web application framework by 280 north that lets you “build desktop-caliber applications that run in a web browser”. He expresses a commonly-held criticism of Cappuccino, which is that it divorces developers from having to understand or appreciate the core web technologies and principles of HTML, CSS, JavaScript, openness and standards. In doing so, it encourages people to create web apps that simply don’t work well with the rest of the web, and simply ignore most of the last few years’ significant progress in accessibility, interoperability and more across the rest of the standards-based web.

I generally agree with most of Ben’s sentiments — I am a web developer first, and my experience with native GUI app development and Flash/Flex development run a far second and third respectively. However, even after reading many similar rants, I still can’t get myself angry about Cappuccino.

In my eyes, Cappuccino is an early, prototype of an open-source version of Flash/Flex, which is built on the standard web technologies of HTML, CSS and JavaScript. To me, this is a good thing to have around. There is increasing demand for desktop-style applications that are served over the web, and the idea of letting Adobe create another proprietary monopoly in this space scares me more than Cappuccino’s backward steps.

Yes, its standards-compliance and accessibility are pretty dire at the moment, but I believe that these are things that can be improved. It’s open-source, after all.