Matt MacAulay

While I’m excited to see what the future holds for single sign-on systems, I don’t think we’re at the point where we can discard the traditional site registration paradigm, though, traditional user registration models still have a place in today’s ‘nets. One pain point I have with some sites is that I can never remember what username I used to register – sure, most of the time it’s the same one, but occasionally someone will have taken it before me. Other sites use your email address to log you in and do away with the concept of a username altogether. This is preferable as you’re not likely to forget your email address (and if you are, you’ve probably got bigger problems than being able to log in to some social site). Unfortunately, some sites have a real need for usernames, especially if users can interact with each other – you don’t want them to be able to see each other’s email addresses unless they’ve explicitly permitted it.

There’s a simple solution for this – let users log in with their username or email address. Earth-shattering, I know, but it’s the small things right?

I’ve been working on a small Rails site in my free time using the excellent Authlogic. This thing really simplifies a lot of the usual toil and drudgery associated with implementing a membership system, and lets you get back to the part where you can work on features.

It also lets you implement log in with username or email very easily:

user_session.rb:

class UserSession < Authlogic::Session::Base
  find_by_login_method :find_by_login_or_email
end

user.rb:

class User < ActiveRecord::Base
  def self.find_by_login_or_email(login)
    User.find_by_login(login) || User.find_by_email(login)
  end
end

That's it, you can also change your login page thusly:

views/user_session/new.html.erb:

   <%= f.label :login, "Username or email address" %><br />
   <%= f.text_field :login %>

And you're done! I love when things Just Work ™.

I found this on Stack Overflow, but it's probably somewhere in the Authlogic Documentation as well.

My Windows 7 RC installation has expired, sadly. I had it installed in a Boot Camp partition and was using it in VMware Fusion as well. After reinstalling my licensed version of Vista (sad face), I discovered that VMware Fusion no longer works. Not surprising really, but how to fix? The answer, as it turns out, is pretty straightforward:

• Make sure VMware Fusion is shut down.
• In Finder, navigate to /Users/{username}/Library/Application Support/VMware Fusion/Virtual Machines/
• Delete the Boot Camp and Helper folders

The next time you start up VMware Fusion, you’ll be able to set up your Boot Camp partition again. Easy!

Just stumbled upon the Sarcastic Font.

Help support this important cause!

Just discovered an interesting gotcha in the Twitter API: calls to the user_timeline method will have retweets stripped out.

From http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-user_timeline:

Note: For backwards compatibility reasons, retweets are stripped out of the user_timeline when calling in XML or JSON (they appear with ‘RT’ in RSS and Atom). If you’d like them included, you can merge them in from statuses retweeted_by_me.

Huh. So in other words, making a call like this:

http://twitter.com/statuses/user_timeline.xml?screen_name=mmacaulay&count=1

might give you an empty result. Sneaky. Even if you increase the count parameter there or remove it altogether, you might end up with an empty result if the user does nothing but retweet things. If you want to see the same thing as you’d see by viewing the user’s timeline on twitter.com you’ll have to make an extra call to retweeted_by_me.

Dear Twitter developers: it would be nice if instead of stripping out the retweets you did one of two things:

• If I make a request with count=n, return the first n non-retweet statuses
• Allow me to specify whether or not retweets are included in the response via another parameter

Oh well. It’s Friday.

So I’ve been tasked with maintaining an iPhone app that my company built on contract over the summer. At the time, the guy who built it (let’s call him Ray) didn’t know anything about iPhone or Mac OS development, and neither did I. In fact I’d never even owned a Mac before a few months ago when I purchased the MBP I’m typing this on. We’re a .NET shop here, and although we consider ourselves pretty progressive and open to new things, developing software in the Apple ecosystem is radically different to anything we’ve done before.

Ray left the company at the end of 2009, leaving me to carry on in maintenance mode until our support contract is up. While I was never involved in the project during the initial development phase, I did hear some interesting stories from Ray about how complex the app had become – among other things: 20000 lines of code! For a piece of software with modest functionality, and built with modern tools from the company who prides itself on user experience above all else, it seemed like an awful lot to me!

I reluctantly set out to learn the ins and outs of the app, and of course iPhone dev/Xcode/Objective-C and all the other fun stuff that comes with it. At first, I just accepted the fact that the app was complex and went about fixing bugs without really giving it a second thought. That was until earlier this week, when during our weekly status call with the client, one of the issues that was brought up was the fact that certain screens in the app don’t meet the interface guidelines set forth by the client. Things like colours or fonts not matching what’s in their PSDs can be a lot of toil and drudgery when all those colours and fonts are defined throughout the app in a lot of repetitive code. While we were discussing it, the client wonders why Interface Builder wasn’t used to create all the UI screens. I’m wondering the same thing myself.

Some developers view WYSIWYG tools as lazy, inefficent, and less flexible than “doing it by hand”. In some cases, I believe this to be true. I’ve never used a HTML WYSIWYG tool such as Dreamweaver in my life, and I intend to keep it that way. On the other hand, writing Windows desktop software in Visual Studio with .NET or even MFC is miles ahead of the drudgery of the Windows SDK stuff I remember doing in school. ASP.NET web apps have been the bread and butter of my company (and my career) since it’s inception, so we’re used to writing UIs in HTML by hand.

What is the recommended approach in iPhone world? Well, after some googling around I came across this: Don’t Fear The Interface Builder. I think this quote sums it up nicely:

If you’re writing tons of code to implement your user interface, that’s lots of code you have to write, maintain, and debug.

This is exactly the feeling I got when I started going over the endless lines of code doing things like instantiating buttons or table views and placing them on the screen – that’s a lot of code to debug and maintain! Things that don’t really have anything to do with the core functionality of the app. Now that I’m up to my neck in a sea of code, much of which serves no other purpose than rendering widgets, I’m feeling the pain. Before he left, I had the sense that Ray was too, although I’m not sure what prompted him to take the route he did, or if he realized the implications of writing all that UI code. If he reads this, I hope he doesn’t take it the wrong way, hindsight is 20/20 and I can’t say for sure if I wouldn’t have made the same decisions he did.

For now, I’ve decided to take the positive view that it’s an opportunity to learn about the innards of how iPhone (and to some degree OS X) apps are created. In the future, when I get the opportunity to work on a new iPhone project from the beginning, I’ll be sure to take this all into careful consideration. After all, when it comes to software and lines of code, I truly believe that less is more.

-M