Some time last year I managed to smash the screen of my iPhone. The LCD and digitiser (that's the bit that does the multitouch stuff) were both working fine, I just had to put up with pieces of broken glass coming off into my fingers and/or ear.
As of now, after the second round of repairs, I once again have a working iPhone and have a few of pieces of advice I wish I'd had before I started trying to fix it.
I was tasked with rewriting a piece of horribly underperformant code recently and in the process of checking I hadn't introduced any bugs I came across some behavioural oddness in Webkit (I use the nightlies with the excellent inspector as a development browser) and IE. Part of the form involved showing or hiding different dropdowns based on which radio button was selected, and both these browsers had quirks in their change events.
In IE a change event is only fired when you blur away from the radio input. I'd come across this before so just filed it under "fix later" and moved on. When I was testing keyboard interaction however, Webkit threw me a curve ball: it doesn't fire a change event at all if you modify the selected radio using your keyboard.
Since I was relying on change events to reveal the correct portion of the form this completely wrecked accessibility. The hunt was on for an elegant, general-purpose solution that didn't involve sticking conditional checks into my existing event handlers.
I'm currently doing a stint at LBi working on a large project which is nearing the initial release. All the functionality has been written and most of the bugs have been squashed, so we're turning our eye to performance. There's a lot of javascript which runs nice and speedily in modern browsers but we're looking at over a second of javascript execution on DOM ready in Internet Explorer 7.
Using dynaTrace to identify the worst offenders I was surprised to see how much time was being spent in selectors, a lot of which weren't finding anything. Over 30 selector calls were being made on every page load, and whether they returned anything or not it was taking IE a long time to process them all.
Wordpress' code structure makes me cringe every time I have to deal with it. I keep coming back to it because the admin interface is great and the non-technical people who actually use the sites I build get on well with it. This means looking after multiple Wordpress installs, each of which needs upgrading when a security fix is released.
Until now I've been having to do the upgrades in a really slow, tedious
way --- unpack the new release into its own folder, copy everything
install specific to the new version, and then fire up your test
environment whilst hoping you didn't forget anything. Yesterday I
decided to find a better way. I've been using Git to manage my
projects so unsurprisingly my solution is centered around it. I can now
upgrade a Wordpress install with a simple git merge -s subtree
wordpress/master.