“How do you test request headers? The request object is frozen…”
The team is using rspec to test an OAuth implementation and needs better access to the request object.
“AR attribute appears to be skipped by text field helper?!” Apparently the model method is bypassed by the text field helper if a column of the same name is present in the underlying table. This was experienced in Rails 2.2.
Others have apparently experienced this in the past but a clear answer did not surface.
I’ve been wanting to use Pivotal Tracker on my iPhone, so I wrote a little proof of concept using the Tracker API. I thought that a native application would be much more difficult than a skinned web application using ActiveResource.
I tried out Dashcode, Apple’s recommended iPhone-compatible front-end web development tool, but was disappointed. I basically found myself developing the entire application in javascript, actually using XMLHttpRequest to talk directly to the API. This would have been pretty neat if I could have pulled it off, but I’d rather develop a data-heavy application in rails than javascript.
I ended up using simple CSS to skin the application called UiUI. It’s the best looking iphone UI I’ve seen, with tons of elements to choose from. It’s missing effects, of course, being only CSS. I also used Heroku, a free and scalable rails deployment environment to host my application. With it, I was up and running with a functional tracker application in under 3 hours. Since then, I’ve added the ability to create and update stories.
Check it out, let me know what you think:
http://itracker.heroku.com
If you’re not on an iPhone, be sure to use Safari. It doesn’t look great in Firefox or IE.
Selenium removes the If-Modified-Since header. This gets in your way if you are testing ETags.
Speaking of ETags – they are awesome. See Ryan Daigle’s article for code.
Just how slow is Mongrel when serving static images?
The answer is – pretty slow. The reason for the question was that Google’s crawler tends to keep a single connection open and fire lots and lots of http requests over a period of several hours. With a standard Nginx/Mongrel setup, this would tie up a mongrel for this entire period.
A proposed solution to this problem is to use HAProxy between Nginx and Mongrel.
Warning: a bit of Shameless Self-Promotion follows
Sitting in more than one session at RailsConf 2008, I noticed speakers that were advocating, directly or indirectly, Agile practices. But, aside from Kent Beck’s great keynote, there wasn’t a lot of ‘pure Agile’ on the program.
I left the conference inspired to write a presentation that would help those in the Rails community get better at their jobs.
I had some ideas, but last summer I asked you what helped you be Agile day-to-day. I took your comments, the tips from fellow Pivots, and my own hacks and made them blend. The result is a presentation called “I Rock, I Suck, I Am” that was accepted for the program at RailsConf 2009.
So thanks to you for your thoughts & comments – they all helped shaped my presentation. And if you’re at RailsConf, come on by with your curious and/or reluctant peers and have a listen.
user.purchases.sum(), you are invoking ActiveRecord::ClassMethods#sum rather than Enumerable#sum. If you want to invoke Enumerable#sum (which takes a block and is more powerful though less performant), you’d have to call user.purchases.target.sum() {|p| p.price * p.quantity}.bash/readline messing with the terminal? We’re always typing some ridiculously long command and bash starts writing over itself. Especially when we use Ctrl+A and Ctrl+R and edit the line. Anyone know how we can stop/fix this once it happeneds?{:a => 1, :b => 2}.to_a? It’s Hash[:a, 1, :b, 2].:order => "position" on every acts_as_list model
Frederick Cheung discusses this in more detail here. This might be related to the Selenium + class reloading issues some pivots have experienced in recent weeks. The alternative is to rely on Rails automagic loading or ‘require_dependency’.
Props to pivot Pat Nakajima for creating acts_as_fu.
How many times has this happened to you? You get a cool design for your website, and you spend a bunch of time lining up all of your images and roundy-corner widgets and input boxes just… so…, and everything looks great. But, then you submit a form without typing in your favorite ice cream (a required field, of course), and suddenly your layout is splattered about like an extra large scoop of rocky road in the hands of a two year old. It’s enough to make you want to stab your eyes out with a hedge trimmer.
The reason is, of course, that ActionView automagically wraps a div around any input element for an ActiveRecord attribute with validation errors. This div has the class ‘fieldWithErrors’, which makes it all red and nasty looking to tell your wayward user that they need to cough up some more information.
Now, input elements are inline elements, so they don’t break page flow. At the same time, div elements are block elements, so they break page flow and use up as much width as is available to them. When ActionView renders a form for your ActiveRecord object with errors, it alters the HTML structure that you’ve so painstakingly laid out, inserting these disruptive divs where previously there were only gentle, friendly input elements. Not to mention that it might be inserting these div elements inside other HTML elements that, according to the standard, mustn’t contain div elements. BOOM. Browser-specific nastiness all over the place.
So, a fellow by the name of Alex MacCaw opened a Rails ticket with a patch to change this fieldWithErrors div element to a span. Span elements are, of course, the inline version of div elements.
Based on some of the feedback, and the fact that ActionView modifying the HTML structure of my views annoys me, I created a somewhat more invasive patch for this ticket.
I changed ActionView to not add an any elements to the HTML structure, but to add the ‘fieldWithErrors’ class directly onto the input element for the attribute with errors.
I also added a #field_error_options class accessor on ActionView::Base, with which you can customize the HTML attributes that ActionView adds to these inputs. The value of #field_error_options defaults to
{ :class => 'fieldWithErrors' }
This will combine with any class option you’ve specified on your tag builder, so
<%= text_field @foo, :bar, :class => 'wibble' %>
will generate
<input type='text' name='foo[bar]' class='fieldWithErrors wibble' />
when the bar field fails validation on @foo.
ActionView::Base still has the #field_error_proc class accessor, so you can still add HTML structure to input elements for invalid attributes if you so choose. However, I changed this to default to nil.
Check it out, see what you think. And keep away from the hedge trimmer.
Rails has had the has_one :through association for a while now, and you probably use it on occasion. But, has it ever given you the heebie-jeebies a little bit? Maybe something happens now and then that doesn’t seem quite right? Well, the reason for this is that HasOneThroughAssociation, the class that ActiveRecord uses (shockingly) to implement has_one :through associations, is a subclass of HasManyThroughAssociation.
Whhaaaaaaaaaat?
Yes, oddly enough, a has_one :through association is a collection that is special-cased to always return just one element. Seems kind of dirty, doesn’t it?
I have two, related, problems with this inheritance relationship. First, it violates Liskov substitutability. One cannot in any way argue that a has_one :through association IS A has_many :through association; substituting one for the other would not be likely to maintain a program’s correctness. Second, the inheritance relationship exists to share implementation, not interface. Among others, the Gang of Four have described, persuasively, why this is a terrible idea.
More practically, I’ve now run into two serious bugs caused by this relationship. The first one caused newly created has_one :through associations to return an empty array rather than nil. I fixed that here, with the help of wunderkind David Stevenson. The second I ran into in the last few days while working on this patch, which I’ve written about here. It turns out that trying to get #method_missing to behave sensibly for all non-collection associations is difficult when one of those associations inherits a pile of collection-specific functionality.
So, in order to make my #method_missing patch work I had to rewrite HasOneThroughAssociation with a more appropriate superclass (I used HasOneAssociation). You can find that patch here. Hopefully this change will make its way into the Rails codebase and will make lives easier for generations to come.