Always The Critic

Fix alerts for Google calendars on Mac

I like to live life on the edge, and helping me to do that is my Mac's Calendar app with its predliction for silently discarding all alert settings for Google calendar entries. This stresses me out as I'm just waiting for the first time I embarassingly fail to turn up for something. Today, and frankly not for the first time, I set out on a serious Google hunt to find a resolution. I now have one that's just about tolerable.

It seems the basic problem is that when you modify a Google calendar entry via Calendar, it then immediately syncs back from Google and wipes out any alert that you just configured. But you didn't want to go to that meeting anyway, right?

I can't claim original credit for my solution, but I can endeavour to explain it very clearly and add a few extra tidbits. The trick/workaround is to configure Google Calendar itself, via its web UI, to have a default alert for all newly created events. Then it seems that you can modify the alert successfully from within Calendar, to a different number of minutes ahead. However you can't remove it, so you have to just live with alerts for everything. To me that's far preferable to none at all.

You can change the setting for Google Calendar as follows.

• Sign in to your Google calendar at https://www.google.com/calendar.
• Open the settings page by selecting "Settings" from the gear dropdown in the top right.
• Select the "Calendars" tab at the top.
• In the list of calendars (which probably only contains your one calendar) select "Reminders and notifications"
• In the "Event reminders" section at the top, select "Add a reminder"
• Select "Popup" and however many minutes you want, for the default reminder.
• Don't forget to click the Save button at the top left.

Windows 8 = CQRS

Allow me to wax philosphical for a moment with an observation about where computers and their operating systems are heading.

In the world of software development CQRS = Command Query Responsibility Segregation, which in its simplest sense recognises that it's sometimes better to use a different mechanism for reading data than it is for writing it. See Martin Fowler's exposition of the concept if you want to know more, but this post isn't actually about software development at all!

I reckon that we're at a critical juncture in the evolution of personal computing devices and that the CQRS principle is necessarily coming to the fore to save the human race.

Tablet computers are taking the world by storm, in case you hadn't noticed. Apple could barely make enough iPad Minis for me to be able to get my wife one for Xmas, though I did manage it at the very last minute, and shortly thereafter bagged one for myself too. Frankly it's bloody brilliant, but I use it predominantly for consuming rather than creating and I'm far from alone. This is partly because the human populace is inexorably dumbing down towards being fat blobs with brains wired directly into the 'net, consuming inane banter, amusing picture of cats and the latest celebrity news, 140 characters at a time. But that aside, it's just not very pleasant to write large quantities of text, manipulate images or perform other expansive creative works by prodding a tiny screen. Or even a big screen.

To write software, construct lengthy blog posts (ahem), edit movies, sequence the human genome or design great buildings requires a proper computer! On that basis I posit that there will always be a place for desktops and laptops, or indeed whatever replaces them but which necessarily has a non-trivial input mechanism. I genuinely worry that the market for serious computers will be increasingly neglected by the manufacturers, refocussing as they are on the mass consumer market, inevitably leading to the downfall of humankind. Perhaps I exaggerate - at least I hope so.

Now I've never used Windows 8, indeed I shudder at having to use Windows 7 on a daily basis at work, but I understand it represents something of a chimera. It is best known for its shiny, touchy, slidey 'Metro' UI, beckoning your greasy fingers to caress its tiles. However it also allows you to fall back into the more staid world of traditional Windows where presumably you can get some proper work done, as long as you have a keyboard and a pointing device other than your finger. I understand critics are conflicted about this hybrid approach, but it's CQRS writ large and may therefore be the way forwards. One way or another, at least some people will need to create great works. I do hope to be one of them, and to have the equipment to be able to do it.

Apache Bench (ab) stalls after 16000 requests, due to ephemeral ports

I've been doing some trivial benchmarking of Play 2 with ab (Apache Bench) just to get an idea of its raw capabilities for serving simple requests - and because it's what I always do when picking up a new framework so I know what I'm dealing with. In doing so I ran into a bit of a puzzler that had me thinking Play 2 was bugged - but my spidey sense soon kicked in and told me it was more likely to be an OS or ab issue. I had done approximately the following, using Play 2.0.1 on OS X 10.7.3, and I'm pretty certain you'll see the same results if you do this on a Mac:

> play new hello  [select option 1 - basic Scala app]
> cd hello
> play start
> ab -c 50 -n 16000 http://localhost:9000/  [Runs fine - about 3700rps]
> ab -c 50 -n 16000 http://localhost:9000/  [Gives up with timeout]
> ab -c 50 -n 16000 http://localhost:9000/  [Runs fine - about 3700rps]
> ab -c 50 -n 16000 http://localhost:9000/  [Gives up with timeout]

It took me a bit of experimentation to establish that it's about 16000 requests that work fine, followed by timeouts, in a reliable pattern. That's a suspicious number, being near enough a power of 2, which is what clued me into it being an OS limit that I was running into. I ran the same ab test (with the same result) against the built in Apache https serving a static file, confirming that Play 2 probably wasn't to blame.

Sure enough, a quick Google turns up the goods. My OS was running out of the approximately 16000 ephemeral ports available and having to wait for them to be released before it could reuse them. So not Play 2 or ab's fault at all. Actually in some senses it is Play 2's fault for being so fast that I've run into this limit.

I'm not going to go into the details of what ephemeral ports really are, as others have done that perfectly well, and there is a good StackOverflow answer with some key ways to work around the problem by modifying parameters of the OS' network stack - but be careful and make sure you understand what you're doing.

However, one very simple way to workaround the issue is to simply pass the -k option to ab, to use HTTP keepalive (assuming the server you're testing supports it). Note that this changes the nature of your test though, as you're no longer really simulating large numbers of separate connections - but for basic sanity check testing it may help. For the record `ab -c 50 -n 100000 -k http://localhost:9000/` benchmarked Play 2 at about 7000 requests per second on my 2.4GHz Core Duo MacBook.

RVM and NetBeans

I've been having a lot of trouble with my Ruby 1.9.1 install on Mac OS X. Mostly it works fine, but I struggle when installing gems that require native extensions. I think this is because the way my install was built causes linkage problems, perhaps due to 32 vs 64 bit issues, or due to linkage with other libraries. I'm not entirely sure what's causing the problems, but recently I decided enough was enough and tried out rvm since I've heard a lot of good things about it. I got the impression that by compiling from my own source I was stubbornly making a lot of my own trouble.

Rvm is trivial to install: it's a gem that installs some of its own executables. I did hack my PATH first, to remove /usr/local/bin (where my custom Ruby lived) so that I'd be using the stock Mac OS X Ruby for the rvm install.

> sudo gem install rvm
> rvm-install

Note that rvm-install added the following to the end of ~/.bash_profile automatically, so I could ignore the instruction it gave me about adding it myself:

if [ -s ~/.rvm/scripts/rvm ] ; then source ~/.rvm/scripts/rvm ; fi

I then used rvm to install a fresh version of Ruby 1.9.1: >> rvm install 1.9.1

Actually that failed with an error about libsqlite3.dylib being the wrong architecture - perhaps another hangover from my old manual installs, or a problem I'm going to have to solve sometime in the future! For now I moved the old version of that file and tried again:

> sudo mv /usr/local/lib/libsqlite3.dylib /usr/local/lib/libsqlite3.dylibOLD
> rvm install 1.9.1

And that left me with a decent ruby 1.9.1 install. Which brought me back to one of the things that I was originally frustrated by: getting NetBeans Ruby debugging working with the fast debugger. With my old install the ruby-debug-ide gem would not install, but I'm pleased to report that it does with this new setup.

However getting NetBeans to actually use my new rvm ruby required a bit of a trick. The Ruby Platform management GUI in NetBeans doesn't show you hidden folders in its file picker, so you can't navigate to the ~/.rvm/ruby-1.9.1-p243/bin/ruby file that it wants. The trick is to create a non-hidden symlink, so you can then find it from NetBeans (and it's also handy to get at your rvm files from Finder):

> ln -s ~/.rvm ~/rvm

One word of warning: once you're using an RVM Ruby install, do not use sudo for gem installs, as the gems (and every part of rvm) live in ~/.rvm so sudo is not required. In fact using sudo will knacker your gems quite badly as it gets its PATH wrong and its permissions and you end up deleting a bunch of stuff to get back to a known good state. I learnt this the hard way!

MacRuby 0.5 beta 1 Released

I was very excited to see MacRuby 0.5 beta 1 had been announced, complete with ahead of time compilation via LLVM. It has been long while since the previous update on the MacRuby blog in March, but clearly a lot of work has been taking place. At the moment this beta shows the promise of things to come but isn't yet fit for much more than anticipatory experimentation. If you want to try the macrubyc compiler, Antonio Cangiano's blog post on the topic is a must-read.

The MacRuby notes suggest that compiled ahead of time or not, it uses LLVM for a big speed win, but my own quick experiment showed the macruby interpreter to be about 3 times slower than the standard MRI Ruby 1.9.1. This was with a single small benchmark app only though, just to prove things were working, so I can't draw conclusions. I can't pretend I wasn't a little disappointed not to see MRI blown out of the water though, even though I know it's unscientific and wrong of me!

I couldn't get a fully compiled version to produce any output, though it appeared to run without barfing, so I couldn't tell if it was really working or not. It was notable that the compiled binary was nearly 15MB so there must be a lot of statically linked code being included to swell my couple of KB of Ruby code so much. I'm hopeful that this can be improved in the future in order to support my dream of iPhone apps being written with Ruby hooking into Cocoa. In fact more than a dream - I'm hopeful and optimistic that in the long-run Apple will make Ruby a heavily promoted first class citizen for Mac and iPhone development, sitting on top of Objective-C but hiding it for the most part. The whole world has moved on from primitive C-based languages to higher levels of abstraction and I think Apple really needs a successor to Objective-C within the next 5 years. Is MacRuby it?

Mighty Mouse Ball Cleaning

Every few months the scroll ball on my Apple Mighty Mouse starts to get a bit intermittent because of the build up of dirt, fibres and grease in the mechanism, which is very frustrating. For the past few days I've only been able to scroll up, and reading web pages backwards is losing its novelty. There are a million and one web pages out there telling you how best to clean your ball, and I've tried several of them.

Some people suggest taking the mouse apart, but that apparently incurs a high risk of cracking it, requiring gluing back together, and is clearly an all round monumental faff, so I count it as an option of last resort which thankfully I've not had to employ yet.

Running a fine piece of sticky tape under the ball and flossing was a particularly delicate operation but didn't make much difference, so I don't recommend that.

Turning the mouse upside down and simply rolling the ball around on a clean piece of paper has the beauty of immediacy and simplicity and certainly helps a bit, but not if you've got major problems.

Best of all is the application of WD40 (or even vodka as one German YouTuber advocates) then a good roll around with a clean rag. The idea is to get your cleaning fluid all around the ball so it cleans the rollers underneath, dissolving the grease and lifting fibres, so I recommend long circular movements in many directions, trying to get the ball going every which way. A second application may be required. Don't use too much fluid though or it may wreak havoc with the inside of your mouse. WD40 is just viscose enough, and easily sprayed on in a small quantity, so it's controllable. It sorts me out every time.

Snow Leopard Arrives

Precisely one week after it was launched, my copy of Mac OS X 10.6 "Snow Leopard" landed on my desk at work. Apple claim to have posted it last Friday, but the bank holiday weekend and postal strikes have conspired to keep me waiting this long.

On my recent Mac Pro it installed in 28 minutes and recovered a startling 31GB of disk space. I'm not quite sure how it managed that to be honest, as it's a lot more than most others are reporting. [Update: actually I suspect it's because Apple have changed the definition of a GB for Snow Leopard, so my comparisons of space used before and after are not comparing like for like. Now 1GB = 10^9 = 1,000,000,000 bytes, whereas previously it was 2^10 * 2^10 * 2^10 = 1024 * 1024 * 1024 = 1,073,741,824 bytes.]

That same Mac Pro is also capable of booting into the 64 bit kernel by holding down '6' and '4' during boot. You can check it's worked in System Profiler, where on the Software page it should say  "64-bit Kernel and Extensions: Yes". I've not noticed any abnormalities and supposedly it might run a bit faster this way, so if it stays good then I'll probably set it to 64 bit kernel permanently.

Note that only XServe machines boot with the 64 bit kernel by default, and many 64 bit Macs (like older Core 2 Duo MacBooks) can't do so because they lack 64 bit EFI (Extensible Firmware Interface).

In general I like Snow Leopard - it's the same as Leopard but all round snappier and a bit nicer. Some changes confuse me though. Take the new arbitrarily styled menus for dock items, as shown below. Nothing else in the system looks the same, and that's probably a good thing because it's hard to read, with the section heads and tick marks being far too low contrast. They're almost invisible! A real UI own goal if you ask me. Maybe they designed it before they set the gamma to 2.2...

Snow Leopard Up-To-Date Program: Not Working for UK

Update (26th Aug 2009): It does now seem to be working and I've successfully ordered my copy. In fact it tried to order me 4 copies, apparently having remembered my previous failed attempts.

I recently bought a new Mac so I qualify to get Mac OS X 10.6 (Snow Leopard) super-cheap as part of Apple's Up-To-Date program. Unfortunately, the online up-to-date system doesn't seem to be working, for the UK at least. Here's my transcript of live chat with the Apple rep, where they state that indeed it's not working and they know it.

• You are chatting with Danielle C, an Apple Expert

• Hi, my name is Danielle C. Welcome to Apple!

• Hello - I'm struggling to use the Snow Leopard Up to date program.

• Good evening

• You are trying to register for it online?

• I click through, fill in details, it says my computer is qualifying, but then it says "There are no items in your basket"

• yes - using website

• I apologize for the inconvenience.

• I'm clicking through from http://www.apple.com/uk/macosx/uptodate/index.html

• Unfortunately there is a glitch in the site, you can still order via post or fax in your order form.

• :-/

• I've been trying for days.

• Using different browsers, assuming the problem might be my fault.

• The site is not working for most people trying to order it unfortunately.

• You would have to fax or send in your order form.

• How about putting something up on the page to say so, to save all those people's time?

• I am very sorry about the inconvenience.

• How do I email in an order?

• You cannot email it in, it has to be Fax or Post.

• I bet a lot of people will stump up the full amount, to get past the inconvenience.

• Which might be why nobody's fixing it or even putting up a sign saying it's broken. But that's the cynic in me.

• Do you know when it might be fixed? I'll wait if it's fairly soon.

• Unfortunately I would not have that information.

• Do you mind if I post this transcript on my blog?

• Thanks for waiting. I'll be right with you.

• Sure.

iPhone Calendar Entry - Change Calendar

I've noticed that in iPhone's Calendar, you can't change the calendar (Home,Work, etc.) of an entry once it's been created - only at the point that it is being created. This is immensely frustrating as quite often I fail to spot which calendar an entry is being created in until after I've hit Done and I see it showing up in green or blue in my calendar. I split about 50/50 between Home and Work entries and so very often each new entry is of a different type to the last (though I fail to notice it) leaving the default calendar assignation incorrect. Grrrr.

Update: I realised that a big reason for failing to spot which calendar is being used at point of entry is that it doesn't use the calendar colour in the creation UI - only the name. If it backed the name with a big splash of colour (green for home, blue for work) I for one would be far less likely to mess up.

Update iPhone Software Using Internet Tethering: Don't!

Because my broadband wasn't working I've been using internet tethering with my iPhone for my main internet connection for my computer. So when my iPhone demanded I update its software to cure its SMS vulnerability I thought hey why not go ahead! I figured it would download the update to the computer (via the iPhone's net connection) as per normal, then perform the update. No reason to suspect a problem. 

Unfortunately once it had got the whole 300MB package and tried to install it, it required access to some Apple server in order to finish the install, but the iPhone was half-updated and no longer providing internet connectivity. So I got stuck there, with an iPhone just showing a "connect to iTunes" graphic when switched on. I understand this is known as "recovery mode". And that's how it's been for a full day, but thankfully I now have broadband working and have managed to get it back up on its feet. That required a factory restore then update from backup then full sync though, and I'm yet to determine if all is truly well.

So the lesson here is - don't use your iPhone as the sole internet connection in order to update your iPhone!