I’m now on twitter. Shame on me.
I'm working on an iPhone app right now, which mostly involves dev/test against the simulator, with occasional runs on a real iPhone to check everything is running the same there. But every time I flip that menu in the XCode toolbar from Simulator to Device and hit cmd-R I spend five minutes of confusion trying to figure out things aren't working even nearly right.
After a while and maybe a bit of debugging I'll get a hunch that all is not as it seems, I'll do a complete clean and rebuild and then my code will behave perfectly, with XCode whistling cherubically with an innocent look on its face. All that remains is for me to check the Build menu to reassure myself that cmd-R does in fact do "Build and Run" which it most certainly does.
I can only assume that there is a bug in XCode that doesn't correctly reset build state when switching between targets, so it thinks my build is up to date when in fact it's ancient.
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.
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.
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!
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.
Many people don't know about Apache Bench, even though it may be installed on their system. For instance it's installed on Mac OS X by default. It's a very simple command line utility to perform basic stress/performance testing of websites. It can request a given URL repeatedly, then report back statistics. I generally use it in this form:
> ab -n 100 -c 4 http://www.somewebsite.com/test/page.htm
Dissecting that command:
- ab is the Apache Bench executable itself (found in /usr/sbin on my machine)
- -n 100 tells it to send the request 100 times
- -c 4 tells it to use 4 concurrent threads to do so
- finally we have the URL itself.
Even though it's simple, there are some important gotchas worth knowing about:
- Remember to put the URL in single quotes if it contains characters that would otherwise be interpreted by the shell. This is often the case for any URL with a query string, as the & characters will mess things up otherwise.
- If using a base URL for a site (just host name), you must use a trailing slash. http://foo.com doesn't work, but http://foo.com/ does work.
- Quite often you may see in the statistics "Failed requests: 5" or similar, followed by a list of the types of failure: "(Connect: 0, Receive: 0, Length: 5, Exceptions: 0)". If the only type of failure that actually occurred is 'Length' then don't be alarmed. This simply means that each request (for the same URL) returned a different length response, which ab regards as suspicious. However it's perfectly normal for dynamic webpages, especially if they include the time or other very dynamic data on the page.
- I find on one of my machines that it just doesn't like localhost as a hostname, so I have to use 127.0.0.1 instead. I have no idea why, as localhost works fine in other contexts on the same machine.
I saw this and smiled. What a delightfully simple design for a clock with easy daylight savings adjustment. Only one downside – accidentally knock it without realising, or more likely have a mischievous friend knock it deliberately - and you'll be an hour out. So I'd be tempted to add "Summer" and "Winter" or some neat icons along the flat edges to make it obvious what setting it's currently on. That also solves the problem of knowing what position it's supposed to start off in when you get it.
I've endeavoured to rely on NetBeans' auto-formatting feature before now, but I've never been able to configure it quite to my tastes. In particular I had struggled to get rules for braces and line wrapping setup how I wanted for Java, with them almost always on a new line. I'm not sure whether I had simply failed to find the right options or if they're new in 6.5.1 or another recent release.
It's perfect for cleaning up code that you're copying and pasting from the web, taking the labour out of it. All I need now in NetBeans is a less tedious way of generating getters and setters that requires less mouse clicks, remembers your last preferences (put at end of file, no comments) and can have m_ prefix on the vars but not the accessor method names.
That said, better still would be for Java to grow up a bit and gain a better way to do boiler plate accessors. Which is better:
Java:
public int getFoo()
{
return m_foo;
}
public void setFoo(value)
{
m_foo = value;
}
public String getBar()
{
return m_bar;
}
public void setBar(value)
{
m_bar = value;
}
Ruby:
attr_accessor :foo, :bar