a timocracy of one

I mentioned this in my previous post, but to make my plugin easier to test I tried to make it not need to touch the DB, which was interesting to do, given that scaffold_resource is very much tied to a model. This was a big inspiration and this the final (as of now) result:

class Resource < ActiveRecord::Base
  @@count = 1
  def self.count() @@count end
  def self.columns() @columns ||= []; end
  def self.column(name, sql_type = nil, default = nil, null = true)
    columns << ActiveRecord::ConnectionAdapters::Column.new(name.to_s, default, sql_type.to_s, null)
  end
  def self.find(param)
    return param == :all ? [Resource.new{ |m| m.id = 1; m.name = 'bob' }] : Resource.new{ |m| m.id = 1; m.name = 'bob' }
  end
  def save() @@count += 1 and return true if valid? end
  def destroy() @@count -= 1 end
  column :name,          :string
end

In testing DynamicScaffoldResource, I have been working on sort of mocking/overloading ActiveRecord so that it doesn’t touch the DB, so I can minimize how much it depends on the root Rails environment to test, since it’s a plug-in.

class Resource < ActiveRecord::Base
  def self.columns() @columns ||= []; end
  def self.column(name, sql_type = nil, default = nil, null = true)
    columns << ActiveRecord::ConnectionAdapters::Column.new(name.to_s, default, sql_type.to_s, null)
  end
  def self.find(param)
    return param == :all ? [Resource.new(:id => 1, :name => 'bob')] : Resource.new(:id: => 1, :name => 'bob')
  end

  column :id,            :integer
  column :name,          :string

  validates_presence_of :name
end

Well Rails treats the id as a special field, since it is. I tried letting it implicitely add it, and explicitely as above, but there was no way I seemed to be able to set it manually and access it (maybe the problem is prior to a save?), so my edit named route in the view wouldn’t choke (the show path had no problem with the nil, which I might not have caught for a while). While there is probably some way to open up access to the id column, this mailing list post opened up an alternative that works, just use:

Resource.new{ |m| m.id = 1; m.name = 'bob' }

Dreamhost upgraded the RAM on my server yesterday. This meant it was down unexpectdly and I felt like that was teh last straw. BUT, I checked their special status page, and saw what was happening, and they did have it right back up around the time frame they said they would.

My sites perform MUCH better now. I’m still stuck with the vagaries of being on a shared host, with the (mt) gs set-up might be the solution for, but so far I haven’t had any problems. Maybe half my problem was just being stuck on an underequiped server. And after trying out the gs, I might be asking for a refund (they said they’d give me one, if I chose). I’m just too addicted to the featurefulness of DH. mt didn’t have SRV records (needed for the chat for GMail for Your Domain), email plus addressing (tim+randomstring@timocracy.com), anyway to run Trac, barring good (bad) old cgi, or mod\_dav\_svn (svn over Apache).

The solution for most of these would be too keep my DH account for those and use the Grid for things like Rails sites that need better performance. Well, why not just keep my DH only then, since my sites are performing fine now. I can always go back to mt later, after they add a Python container and SRV records (two things I know they are planning to implement). Thanks mt, for making it easy to cancel and get a refund, I’ll remember that when I need a little more umph, or if DH starts sucking again.

While Apache fcgi may suck, it’s better than that.

I’m getting really tired of Dreamhost’s non-stop problems. Hell even when something isn’t officialy broken my performance sucks. While I don’t expect to find mod_python so Trac will run nicely, for the Rails side of things (and all around, actually) a very nice looking new option sprung up: MediaTemple’s new Grid Server hosting. I’m seriously considering migrating everything over to their basic plan. Hell, I can keep my Dreamhost for random filestorage forever (well as long as one certain old client doesn’t get as tired of the performance as I am, and switch), given my referals (I might have to cut back to the basic plan).

I’m basically just waiting to hear back that Trac should run fine under .fcgi, which I expect it will, and to maybe read some reviews, since it JUST went live.

Oh, and the fact that DH just 10-foldified their disk space on plans, but are still DESPERATELY trying to get vendors to sell them a massive network storage solution doesn’t look good.

So I’ve taken to changing my permalinks ala: http://www.notsostupid.com/blog/2006/07/07/urls-on-rails/. Of course, Typo already has user-friendly slugs, but I am now prefacing the article id to the title, for the permalink. My thinking being it would take a minor patch to Typo to allow for this sort of routing, and suddenly I have the freedom to rename my article and permalink at will, without making old links obselete. I mean who hasn’t realized a glaring typo AFTER an article is published. Well, if one ever has readers (not me, of course ;)) then you can’t just go and correct it, without making potential links out there incorrect.

Yes, I realize this scheme isn’t actually RESTful, it just came up in looking into REST stuff, and has some potential advantages.

My first Rails plugin, DynamicScaffoldResource has hit 0.1 – it now should handle all the basic REST actions almost identically to the generated scaffold_resource. The main difference is it uses the ActiveRecordHelper form() call to dynamically generate the forms, and auto-iterates over the columns on index and show, just like the offcial scaffolding. This is more fitting for the dynamic scaffolding than the blank form approach of the generator, which makes sense for that, since you will be filling that in manually.

If anyone is interested the subversion repository is up at http://svn.infosauce.org and trac is at http://trac.infosauce.org

It is still completely undocumented and untested, but those are the plans for the next release. Knowing what else needs to be fixed it probably won’t be before 0.4 or 0.5 before I’d say it’s public ready. For instance, it still requires you to have these patches applied.

I finally found an extension that lets me use Firefox for testing that I would previously had to use curl for, namely submitting text/xml only requests (for testing REST APIs, for example) or similar. I thought ModifyHeaders would do the trick, but I never really got that working. But TamperData is exactly what I wanted.

I just got Trac running on Dreamhost for InfoSauce (basically my) Open Source Projects to make it the home of the new Dynamic Scaffold Resource plugin for Rails

The Dreamhost Wiki entry on Trac made it a breeze, if only because of the link to an automated install script .

My only gripe would be that their section on Pretty URLs had a minor bug (for me).

DirectoryIndex wiki

should be

DirectoryIndex index.fcgi

I just submitted my first two patches to Ruby on Rails. I was thinking that I wanted something a certain way, and the best way to get that is contribute. I submitted these two “tiny” patches:

add options[:url] to form() in active_record_helper.rb – partially allows for RESTful call

add options[:method] to form() in active_record_helper.rb – partially allows for RESTful call

as they truly are tiny and might get applied. And of course, I submitted the tests, so my patches didn’t get tossed out immeditately.

I have to say trying to get Rails to pass its tests is a pain, and from the look of their ticket system, some of those might not be meant to pass yet (TDD). Anyways, I gave up on some of the minor tests that might not work on my system (Win32), and just made sure I did not break anything else, in making my changes. One I did that, it was actually pretty easy.

Then since the end goal I am aiming at is significantly larger, I submitted the following email to the core mailing list, instead of just jumping in and stepping on toes.

So I’ve RESTified a couple controllers, now, using the latest stuff in Edge and they don’t feel very-DRY. I realize that after they get more complicated they will need to be able to be stand-alone, but they are currently pretty wet. I considered working on an abstract REST controller, but then realized that dynamic scaffolding was almost all I needed. I just want to be able to not have to repeat myself until the controller diverges from the norm.

Now perhaps an abstract controller might be able to be figured out in such a way to allow for better TDD, but I think basically a copy of the current generated tests for scaffold_resource could just be dropped in test for those who want to do TDD, and the scaffolding could use updating if everything is supposed to move towards REST/CRUD.

I submitted a couple tiny patches to active_record_helper.rb form() to add options[:url] and options[:method] so that the ARH form could at least be called in the current REST style (since the scaffolding uses that form(), which was hard-coded to an old-style url :action =>), but wanted to ask here before proceeding further.

Am I completely off base here? If I want a dynamic scaffold_resource :model should I proceed and submit the patch? Should I just update the current scaffolding to use the new REST style, or make it scaffold_resource? What are the odds of this sort of thing getting applied? More likely given the push to REST, and since this would add another minor nudge? Should I make any other tiny patches needed to core, and then just make the rest a plug-in?

Tim

So nothing has been accepted yet, but my first patches are submitted at least. Yay!

While setting up a new typo install on Dreamhost I hit a bug in the migrations, specifically 051_fix_canonical_server_url. Basically, if you run rake db:migrate to get the DB ready for typo, it chokes because it expects that you have already configured typo.

b.settings['canonical_server_url'].gsub(%r{/$},'')

fails because b.settings[‘canonical_server_url’] isn’t defined, but it’s easy enough to fix, just add unless b.settings[‘canonical_server_url’].nil? to the end of that line:

b.settings['canonical_server_url'].gsub(%r{/$},'') unless b.settings['canonical_server_url'].nil?