johnreilly

subqueries: sqlite3 vs. mysql

Ugh. I thought rails was supposed to handle database peculiarities for me. Is this a bug, or am I being stupid?

Here’s the gist:

new to obj-c

I’m working my way through the Pragmatic iPhone screencasts, and my complete newbosity to Objective-C is thoroughly kicking my ass.

Basically, there’s a main application delegate that has a property on it for data shared amongst other controllers. The controllers “should” be able to access it… as far as I can tell I’ve set up all my connections and @synthesize’ed it correctly, and the property appears in Xcode’s autocomplete. But, the compiler? Not so happy.

Whenever I try to access the delegate’s property (in this case, the property is called “recipes”) in a controller, Xcode spits out an error:

Request for member ‘recipes’ in something not a structure or union

To me, this seems like an old school C pointer de-referencing problem, which I thought Obj-C’s @property and @synthesize bits would have done away with.

I’m at a loss. Any suggestions?

Update

Turns out I wasn’t including the header files for the app delegate class. So, the particular implementation I was working in had no idea what properties/methods were available on the app delegate.

If you look at the screenshot above, I simply added the following line just below the first #import statement:

#import "RecipesAppDelegate.h"

In hindsight, this was a rather silly mistake on my part (but hopefully forgivable since this is my first day with Obj-C…). But what strikes me as weird is that Bill (the screencast’s author) never added the header file during the screencast.

Was it somehow added automagically in his project when connecting up the delegate outlet in Interface Builder? Who knows. At least I’ve got it running now… On to the next section. :)

rspec is mocking me

Grr. I hate situations where it works here, but doesn’t work there, and I can’t see where the difference is. Something has to be different, I just can’t for the life of me figure out what. Maybe someone can help.

Here’s what’s up.

I’ve got rspec and rspec-rails installed as git submodules. Running the latest edge rails. I’m gonna generate up a quick rspec_scaffold:

$ script/generate rspec_scaffold Bike name:string sku:string

This generates the following controller test (abridged):

describe BikesController do

  def mock_bike(stubs={})
    @mock_bike ||= mock_model(Bike, stubs)
  end
  
  describe "responding to GET index" do

    it "should expose all bikes as @bikes" do
      Bike.should_receive(:find).with(:all).and_return([mock_bike])
      get :index
      assigns[:bikes].should == [mock_bike]
    end

  end
end

Looks fine. BUT. In my project, this spec fails, because it is somehow loading up the view and the name and sku calls are tripping up the mock, as it isn’t expecting them to be called in this controller test.

Note, however, that I am NOT calling integrate_views inside my controller spec, so I don’t have any idea why the view code is being run.

% rake spec:controllers
(snip)
ActionView::TemplateError in 'BikesController responding to GET index should expose all bikes as @bikes'
Mock 'Bike_1017' received unexpected message :name with (no args)
On line #11 of app/views/index.html.erb

8: 
9: <% for bike in @bikes %>
10:   <tr>
11:     <td><%=h bike.name %></td>
12:     <td><%=h bike.model %></td>
13:     <td><%= link_to 'Show', bike %></td>
14:     <td><%= link_to 'Edit', edit_bike_path(bike) %></td>

app/views/bikes/index.html.erb:11
app/views/bikes/index.html.erb:9:in `each'
app/views/bikes/index.html.erb:9

This happens for 10 of the 18 scaffolded specs.

I can fix the errors by adding expectations to the mock like so:

it "should expose all bikes as @bikes" do
  Bike.should_receive(:find).with(:all).and_return([mock_bike])
  mock_bike.should_receive(:name)      
  mock_bike.should_receive(:sku)
     
  get :index
  assigns[:bikes].should == [mock_bike]
end

But that kind of defeats the purpose of having a controller-only test, as it’s now testing the view code as well.

What’s weird is, I started a brand new project, and all the tests passed with flying colors!

% rails rspectest
% cd rspectest 
% rake db:create:all
% script/plugin install git://github.com/dchelimsky/rspec.git
% script/plugin install git://github.com/dchelimsky/rspec-rails.git
% script/generate rspec
% script/generate rspec_scaffold Bike name:string sku:string  
% rake db:migrate
% rake spec
(in /Users/john/src/test/rspectest)
.....................................

Finished in 1.006109 seconds

37 examples, 0 failures

So a brand new project runs the rspec_scaffold specs in isolation, but my project somehow doesn’t.

I’m tearing my hair out on this one. I can’t figure out what I’ve done to my project to cause these specs to stop working.

Anyone out there have any ideas/suggestions?

Update!

Wow. Through the magic of git bisect, I’ve determined that the problem occurs because of a change in edge rails. Turns out, this commit causes the specs to fail. Everything before it passes, everything after fails.

I have no idea how to fix this (or if it is rails’ or rspec’s fault), but I’m getting closer. :-)

PS, if you’ve never used git bisect before, you really haven’t lived.

Update 2!

The latest commits to rspec and rspec-rails fix the problem. Bravo rspec team.

off to sodak

Heading out to see Eric in South Dakota today. I’ve been promised pizza and beer. In exchange, I will be used as a prop in a photoshoot of Katy.

Updates forthcoming.

sqlite3-ruby-1.2.2 and rails == no good

Tonight I fired up a new rails app to play with… did my initial git stuff, ran script/console for the first time, fired up localhost:3000, etc etc.

Everything was going so smoothly.  Until I hit the “About your app’s environment” link on the default index page.  Observe the pinkish horror:

Here’s the relevant error text (for google to index):

MissingSourceFile in Rails/infoController#properties

no such file to load -- sqlite3/database
RAILS_ROOT: /Users/john/src/trms/cam

This error occurred while loading the following files:
   sqlite3
   sqlite3/database

Nasty.

Turns out, this isn’t a huge deal to fix.  Just prior to railsing up my new app, I had updated all of my installed gems, which included the latest sqlite3-ruby gem (ver 1.2.2). After doing a bit of research, I discovered 1.2.2 doesn’t play nicely with rails.

Oookay fine, downgrading is easy:

$ sudo gem uninstall sqlite3-ruby -v=1.2.2
Password:
Successfully uninstalled sqlite3-ruby-1.2.2

This put me back to 1.2.1. Running script/console once again proved the workingness had returned.

Bottom line, make sure your latest and greatest sqlite3-ruby gem is no higher than version 1.2.1. I’m not sure what the problem is with 1.2.2, but this worked for me, hopefully it helps someone else as well.

Update Aug 28 2008

Word on the street is that the recently released sqlite-ruby-1.2.3 fixes this issue. Haven’t had a chance to try it myself, but people report success.

why inline labels suck

Came across a form on a website today.  A typical signup form, you see these a jillion times a day. But this one thought it would be clever, and use the hip new style of “inline labels” for its input fields. Observe:

See? The label for the field is inside the field itself. And when you give the field focus (aka click on it), the label disappears, quickly getting out of the way for your personal information. Tricksy! 

This can be a handy technique, and I see it being used more and more. When space is valuable on your form, this can save some crucial pixels. 

But there’s a problem. Even if you’ve done your job as a responsible web designer and written (or copied) all the necessary javascript and CSS to position/hide/reveal the labels just right, you’ve still got a problem with the form, and you can’t get away from it.  

Consider a typical use case; me, trying to fill this form out.

I’m kind of a jerk when it comes to personal information. So, whenever I come across a site asking me to trade my pertinent details in exchange for a freebie of some sort, well, I tend to feed it bogus info. (I’m a jerk cuz I still want the free thing, I just don’t want some marketing dude to know about me.)

So, I dutifully fill out the form the quickest way I know: “a” for everything. Sometimes you get lucky, and the site forgets to perform any input validation.

Well, in this case, I get smacked by a javascript validation error:

Sigh, so they want something that resembles a valid email address.  That’s cool, how about a@a.com? Let’s see if that’ll make it happy.

…

Um, Wait.

Can you see the problem?  Have a look at the form once again, as I have last left it:

Uh, which one of those is supposed to be my email?  I have no freakin’ clue.

And there, my friends, is the intractable problem with inline labels. After you complete the form, you’re left in the tall grass as to which field represents what data.

Granted, my example is a bit of an edge case. You could argue that if someone filled the form out correctly, but made a small slip (say, by forgetting the ‘@’ symbol in their email), they’d be able to cross-reference the phrase “Email Address” from the validation error with their own email address in the form and correct the mistake. No big deal.

BAAMP. Sorry, it is a big deal. Really.

By forcing your users to “divine” your meaning, you’re setting up a barrier between them and the successful completion of your form. Sure, it may only take them a few hundred milliseconds to figure it out, but milliseconds add up.  The longer you delay your user from completing the form, the more likely they are to simply give up. Odds are, your freebie wasn’t all that enticing in the first place. Certainly not enough to waste time fighting with a cranky web form. Maybe there’s something new on Facebook. [closes window]

Congrats to you, web designer. You just got your friend in marketing fired. :)

Bottom line, inline labels suck. Just don’t use them.

ADDENDUM:

…Well, most of the time. I think there is exactly one instance in which an inline label is appropriate: a single input field that follows Postel’s Law.  Have a look at the “Local Weather Search” on weather.com:

There’s a single field, and you can enter pretty much anything; zip codes, cities, points of interest, etc.  There’s nearly zero chance that you’ll need to smack the user with a validation error, and even if you did, there’s only one field to remember!

In this case, I won’t get mad at you if you use inline labels. :-)

This post brought to you by Luke Wroblewski’s new book Web Form Design: Filling in the Blanks [Rosenfeld Media, 2008]. Thanks Luke, for making me pick apart every web form I see.