I was having a good bit of trouble getting ports to install ImageMagick and have had trouble many other times getting ports to install things. As such, I often fell back on fink or compiling and installing from source rather than figuring out the root causes of my macports problems.

Macports was surprisingly easy to fix up and get fully operational again, and this was on a fairly old machine that I am pretty certain I started with “Darwin Ports” roughly 3.5 years ago.

First Thing’s First

First, know that the official macports website is: trac.macports.org. Be wary of anything “darwinports” as name is officially retired in favor of “macports.”

Trouble a-brewing

It all started innocently enough. I wanted to install ImageMagick on my mac. I’ve been through installing ImageMagick on Linux and knew it was not going to be a cakewalk to install from source. ImageMagick simply has too many dependencies to relish the thought of an install from source route. So I googled and found instructions for ports and began:

sudo port install tiff -macosx imagemagick +q8 +gs +wmf
Warning: Group file could not be located.
--->  Activating tiff 3.8.2_3
Error: Target org.macports.activate returned: Image error: Another version of this port (tiff @3.8.2_2+darwin_9+macosx) is already active.

Oh, ok, lets remove the old one…

sudo port uninstall tiff -macosx imagemagick +q8 +gs +wmf
--->  The following versions of tiff are currently installed:
—>  	tiff @3.8.2_2+darwin_9+macosx (active)
—>  	tiff @3.8.2_3
Error: port uninstall failed: Registry error: Please specify the full version as recorded in the port registry.
[mwlang@macdoze shared] sudo port uninstall tiff @3.8.2_2+darwin_9+macosx
—>  Unable to uninstall tiff 3.8.2_2+darwin_9+macosx, the following ports depend on it:
—>  	gtk2
—>  	lcms
—>  	sane-backends
—>  	xsane
Error: port uninstall failed: Please uninstall the ports that depend on tiff first.
[mwlang@macdoze shared] sudo port uninstall tiff @3.8.2_2+darwin_9+macosx gtk2 lcms sane-backends xsane
—>  Unable to uninstall tiff 3.8.2_2+darwin_9+macosx, the following ports depend on it:
—>  	gtk2
—>  	lcms
—>  	sane-backends
—>  	xsane
Error: port uninstall failed: Please uninstall the ports that depend on tiff first.
[mwlang@macdoze shared] sudo port uninstall gtk2 lcms sane-backends xsane
—>  Unable to uninstall gtk2 2.12.9_0+x11, the following ports depend on it:
—>  	gconf
—>  	gnome-keyring
—>  	libglade2
—>  	gail
—>  	libgnomecanvas
—>  	libbonoboui
—>  	poppler
—>  	py25-gtk
—>  	gtk-nodoka-engine
—>  	xsane
Error: port uninstall failed: Please uninstall the ports that depend on gtk2 first.

Not a very auspicious start, is it? Time to step back and think about this one and dig into the macports facility to learn how to properly manage things. New strategy: Get an education.

Discovering Deactivate/Activate

So, looking at the above problem, I realized that there was almost certainly an easier route out of this dependency nightmare and I needed to learn how to upgrade those old, stale packages. Going through the docs reveals activate and deactivate commands. Sounds perfect, lets try:

sudo port activate tiff @3.8.2_3
--->  Activating tiff @3.8.2_3
Error: port activate failed: Image error: Another version of this port (tiff @3.8.2_2+darwin_9+macosx) is already active.
[mwlang@macdoze shared] sudo port deactivate tiff @3.8.2_2+darwin_9+macosx
—>  Deactivating tiff @3.8.2_2+darwin_9+macosx
[mwlang@macdoze shared] sudo port activate tiff @3.8.2_3
—>  Activating tiff @3.8.2_3

So there’s the kicker. First, deactivate the old version, then activate the new version.

So Macports itself is out of date, you say?

sudo port install tiff -macosx imagemagick +q8 +gs +wmf
Error: Unable to execute port: invalid command name "use_autoreconf"

I had no clue what this was. Googling around was turning up precious little. So I hopped over into the IRC #macports channel. Right off the bat, Toby tells me to selfupdate. I had made the mistake of thinking that “sudo port sync” was keeping macports packages all up to date in one fell swoop. But the two are two distinct activities. So remember to keep ports itself updated with this:

sudo port selfupdate

With that, port was upgraded from a very old version to a bright and shiny new version. Time to try to install ImageMagick again. And I’m happy to report that I got much further along this time. But still hit a roadblock…

Mysterious failure demystified

A little down the chain of installing various xorg packages, I hit upon this one with the xorg-libx11 package:

checking for XPROTO… configure: error: Package requirements (xproto >= 7.0.13) were not met.
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively you may set the XPROTO_CFLAGS and XPROTO_LIBS environment variables
to avoid the need to call pkg-config.  See the pkg-config man page for
more details.

Error: The following dependencies failed to build: ghostscript xorg-libXext xorg-libX11 xorg-libXt xorg-libsm xorg-libice
Error: Status 1 encountered during processing.
[mwlang@macdoze shared] sudo port install ImageMagick
Error: Requested variants do not match original selection.
Please perform ‘port clean ImageMagick‘ or specify the force option.
Error: Status 1 encountered during processing.

Strange, what’s that xproto >= 7.0.13? How odd that a dependency would fail! I tried a sudo port install xproto, but that was a no-go (so don’t bother trying, it’ll fail for you, too). but then I noticed the dependency list (which oddly is missing xorg-xproto) and most of the packages are prefixed with “xorg-”, and tried sudo port install xorg-xproto and thus, was on my way again.

I lie! I lie! I had no clue. I googled “xproto port install” and learned the truth for the real package name that way. However, as it happens, I found the answer on darwinports dot com in a dependency list for xorg-libx11. I casually mentioned this site in the IRC channel and the #macports tenants were very quick to point out was an imposter site, so be wary of anything you read and learn there. Information is liable to be stale while the site owner attempts to lighten your wallet a bit for no good cause. Little did I know!

Final tidbit

Once I got the ports system updated and the xproto package installed, it was a fair breeze to finish with the ImageMagick installation. One last command I learned from the good folks in #macports is to run the following on a frequent basis to keep your macports installation in fair good shape:

sudo port selfupdate && sudo port upgrade outdated

Conclusion

For years, I struggled with ports, and for no good reason. Once I took the time to learn the package management’s commands (along with the help of those in #macports, for which I’m very grateful to them for saving me a few hours of head-scratching), I am finding I’m able to install packages painlessly on the mac and have even tried a couple of others I had problems with in the past and they’re all installing without a hitch. The lesson for me: take the time to learn your tools. It may be slow-going at first, but the rewards always seem to pay back big dividends down the road.

The Problem

I am working on a content management system (CMS) where I want the pages to have a hierarchical structure that turns into a menu with sub-menus. The content manager needs to also be able to order these pages so that the menu structure renders in the desired order.

The Solution

Two plugins jumped to mind almost immediately: acts_as_tree and acts_as_list. The tree plugin will manage the hierarchy, hinging off the parent_id field of the model whilist the list plugin uses the position column to manage the order. What’s unique here is that I have never used both on one model, but doing so was surprisingly easy:

   1  class Page < ActiveRecord::Base
   2    acts_as_tree
   3    acts_as_list
   4  end

Constructing a Hierarchical Menu

Before going too far, if you haven’t seen the Suckerfish menus, yet, please do check out the article as it will help you quickly see how I approached the menu rendering. Secondly, to install the two plugins, its a simple pair of command line calls as follows:

   1  script/plugin install acts_as_tree
   2  script/plugin install acts_as_list

With the CSS handling all the styling, all I needed was to render the nested unordered lists. I began by grabbing all of the pages at the top level (where parent_id is null) with this bit of code:

   1  class Page < ActiveRecord::Base
   2    acts_as_tree :order => :position
   3    acts_as_list
   4 
   5    def self.top_level_pages
   6      find(:all, :conditions => ["parent_id IS NULL"], :order => :position)
   7    end
   8  end

If you noticed the “:order => :position” clause and thought, “but acts_as_list handles that for you,” then you have spotted the first “gotcha” I encountered with using both tree and list on a model. The tree plugin loses the position ordering that the list plugin mixes in and adding these order clauses in preserves the order of the records. With the query to get the top-level menus in place, I set the @pages variable by calling Page.top_level_pages in the controller and then rendered with this call in my view:

   1  <div id="site-navigation">
   2  	<ul>
   3  		<%= render(:partial => "/layouts/site_navigation", :collection => @pages) %>
   4  	</ul>
   5  </div>

To make it all nice and nested, I simply recursively called the same site_navigation partial on the children like so:

   1  <li><%= link_to(site_navigation.name, url_for(site_navigation))  %></li>
   2  <ul><%= render(:partial => "/layouts/site_navigation", :collection => site_navigation.children) %></ul>

To give the user ability to move the menu items around, I added “move_up” and “move_down” actions to the Page Controller in which I called the “move_higher” and “move_lower” methods that are mixed in by the acts_as_list. I realized rather quickly that the position index was getting out of sync and added a reindex method to the Page model to clean up the data along with a scope declaration to the model. Along the way, I also realized that if I moved a page from one parent node to another parent node, I potentially opened a gap in the position index in the collection of Pages and this again breaks the position index sequencing. The acts_as_list mix-in expects the position index to always go [0, 1, 2, 3, ...N]. Whenever this is not the case, the move_higher and move_lower methods stop working and the user interface no longer responds correctly. So this is why we care so much about the position index sequence. So, to handle scoping of the position index sequence correctly and to handle Pages being moved to another parent, we arrive at this final version of the Page model:

   1  class Page < ActiveRecord::Base
   2    acts_as_tree :order => :position
   3    acts_as_list :scope => :parent_id
   4 
   5    before_save :keep_position_sane
   6 
   7    def self.top_level_pages
   8      find(:all, :conditions => ["parent_id IS NULL"], :order => :position)
   9    end
  10 
  11    def self.reindex_top_level_pages(recurse = true, departing_child = nil)
  12      reindex_pages(self.top_level_pages, recurse, departing_child)
  13    end
  14 
  15    def reindex_children(recurse = true, departing_child = nil)
  16      Page.reindex_pages(children, recurse, departing_child)
  17    end
  18 
  19    private
  20 
  21    # takes a given array of pages and recursively (or not) reindexes
  22    # if departing_child is supplied, it is removed from the array so 
  23    # that former siblings are reindexed as though it was already 
  24    # removed from the collection.
  25    def self.reindex_pages(pages, recurse, departing_child)
  26      pages.select{|r| r != departing_child}.each_with_index do |page, index|
  27        page.reindex_children(true) if recurse
  28        page.update_attributes(:position => index + 1)
  29      end
  30      true
  31    end
  32 
  33    # When the parent id of a node changes, the acts_as_list gets lost, so 
  34    # we need to reindex the affected nodes to keep things sane
  35    def keep_position_sane
  36      return unless self.parent_id_changed?
  37 
  38      # reindex the group this page is being removed from
  39      if self.parent_id_was.nil? then
  40        Page.reindex_top_level_pages(false, self)
  41      else
  42        Page.find(self.parent_id_was).reindex_children(false, self)
  43      end
  44 
  45      # make this page the last sibling of the new parent group of pages
  46      last_page = (self.parent_id.nil? ? Page.top_level_pages.last : Page.find(self.parent_id).children.last)
  47      self.position = (last_page.nil? ? 1 : last_page.position + 1)
  48      true
  49    end
  50  end

Check out the “keep_position_sane” callback. You’ll see a nifty application of the new Dirty records feature of ActiveRecord (which I believe was released with Rails 2.2) and was covered by Ryan Diagle in his post,
What’s New in Edge Rails: Dirty Objects. In order to detect that the parent node was indeed changing and which parent’s collection the Page belonged to, I checked the “parent_id_was” value. In this case, I had to handle top level pages being moved into another Page’s collection as well as A sub-page being promoted to top-level.

A Handy Rake Task

If you’re wondering why the recursive parameter and otherwise unnecessarily complex procedures, its because I also added a rake task to recursively reindex all pages in the menu hierarchy:

   1    namespace :pages do
   2      desc "re-index page positions"
   3      task :reindex => :environment do
   4        Page.reindex_top_level_pages
   5      end
   6    end

Conclusion

Rails has really come a long ways since its early days, but its still not without its little “gotchas” and sometimes its tough to uncover silent failures (like with the position order clause not being rendered from the acts_as_list plugin) when mix-ins from different plug-ins are utilized. Hopefully, this article shows you a few new tricks and how to utilize somewhat competing plugins safely within one model. The new Dirty attributes feature of ActiveRecord definitely made the chore of implementing this functionality much easier and sane than it would’ve been back in the Rails 1.x days.

Introducing Ramaze

One I found is Ramaze. I have to say that Ramaze is a very minimalist approach to a framework that is actually rather enlightening. For one coming from a Rails’ world, it can feel a bit sparse at first. But lately, I’m attributing my lack of comfort to being put on my toes to do some actual real Ruby coding. Its both a little scary and liberating at the same time. I have found that I am enjoying Ruby a lot more as a result of my exposure to Ramaze and my thought process is actually radically changing, almost like a Visual Basic programmer going to Borland Delphi might feel.

So I decided to take a hard look at performance metrics between Rails and Ramaze’s. At the same time, I wanted to see how MRI 1.8.7 stacked up against Ruby Enterprise Ed. 1.8.6, so I’m satisfying a dual curiosity herein. Being quite happy with Phusion Passenger, I decided to set things up with Apache 2.2.9 + Passenger + Rails/Ramaze. Since I’m quite comfortable with ERB and ActiveRecord, I tweaked Ramaze to be a bit more like the familiar Rails world I am familiar with.

Un-DRYing the Results

There’s no point in generating a lot of data and reporting on it if others cannot repeat yourself (CRY!) in replicating the results, so with that in mind, I attempt to refrain from further bad turn of words by busying myself in pushing everything I utilized to github.com and documenting the basic bootstrapping of Ubuntu Intrepid. For these tests in particular, I used two scripts, bootstrap-passenger-std.sh and bootstrap-passenter-ent.sh to set up four distinct configurations under the Ruby1.8 interpreter. Ruby 1.9.1. was a bit difficult to set up and there is a bootstrap-passenger-191.sh script that I assembled as I installed things, but I haven’t run it to ensure it works end-to-end.

I utilized this simple call to Apache Bench to run through the four test scenarios:
All data collected was based on 10,000 requests at 100 concurrent users after an initial “warmup” of the passenger threads with start of 100 requests at 10 concurrent users. The following command shows the basic set of parameters issued to Apache Bench:

ab -n 10000 -c 100 http://demo.u64rails01.local/posts

What was tested?

In order to compare, as close as possible, apples to apples, I opted to use Active Record and ERubis in Ramaze to set up the same MVC classes in both the Rails and Ramaze project. ActiveRecord is probably the heaviest weighted ORM that can be utilized with Ramaze. I tried briefly to get Erubis working with Rails so that the two frameworks’ projects would be more closely aligned than the out-of-box ERB rendering Rails ships with would have afforded. I did attempt Erubis with Rails, however, I was either doing something very wrong or Erubis under Rails takes a sizable performance hit and I stuck with out-of-box ERB for these tests given its better performance. As such, Rails uses out of box ERB rendering in these tests.

The application itself is ridiculously simple, offering only one model and performing only a read against the database, but hopefully, an effective start towards building this benchmark framework towards more substantive benchmark tests to come. For now, lets take a look at how Rails and Ramaze stack up to each other and what affect the underlying interpreter can have on performance. Standard packaged Main Ruby Interpreter (MRI) 1.8.7 consisted of simple package install provided by the Ubuntu Intrepid repositories whle Ruby Enterprise Edition (REE) 1.8.6, which hails from the same folks bringing you Phusion Passenger, is compiled from source.

As a bonus, I also compiled and clocked metrics for Ramaze on 1.9.1. This was a tricky environment to get set up and working. And my initial results made me think I did something horribly wrong with compiling and configuring Ruby 1.9.1. However, I fully replicated Antonio Cangiano’s benchmarks in my test environment (see The Great Ruby Shootout (December 2008)) and MRI 1.9.1. did indeed crush the other Ruby interpreters in Fibonacci number crunching (amongst others). The theory tossed around in the Ramaze IRC channel was that 1.9.1. change in implementation of the String class (and it being unicode native now) slows things down a good bit with string processing.

The Results

The following table tabulates the results gathered from Apache Bench as well as passenger-memory-stat. I ran a short run to warm things up (100 requests, 10 concurrently). And then ran the big bench at 10,000 requests, 100 concurrently, and then ran again and recorded the results. At around 5,000 requests, I ran passenger-memory-stat to collect the data during mid-processing and then again at the end. These tests were run on a Ubuntu 64-bit Intrepid 8.10 virtual server that was allocated 1 CPU core and 512MB of RAM. Swap space was never triggered (0k utilization), and CPU utilization was roughly 85% within the Virtual Machine during the test runs. The host machine, which is four core CPU, showed one core busy at near 100% with the other three cores pretty much idle.

Throughput

Everybody likes to talk about throughput, so lets start there. As you can see, MRI and Rails was the worst performer while REE and Ramaze clocked in with the highest throughput in terms of requests per second. Be forewarned that throughput doesn’t necessarily equate to user response times. This metric simply tells you the load at which your system is capable of delivering content at.

Time per Request

Time per request helps you see about how long an average user request takes for a given load. As you can see here, with times in the milliseconds, we’re talking about numbers that will easily be swallowed in the noise of network latency. Even so, its not hard to be impressed by what the REE folks managed to pull out of their hat with regards to performance on the main ruby interpreter.

Memory Consumption

This final graph shows the sizeable dent REE makes in memory consumption for running a Rails application. Ramaze is already pretty efficient and lean and REE made practically no dent in memory consumption here. However, REE’s use of the faster memory allocation routines does have a good effect on boosting Ramaze’s performance (as seen in above graphs), so there’s still lots to be gained by running Ramaze with REE.

Conclusion

For me, I have two very, very viable solutions before me. Rails on Enterprise Ruby or Ramaze on Ruby 1.8.7. The final choice comes down to how much I can bet on my own Ruby prowess. Ramaze is a very lean framework that gets you going, but doesn’t get you a nine inch pillowed mattress topping for your bed like Rails does. Because Ramaze is so lean, I realize I will have to really take my Ruby skills to the next level and truly understand the ruby code that other developers produce. Unlike Rails, where there’s gobs and gobs of plugins and blogs on the topic that make pretty much any need simple to satisfy and get working, I have to know my Ruby to get a solution implemented on Ramaze. Not a bad thing, but certainly a more challenging and potentially rewarding path to take.

Aside from my personal concerns about making the jump, looking at these results, it is good to see that I have options and how easy it is to get a good deployment up and working compared to 3 or 4 years ago when I was banging my head against the wall for days on end to keep lighttpd + fcgi processes up and running around the clock. In these tests, it was very, very satisfying that not one single crash or dropped request was recorded in all the benchmarking I performed. Mongrel came along and made a big impact, but you still needed something like monit to watch Mongrel and restart it on ocvasion. Now Passenger has come along and made yet another big impact in the ease of deploying Rails, Ramaze, or any of the other ruby-based frameworks. We’ve come a long ways, indeed. I, for one, certainly look forward to what the Ruby sphere will bring us over the next couple of years.

Bootstrap Passenger

Begin by Bootstrapping Ubuntu.

The next step is to run the script for installing Passenger. The standard passenger install against the standard Ruby 1.8.7 package managed libraries are installed with the following:

(assuming you’ve downloaded the bootstrap scripts and are in the ~/bootstrap-scripts/ubuntu/intrepid folder already, execute the following script:

./bootstrap-passenger-std.sh

Passenger’s install prompts you two or three times. Simply press and ignore the additional configuration instructions (the bootstrap script carries out these instructions for you).

Set up a demo Rails project

cd /var/www
sudo mkdir rails
cd rails
sudo rails demo
cd ..
chown -R www-data:www-data rails

Set up a Virtual Host Entry

Apache2 on Ubuntu makes it fairly straightforward to set up a provider for the Rails application, simply create the following in /etc/apache2/sites-available/demo:

<VirtualHost *:80>
  ServerName localhost
  DocumentRoot /var/www/rails/demo/public
</VirtualHost>

And then enable the site:

sudo a2ensite demo
sudo /etc/init.d/apache2 reload

End Result

If all goes well, you should then be able to browse to http://localhost and see the rails greet page. Your system will look something like this:

OS: 2.6.27-7-server x86_64 GNU/Linux
Apache: Server version: Apache/2.2.9 (Ubuntu)
Passenger: 2.0.6
Ruby: ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
Rubygems: 1.3.1
gems:
 - actionmailer (2.2.2)
 - actionpack (2.2.2)
 - activerecord (2.2.2)
 - activeresource (2.2.2)
 - activesupport (2.2.2)
 - fastthread (1.0.1)
 - passenger (2.0.6)
 - plist (3.0.0)
 - rack (0.9.1)
 - rails (2.2.2)
 - rake (0.8.3)

Where to go from here?

After you have Passenger working, you may be interested in trying it with the so-called Enterprise version of Ruby which claims 33% memory footprint reduction overall for a typical Rails application. If so, you can flip over to the Enterprise version by running the following bootstrap script:

./bootstrap-passenger-ent.sh

This script will download and compile Enterprise Ruby and install Passenger against this version of Ruby, disabling the standard passenger modules in Apache (if they’re installed as per above) in the process. Does it make any real difference? We shall see! I am benchmarking performance of both standard and enterprise and will be reporting on my findings soon.

• Ubuntu Site: http://www.ubuntu.com
• ISO Image: ubuntu-8.10-server-amd64.iso

If you’re new to my bootstrapping series, please see Bootstrapping my blog for some background information.

Install the OS

No need to beat a dead horse to death. If you need instructions for installing Ubuntu, then please follow Ubuntu’s most excellent guides for installing Ubuntu Server. For my purposes, I install everything to default choices, only choosing to install OpenSSH Server (and no others). Everything else is simply supplying the simple information requested at each prompt in order to get me to the bootstrapping stage most directly.

Bootstrap!

Once the OS is installed and boots for the first time, log in and run the following:

   1  sudo apt-get install git-core
   2  git clone git://github.com/mwlang/bootstrap-scripts.git
   3  cd bootstrap-scripts/ubuntu/intrepid
   4  sh bootstrap.sh

This will install the prerequisite git commands and check out the bootstrap-script repository and then run through upgrading the Ubuntu server and install the build-essentials.

That’s it! You can now return to the article that brought you here.

Nice, but what is this all about?

Bootstrapping is just that. Getting the bare minimum components installed so that you can proceed to do more complicated tasks. Rather than writing things over and over, I scripted them and checked them into git repository and then refer to them, hopefully much to your gain (as well as my sanity).

Depending on where you want to go with your server instance, you can run any of the other bootstrap scripts in the folder. For example, to install Ruby 1.8.7 from packages (not source) and install Apache2 and Passenger and Rails, run the following script:

   1  sh bootstrap-passenger-std.sh

You’ll need to hit the key a couple of times when passenger’s installer runs, but otherwise, should run start-to-finish, installing everything without any further action on your part to get a fully functioning Apache2 + Passenger + MRI Ruby 1.8.7 + Rails stack installed.

Be careful, though. I didn’t put any dependency checks around these scripts. Its fairly safe to run any of the bootstrap-XXX.sh scripts without running anything else (these scripts do call the main bootstrap.sh script listed above). But several scripts, such as rails.sh do indeed have prerequisites and you will have issues running these out of order. Also, bootstrapping is targeting specific outcomes. Don’t expect to run one bootstrap-XXX.sh script and then run another. They are very likely to collide with undesirable outcomes.

Documentation will be fairly sparse in the git repository, with the intent to spell things out in the accompanying blog articles.

For me personally, I get downright tired of writing the same thing over and over. Like my code, I want my blogging efforts to be efficient and DRY. Since I work extensively with virtual machines to maintain an orderly environment in a known state, I figured it makes just as much sense to document by establishing a git repository that contains all my bootstrap scripts and configuration scripts needed to get things installed. Whether you use bare metal or virtual machines, you are now empowered to fully recreate the environments I discuss in my posts.

Now, rather than constantly regurgitating basic setups in a sort of preamble to the topic I wish to discuss, I will simply link to my Setup specific articles to get you going and then dive straight into the topic at hand.

It all begins with you establishing your basic out-of-box instance, installing git, then pulling the bootstrap scripts down from my bootstrap-scripts repository.

The three environments I intend to discuss most (at this time) is Ubuntu 8.10 (Intrepid), CentOS 5.2, and Leopard OS X. I will not give each of these equal coverage with respect to bootstrapping as I am presently only bootstrapping Ubuntu on a regular basis (and I haven’t reinstalled Leopard in ages). However, when I do bring up any new environments, I will make a full effort to fully document bootstrapping that environment and push to git. For now, you can expect Ubuntu Intrepid to be my most well-documented environment.

Please keep in mind: These are very simple scripts, highly targeted at the environment they’re written for. They’re not meant to do the job one might employ capistrano or puppet for. I know what I want my target environment to be and I aim straight at it with these scripts. Also, the repository will be organized atypically for preserving history rather than for merging commits into a well-maintained master branch.

All articles dealing with operating system and package installs will be filed under the Setups category and, if appropriate, the pertinent sub-category.

Another drawback I have with Google Syntax highlighter is that the page renders without highlighting and then all the code listings change to syntax highlighted text a few moments later.

Introducing Ultraviolet, a syntax highlighter supporting over 50 syntaxes and any TextMate theme.  Ultraviolet is based on Oniguruma, a regular expression library that comes standard with Ruby 1.9. Ultraviolet requires a little more effort for me to cut and paste, but I am definitely much happier with the end results and Wordpress no longer mungs my posts. Only real complaint I have is that I can’t read the posted code inline in HTML format (but I can read it in Visual mode!).

Ruby Script

   1  require ‘rubygems‘
   2  require ‘ramaze‘
   3  require ‘maruku‘
   4  require ‘sequel‘
   5 
   6  $LOAD_PATH.unshift(__DIR__)
   7 
   8  require ‘env‘
   9 
  10  require ‘vendor/flickr‘
  11  require ‘vendor/haml_maruku_filter‘
  12  require ‘vendor/image_science_cropped_resize‘
  13 
  14  require ‘model/init‘
  15  require ‘controller/init‘
  16 
  17  require ‘db/init‘ if SOCIAR.mode == :dev
  18 
  19  r = SOCIAR.ramaze
  20 
  21  =begin
  22  if r.gzip
  23    require ‘ramaze/contrib/gzip_filter’
  24    gzip = Ramaze::Filter::Gzip
  25    gzip.trait :threshold => 1
  26    Ramaze::Dispatcher::Action::FILTER << gzip
  27  =end
  28 
  29  Ramaze.start :adapter => r.adapter,
  30               :host => r.host,
  31               :port => r.port,
  32               :boring => r.boring

Shell Script

   1  #!/bin/sh
   2 
   3  ### BEGIN INIT INFO
   4  # Provides:          lm-sensors
   5  # Required-Start:    $local_fs
   6  # Required-Stop:
   7  # Default-Start:     S
   8  # Default-Stop:
   9  # Short-Description: lm-sensors
  10  # Description:       hardware health monitoring
  11  ### END INIT INFO
  12 
  13  . /lib/lsb/init-functions
  14 
  15  [ -f /etc/default/rcS ] && . /etc/default/rcS
  16  PATH=/bin:/usr/bin:/sbin:/usr/sbin
  17  PROGRAM=/usr/bin/sensors
  18 
  19  test -x $PROGRAM || exit 0
  20 
  21  case "$1" in
  22    start)
  23  	log_begin_msg "Setting sensors limits"
  24  	if [ "$VERBOSE" = "no" ]; then
  25  		/usr/bin/sensors -s 1> /dev/null 2> /dev/null
  26  		/usr/bin/sensors 1> /dev/null 2> /dev/null
  27  	else
  28  		/usr/bin/sensors -s
  29  		/usr/bin/sensors > /dev/null
  30  	fi
  31  	log_end_msg $?
  32  	;;
  33    stop)
  34  	;;
  35    force-reload|restart)
  36  	$0 start
  37  	;;
  38    *)
  39  	log_success_msg "Usage: /etc/init.d/sensors {start|stop|restart|force-reload}"
  40  	exit 1
  41  esac
  42 
  43  exit 0

Apache Config

   1  <VirtualHost *:80>
   2  	ServerName www.stinger.local
   3  	ServerAdmin webmaster@localhost
   4 
   5  	DocumentRoot /var/www/
   6  	<Directory />
   7  		Options FollowSymLinks
   8  		AllowOverride None
   9  	</Directory>
  10  	<Directory /var/www/>
  11  		Options Indexes FollowSymLinks MultiViews
  12  		AllowOverride None
  13  		Order allow,deny
  14  		allow from all
  15  	</Directory>
  16 
  17  	ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
  18  	<Directory "/usr/lib/cgi-bin">
  19  		AllowOverride None
  20  		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  21  		Order allow,deny
  22  		Allow from all
  23  	</Directory>
  24 
  25  	ErrorLog /var/log/apache2/error.log
  26 
  27  	# Possible values include: debug, info, notice, warn, error, crit,
  28  	# alert, emerg.
  29  	LogLevel warn
  30 
  31  	CustomLog /var/log/apache2/access.log combined
  32 
  33      Alias /doc/ "/usr/share/doc/"
  34      <Directory "/usr/share/doc/">
  35          Options Indexes MultiViews FollowSymLinks
  36          AllowOverride None
  37          Order deny,allow
  38          Deny from all
  39          Allow from 127.0.0.0/255.0.0.0 ::1/128
  40      </Directory>
  41 
  42  </VirtualHost>

Environment

This post will guide you through setting up the following environment on Ubuntu Intrepid (8.10):

• Apache 2.2.9
• Passenger 2.0.6
• ActiveRecord 2.2.2
• Ramaze 2009.01
• Erubis 2.6.2
• MySql 5.0.67 (assumed installed)

To get started:

sudo apt-get install apache2 passenger
sudo passenger-install-apache2-module

Install the Rack, Ramaze, Activerecord, and Erubis gems

sudo gem install rack, ramaze, activerecord, erubis

Establishing Project

Now create your first ramaze project with:

ramaze --create demo

Then change to the demo directory. If you see a start.ru file, rename it to config.ru or Passenger won’t find it. Create a file called passenger.rb with the following:

require 'rubygems'
require 'ramaze'

# Add directory start.rb is in to the load path, so you can run the app from
# any other working path
$LOAD_PATH.unshift(__DIR__)

# Initialize controllers and models
require 'controller/init'
require 'model/init'

Ramaze::Global.sourcereload = false
Ramaze::Global.sessions = true
Ramaze::Log.ignored_tags = [:debug, :info]

Important: Do not include “Ramaze.start …” in this file or this will surely mess things up for Passenger.

Now edit the config.ru file (formerly start.ru):

/usr/bin/env rackup
# start.ru for ramaze apps
# use thin>=0.6.3
# thin start -r start.ru
#
# rackup is a useful tool for running Rack applications, which uses the
# Rack::Builder DSL to configure middleware and build up applications easily.
#
# rackup automatically figures out the environment it is run in, and runs your
# application as FastCGI, CGI, or standalone with Mongrel or WEBrick�..all from
# the same configuration.

require 'app'
Ramaze.trait[:essentials].delete Ramaze::Adapter
Ramaze.start
run Ramaze::Adapter::Base

Add the following virtual host file to /etc/apache2/sites-enabled/001-ramaze-demo

<VirtualHost *:80>
    ServerName ramaze.demo.local
    RackBaseURI /
    RailsAutoDetect off
    RackAutoDetect on
    DocumentRoot /var/www/ramaze/demo/public
</VirtualHost>

And edit your /etc/hosts file to include “ramaze.demo.local” so it resolves to localhost.

Database

Next, create a database called ramaze_demo (or your choice) and add a posts table and
some data via SQL or migrate scripts (this being a minimal demonstration and all that).

create table posts (
    id        int(11) not null auto_increment
  , title     varchar(255) not null
  , body      varchar(1024) not null
  , primary key (id)
);

insert posts values (1, "First Post", "Thank hrnt for getting passenger talking to ramaze.");
insert posts values (2, "Another Post", "Ask Pistos what SelfMarks is, because he is bored with diigo");
insert posts values (3, "IRC, you say?", "Visit #ramaze on Freenode");

Model

Edit the model.init.rb file with the following:

require 'activerecord'
require 'cleanup_connection_patch'

  ActiveRecord::Base.establish_connection(
    :adapter  => "mysql",
    :database => "ramaze_demo",
    :host     => "localhost",
    :username => "root",
    :password => "secret"
  )

class Post < ActiveRecord::Base
end

Important: cleanup_connection_patch comes from github.com and makes the ActiveRecord behave correctly in a threaded environment. Please see Monkey patching ActiveRecord to automatically release connections « coderrr for more information.

Controller

With the model squared away, time to turn our attention to the controller. Edit controller/init.rb:

class Controller < Ramaze::Controller
  layout '/page'
  helper :xhtml
  engine :Erubis
end

class PostsController < Controller
  def index
    @posts = Post.find(:all)
  end
end

View

Create a folder under view for posts and add the following Erubis template view/posts.rhtml:

<h1>Listing Posts</h1>

<ul>
  <% for post in @posts %>
      <li><%= A(post.title, :href => "/post/#{post.id}", :title => post.body) %></li>
  <% end %>
</ul>

Note: that while Rails uses filename.html.erb, the Erubis engine expects *.rhtml extension in Ramaze.

Running

Test out the above with webrick, mongrel, or thin with:

ruby start.rb

If all goes well, you should see the three postings above listed.

Launch Apache2, if you haven’t already and point your localhost’s browser at http://ramaze.demo.local/posts

You should now have a listing of posts rendered through Apache via Passenger.

Conclusion

I am finding much to like about Ramaze, especially after developing with Rails for a few years now and watching it grow at an alarming rate in complexity. Ramaze is a refreshing return to basics. I am finding that Ramaze just may be able to give me most of what I need while giving me a sizeable performance boost in the process. Here’s a rails bench on the equivalent of the above:

Concurrency Level:      50
Time taken for tests:   4.277 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      10218492 bytes
HTML transferred:       9595000 bytes
Requests per second:    233.83 [#/sec] (mean)
Time per request:       213.828 [ms] (mean)
Time per request:       4.277 [ms] (mean, across all concurrent requests)
Transfer rate:          2333.42 [Kbytes/sec] received

And this is Ramaze:

Concurrency Level:      50
Time taken for tests:   2.248 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      9815000 bytes
HTML transferred:       9555000 bytes
Requests per second:    444.91 [#/sec] (mean)
Time per request:       112.383 [ms] (mean)
Time per request:       2.248 [ms] (mean, across all concurrent requests)
Transfer rate:          4264.42 [Kbytes/sec] received

Elemental provides enumerated collection of elements that allow you to associate ruby symbols to arbitrary “display” values, thus allowing your code to think symbolically and unambiguously while giving you the means to easily display what end-users need to see. Additionally, symbols are associated with ordinal values, allowing easy storage/retrieval to persistent stores (databases, files, marshalling, etc) by saving the  Element#value as appropriate (String by default, Fixnum if you “persist_ordinally”).

The primary aim of Elemental is to collect and abstract literals away from your code logic. There’s an old programmer’s wisdom that you should not encode your logic using literal values, especially those the end-user is exposed to.

Complete details provided in README.txt

http://github.com/mwlang/elemental/tree/master
http://rubyforge.org/projects/elemental/

From Gem:

sudo gem install elemental

From Source:

gem install bones, rake, test-unit
git clone git://github.com/mwlang/elemental.git
cd elemental
rake gem:package
cd pkg
sudo gem install elemental

Example of Using:
Here’s an example of how Elemental might be used with a Rails application. In your ~/config/initializers/elementals.rb file:

require 'elemental'

class PublicStatus
  extend Elemental

  member :unpublished,      :display => "Not Published", :default => true
  member :editor_approval,  :display => "Editorial Approval Needed"
  member :published,        :display => "Published"
  member :archived,         :display => "Archived"
end

class CommentType
  extend Elemental
  persist_ordinally

  member :all,        :display => "Anyone can post"
  member :moderated,  :display => "Moderated", :default => true
  member :closed,     :display => "Closed to new posts"
end

Create a “posts” table with this migration:

class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts do |t|
      t.string :title
      t.text :body
      t.string :public_status
      t.integer :comment_type

      t.timestamps
    end
  end

  def self.down
    drop_table :posts
  end
end

In your ~/app/views/posts/edit.html.erb:

<h1>Editing post</h1>

<% form_for(@post) do |f| %>
  <%= f.error_messages %>

  <%= render :partial => 'form' %>

  <p>
    <%= f.submit "Update" %>
  </p>
<% end %>

<%= link_to 'Show', @post %> |
<%= link_to 'Back', posts_path %>

Similarly for ~/app/views/posts/new.html.erb

<h1>New post</h1>

<% form_for(@post) do |f| %>
  <%= f.error_messages %>

	<%= render :partial => 'form' %>

  <p>
    <%= f.submit "Create" %>
  </p>
<% end %>

<%= link_to 'Back', posts_path %>

An form partial that utilizes the Elemental classes above to populate a pair of drop down lists:

<p>
	<label>Title</label><br />
	<%= text_field :post, :title, :value => @post.title %>
</p>
<p>
	<label>Body</label><br />
	<%= text_area :post, :body, :value => @post.body %>
</p>

<p><label>Public Status</label><br />
  <%= select "post", "public_status",
    PublicStatus.sort.map{|a| [a.display, a.value]},
      { :include_blank => false, :selected => PublicStatus.defaults.first.value }
  %></select>
</p>

<p><label>Comment Type</label><br />
  <%= select “post”, “comment_type”,
    CommentType.sort.map{|a| [a.display, a.value]},
      { :include_blank => false, :selected => CommentType.defaults.first.value }
  %></select>
</p>

An example ~/app/views/posts/index.html.erb file:

<h1>Listing posts</h1>

<table border=1 cellpadding=5px>
  <tr>
    <th>Post</th>
    <th>Public status</th>
    <th>Comment type</th>
    <th colspan=3>Actions</th>
  </tr>

<% for post in @posts %>
  <tr>
    <td><%= link_to post.title, post, :title => post.body %></td>
    <td><%=h PublicStatus[post.public_status].display %></td>
    <td><%=h CommentType[post.comment_type].display %></td>
    <td><%= link_to ‘Show’, post %></td>
    <td><%= link_to ‘Edit’, edit_post_path(post) %></td>
    <td><%= link_to ‘Destroy’, post, :confirm => ‘Are you sure?’, :method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to ‘New post’, new_post_path %>

My System

2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 11:57:43 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

The Problem

If you simply execute:

sudo gem install mysql

You’ll get the following errors on a 64-bit system:

$ sudo gem install mysql
Building native extensions.  This could take a while...
ERROR:  Error installing mysql:
        ERROR: Failed to build gem native extension.

/usr/local/bin/ruby extconf.rb install mysql
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/usr/local/bin/ruby
        --with-mysql-config
        --without-mysql-config
        --with-mysql-dir
        --without-mysql-dir
        --with-mysql-include
        --without-mysql-include=${mysql-dir}/include
        --with-mysql-lib
        --without-mysql-lib=${mysql-dir}/lib
        --with-mysqlclientlib
        --without-mysqlclientlib
        --with-mlib
        --without-mlib
        --with-mysqlclientlib
        --without-mysqlclientlib
        --with-zlib
        --without-zlib
        --with-mysqlclientlib
        --without-mysqlclientlib
        --with-socketlib
        --without-socketlib
        --with-mysqlclientlib
        --without-mysqlclientlib
        --with-nsllib
        --without-nsllib
        --with-mysqlclientlib
        --without-mysqlclientlib

Gem files will remain installed in /usr/local/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection.
Results logged to /usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out

After digging into the gem options and logs a bit and looking at where mysql actually got installed, I discovered that it was hitting all the locations the 32-bit version would normally install to, but not the 64-bit version, which ends up in /usr/lib64/mysql.

Installing the Ruby gems

To properly install the Ruby gems for mysql, you’ll have to explicitly tell the gem where the mysql config is and it will then handle all the rest.

gem install mysql -- --with-mysql-config=/usr/lib64/mysql/mysql_config

With that, you should see the following:

Building native extensions.  This could take a while...
Successfully installed mysql-2.7
1 gem installed

Check it out with:

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'mysql'
=> true
irb(main):003:0> quit

Life is good.