After some wrangling back and forth, I’m happy to announce that my first iPhone application, Squeemote (formerly iSqueeze) is now available on the iTunes application store.
Squeemote for iPhone and iPod Touch is a remote control application for the SlimDevices Squeezebox™ and similar devices such as the Duet and Boom. This first release is aimed at people who mainly use their own music library rather than streaming services (support of which is currently limited). I intend to add browsing support for streaming services in a later release but my main focus for this initial release was on quality over quantity: I didn’t (and do not) want to cram it with features. I focussed on making this the best possible experience for browsing your SqueezeCentre library and controlling your device.
I already have some ideas on further improving the user experience for music browsing and playlist management that will appear in a future release. Another area which is currently quite basic is device management; Squeemote supports multiple devices and allows you to choose which device to use and set a default device but there is currently no support for grouping devices for synchronous playback. This, plus browsing support for streaming services will be my priority in the next major release.
It’s been an interesting experience writing my first ever iPhone (or Cocoa) application and getting it submitted to the iTunes store but I’ll save the technical notes for a separate post.
If you have any questions or problems, feel free to leave a comment or drop me an email. I have also set up a support page on GetSatisfaction.
Chris Wanstrath from GitHub recently tweeted about his new website. Whilst trying to load it earlier today I accidentally misspelt his username, revealing a GitHub feature that I hadn’t come across – GitHub pages.
Simply go to yourusername.github.com and you’ll be presented with a friendly error page explaining how to set up your own github.com sub-domain website. It’s fairly straightforward – create a repository named yourusername.github.com, create a local master branch and push it to GitHub. Within ten minutes or so, your new site will be up and running. Very cool. Here’s mine (yes, fairly pointless I know). And here is another.
Update: It seems that I just beat the guys at GitHub to it with their official announcement.
Last Friday was my last day at Reevoo. I had been contemplating leaving for about a month when some unexpected changes at Reevoo forced my hand. In many ways I had become tired of working on the same thing week in, week out and I craved new challenges. It is with some regret however that I leave what is in my opinion (and others) the best Ruby/Rails team in the UK. I have learnt a lot over the last 18 months and much of that is due to the sheer breadth and diversity of knowledge across that team as well as everybody else at Reevoo. I have learnt how to be a better team player, I have come to appreciate pair-programming more than I ever did and I have faced the real day to day challenges of being part of an “agile” team.
As of this week, I officially enter the world of Ruby contracting. Inspired by the likes of Obie Fernandez (I’m a big fan of his blog and I love what the guys over at Hashrocket are doing), Jay Fields (the linked article is what really got me thinking in the first place ) and James Adam, (my former Reevoo colleague, who has recently gone “free-range”), I have decided to take the plunge and fully invest in building my “brand” and jumping head first into the contracting world. I have been working with Rails since almost the beginning and it has taken me nearly four years to get to this point. It’s a scary prospect, leaving the comfort and safety of a regular monthly income but with hard work there is the prospect of great rewards. I look forward to working with other members of the Ruby and Rails community across a wide range of projects.
if you’re looking for a Ruby/Rails expert to help out with your project.
Blogging, Git style
You may have noticed the new design. The main objective of the new design was to move towards a traditional blog-style format; I liked my old design but it certainly placed an emphasis on individual articles, something that I’ve had less and less time to write, hence the scarcity of posts in the last year. The idea is that with the new design, I feel less pressure to write long article-style entries and therefore blog more frequently. I also feel that now more than ever is an appropriate time for a refresh.
I’m no longer running Mephisto but am instead using a heavily modified version of Marley, a lightweight Sinatra app that comes with no admin interface but instead pulls blog entries from a git repository. This means I can write all of my posts offline in my favorite text editor in an iterative fashion, stored in a local git repository and pushed to github when I’m ready to publish (Marley pulls from GitHub by way of a post-receive hook). Marley is relatively new and was a bit rough around the edges but I found it a great base platform to start hacking away on (as you can see by the frequency of commits to my github fork over recent days).
I’ve also abandoned my old nginx/mongrel deployment setup and moved back to Apache running Passenger – the ease with which you can configure and deploy a simple Rack-powered app like Marley (or any Sinatra based app) is astounding. No more messing around with monit configs and restarting of mongrels for me. I’ve set up some mod_rewrite rules so all of the old blog URLs should 301 redirect to the new URLs.
There’s probably a few bugs here and there, and some of the images might be broken until I’ve had a chance to reupload them. There is currently no syntax highlighting on code samples; this is on my todo list. I’ll hopefully iron these issues out over the coming days. People who have subscribed to my feed using the FeedBurner URL should not need to change anything; those who were using the direct URL should subscribe to the FeedBurner URL instead.
Are you a Ruby and/or Rails contractor? How’s it working out for you?
The iPhone 3G and the app store launched about a month ago now and I think it’s been somewhat of a mixed bag: there is a plethora of shit on there which makes it hard to spot some of the gems.
When Apple announced the $99 fee for the developer program, there was an initial feeling that this would help reduce the number of people with little interest in writing original/interesting/quality apps. Unfortunately it hasn’t; a cursory browse through the app store reveals more tip calculators, fuel/expense trackers, note-taking apps, todo lists, Sudoku, and converters than you could shake a shit-covered stick at. And then there is the really pointless crap: flashlights, novelty apps, fucking candles (and they even have the audacity to charge for this rubbish), not to mention the people who don’t have a clue what user interface guidelines are all about and what makes a good UI (yes, I’m talking about you Stevens Creek Software – you’re apps are an abomination).
That said, there are good apps on there, some of which are of really high quality. Here’s a few that I use regularly:
NetNewsWire
I’ve tried many RSS feed readers on my Mac but I’ve always come back to NetNewsWire. It’s the only feed reader that just feels “right” to me and the syncing between all of my machines courtesy of it’s online NewsGator service is probably it’s killer feature. I’d tried various web-based readers optimised for the iPhone prior to the the app store launch, including NewsGator, but they always seemed slow and clunky so I was quite happy to see NetNewsWire for the iPhone make it out of the door so early.
Downloading feeds over an EDGE or GPRS connection can be painful but since upgrading to the iPhone 3G, it has been a pleasure to use, syncing with my online NewsGator account to retrieve a list of feeds and read/unread data.
A few usability gripes: with a long list of feeds, it can become hard to distinguish between folders and feeds; some kind of visual distinction would be useful. It’s also not immediately obvious that you can view articles with the built-in web view by tapping on the article heading (there is a separate button to view in Safari). Both minor gripes however and if you need your constant RSS fix, NetNewsWire should be at the top of your “to buy” list. NetNewsWire App Store link
Texas Hold’em Poker (Apple)
OK, if you don’t play poker and your eyes are already glazing over, you might as well skip this one. This app is developed by Apple themselves and it shows. The game is straightforward: compete over a number of venues from your garage though Las Vegas all the way up to Dubai with the stakes and difficulty increasing as you progress.
The AI isn’t exactly brilliant and there will be times where the game is just plain frustrating: you’re heads up and you put your opponent all-in with your KQ suited and he/she calls with 10-2 off-suit, only for the flop to come down 10-10-2. It’s probably a good thing that this isn’t for real money, lest you through your phone out of the nearest window. However, the AI is “good enough” for a fun game of poker and it makes a the daily commute slightly less tedious.
Where this app really shines and makes it so obviously an Apple product is the near-perfect use of the iPhone’s touchscreen gesture support to provide an intuitive and fun user interface; cards can be folded by flicking them into the middle of the table; chips and be pushed into into the pot to go all-in; checking is as simple as tapping the table. You can also switch between a virtual-table mode (where you can see the players as the look at their cards and place their bets) and a more traditional racetrack mode (familiar to anybody who has played online poker) by simply changing the phone’s orientation. Texas Hold’em App Store link
Vicinity
One of the first apps that I’ve played with that takes real advantage of the location-based services available; after working out your location using triangulation or GPS, it provides you with a list of useful locations in your vicinity (do you see what they’ve done there?): nearby places, cafes, banks, pubs, supermarkets, taxis, hotels and restaurants. Again, this wasn’t very useful on the original iPhone as the cell-tower triangulation was just too slow for it to be usable but on the 3G its incredibly useful. The wikipedia/flickr links are a nice added bonus, especially if you live in a busy area/large city with many points of interest such as London. Vicinity App Store link
Facebook
This native app is a continuation of the good work that the Facebook team have already done with their web app – for my money one of the best web apps available for the iPhone. The native app doesn’t offer a whole lot more but it does mean a faster, smoother user experience (e.g., swiping a message in your inbox to reveal a delete button ala Mail) and there is also now a built-in chat option. Unfortunately there still doesn’t seem to be a way to edit your profile (other than your status, which I update through twitter anyway). Facebook App Store link
Twitterific
As well as NetNewsWire, Twitterific was another app that I installed straightaway. It’s not bad but it doesn’t match up to it’s desktop counterpart – I find the dark interface quite ugly on the iPhone (there is a light interface in the paid-for version although I can’t find a screenshot of this anywhere – is it really too much to ask to have this as an option in the free app too?) and scrolling is very slow and clunky. I don’t mind the ads though so I don’t really feel compelled to pay for the premium version (the same goes for the desktop version). Despite it’s lack of polish, I still think it’s the best Twitter client available (at the moment). Twitterific App Store link
Things
I’ve also grabbed a copy of Things. The interface is very pretty and I’m sure the app will eventually be great but I still need to motivate myself to use it. One thing I’ve found lacking is the ability to set alarms/receive reminders for scheduled events although I suspect that is a limitation of the platform itself. You really need to be checking it every morning to get the most out of it (although I suspect that is the idea if you’re a GTD addict). There is also no syncing with the desktop version which is a deal-breaker for many (not me) but I’d encourage you to snap it up at the introductory price and wait for syncing which will arrive as a free update. Things App Store link
Speaking of updates
Unfortunately, the worst part of the whole experience is the App store itself and the way iTunes and the iPhone sync with eachother. When you plug your iPhone in, any apps you’ve downloaded via the iPhone app store don’t seem to sync to iTunes automatically – instead you need to manually select “Transfer purchases”. iTunes also seems to be confused about any updates that I need – it frequently tells me that I have “x apps requiring updates” when in fact there aren’t any. The iPhone App store app itself seems slow and buggy and on occasion has caused my phone to freeze altogether, requiring a hard reset – not good.
Writing my own apps
I’ve been meaning to learn how to write Objective-C/Cocoa Mac applications for a while now but haven’t ever gotten around to it. The release of the App store and the iPhone SDK has turned out to be that kick up the backside that I’ve needed – I’ve recently started learning Objective-C/Cocoa and I have a few apps in mind (I’m already working on a native iPhone interface for the SqueezeCenter software that powers Squeezebox music players.
Simon Willison argues that the iPhone app, Exposure, behaves “suspiciously” because it uses an embedded web view for users to log into to their Flickr/Yahoo accounts using OAuth.
The crux of his argument is that the embedded web view makes it impossible for users to tell if they are logging into the genuine Yahoo OAuth website or a phishing site. He cites Pownce as a better implementation because it opens the authentication page in Safari, which has lead to complaints/negative reviews from users due to the interruption of having to exit the Pownce app, sign in in Safari, then return to the Pownce app.
Whilst I can see his point about the transparency of using Safari directly, I’m not convinced that it’s worth compromising on the end-user experience to attain some kind of technical compliance with a protocol that most users haven’t heard of nor care about. More to the point, I’m not convinced this is as big a security issue as is being made out.
Ultimately, security often boils down to trust. Do you trust Service X with your credentials and personal information? If the answer is no, then you should not use Service X.
Using an embedded web view in the way that Exposure does isn’t really any different from a native login UI using iPhone interface widgets – without the source code to that application you have absolutely now way of knowing what that app is doing with your credentials. Most of the service-based iPhone apps that I use have a native iPhone login screen – NetNewsWire, Twitter etc. Am I wary of inputting my login details, despite the fact that they could be doing anything with them? No, because I trust the developers of these apps with my credentials (in the same way that I trust them with the same data when I use NewsGator or Twitter.com).
By passing users over to Safari to login – despite the transparency – all they are really doing is shifting the burden of trust on to the login provider and damaging the user experience overall.
As well as our own personal projects, myself and the others here at Reevoo have developed some useful libraries and Rails plugins many of which we hope to share with the community, including the already well-known Ruby mocking library, Mocha.
The first couple of plugins considered ready for public consumption are already up on the site (sorry about the lack of Subversion repository – all of our code is in a private repository and we’re still working on a mirror – I’ll try and get some of the projects up on my GitHub project page next week).
As well as acting as a place to share our various projects, we’ll also be maintaining a blog which will contains some interesting articles on some of the problems we’ve faced and how we solved them as well as general Ruby/Rails articles. Look out for some interesting architecture/infrastructure pieces from our system admins in the next couple of weeks – don’t forget to subscribe to the Reevoo Labs Atom feed.
On Monday 16th June, after seven and a half years together, Julie accepted my marriage proposal. Thank you Jools.
As the title says, I’m selling my two year old MacBook Pro to make way for a more recent, but more portable black MacBook. It was my first Mac and it’s served me well over the years; it’s still a great machine, I’m just in the market for something smaller with a little more oomph. Here are the pertinent details:
- Rev. A MacBook Pro (March 2006)
- 1.83 Ghz Core Duo processor
- 1.5GB RAM
- 80GB Hard Drive
- SuperDrive
- Comes with original box and packaging, accessories and Tiger install CD
- I can ship it with Leopard pre-installed if you so wish
It’s well used and has a few battle scars but nothing serious and is otherwise good condition and in perfect working order. The wireless problems that I mentioned in a previous blog post seem to have gone away since the latest Leopard update (so I guess it was a software issue after all) and there are no other issues with the machine.
So if you’re looking to hook yourself up with a great value laptop which is perfect for Ruby/Rails development you can bid on the item on my eBay auction or alternatively, take it straight off of my hands without going through eBay for £650 + shipping costs (£20, Royal Mail special delivery) by dropping me an e-mail – there is a contact link at the top of the page. If you are based in London, I’m also happy for you to collect it. See the eBay auction page for full details and some photos and don’t hesitate to e-mail me with any questions.
Whilst pairing with Paul the other day I noticed that he preferred not to use Symbol#to_proc; on asking why, he told me it was because of the unnecessary performance hit that Symbol#to_proc imposed.
Now I’m not one for premature optimisation, but with an idiom like Symbol#to_proc likely to be used throughout a codebase, performance hits like this add up and as things stand, the Rails implementation of Symbol#to_proc is pretty expensive:
require 'benchmark'
require 'rubygems'
require 'active_support'
BIG_ARRAY = ['x'] * 1000000
Benchmark.bm do |bm|
bm.report("Standard block") do
BIG_ARRAY.map { |c| c.upcase }
end
bm.report("Symbol#to_proc") do
BIG_ARRAY.map(&:upcase)
end
end
Output on my 2Ghz quad-core Mac Pro:
user system total real
Standard block 0.720000 0.060000 0.780000 ( 0.772927)
Symbol#to_proc 3.030000 0.010000 3.040000 ( 3.040889)
Ouch. That’s roughly four times slower. -Based on my naive understanding of how Symbol#to_proc was implemented, it figured that the bottleneck was the creation of a new Proc object for every iteration; the proc doesn’t need to change for each iteration so surely we could just memoize it-?
Update: It seems that my initial assumption was incorrect; to_proc is in fact only called once. The real issue here is not the instantiation of a new proc, but the Rails implementation. Rails uses this slightly more complicated implementation in order to support passing of multiple arguments with the method call:
Proc.new { |*args| args.shift.__send__(self, *args) }
This allows you to do a few neat things with multiple elements of a collection like [1, 2, 3].inject(&:+) but I consider this supporting an edge case at the expense of performance.
I’ve never found myself in need of the functionality provided by Rails’ implementation (I didn’t even know it was supported) but I do find myself using the obj.map(&:method) idiom a lot so the following simplified implementation suits me just fine:
class Symbol
def to_proc
proc { |obj| obj.__send__(self) }
end
end
The performance gain is significant:
user system total real
Symbol#to_proc 0.910000 0.010000 0.920000 ( 0.916718)
The implementation itself is trivial but I’ve made it available on pastie – just drop it into a file somewhere in your Rails lib folder. If I find the time, I will try and package it up as a basic Rails plugin too. It’s worth bearing in mind that Ruby 1.9’s implementation will probably support the passing of arguments like the Rails implementation but hopefully it should be much faster.
The performance of Symbol#to_proc has also been brought up on Pratik Naik’s blog and this Rails ticket.
Update: Some of my original assumptions about the way Ruby invokes to_proc were incorrect and I have updated my article accordingly.
Rather than spending time discussing Leopard’s much discussed new major features, I thought it would be interesting to point out some of the smaller, minor but useful updates that I have picked up on so far. I will update this list over the next week or two as I discover new things, good and bad:
- Installation didn’t go too smoothly for me; there appears to be a bug in the install process affecting some machines that means that my hard drive wasn’t showing up in the “Select a destination” panel. Fortunately I was able to find out from the Apple discussion forums that after waiting 10 to 15 minutes your available drives will appear. One cup of tea later, and the install routine was back on track. I opted to perform an “Erase and Install” on my MacBook Pro to get rid of the sheer amount of crap that I had accumulated over the last 18 months which went as smoothly as I’d expected. I am yet to try the upgrade option on my Mac Mini so YMMV here.
- My first impressions were that Leopard seemed faster and given that it was probably hard at work indexing my hard drive for Spotlight this was pretty impressive. My Airport problems in Tiger (the connection would frequently just stop responding or lose packets making it incredibly frustrating to do anything useful) appear to be resolved, at least, when running on mains power. When running on battery I still seem to be suffering from random disconnections although Leopard at least shows that it has lost its connection and reconnects pretty fast. This may be a problem with my router and still requires further investigation on my part.
- The new dock is not as bad as everybody has made out and I have left it at the bottom for now even though I’m traditionally a dock-on-the-side person. The new Stacks functionality is useful and looks great although the cool “fan” effect only works when the dock is on the bottom. I imagine the novelty will wear off quite quickly and I will be back to having my dock on the side soon enough.
- I’m sure that most Rails developers have been aware for a while now that Leopard will ship with Rails. The new Ruby/Rails stack in Leopard is well thought out and organised and comes with Ruby 1.8.6, Rails 1.2.3 and and a host of other useful gems. Rails itself is simply bundled as a gem and is easily updated. A good overview of the changes to Ruby in Leopard is available.
- One utility that anybody who frequently uses SSH and public/private keys would not be without is SSHKeychain which integrates with Apple Keychain and acts as an SSH agent. In my experience SSHKeychain could be flaky and would sometimes silently crash for no apparent reason; good news then because as of Leopard, OSX maintains its own Keychain-integrated ssh-agent making passphrase-protected keys painless to use out of the box.
- Speaking of which, the new Leopard Terminal finally supports tabs and is much easier to customize thanks to built-in themes. Despite some niggles (like not being able to jump to a specific tab using Cmd+number) I think that it is finally time to say goodbye to iTerm.
- Connecting to your mail server over SSL using a self-signed certificate in Mail.app is no longer a pain in the arse. Before, Mail would prompt you that the server certificate was not from a trusted source every time you tried to connect unless you manually dragged the certificate to the desktop and added it to your keychain. In Leopard, Mail finally has an option to “always trust this certificate” as well as a number of other fine-grained trust options.
- The new version of Front Row, based on the Apple TV software, seems like a regression to me. The new interface doesn’t seem as slick and suffers from some annoying bugs like not being able to view album artwork on a shared library and most annoying of all: there doesn’t seem to be any way to get Front Row to open on a second monitor. In Tiger, Front Row would always open on the primary display – this was documented behavior and in Leopard this behavior seems to have disappeared. I like to hook my MBP up to my plasma TV but now Front Row will only open on my MBP screen, even if its not the primary display, severely limiting its usefulness.
- On the plus-side, Quicktime now has some useful full-screen options including options to stretch or fill a widescreen display when viewing videos in a 4:3 aspect ratio. Quicktime does work on a second display and allows you to select which screen it will display on in full-screen mode independently of your primary display settings.
Update 1: Airport Woes
When running in battery mode, Airport performance is horrendous, even after installing the latest keychain fix. The signal will go up and down and the transmit rate will jump up and down wildly between 0 and 54 before eventually just disconnecting – it seems to disconnect every couple of minutes.
The question is, is this a) a continuation of the connection stability problems I was having in Tiger but manifesting itself with different symptoms (or simply that Leopard is more responsive to Airport connection status changes than Tiger), b) an entirely new problem created by the latest Airport drivers, c) a hardware issue (dodgy Airport cards?) or d) a problem with my router.
Until I can test out Airport performance on my Mac Mini in Leopard, I can’t rule out D although the fact that many other people are having the same problem seems to suggests this is not the case. Airport performance seems reliable when connected to the mains, so maybe its an issue of power consumption by the Airport card?
Something else that I just noticed: there appears to be a rather nasty looking, if ultimately harmless, rendering bug when scrolling in Finder when in column mode:
More Airport updates
I’m beginning to become more and more convinced that the problem with Airport is a power issue. My Airport connection seems to be very stable with no disconnections when running on mains power but in battery mode the disconnections come very frequently. I’ve also managed to perform the following test with reliable results: plug in the power adapter and wait a few minutes to confirm a stable Airport connection. Now remove the power adapter – in my observations, about 80% of the time the Airport connection will drop within 10 seconds. This would indicate to me that the problem lies in the Airport card not being able to draw enough power to operate in a stable manner whilst running in battery mode.
Yet another update
I mentioned earlier that I was having trouble getting Front Row to display on my TV even though it was set as the primary monitor. Last night I gave it another try and et voila; Front Row was displaying on my TV. Further investigation led me to this post on the Apple discussion forums:
“Not sure if this is related to the bugs you are having, but one I’ve noticed and reported to apple is this: When you first start front row it appears on your primary display, it also remembers which display it first started on. So, if you exit but don’t kill the front row process (in activity manager), front row will always display on that initial primary monitor, even if you swap your primary/secondary in sys pref. I haven’t tried mirroring the displays. " cmendill, Apple Discussion Board
I haven’t had the change to verify this (yet) but it makes sense – if exiting Front Row doesn’t actually kill the process, then Front Row will not pick up changes to your primary display settings until you do. I still consider this to be a bug but at least it’s an explanation!
Leopard reviews:
I'm Luke Redpath, a Ruby/Rails developer based in London, UK. I am
on a contract basis.