So what?

Well, you can use the global variable DATA to get the contents of what you wrote after the __END__ block. DATA is actually a File object to just that piece of text in your script.

How about a little sample to make things a little clearer?

#!/usr/bin/env ruby
%w(yaml pp).each { |dep| require dep }

obj = YAML::load(DATA)

pp obj

__END__
---
-
  name: Adam
  age: 28
  admin: true
-
  name: Maggie
  age: 28
  admin: false

So with this, I was able to embed a little bit of YAML directly into my script. I added the YAML after __END__. YAML::load will accept a File object, so I just passed it DATA and now I have a reconstituted array.

Maybe that’s not the most practical use of this information; however, Sinatra provides a really awesome use of this.  With Sinatra, you can create a whole web application that lives in one single, solitary ruby file.  Sinatra can use in-file templates.  In-file templates are added into the space after __END__ where each view file is annotated with @@view_name.

require 'rubygems'
require 'sinatra'

get '/' do
  haml :index
end

__END__

@@ layout
%html
  = yield

@@ index
%div.title Hello world!!!!!

Not bad for a useless trick!

Prerequisites

Now I don’t want to go too deep into this, so I’m going to assume that if you are reading this, that you have the following installed

• Mac OS Developer’s Tools
• MacPorts
• Ruby (comes with Leopard)
  • Ruby Gems (also comes with Leopard)

So now that you have all of those dependencies out of the way, let’s get to installing us some PostgreSQL.

PostgreSQL

To install the database software, simply run the following command in Terminal

sudo port install \
  postgresql83 \
  postgresql83-server

This will install the client and server needed for you to run this on your machine. Now pay special attention to the installation script. At the end of installation processes, macports will display a message for you that contains some commands for you to get started with.

Configuration

First, execute these lines of code. This will setup a new database for you to play with

sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb'

Start PostgreSQL Automatically

By running the next command, you can have PostgreSQL lunch automatically so that it’s always available to you

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist

pgAdmin III

pgAdmin III is a PostgreSQL management and administrations piece of software. It’s a nice GUI to some things that you may find yourself wanting to do, like created databases and whatnot. Installation of this is pretty cake.

sudo port install pgAdmin3

Upon completion of installation, you can find the application in /Applications/MacPorts/pgAdmin3

PostgreSQL Libraries for Ruby via Gems

I have to admit, the previous installation steps were nothing to cry about; however, it was this step that made me want to put together this little walkthrough.

sudo env ARCHFLAGS="-arch i386" \
  gem install postgres -- \
  --with-pgsql-lib=/opt/local/lib/postgresql83 \
  --with-pgsql-include=/opt/local/include/postgresql83

That’s not exactly your everyday gem install command. For one, the environment variable ARCHFLAGS has to be set. Secondly, the gem command needs to know where the PostgreSQL libraries and include headers are so that it can compile. Looking back, it’s actually quite easy to copy and paste that command, it just took me a while to find out exactly what I needed to make it work.

Fin

Well, I hope that helps anyone looking to install and setup PostgreSQL in Leopard. Until next time…

Why Rack

Well for one, it’s light weight. So if you want to deploy your ruby script using CGI, you can do that with Rack.

But let’s say, you want to your script to Mongrel, or WEBRick, or FCGI; you can do that too, and with very few changes to your script. That’s because Rack abstracts all the boilerplate code you would need to work with those servers and bundles it up into a nice interface for you to use.

Oh, and the code to use Rack is very easy. Here’s an example of a Rack app for you:

Examples

%w(rubygems rack haml).each { |dep| require dep }

class IndexPage
  def call(env)
    haml_engine = Haml::Engine.new(File.read('../templates/index.haml'))
    [
      200,
      { "Content-Type" => "text/html" },
      haml_engine.render(Object.new, {})
    ]
  end
end

Rack::Handler::CGI.run(IndexPage.new)

The secret behind Rack is that it will run any ruby object that has a call method and pass in the environment variables to it. In that environment variable, you will find things like HTTP_HOST, or QUERY_STRING, and the like.

If you wanted to have this script now work with WEBRick, no problem.

# Same code as above, with just a little tweak to the last line

Rack::Handler::WEBRick.run(IndexPage.new, :Port => 3000)

Tada! So now you can run a test server without worrying about setting up Apache or Lighttpd.

More Goodness

To make your life easier, Rack also comes with a set of middleware for you to use. Say you have an error in your application. Perhaps you would like to see that error formatted nicely in your browser. You can enable Rack::ShowExceptions. Perhaps you would like the code you have to be reloaded from the server whenever it changes, like when you’re developing your application, then you can use Rack::Reloader.

To use those options, you can write your Rack handler like

app = Rack::Builder.new do
  use Rack::CommonLogger  # apache-like logger
  use Rack::ShowExceptions
  use Rack::Reloader
  use Rack::ShowStatus  # create default pages for common HTTP error codes
  use Rack::Lint  #ensures all applications behave validly
  run Index.new
end
Rack::Handler::WEBRick.run(app, :Port => 3000)

There’s plenty of magic going on with Rack; A magic that does not sacrifice speed and/or flexibility. I would highly recommend giving Rack a look into the next time you want to write a simple web page.

Since you’re using CGI, you don’t _have_ to worry about setting up FCGI, or Mongrel. You can use mod_ruby if you’re using Apache or cgi with Lighttpd.

So now that servers are out of the way, time for some code.

I mentioned that you don’t have to give up HAML. So for that, I propose this little directory structure.

mysite/
   |- templates/
   `- public/

Hopefully you guessed that templates contains your HAML templates and public is the webroot for your site. Now in your public directory, create an index.rb file, and perhaps it could somewhat look like:

require 'rubygems'
require 'haml'
require 'cgi'

# A Hash for all of the variables we want to send to HAML
model = {}

# Why not get the time
model[:time] = Time.now

cgi = CGI.new

# Set up the template
haml_engine = Haml::Engine.new(File.read('../templates/index.haml'))

# Render out the HTML
cgi.out { haml_engine.render(Object.new, model) }

And there’s the tedious code. There are some interesting pieces to notice. For one, when calling cgi.out, that sends out the proper headers out to the browser *(very important)*. Also, this could probably be wrapped up into a nice function to reduce the strain of repeating one’s self.

Sometimes, a design requires a little extra markup, perhaps something to get that rounded corner to work or what-have you. Now let’s say this piece of code requires certain classes, a certain kind of structure, including a tile, and has to be used in many places, something like a sidebar piece. Instead of copying and pasting this structure over and over, you can use a helper to make you life easier, and if you combine it with a block, it will just feel even more painless.

The Setup

<div class="sidebar">
  <div class="bottom">
    <h3>Title</h3>
    <div class="body">
      <p>Some Content</p>
    </div>
  </div>
</div>

There are two elements which must change; the title and the contents of the body. The title should simply be just some text that goes in between the h3 tag. The contents of the body could be anything, in this case, it is the paragraph tag and everything inside.

Creating a Helper without a Block

Since we have these two varying things, we could create a helper method to encapsulate our structure. The first parameter of the helper will be the title while the second parameter will be the contents of the body.

def sidebar(title, body)
  content_tag(
    'div',
    content_tag(
      'div',
      content_tag('h3', title) + content_tag('div', body, :class => 'body'),
      :class => 'bottom'
    ),
    :class => 'sidebar'
  )
end

That looks pretty easy. Now let’s look at the interface for this helper

<%= sidebar('Hello World',
  '<p>It is one of these "Hello World" things again.</p>') %>

Not too shabby, but what if we wanted to do an unordered list?

<%= sidebar(
  'Hello World',
  '<ul>' +
    '<li>Item</li>' +
    '<li>Item</li>' +
    '<li>Item</li>' +
  '</ul>'
) %>

This feels pretty clunky and ERB is completely ignored. Instead of this procedural way of thinking, why not see what a block can do for us?

Creating a Helper +with+ a Block

For this to work, we will still need the first parameter to be the title, but the body will be passed in as a block to be processed from within our helper. The block we create will be ERB code, this will feel more natural to the person who has to implement the code. The magic to get this done comes from the concat method of ActionView::Helpers::TextHelper module.

def sidebar(title, &block)
  raise ArgumentError, "Missing block" unless block_given?

  start = <<-END
    <div class="sidebar">
      <div class="bottom">
        <h3>#{title}</h3>
        <div class="body">
  END
  concat(start, block.binding)

  block.call

  end = <<-END
        </div>
      </div>
    </div>
  END
  concat(end, block.binding)

end

This may look slightly odd, but I assure you, the interface makes up for it.

<% sidebar('Hello World') do %>
  <p>And now back to the way I was doing things before</p>
  <ul>
    <li>Item</li>
    <li>Item</li>
    <li>Item</li>
  </ul>
<% end %>

The Benefits

• The implementation code is more readable
• It gives you one place to make your common edits
• It keeps your code DRY(don’t repeat yourself)

def create_new_active_record_model(class_name)
  klass = Class.new(ActiveRecord::Base) do
    belongs_to :old, :class_name => class_name
    def some_method_you_want
      "something"
    end
  end
  Object.const_set "#{class_name}Target", klass
end

I know that some of this could have been encapsulated in a polymorphic association but this allows you to do something beyond just keeping everything in one table, like with polymorphic associations.

This could be useful for creating something like a garbage collector. After something is deleted, it could go to this garbage heap. Having a lot of models would mean having a lot of garbage collection models. The garbage collection models could easily be abstracted enough so that one doesn’t have to worry about the man behind the curtain.

In some ways it would be better than an acts_as_paranoid For large tables there won’t be data cluttering it up. Since all of the data is happening on live data, keeping the dirty out can help performance. Also, when I used acts_as_paranoid, I had to make sure that I put conditionals on all of my belongs_to and has_many statements; that way when I do something like user.posts,I wont get deleted posts.

If I had to compare it to something that already exists, it’s like an acts_as_versioned but it only cares when something is deleted.

When I get some more time, I will work on creating a acts_as_trashable or something of that nature :)

Tonight I found video of that presentation and I got excited about CRUD(Create, Read, Update, Delete). It pointed out that I’ve been making some controllers a little bloated. I have coupled much functionality into one controller; when looking back, I clearly could have separated out some functionality.

Learning to love has_many :through even more with CRUD

One of the points about this is that the coupling often happens when you have models that are joined by a table, like in a HABTM(has_many_and_belongs_to) relationship. The table that joins the two other tables as an amorphous name, whose role changes depending on which side of the join table you are looking. has_many :through fixes this ambiguity as it gives a name to a new model, and thus a new domain to think about creating clean uses of CRUD. An example will make this much clearer.

The non-CRUD way

class Author < ActiveRecord::Base
  has_and_belongs_to_many :books
end

class Book < ActiveRecord::Base
  has_and_belongs_to_many :authors
end

Let’s say I have a AuthorController and we want to add books to an author, or remove a book from an author, we could write the following.

class AuthorController < ApplicationController
  def add_book
  end

  def remove_book
  end
end

This doesn’t seem that harmless, but what if we wanted to add authors to a book?

class BookController < ApplicationController
  def add_author
  end

  def remove_author
  end
end

This does not follow the ways of DRY(Don’t Repeat Yourself), because depending on which side of the coin you are looking at, you have two different ways to accomplish pretty much the same thing.

Enter has_many :through

DHH points out that if we can identify the link between Authors and Books, there will be a new a less ambiguous and more elegant way to think about this issue. The link to identify here is Authorship. Now let’s change our models some.

class Author < ActiveRecord::Base
  has_many :authorships
  has_many :books, :through => :authorships
end

class Authorship < ActiveRecord::Base
  belongs_to :author
  belongs_to :book
end

class Book < ActiveRecord::Base
  has_many :authorships
  has_many :authors, :through => :authorships
end

Because the link has been identified, a controller can be created with the ideals of CRUD put right into place.

class AuthorshipController < ApplicationController
  def create
    #Authorship.create(:author_id => params[:author_id], :book => params[:book_id])
  end

  def destroy
  end
end

Everything is right with the world again

POST, GET, PUT, DELETE

The other big thing that was mentioned was mapping CRUD functionality to HTTP(hypertext transfer protocol) method definitions: POST, GET, PUT, and DELETE respectively. The HTTP method acts as the verb for what the controller should do. Here is the basic outline, the comments are how things fit into the lovely world the the HTTP methods as verbs:

class SomethingController < ApplicationController

  # POST /something
  def create
  end

  # GET /something/1
  def show
  end

  # PUT /something/1
  def update
  end

  # DELETE /people/1
  def destroy
  end

end

Since browsers don’t use PUT or DELETE, Rails has a hack for this; it’s going to send hidden fields with the actions so that the mappings know how to handle everything. Those methods aren’t the only ones that are apart of the CRUD; there are other ones that are common to most controllers:

class SomethingController < ApplicationController

  # GET /something
  def index
  end

  # GET /something;new
  def new
  end

  # GET /something/1;edit
  def edit
  end

end

index is responsible for listing all of the somethings, while new and edit are how users first start their journey to creating or updating something.

Clarity in this layout isn’t the other reason to use this. The other reason Rails is going to be embracing REST(Representational State Transfer) ideals into the way Rails will route your URLs. More on this later when I dive deeper into it.

Because of this presentation, I’m thinking about how I’m doing my controllers. I usually don’t have this type of setup, but I am definitely going to start using it. From now on, I will not be afraid do use the command script/generate controller Something index new create show edit update destroy and start to think about controllers from a CRUD perspective rather than creating more monolithic controllers, and to be ready for when Rails 1.2 comes in full effect.