culann.com

And the greatest of these is laziness

The three virtues of excellent programmers are well-known - laziness, impatience, and hubris. Last night, I had an epiphany related to the first of these… and thus was born the laziness plugin.

You know how, when you find a bug in your app, you’re supposed to write a failing test before fixing it? Well, laziness makes this a bit easier by writing the test for you. If you’re running in development mode, laziness will add a test like the following to the bottom of your error page:

def test_get_sessions_new_should_not_raise_exception
assert_nothing_raised do
get :new, {}, {:return_to=>"/"}, {:notice=>"You cannot access that page"}, {}
end
end


The first step to fixing the bug, then, is to paste that into your functional test file and run it; if it passes, you’re most likely looking at a data issue (since the params, session, flash, and cookies are specified in the test). If it fails, you’ve got a starting point for debugging.

Laziness isn’t just helpful in development mode, though - it also comes into play in production. If you’ve installed the exception_notification plugin (and you really should have - if not, go ahead; I’ll wait), then laziness will add its generated test to the email you receive whenever your production app throws an unexpected exception.

If you can’t wait to be lazy, you can grab the plugin from Viget’s SVN repository (at http://svn.extendviget.com/lab/laziness/trunk) or GitHub. Patches are welcome through either mode (git slightly preferred).

Posted in ruby and rails, testing | 10 Comments »

Still no baby

So our daughter’s due date was last Saturday, but she’s been somewhat reticent to join us in the outside world. We’re expecting her at any point in the next few days, though, so I may disappear from pretty much everything rather suddenly. Consider yourself duly warned.

Posted in life, metablog | 1 Comment »

The dreaded :false

If you use the restful_authentication plugin, you’ve probably run up against :false. If not, let me explain:

Restful_authentication provides a method called current_user. If someone’s logged in, the method returns his or her User object. If no one is logged in, though, current_user returns :false. This is (for me, at least) a violation of the PoLS - I’d expect it to return nil, or at worst the Boolean false.

The rationale for returning :false is that is allows RA to memoize the results of the current_user method, which is defined thusly:

def current_user
@current_user ||= (login_from_session || login_from_basic_auth \
|| login_from_cookie || :false)
end


So if it’s the first time you call current_user, the system will try to authenticate the current user in a variety of ways; if each fails, it returns :false, which prevents subsequent calls from hitting those methods again. It’s a good idea, but that :false still irks me.

Since Rick Olson’s plugins are now all on GitHub, though, I have some recourse. I forked restful_authentication and made the following single change:

def current_user
@current_user ||= login_from_session || login_from_basic_auth || \
login_from_cookie unless @current_user == false
end


This has the same memoizing effect as using :false, but sets current_user to Boolean false instead of to the symbol. The key is the explicit unless @current_user == false - which fails if @current_user is undefined or nil (unlike unless @current_user, which passes in those cases).

It’s a simple change, and one that I think makes a lot of sense.

UPDATE OK, I’m a moron - there are two other minor changes in this version of RA. here’s the entire changed section:

def logged_in?
current_user
end
 
# Accesses the current user from the session. Set it to :false if login fails
# so that future calls do not hit the database.
def current_user
@current_user ||= login_from_session || login_from_basic_auth || \
login_from_cookie unless @current_user == false
end
 
# Store the given user id in the session.
def current_user=(new_user)
session[:user_id] = !new_user ? nil : new_user.id
@current_user = new_user
end


Posted in ruby and rails | 5 Comments »

The rumors of iUI’s demise

With the release of the iPhone SDK last week, there’s been some speculation that the end of iPhone web application development (and of the usefulness of the iUI library) is on the horizon. I think this is a mistake, though; the SDK just makes the equivalent of desktop application development possible, and we know from tons of experience that desktop and web applications can live and grow in parallel.

There are two main differences - the developers, and the projects. Some people work better in, say, Objective-C than they do in XHTML, CSS, and JavaScript; some projects work better on the web. There’s nothing wrong with any of these preferences or tendencies. In fact, I think there’s a benefit to this - we get more, better applications by allowing a diversity of platforms (both native and web-based).

If you’re so inclined, put down iUI and pick up and your Cocoa Touch project in XCode. It you’re not, stick with your web framework of choice and iUI. Either way, keep building apps for the iPhone!

Incidentally, this video is a great place to start if you’re not familiar with iUI.

(photo from kitcowan on Flickr)

Posted in iphone | No Comments »

Testing iPhone web applications

One of the ongoing frustrations with web application development for the iPhone is testing - until last week, you were either forced to use an actual iPhone with some manipulation to get your development site accessible to it, or to experiment with “simulators” that are really nothing more than constrained views (I’m looking at you, iPhoney). Luckily, however, the release of the iPhone SDK solves this problem once and for all.

While most of the SDK is targeted at native application development, it also includes an iPhone simulator that accurately recreates the experience - from proper scaling to rotation, and even including multi-touch. If you’re developing web apps for the iPhone, you owe it to yourself to suffer through the 2.1GB download just for this tool alone.

And just as a note - if you’re trying to run the simulator after installing the SDK, it might be called “Aspen Simulator” instead of “iPhone simulator.” Not sure what’s up with that, but there it is.

Posted in iphone, web development | 4 Comments »