What’s in a session
I’d made a little progress towards associating a user with an account, but the key to it all was still the account. User id is now the main piece of session state, so from there it can look up oauth keys and whatever else is needed.
I’ve been trying to use Siggnal myself for a little while, but getting an iPad gave it a few more nudges. I’ve found that the siggnal/noise buttons are just big enough, although I might want to separate them more at some point. It’s also not nearly as convenient to edit URLs, so I added more internal links and moved them to the layout. Around the same time, I moved the e-mail list sign-up from the layout to home page, since the change in width was causing status updates to reflow as they got checked off.
Where is a name
Moving navigation to layout means it can’t depend on twitter (though several link paths still do) If I ever make to multi-account, it won’t be so obvious what to name a user. The user model got it’s first method, a name lookup. So far it’s just grabbing the first account, but it’s an abstraction point for the future.
One thing I’ve discovered on iPad, e.g. Mobile Safari, is that rendered pages can be discarded and re-rendered. This is an issue if the DOM has been modified – in my case removing items that have already been voted on. At some point I’ll have to see if any event is generated by the re-render that can be hooked to refresh the data.
Some things are merely decorative. For instance, for some time Siggnal has been picking up the Twitter favicon from it’s detour through OAuth. On the iPad, the springboard icon was also a screenshot. I couldn’t resist setting up a favicon and ‘apple-touch-icon’, both just simple files and header links. I even found that the springboard icon updated immediately.
I’ve been thinking that the coolest thing about Siggnal, as it stands, is the graph. However, it wouldn’t be much to see starting out. I figured I could put mine on the home page to show off, but this required a bit of abstraction. Putting the graph view in a partial was easy, and the top-5 lists followed just as easily. The challenge was figuring out how rails helpers worked, and setting up shared methods that could be called both from a controller, and from a ‘graph’ helper. And then figuring it out all over again in the testing context.
Briefly: helpers are defined in controllers, but actually define methods for views. Often a controller method is marked as a helper. However, one has to be careful because it’s not marking the method as available – the helper methods can’t call non-helper controller methods, so in a sense it’s a bit viral. If you want to have a module used in both places, you have to both include it and helper it in the controller.
If only it described a solution
I’ve had some noise from RSpec for a while – it seems some matchers are missing ‘description’ methods, and it prints a few paragraphs of noise to complain. I do have one custom matcher, ‘have_a_link_to’, but I can’t figure out the magic invocation. I’ve tried both the match-dsl ‘description’ method, and ‘def description’, both to no avail.