a timocracy of one

While properly setting up my Rails app server maintenance tasks, I noticed that my Typo install was running even more bloated than I remembered – no wonder the Dreamhost watcher processes kill it off. After digging around and trying a couple things it seemed that deleting your unused text-filters, sidebars, and plugins does nicely, for trimming down Typo.

Well, I got my Typo install down from running in the 50s to 30s (megs)upon the initial start (it still grows as it leaks, of course). See the glory of what I hacked out of the vendor folder.

!      vendor/bluecloth
!      vendor/plugins/magnolia_sidebar
!      vendor/plugins/haml
!      vendor/plugins/aimpresence_sidebar
!      vendor/plugins/fortythree_sidebar
!      vendor/plugins/technorati_sidebar
!      vendor/plugins/typo_textfilter_tmcode
!      vendor/plugins/tada_sidebar
!      vendor/plugins/typo_textfilter_lightbox
!      vendor/plugins/typo_textfilter_markdown
!      vendor/plugins/tiny_mce
!      vendor/plugins/xbox_sidebar
!      vendor/plugins/typo_textfilter_amazon
!      vendor/plugins/typo_textfilter_sparkline
!      vendor/plugins/amazon_sidebar
!      vendor/plugins/recent_comments_sidebar
!      vendor/plugins/typo_textfilter_textile_and_markdown
!      vendor/plugins/audioscrobbler_sidebar
!      vendor/plugins/backpack_sidebar
!      vendor/plugins/xml_sidebar
!      vendor/plugins/typo_textfilter_flickr
!      vendor/plugins/typo_textfilter_code
!      vendor/plugins/flickr_sidebar
!      vendor/plugins/typo_textfilter_smartypants
!      vendor/plugins/upcoming_sidebar
!      vendor/plugins/sitealizer
!      vendor/plugins/fortythreeplaces_sidebar
!      vendor/rubypants
!      vendor/flickr
!      vendor/jabber4r
!      vendor/sparklines

Here are the corresponding environment.rb changes. I also deleted all but the Textile and none filters in the admin interface. The first thing I tried chopping out, though, was the newly added sitealizer. Since this is run via an around filter, you have to edit your application.rb thusly, if you take it that far. I, also, got carried away and took out BlueCloth, since Textile is handled by RedCloth. In doing so, I found at least one place in the admin interface were it is hard-coded, and will cause your new content form to choke: app/views/admin/content/_form.rhtml

UPDATE – five minutes later: I forgot, I also turned off live Preview to stop hammering my poor app, and started editing directly in Textmate, from the textarea

UPDATE – 4/19/2007 – Found another hard-coded instance of BlueCloth that I had to comment out: app/models/text_filter.rb/comment_help line 96

f.help_text.blank? ? '' : help_text  # "#{BlueCloth.new(f.help_text).to_html}\n" 

I got tired of waiting for the weird typo formatting bug that seems to only affect some installs and not others and wanted my code blocks to just look right. Ya, maybe I could have tracked it down, but trunk seems to be under some sort of constant reorganization.

Instead, I just swapped out all the tm:code macros with the html

as = Article.find(:all)
as.each{ |a|
  a.body.gsub! /<typo:code>/, '<pre><code>'
  a.save
}
as.each{ |a|
  a.body.gsub! /<\/typo:code>/, '</code></pre>'
  a.save
}

And now my code formatting is back. At some point maybe I’ll tweak my css, and drop the redundant pre, now that I’m not depending on the macro anymore.

I updated my versioncopy of typo and cribbed some of the fixes from scribbish (which my theme is based on, since it’s touted as a good tabula rasa for building themes) for returning feedback to the user even with moderation enabled.

As you can no doubt see, this blog has return from its hiatus. As I’ve complained about before, running Typo on Dreamhost isn’t that dependable, so while I was busy wrapping up the sale of my condo and then moving to Tucson, I let it slide. But now that I am somewhat settled in, I’ve gotten around to the updating, tweaking, and praying required to get everything working again, and will probably be keeping a little closer eye on it.

I’ve turned on various spam protection measures (such as Akismet, disabling non-ajax commenting. moderation, etc), and am hoping that will alleviate some of the performance issues. If not I am thinking of moving onto a new system- looking for something that is less of a pain for me to maintain with this set-up, since I will be needing to get a job, and thus will have better things to do with my time than getting frustrated with Typo/Dreamhost-fcgi. I’ve been considering the newest kid on the block in the Rails blogging world SimpleLog, but maybe things will stay functional enough that I don’t have to go down that road and spend more time converting everything over.

Either way, I’ll be posting again here some, as I work on finally getting the Lost River Outfitter’s site updated with the new functionality that I promised them as a Christmas present ages ago, and then finally get around to playing with some of my ideas for InfoSauce 2.0. If I get a non-tech job (like my plan to work in a bike shop), I’ll probably be willing to spend more of my spare time developing, but either way I’ll try and post semi-regularly as I come across cool stuff.

As well, I’ll probably be working on getting the design updated with Stf’s work (after I feedback to her on the first round logo stuff), so I can get rid of the stupid placeholder header image, fixing the homepage nav in Safari, putting my resume up, and other house-keeping as I have time.

I was trying out giving articles a publication date in the future, to build up a queue and avoid the feast or famine approach to posting I’ve had so far. In theory it should be straight forward: uncheck published and set the date to publish sometime the future (I was going with every other day, to give me an easy way to slip more timely posts in between the scheduled ones).

Well, when I checked on my blog tonight it had totally choked. The front-end appeared fine, since it was cached, but the admin was kaput. I tried clearing out everything, updating, and restarting, and then I was getting a stack level too deep error on the article id of the one I had tried queuing up. So my first guess, of course, is that it choked once it passed it’s sell by date.

I’ve sent a question to the mailing group, about wether anyone has seen this before, and will follow up here, when I have more info (either hear back, or dig into it myself)

I looked into it a little more this morning, and came up with how to still get the submit button disabling, to avoid double-posts, without having to rework anything substantially.

<%= submit_tag 'Submit', :onclick => "$('commentform').onsubmit();this.disabled=true;Element.hide('preview');return false;"%>

You first call the form’s onsubmit, since IE won’t call it if you submit the form via JavaScript, then you prevent browsers that don’t cancel the form when you disable the submit button from double-submitting, by returning false at the end.

This should still work with javascript off, if you have the “Allow non-Ajax comments” setting turned on.

For those who may have noticed that your Typo blog won’t allow comments from IE users (is that a feature, or what?), I found the problem.

<%= submit_tag 'Submit', :onclick => "this.disabled=true; Element.hide('preview');" %>

The “this.disable=true” disables the submit button before the form is submitted, so all that happens is the onclick. For now I am just taking that out of mine – I’ll look at a better fix later.

So I thought I’d hold onto Dreamhost as my primary host a while longer, but its driving me mad. It just won’t perform wortha snot, especially anything that depends on fcgi. Hence Trac and Typo (Rails is Apache fcgi on Dreamhost) are not exactly running up to snuff. But it’s not like anything has ever been going F1 speeds for me with them.

You want to know how I knew right away there was a comment posted on one of the entries? I have been giving the new Rails monitoring service, Heartbeat, a try, and I got a notification from them that my domain had changed from “200 OK” to timing out. Great, the load of serving up a couple page-views and handling a single comment pushed my Typo install to it’s limits.

I’m going to keep Dreamhost for storage, backup, and mirroring svn, since you get a lot for your dollar, but I can’t stand it as a primary domain any longer, even just for my blog and minor personal projects.

In what seems to be my new drive for finding distractions, I decided I got tired of not knowing when I was at my own blog, due to having the same new theme as everyone else using Typos (Scribbler). So, I ported over the old theme from my company, InfoSauce. I slightly repurposed it and upgraded the css to work with the new code. Of course, in doing so I broke it in at least IE, somewhat, so I’ll be touching it up as I go.

I noticed that Scribbler actually has one minor bug in IE, as well. The code blocks don’t autoscroll like they do in Firefox, so if they are too wide they kick the sidebar down to the bottom. I just gave them a width, so IE would know to engage the overflow:auto. That is still not perfect, because then you get vertical scrollbars in IE, due to the loss of 16px, when the scrolling is activated, but it’s better than it was.

One of the first things I learned working on the typo-permalink-with-id plugin was how to load fixtures from a plugin. I had previously just been mocking out ActiveRecord, but the Typo object model is complicated enough that it was easier to just schlup their envirnment.rb and then load their fixtures into my tests.

require 'test/unit'
require 'active_record'
require 'active_record/fixtures'
RAILS_ENV = "test" 
require File.expand_path(File.join(File.dirname(__FILE__), '../../../../config/environment.rb'))

class TypoPermalinkWithIdTest < Test::Unit::TestCase

  def setup
    fixtures_dir = File.expand_path(File.join(File.dirname(__FILE__), '../../../../test/fixtures'))
    Fixtures.create_fixtures(fixtures_dir, File.basename("blogs.yml", '.*'))
    Fixtures.create_fixtures(fixtures_dir, File.basename("users.yml", '.*'))
  end

  def test_fixtures_loaded
    assert_not_nil Blog.find_by_id(1), "blogs.yml not loaded" 
    assert_not_nil User.find_by_id(1), "users.yml not loaded" 
  end

Edit: This idea slightly cribbed from Loading Fixtures in a Migration