Musings of a Trained Monkey

I am done with Liquid Templates. I grasp the idea of “user” editable code that is “safe”, but I don’t want to spend my time programming with it. Having spent time with Mephisto and working through the leakiness of the Liquid Template abstraction, I now have an even greater appreciation for coding templates directly in Ruby.

This just confirms the wisdom of prophet DHH about “The false promise of template languages”. <-That was posted back on Valentine’s Day 2005!

I am not a designer (INAD?) so why would I choose a blogging engine that doesn’t cater to me as a programmer? As a programmer, using Liquid is the equivalent to having to wear a condom, all the time. I want the full Ruby sensation, thanks!

Java SE 6 is to be released this December 7th, 2006 (a day that will live in infamy indeed!). Wow! How out of date are the Java applications you are working on? I feel almost as bad as I did when JDK 5 came out (December 2004!!!) and I wasn’t able to utilize it for months years. I fear the lag time will be much longer this time.

I’ve been toying with switching over to Mephisto and spending some extra time studying memory consumption, which is quite a bit higher in Mephisto than Typo. Using the latest svn trunk of RubyGems (r1100), the bug with multiple Gem::GemPathSearcher instances being created has been fixed, but now there is a different problem. Multiple Gem::SourceIndex instances are created. I can see where this might be needed with the recent “incremental updates to the gem list” change that went into RubyGems, it doesn’t make sense to have these hanging around in memory for the lifetime of a Rails application.

I took the same approach to a fix as last time, adding the require and include for Singleton into the SourceIndex.rb class. This worked fine for loading up Mephisto and indeed reduced the memory use substantially.

I haven’t checked to see how this change impairs RubyGems for getting new gems, update, etc. but it seems like there needs to be a different amount of information loaded for bootstrapping the gem command, versus a running Ruby or Ruby on Rails application.

• Does the running application really have a need to know the complete dependency hierarchy for all of the installed gems on a system?

• Even if your application did, would you want that information stored into memory from startup to shutdown?