fatvegan

ActionController::MethodNotAllowed
Only get, head, post, put, and delete requests are allowed.

I started getting this funny little error this morning. It is a funny error in the humorous sense, but possibly you need to have used REST to think so. There were a few people getting this problem and finding a few different solutions, but my problem was I had a map.namespace in my routes.rb file. map.namespace appears to be deprecated/abandoned. So I tried using map.resource instead of the map.namespace. Technically I'm looking for a namespace and not a singleton resource, but it worked for me and namespaces and singular resources provide pretty similar functionality in this case. Although I'm still struggling to fix my tests so they they figure out what URL to use.

Update: Singleton resources seemed to cause problems with the :collection option, so now I've rolled my own namespaces with :path_prefix.

I finally got confirmation that I had passed my last subject. I got 55. I brought my overall average to 75.710. It was close, but I managed to finish uni with a distinction average.

I've just replaced a whole stack of nasty hand-coded SQL with nested scopes. There is a lot you can do with them that you aren't quite able to do with the standard associations. The main benefit is that you don't lose find_in_collection which all the examples seem to neglect. It's pretty rare that you want everything in a table. You mostly want to sort it and slice it, or search through it. So finder_sql isn't useful for very much. It doesn't provide any value that a standard method with some custom SQL search doesn't provide.

class User
    def public_topics(*options)
        Topic.with_user_scope(self) { Topic.with_public_scope { Topic.find(*options) }
    end
end

I was able to replace a nasty SQL subquery with this. And even swiftier, you can give it your normal ActiveRecord::Base.find options. It's probably not clear why I couldn't just use normal associations here, but I really couldn't. There was a topic_relationships table which connected users to topics very oddly, which is what created all the headaches.

So the moral of the story is, with_scope is the probably best option when normal associations won't cut it.

I'm curious about nuclear waste. I know it's bad and all that, but it's interesting to compare the amount of nuclear waste the world might conceivably create compared to the amount of other stuff we consume. So I did some maths.

(16.33 * 1,000,000,000) / (1000 * 365 * 24) * 33 = 61517

or

(16.33 billion MW/h per year total world electricity consumption) 
   / (1000MW nuclear reactor * 365 days * 24 hours) 
   * 33 tonnes of annual waste from each reactor
   = 61,517 tonnes of waste per year

That is approximately how many tonnes of nuclear waste we'd generate per year if the whole world ran on nuclear electricity. It's quite a large amount. However, compared to amount of coal leaving Newcastle each week, it's doesn't seem like so much. Newcastle coal port exports 1,610,000 million tonnes of coal in a bad week.

I'm not wanting to suggest that we can just stick everyone's nuclear waste in our Hunter coal holes and be content. But I do find the scale of these things very interesting. At first glance (or perhaps this is the second glance) we don't seem to have real issues with the sheer quantity of waste we might generate.

There are still plenty of good reasons to not like nuclear power (or possibly just a couple of super important ones), and I'm not a big fan of it. Solar plants still seem pretty winner to me.

It's also possible I have done the maths wrong.

Sources

1. How much power a 100 MW power plant generates annually?
2. The Nuclear Fuel Chain
3. The World Factbook

I started getting exceptions like this without really being sure why:

 ActionController::MethodNotAllowed 
 (Only get, put, and delete requests are allowed.)

I think the version of Rails was probably updated and it became less forgiving of our pitiful custom form builder.

One of the frustrating things about custom form builders is the Rails form helpers seems to move faster than it's practical to keep up with. So you end up with a whole lot of old-fashioned form builder code lying around that is either bigger than it needs to be or totally broken.

The new Rails RESTful routes stuff uses the "put" method to update existing records. Which I think is slightly silly, but someone is convinced we need to apply the HTTP CRUD metaphor to web forms. So we use hacks like <input type="hidden" name="_method" value="put" /> because forms don't support proper HTTP puts.

But anyway, that's the way things are and as everyone learns with Rails, resistance is futile or at least far more pain than it's worth.

But this particular problem I've fixed. The form action for updates should be /object/1234, which accepts GET, PUT, DELETE. I was getting MethodNotAllowed errors because my form builder wasn't adding the hidden _method field. Rails was treating the update as a normal POST to /object/1234 instead of a PUT. So I got the form builder to add in the hidden field for existing records, and everything was sweet.

Someone else had the same problem for a different reason.

This is a problem I've come across a few times and I keep forgetting why it happens. It occurs when there is an runtime error in the model (script errors fail more loudly). This is typically a NameError, such as a bad library name or method call. The new rails fixtures need to look at the model associations to work out their magic - the mapping between association names and association foreign keys. But if the model code is bad it silently fails and the fixtures code can't work out what to do.

You'll get something like this:

$ rake db:fixtures:load
rake aborted!
Mysql::Error: Unknown column 'holiday_type' in 'field list': INSERT INTO `holiday_periods` (`holiday_type`, ...) VALUES ('school_holidays', ...)

I'd assumed it was a problem with the fixtures or the migrations. But in this case the problem was in the HolidayType class. Which is certainly not clear from the error, but on reflection not really so surprising.

It took me a while to figure this one out, because I'm totally unelite.

Section "Monitor"
  Identifier    "Dell 2408WFP"
  Option        "DPMS"
  HorizSync 30-83
  VertRefresh 56-75
EndSection

Section "Screen"
  Identifier    "Default Screen"
  Device        "ATI Technologies Inc RV380 [Radeon X600 (PCIE)]"
  Monitor       "Dell 2408WFP"
  Defaultdepth  24
  SubSection "Display"
    Modes       "1920x1200" "1280x1024" "1152x864"  "1024x768"  "832x624"   "800x600"   "640x480"
  EndSubSection
EndSection

xorg.conf

Emily, Martin, Tom and I all trotted off to see Happy-Go-Lucky at Broadway last night. I was almost last because I was racing from work. I had to catch two buses and spend $5 but I got there in 35 minutes from North Sydney - which is very speedy. I took a punt on a 200 to Bondi, and it paid off big time. I got into the film about 7 seconds late, which was frustrating but I was big enough to just accept it nobly.

It was a beautiful film. Poppy was the best movie character ever. I totally loved her. She was kind but super tough, and those people always seem to end up being the best. And she was so funny. I laughed for the whole film. I think they must have found an actor who was just like that. I don't think anyone could pretend to be that funny. Everyone in the whole world would like this movie. And they all should go an see it.

I've been reading a little about UJS lately, trying to figure out a nice way of building some AJAX back into the Rails project I'm working on. I had a look at the UJS plugin and tried out the Low Pro. But I'm not sure I'm convinced. PPK suggests that Javascript is to behaviour as CSS is to styling, but I disagree. CSS tends to apply to many elements in a site. Javascript is more likely to be specific to a page. Most of the benefit of CSS comes from classes and being apply to apply the same style to many things at once. It makes sense to keep something like that separate.

The is the "wrong" way to do it:

<a href="/event/new" onlick="AJAX.Request(...);return false;">Create event</a>

And this is the "right" way:

<a href="/event/new" id="create_event_link">Create event</a>
<script type="text/javascript">
//<![CDATA[
Event.addBehaviour({ '#create_event_link': Remote.Link }); // attach event listener to link
//]]>
</script>

Which is pretty verbose, and to truly do it properly you're meant to put that second block in a separate file. In a Rails application, that's going to be somewhere in public/javascripts/ which feels very much like the wrong place to put this sort of logic. The second solution will also break if the link is created dynamically after the page has loaded.

An event delegation solution might solve this particular problem. You could catch all links with the class "remote" for instance, and treat them as AJAX links. But it wouldn't be very configurable. Configurability isn't a big issue for CSS, but I think is an issue for Javascript.

I certainly understand the appeal of UJS, but I don't think the parallel between styling and behaviours is convincing. And for trivial behaviours like this I don't think duplication of code is a serious problem, either for download size or for maintenability.

Ryan & Laurence are girls, originally uploaded by Nutloaf.

Laurence & I went to the housewarming at the Lumpery the other night. It was a carnival sideshow theme, but we ended up pretty much dressing girly. I think I might have been some sort of ringmaster gypsy psychic.