Empty Thoughts

This blog is moving to blog.michaeltrier.com. No real reason except that I’m trying to consolidate some things. Please change your subscriptions accordingly.

Django on Gentoo (DoG) Linux image. This is built on the base Gentoo image that I posted about previously . I added a whole bunch of goodness to run Django. Included are a whole set of startup scripts that build up the system and initialize the application.

AMI ID: ami-29947140
AMI Manifest: eminent-ami/django/10/image.manifest.xml

About this AMI

This image contains a Gentoo Linux 2007.0 installation with Django application support. The following applications / libraries are installed and/or configured:

• Gentoo Linux
  • dhcpcd,
  • logrotate,
  • all packages are recent and updated,
  • AMI tools have been installed and are fully working even for volume imaging,
  • EC2 meta-data is fetched from 169.254.169.254 into /var/spool/ec2/meta-data,
  • EC2 meta-data and user-data include files in /var/spool/ec2/meta-data and /var/spool/ec2/user-data respectively,
  • Disabled password authentication in /etc/ssh/sshd_config
  • Modifications to startup according to Amazon documentation
  • the portage tree has been bind-mounted to /mnt/usr/portage to preserve space on the root file system,
  • the /tmp directory has been bind-mounted to /mnt/tmp to preserve space,
  • the /var/lib/postgresql directory has been bind-mounted to /mnt/var/lib/postgresql,
  • the root home directory contains a dev-copy directory that is needed to build the volume images,
  • all packages have been recompiled to correctly respect the Xen environment.

• Django
  • Apache 2.2.4 installed (not in startup) and configured with Python support,
  • Python 2.5.1,
  • mod_python,
  • Postgresql 8.2.4 (not in startup),
  • psycopg2
  • Subversion 1.4.3 (no repositories are setup)
  • Django trunk version checked out into /home/django/django and installed as normal into the Python site-packages directory (django-admin.py copied to /usr/local/bin/),
  • Support packages: libjpgeg, zlib, freetype2, zip, and unzip,
  • Python packages: PIL 1.1.6, FeedParser 4.1, Markdown 1.6, Unipath 0.1,

• This image contains the following daemons / services:
  • local
  • net.eth0 / net.eth1
  • netmount
  • dhcpcd
  • sshd
  • syslog-ng
  • vixie-cron
  • apache 2 (disabled by default)
  • postgresql (disabled by default)

Sample Application

The instance can accept a set of user data parameters for setting up an application. I’ve provided a default application to indicate the process for creating your own application setup scripts. If you run the instance with the following parameters it will startup a complete running default application based on the Django Vote tutorial.

ami-29947140 -k gsg-keypair -d "app=mysite-setup=http://s3.amazonaws.com/eminent-ami/mysite-setup.tgz"[/code]Once the server is up and running you should be able to to enter the public hostname (starts with ec2) into your browser and view the application. The Admin section of the application is in the location /admin. Credentials are:

Username: admin
Password: password

The default application will be installed into the /home/django/mysite directory. The setup scripts for the application will get installed into /opt/mysite-setup. The Admin media directory and the mysite media directory are both symbolically linked to the /var/www/mysite/htdocs directory.

Postgresql Configuration

Postgresql is installed but there is no database setup and the service is not started by default. The database directory /var/lib/postgresql is bind mounted to /mnt/var/lib/postgresql. The configuration files have been configured according to the Gentoo Postgresql How-To (http://gentoo-wiki.com/HOWTO_Configure_Postgresql) document with the included logging changes. Configuration files are symbolically linked in from /etc/postgresql for those that like that sort of thing. A sample of creating and restoring the database can be found in the mysite-setup scripts for the Sample Application. Write Ahead Logging (WAL) is not implemented, but would be necessary implementation detail for most sites.

Creating an Application Setup Package

The mysite-setup package (http://s3.amazonaws.com/eminent-ami/mysite-setup.tgz) is the base requirements for your own application setup package. At a minimum you are required to have a bin directory with a file in it called setup.sh. Within the setup.sh script you are free to put any setup instructions you need or pass those tasks off to other scripts written in the language of your choice.

Currently the configuration of this image requires that the application setup package is publicly available and downloadable via curl (see the application-setup.sh script). I plan to add security implementation details in the future.

Thanks

Grateful thanks to Geert Bevin for his initial Gentoo image.

Special thanks to RightScale for ideas and guidance provided by their startup scripts

For the past several months I’ve been head down learning Python and Django. Why you ask? Well I believe in using the right tool for the job. I’m working on a new project that Django lends itself to. Could I have written it in Rails? Sure, probably. But it wouldn’t be the best choice. I’m all about being pragmatic, and always looking for an opportunity to learn something new. So Django it is!

As with learning most new things, I was first faced with a lot of frustration in the beginning. I kept saying things like, “That’s stupid.” Or, “Why did they do it that way?” But it didn’t take me long to begin to appreciate the beauty of Django and Python. There were even moments were I found myself sitting back and just laughing in amazement at all that’s there. It is quite elegant, and I look forward to continuing my journey.

Anyway, if you start seeing Django related posts, that’s why. I’m still writing a lot of Ruby code, and still enjoy its elegance. But Django is my newfound love, and it’s what I’m eating and breathing these days.

There’s been some buzz lately about Hobo, a plugin extension to the Rails framework that makes it easy to do rapid prototyping of web applications. You can find out about all of the features at the HoboCentral website. One exciting feature is the implementation of DRYML, a way of drying up your views and providing extendable tag libraries.

Check out the screencasts. They’re very well done. I haven’t been this stunned by a screencast since I saw the original DHH Rails screencast. It’s exciting times.

I was trying to spec out a few of my controllers that had actions on them requiring authentication. After jumping through many mind hoops to figure out how to stub them out properly I asked the RSpec-Users list and received this solution from Graeme Nelson:

def mock_user_authentication(allow_user_to_pass=true)       
  controller.stub!(:login_required).and_return(allow_user_to_pass)
end

It’s elegantly simple and works well. I’m still fumbling around with this RSpec stuff and did not realize I could stub out a method directly on the controller. This has cleared up a big missing piece in my thinking.

Ryan Bates provides an excellent collection of Ruby on Rails screencasts for free. If you have a couple of minutes, literally, please check out what he’s put together.

Some time ago I had envisioned producing something similar, but in no way could I have even come close to this. Ryan really nails it, with high production quality and keeping it concise. Show him some love.

The fine folks developing Slate, a content management system for Rails, have just released a Textile Editor plugin. This works well in conjunction with Err the Blog’s acts_as_textiled plugin.

If you find yourself having to navigate LDAP structures, Softerra has a very nice freeware version of an LDAP Browser. It is a lightweight alternative to their pay for product Softerra LDAP Administrator. It only works on Windows OS.

After months of waiting patiently, I was finally informed that my elastic cloud account was available. If you’re not familiar with all of the cool things Amazon Web Services is doing, I recommend you spend some time getting acquainted with their offerings. I’ve been using S3, their storage solution, for some time now, and I’m definitely stoked about playing around with EC2. This on the heals of Jesse Newland’s announcement of Capazone, a Capistrano task library for managing EC2 servers. Like I needed one more thing to distract me from all the projects I should be working on.

ActiveReload, a new company by Justin Palmer and Rick Olson (of Mephisto fame), just announced the release of Lighthouse. Lighthouse is a simple and elegant issue tracking software as a service application. Signup for free account and give it a whirl.

Subscribing to the RSS Change Log feed to the Subversion repository for Ruby on Rails is a great way to stay on top of what’s going on in Rails land and helps to give you a leg up on the types of things that are coming down the pipe. Today I saw Changeset 6485 and it was quickly blogged about by Dave Thomas. This changeset removes the use of the semicolon in RESTful routes and reverts it back to the old slash way of indicating sub resource intent. What this means is that a route like:

/categories/1;edit

will now become (or should I say become once again)

/categories/1/edit

In addition we get niceties like:

/categories/recent
/categories/1/stamp

I’ve never liked having the semicolon in the url; it just smelled of ugliness. I think we’ll find that this change is a good one and one that allows us to have the benefit of RESTful urls while still allowing for legitimate variations on that theme to support sub resources.

I just spent about an hour trying to figure out why none of my RESTful routes were working properly within my RSpec controller specs. In my controller I had some boilerplate code like this:

# POST /categories
# POST /categories.xml
def create
  @category = Category.new(params[:category])

  respond_to do |format|
    if @category.save
      flash[:notice] = 'Category was successfully created.'
      format.html { redirect_to category_url(@category) }
      format.xml  { head :created, :location => category_url(@category) }
    else
      format.html { render :action => "new" }
      format.xml  { render :xml => @category.errors.to_xml }
    end
  end
end

The line causing the problem was:

redirect_to category_url(@category)

I kept receiving an error on the eval of category_url with an error description of “can’t convert Fixnum into String”.

I tried replacing @category with @category.id to see if I would get different results. The error went away but the test failed indicating that the id returned from the @category instance was not the same as I was expecting. This led me to determine that I needed to stub out the id property on my class. So I added the following to my setup:

@category.stub!(:id).and_return(1)

Everything worked. Problem solved. But wait, that’s ugly and smells of something wrong. I should be able to just pass the object to the category_url and have it return the correct value. What I did next was go down a rat hole trying to figure out what the named route was sending to the object to get the id. I had assumed id, but in fact it’s to_param, which I had already stubbed out as follows:

@category = mock_model(Category, :to_param => 1)

So what’s the problem? It turns out that to_param must return a string. Makes sense. I changed it to the following and everything worked perfectly:

@category = mock_model(Category, :to_param => "1")

It’s little things like this that make learning so much fun. This issue is really indicative of a much bigger problem—my lack of understanding mocks and stubs. But, I’ll have more to write about this later.

I’ve really been enjoying Dave Thomas’ PragDave blog series on Writing a Book. In this series of posts Dave Thomas gives some guidance for those whom desire to write a book, or may be in the process of writing a book.

A long time ago in another life I was very close to accepting an agreement to write a book for Jeff Duntemann’s now defunct publishing company The Coriolis Group. Due to a lot of circumstances, mostly personal, I decided not to do it. It was the right decision at the time, but I have nonetheless thought about writing a book ever since. Perhaps someday the opportunity will present itself once again, and I’ll have both the time and the right life situation to follow through with it.

If writing a book is something you’ve thought about or posted on your list of 43 Things, take advantage of Dave Thomas’ helpful notes.

It’s that time of year again. Yes, when we all have the privilege of calculating how much money we get to fork over to Uncle Sam. But, it’s also a nice annual reminder, for those of us that have the privilege of programming in Ruby, that we are the fortunate ones. Last year at this time someone on the Ruby-Talk mailing list suggested that individuals that made their livelihood by programming in Ruby, should do something to benefit the community at large. And, I agree.

So if you’re wondering what to do, how you can help out, in what way you can give back, wonder no more. There are many ways to help out. In the Rails community there are individuals like Jamis Buck devoting a significant amount of time to produce in-depth quality documentation on the internals of Rails. Drop a dime in his tip jar next time you think of it. But Jamis isn’t the only one. There are many other individuals out there that are working hard, contributing to open source projects, and lending a hand in general. Feel free to Pay it Forward.

Perhaps you should consider giving a donation to Ruby Central, Inc. If you don’t know who Ruby Central is, it’s a non-profit organization founded to support Ruby internationally. Ruby Central is run by Chad Fowler, David Black, and Rich Kilmer. They are responsible for putting on the annual International Ruby Conference, the Rails Conference, and several regional conferences as well. At RubyConf 2006 in Denver, Colorado a participant asked Matz how the community at large could best support the development of Ruby and the team that is working on the future of Ruby. Matz replied that he thought the best way to support Ruby was to support Ruby Central, the public international voice for Ruby. Sounds good to me.

Last year I made a commitment to donate a portion of the money I made from writing Ruby code to support the Ruby community at large. Why don’t you join me and together we can do our part to keep programmers writing happy code.

As I indicated in a prior post I’m beginning to wrap my head around Rspec and use it in a new project that I’m working on. I recently came across a post where someone had written something similar to the following, indicating a spec for has_many and belongs_to in a model.

context "A Category with fixtures loaded" do
  fixtures :listings, :categories

  specify "should have many Listings" do
    l = categories(:cars).listings
    l.should_not be_nil
    l.should_not be_empty
    l.first.should be_an_instance_of Listing
  end
end

One of the comments to the blog post was critical of this approach suggesting that this spec was validating Rails code and that the author should focus only on code that he / she has written. I’ve seen this argument several times in the past and this issue actually came up briefly in the Advanced Rails Training course in Chicago.

While I agree that you shouldn’t be testing Rails code, that’s not what is going on here. The spec is for the existence of the defined relationships within the model, and that things are wired up properly to enable accessing the relationship properly within the model. If someone were to inadvertently remove the has_many method call in the model the spec would fail, which is exactly the behavior we want.

Secondly, even if we were testing Rails code, I think it’s better to error on the side of overcoverage than to not write tests at all. It is important that developers are not so overwhelmed with the “right” or “wrong” way to do testing that testing is not done at all.

The above code actually comes from a project I’m working on. This blog post aside, if you have recommendations on how it should be done differently, please let me know.