Summer's just beginning, so naturally Springwatch has just started on the BBC. At least that appears to be their logic. Very strange.
Update: Aha, Kate Humble admitted it today when she said "glorious summer evening". It's a scam!
For my sins I've been watching Britain's Got Talent on the tele, and I thought Susan Boyle was rubbish. Apparently I was in the minority. Her first few notes of Memory missed utterly and she was a bit reedy through most of the tricky bits. Am I the only person that finds her just plain annoying when she's not singing? Her fist-pumping, full-of-herself celebrations are very un-British and I suspect that the fickle public will turn. That said, I suppose rather sadly that it will be the newspapers that decide whether we should like or loath her, whether her start should soar or tumble. They've decided she's an angel and are unlikely to go back on their reckoning.
Update – 28th May 2009: Apparently it has begun, right on cue:
I've done a lot of web development in my time and a lot of that time is usually sucked up in trying to make a site 'scale' well - not in terms of dealing with vast quantities of users, but responding to changes in font size without the page layout going completely screwy.
Generally the user can change the font size on the fly to suit themselves, and as a page designer you really ought to cater to their whim. This means that you can't assume that your carefully setup sidebar links will always require just one line each, or that your box titles will always fit in the space available. It can be a nightmare to get right and if you have a very 'designed' page you often have to accept that it will only look reasonable within a certain font size range. Here's one of my blog posts unzoomed, looking handsome as always:
I've noticed that web browsers have increasingly been looking to solve this problem without troubling the poor page designers. Safari 4 Beta and Firefox 3 now default to simply scaling the entire page rather than just the text, though you can select a "Zoom Text Only" menu option to go back to the previous behaviour. By zooming every last pixel of the page identically, page layout and design are kept together and in the originally intended proportions no matter what, though any images on the page may start to look a bit fuzzy as they get zoomed up beyond their native size.
Here's that same blog post of mine with text-only-zoom and then everything-zoom in Safari:
You'll notice that Typepad have done a really good job of making their site text-zoom friendly, and with everything zoomed (and not zoomed quite so much) the whole page is too wide to be usable. Horses for courses I suppose – there are going to be cases when each method is superior and hopefully users (ones that care about zooming at all) will be savvy enough to choose what works for them.
What do you call a Spanish shark with pointy ears?
El Fin.
[It came to me in a flash of inspiration on the train home. Tim Vine – call me when you're ready.]
I sync my calendars across two Macs (desktop and laptop) using the horrifically named MobileMe. It mostly works fine (apart from the fact it often fails to sync some entries – a minor thing) but there is one irritation that's really starting to bug me.
I get up in the morning and I wake up my desktop to read email and news over my Coco Pops, whereupon I often get some iCal reminders for the day – which I usually snooze to re-remind me later. Then at some later point I pick up my laptop and immediately after opening it up I get the same reminders (fair enough) and snooze them too. A minute later, after my laptop has synced I get a popup informing me of the clash of snoozed times, which I have to resolve and re-sync. I play this game all day, with sync conflicts ping-ponging between the two machines. It's completely ridiculous.
What would I prefer? Well I can understand the impeccable logic it's applying – it's just unfortunate the timing of events that leads to this result. How about the system always assuming that the last 'command' I gave is definitive and should automatically be applied without asking me on the other machines? Maybe I should email Steve, er Phil, and suggest it.
I've been writing some iPhone apps recently and have thus been re-exposed to the horror that is Objective-C. I've written plenty of Objective-C over the years, but coming back to it from proper modern languages like Java, C# and Ruby is just painful. It's really showing it's age and I harbour a hope that the macruby work Apple's doing right now is actually going to become the official way to write Mac and even iPhone software over the coming couple of years. That would be just perfect as the underlying Objective-C stuff would still be there for compatibility's sake and performance where necessary. Go on Apple, you know you want to!
Anyway, that mini-rant was not what I came here for. I've been wrestling with the best way to name and use instance variables. Version 1 was to name them in no special way at all, but then you end up with confusion between properties and the underlying variable and also with methods that want to use a parameter with the same sensible name (as is often the case with init methods):
@interface Person : NSObject
{
NSString *name;
}
@property(nonatomic, retain) NSString *name;
@end
@implementation Person
@synthesize name;
// This gives a compiler warning because parameter name masks the instance var.
// Calling the parameter anything else is ridiculous though.
– (id)initWithName:(NSString *)name
{
…
// Need to remember to use self.name rather than name if we want to use the property.
// It's easy to accidentally just assign directly to name and get a messed up retain count.
self.name = name;
….
}
@end
So I've decided it's probably superior to use a prefix for the instance var itself, and though I'd always used m in the past, I'm going for _ here because it seems to be an Objective-C convention:
@interface Person : NSObject
{
NSString *_name;
}
@property(nonatomic, retain) NSString *name;
@end
@implementation Person
// Note that we have to use some extra syntax here to hook up the non-underscored property.
@synthesize name = _name;
// Now the param doesn't clash with anything.
– (id)initWithName:(NSString *)name
{
…
// Property works exactly as before, but direct assignment with _name = name really
// stands out so we're only likely to do it knowingly.
self.name = name;
}
@end
Finally I end up agonising over whether I should always access my instance variables via a property (self.whatever), or whether I'm OK to use them directly (_whatever). Some purists argue that it's worth encapsulating with a property and always using that property. This way you can change your underlying data types but potentially retain the same property methods without breaking the code that uses them – i.e. it's an extra layer of abstraction that protects you from breaking changes. A few years ago I might have bought that, but these days I only add in layers of abstraction when they're truly needed, so I will use the property for external access and the instance var directly for internal access (though I'll always assign to the property to ensure retain counts are correct). I can easily refactor to add in the abstraction if necessary at a later point, but if I don't need it now then I won't bother with it.
See my freshly updated post to find out what Dr Oetke had to say about my thinly topped The Deep Dish pizza.
My favourite Ruby web application framework Ramaze has been updated, and in a major way. As of the 2009.05 gem release Ramaze is built on top of sub-project Innate – a lean mean core that in turn builds on top of Rack. Pistos explains the major changes well in his blog post. For me, although I'm yet to properly get to grips with the new code, the most promising things to look forward to are:
- A fresh start with a lot of accumulated cruft thrown out, resulting in cleaner, more straightforward code for Ramaze itself. I end up reading the Ramaze code a lot (it's very accessible and empowering) so this makes it even easier to delve into the internals and figure out what's what.
- Rack middleware is front and centre, making it easy to chain HTTP processing components into your request handling flow – like Java servlet filters. Not required very often, but a godsend when it is.
- A much tidier sessions implementation, with lazy initialisation.
- A rethought render helper that brings a bit more sanity to the many ways to bring in view fragments.
- Layout support is more of a core concern, with more facilities to deal with layouts sensibly.
- Built-in support for serving different content representations from the same controller.
- An interesting new codebase for me to poke my nose into 🙂
Now if only I can find time to get my Ramaze CRUD framework going in this new world order, then package it up to share with the rest of the world. One day!
My train rolled into St Albans station from the siding as per usual, though excruciatingly slowly, and I got on. Then the lights went off and all those whirring noises you didn't realise were there fell silent. Oh dear I thought. Then the lights came back on and the driver announced "I was having some power problems but I've switched the train off and on again and it seems to have cured it." Nice.
Mac OS X comes with a lot of fantastic stuff built-in, like Java, Ruby, Python etc. The downside to this is that users tend to stick with the stock installs of those items and never upgrade them, which can leave them a long way behind the curve. I just ran into that problem when trying to install the latest version of Ramaze (my favourite Ruby web application framework) from the official gems. The IRC channel #ramaze was useful as always and provided the solution. The problem is that rubygems on OSX 10.5 is old and tired, but you can tell it to install a very specific version of innate that sorts it out. So from scratch, assuming Mac OS X 10.5 with the stock Ruby 1.8.6 install:
> sudo gem install innate -v 2009.04
> sudo gem install ramaze
> sudo gem install ramaze
Obviously as new versions of innate and ramaze come out, the exact version of innate required will change. You can tell which verison you need by trying the ramaze install and looking at the error message.
Update: Actually now Ramaze and Innate 2009.05 have been released, it seems things work just fine without any special incantations. So you can just sudo gem install ramaze and you're away.