The MetaSpring Blog Carnival: Issue 3 – Web Development

December 23rd, 2009 by Case Ernsting

How about a little love for the guys and girls behind the scenes, eh? After celebrating some great web design posts last month, we’re turning the focus to Web Development for this edition of the MetaSpring Blog Carnival. So let’s get right to it!

The Trouble with Soft Delete

“Soft delete is a commonly used pattern amongst data-driven business applications”, but as Richard Dingwall points out in this post, “[soft delete] usually ends up causing more harm than good.” Richard outlines the various pros and cons of soft delete and offers a few solutions for those struggling with implementations of the pattern.

Scaling Rails – On The Edge – Part 1

This is the first of three screencasts by Greg Pollack in which he explores nine new Ruby and Rails libraries which can help you to scale your rails application. This first post deals with three tools: Bullet, Rails Indexes, & Scrooge. The content covered in these posts is easy to discern for all levels of Ruby development.

behavior: a Rails gem/plugin for storing application configuration in the database

Paul Campbell from Pabcas.com put together this post highlighting the advantages of a new Rails gem/plugin that he’s pushed out called “behavior”. Paul worked on the Rails Development Directory and developed behavior as a solution to storing issues that came up. As Paul writes, “It is useful to store site title, description, email address, passwords, etc. outside the source code.” Behavior does this with a Yaml configuration file. Installation instructions can be found at the end of Paul’s post on his website.

We Can Have Hack Free CSS With the @unsupported Directive

This forward-thinking post by Chris Eppstein discusses a feature for CSS that does not yet exist. Chris makes his plea to CSS3, requesting an @unsupported directive, which would provide benefits like “Feature Queries” and legacy browser targeting.

Top 15+ Best Practices for Writing Super Readable Code

The developers here at MetaSpring take great pride in well written, succinct code. (MetaSpring programming Architect, John Ku took this concept to the extreme a few months back in a post about Ruby Quines.) Now, Burak Guzel’s post urging developers to write highly readable code will continue that theme, because as Burak says, “readable and maintainable code is something to be proud of in a finished product.”

Top 20+ MySQL Best Practices

Burak Guzel is so good that we had to feature another of his posts! This time Burak covers a few MySQL optimization techniques. Burak walks through a step-by-step process for structuring tables properly, writing optimized queries and assembling better code. This 21 point plan for making optimized web applications is a great read for any programmer.

Next Month’s Issue: Usability

Thanks to all those that submitted blog posts this month. Hopefully you learned as much as we did. Next month’s theme is one that gets discussed a lot in both the world of development and design: Usability. Usability issues are at the forefront of many projects these days, so we’re sure to have a great batch of links. The deadline for submissions on BlogCarnival.com or through our email is January 17th. If you have a usability-related post or a suggestion for a topic that you’d like to see discussed, make sure to let us know at media@metaspring.com.

Happy Holidays!

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

MetaMonday: Ruby Quines

September 21st, 2009 by John Ku

Editor's Note: Today we're pleased to introduce you to a new segment of our blog: MetaMonday's - a chance for us to get really low-level and meta for you. Today's meta post comes from our Systems Architect, John Ku, who is well-versed in all things related to computer science and philosophy. So, let's get on with it!

This MetaMonday post delves into the puzzling nature of quines and will show you how to create one in Ruby. If you've got a passion for self-reference, mathematical logic, functional programming, or philosophical paradoxes - this post is for you!

What Is A Quine?

A quine is a self-referential program that performs the neat trick of outputting its own source code without cheating. Cheating could be accomplished by accessing the external file system that the code is stored on, or in trivial cases, compiling empty code which, unsurprisingly, prints itself.

The Challenge of Writing Quines

Initially, you might think that writing a quine would be pretty easy to do. After all, most programming languages will have a command to simply print out a string. For example, in Ruby, puts "Hello World!" would print out Hello World! as its output. So couldn't a Ruby quine then, simply consist of the puts command followed by a string containing that line of code?

On close inspection, we can see that that strategy won't actually work because it results in an infinite regression. The string printed by the puts command would have to include the whole source code, including the string itself and the puts command that precedes it. We might start out with something like:

  puts "#{source_code}"

where source_code can be thought of as a variable containing that entire line of code. However, to output that line of code in our Ruby quine, we'll need to print it out with puts, yielding:

  puts "puts \"#{source_code}\""

We escaped the inside quotations with backslashes since we want them to be printed as characters rather than interpreted by Ruby as marking the beginning or end of a string. But that's the least of our worries, since we now notice that we still haven't come any closer to figuring out what goes inside source_code or even how to output that line of code along with the puts line.

The problem is that we have to include the puts command outside of the string in order to print source_code, yet including more code outside the string always adds onto the total source code. Thus, trying to substitute all of the source code we've arrived at so far into source_code would just lead to an infinite regression in which our program's output is always one step behind its own source code and unable to close its self-referential loop.

Quine's Paradox and an English Example

How are quines possible then? Rather than simply reproducing the source code as a flat string, the string itself must be generated by the code. Nearly all quines turn out to share a very similar structure for accomplishing this task, generally consisting of some data (e.g. a string) and some code which operates on that data. The data is then made into a representation of the code; the code, in turn, takes the data and prints it twice: once as a data structure and once as executable code.

Let's see how this might work in a language that all of our readers presumably understand: English. Here's an English phrase which outputs itself when interpreted:

"Preceded by its own quotation" preceded by its own quotation.

The quoted phrase acts as the data structure, which also represents code, in English, for performing the syntactical operation of preceding something by its quotation. When the whole phrase is interpreted, what results is the very same English phrase, making it a quine.

We can see how this phrase works with a complete sentence from Quine's Paradox:

"Yields falsehood when preceded by its own quotation" yields falsehood when preceded by its own quotation.

While not technically a quine since it seems to yield a truth value when evaluated rather than itself, it does involve the same essential trick of self-reference. This self-referential sentence is paradoxical because it's an indirect way of saying the same thing that the Liar Paradox says: "This sentence is false."

English to Ruby

The strategy for indirect self-reference implemented in the English quine above can be loosely translated into Ruby to produce a quine like the following:

lambda { |s| puts s + s.dump }.call "lambda { |s| puts s + s.dump }.call "

Here the quotation follows rather than precedes the code, but the result is the same. Basically, the line of code above says to take the quoted string and print it, followed by its quotation.

The lambda method takes a block of code enclosed in curly braces and creates an anonymous function defined by the block of code passed. In functional programming, these functions can then be stored in variables and passed around as first-class objects to higher-order functions, but in this case, it is simply called immediately with the string that follows as input.

When the function is called, the string gets bound to the variable s and the program prints the string along with its quotation. Since the string represents the command to print it followed by its quotation, the result of running this program is the code itself.

We could also have written this in a more conventional Ruby style, as follows:

def follow_by_quote(s)
  puts s + s.dump
end
follow_by_quote "def follow_by_quote(s)\n  puts s + s.dump\nend\nfollow_by_quote "

Are Quines Useless?

Now that you've gotten a taste of what quines are all about, you might be wondering whether they are of any practical use for anything other than nerd sniping. Now, we've actually already seen one use for them in formulating philosophical paradoxes, namely in Quine's Paradox, where its indirect self-reference was used to restate the Liar's Paradox. This leads us to other uses.

It turns out that the proof of Gödel's Incompleteness Theorem also uses the same sort of indirect self-reference we see in quines and in Quine's Paradox. The primary trick Gödel performed was to map a meta-mathematical logic about number theory into number theory itself and use it to state a theorem that that very theorem could not be proven.

This theorem is not quite as paradoxical as the Liar Paradox, but it is still quite counter-intuitive. The theorem cannot be proven true since its truth entails that it can't be proven true. However, it cannot be false since its falsehood entails that it can be proven true. Thus, if number theory is to remain consistent and free of contradictions, the theorem must be true but unprovable. That there are such true but unprovable theorems is arguably one of the most important mathematical discoveries in the past century.

Moreover, if we take a step back and broaden our perspective, we can see quines as one type of fixed point, or a point on a function that is mapped to itself by the function. For quines, the function in question would be the evaluation of a string of code which is performed by the programming language's compiler or interpreter. The quine is a fixed point because it is both the input and output of that evaluation function.

Fixed points have proven to be of great practical importance in theoretical computer science. In fact, a stronger version of the fixed point theorem that guarantees that our strategy for building quines will succeed has informed advances in programming language design and optimization.

The Y Combinator, for instance, shares a similar structure to our quines above and uses fixed points to define recursive (or self-referential) functions non-recursively, resulting in an exponential improvement in the amount of computation time required.

Unfortunately, I can't really do justice to these dense topics in this post, but I hope after reading this, you can share my appreciation of quines not just as an intriguing and wondrous programming puzzle but also as a glimpse into the nature of self-reference and recursion.

A Few Additional Resources

Godel's Theorem in words of one syllable:
http://www2.kenyon.edu/Depts/Math/Milnikel/boolos-godel.pdf

Hal Fulton claims to have the first Ruby Quines:
http://rubyhacker.com/ruby-quine.html

Shortest Ruby Quine (at the end of this post):
http://philcrissman.com/2008/11/30/real-quines-in-ruby

There is also an explanation of how that shortest Ruby quine works here:
http://thisbindle.com/personal/ruby/
(It basically does the same thing as my Ruby quine above).

Lots of quines in different languages (no Ruby though):
http://www.nyx.net/~gthompso/quine.htm

How to write a quine in C#:
http://igoro.com/archive/how-to-write-a-self-printing-program/

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Upgrading Your Rails Development Environment for Snow Leopard

September 2nd, 2009 by Julie Cameron

Now that Apple has released their new OS, Snow Leopard, thousands of devoted Mac web developers are jumping on the upgrade bandwagon - and for good reason! Snow Leopard has implemented a ton of nice little tweaks to make your Mac faster and more reliable, resulting in a much smoother development environment.

One of the biggest changes in Snow Leopard is the shift to 64-bit computing. While this change will make for huge speed increases and optimized memory usage, it also means that you'll need to upgrade or re-compile any 32-bit applications or libraries still lingering around (that is, if you installed Snow Leopard on top of your existing system rather than doing a clean install).

So to make your lives easier, I've put together a list of all the steps that I had to take to get back down to business. These instructions should work for most Mac/Rails setups, though you may need to tweak certain steps or take a few more should errors arise.

1. Prep Your Mac & Install Snow Leopard

Lifehacker put together a pretty solid guide to cleaning up your OS X 10.5 Leopard installation, backing it up in case of errors, and finally installing Snow Leopard: Prep Your Mac for Snow Leopard. Installation took about an hour to complete on my MacBook Pro.

2. Upgrade Xcode with the Snow Leopard Optional Install

Don't pop that install disc out just yet, next we need to install the enhanced version of Xcode developer tools. The Xcode installer can be found in the Optional Installs folder and the default settings should do just fine.

3. Restore Apache configurations from your 10.5 Leopard backup

It's likely that your custom Apache configurations were wiped out during the upgrade, but luckily you read through Step 1 and have a nice lil' backup of your 10.5 install. I only needed to restore my Virtual Hosts file, but I've seen others report that they needed to restore httpd.conf, as well.

4. Upgrade to 64-bit MySQL

Hivelogic has come to the rescue and provided a great tutorial on Compiling MySQL for Snow Leopard. It worked great for me, however I had to run the gem install with a specified C extension to force 64-bit compilation:

sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

A quick note about /usr/local

If you've been running with the default Leopard Ruby install, you won't need to worry about installing Ruby, as Snow Leopard comes bundled with 64-bit Ruby 1.8.7.

However, if you know about the benefits of manually compiling your libraries in /usr/local (no? see here and here), you'll need to upgrade Ruby manually.

In either case, this article from the RidingRails blog should provide additional insight and more helpful hints: Upgrading to Snow Leopard.

5. Upgrade to 64-bit Ruby

Once again, Hivelogic comes through with their Compiling Ruby, RubyGems, and Rails on Snow Leopard tutorial.

6. Upgrade remaining 32-bit gems

The RidingRails blog provided a nice script to look through your installed gems and list out any compiled gems that need to be upgraded for 64-bit.

If you've manually compiled Ruby in /usr/local, you'll need to alter the script to point to the appropriate gem path by changing the following line:

# Dir.glob('/Library/Ruby/Gems/**/*.bundle').map do |path|
Dir.glob('/usr/local/lib/ruby/gems/**/*.bundle').map do |path|

Once you've generated the list of upgradable gems, you'll need to reinstall them. Simply updating may not rebuild the library, so you'll need to uninstall and then reinstall. There also seems to be some confusion on whether or not forcing the C extension to compile for 64-bit is necessary in Snow Leopard, but it doesn't seem to hurt. To do so, run your gem install command like so:

sudo env ARCHFLAGS="-arch x86_64" gem install hpricot mongrel xmlparser

For more information on rebuilding your gems, check out this post from Victor Costan's blog. He also suggests running:

sudo gem update --system; sudo gem pristine --all

7. Upgrade remaining 32-bit libraries

This is where the fun begins. I'd suggest taking a peak into your /usr/local and /usr/local/lib folders to get an idea of what other libraries might still need updating. A few of the bigger ones for me include Git, Sphinx and RMagick.

Compiling Git

And another Hivelogic tutorial for the win: Compiling Git on Snow Leopard. You may need to upgrade some dependent libraries before building git will work (in my case, I needed libiconv).

Compiling Sphinx

iCoreTech put together a quick tutorial on getting Sphinx compiled for 64-bit - be sure to pay attention to the custom 64-bit configuration flags. My configuration looked like:

LDFLAGS="-arch x86_64" ./configure --prefix=/usr/local --with-mysql=/usr/local/mysql

Compiling ImageMagick and installing the RMagick gem

I've compiled a shell script to install the necessary dependencies, ImageMagick and the RMagick gem. It's an updated compilation of Agile Animal's and iCoreTech's scripts.

The updated script can be found at: http://pastie.org/620711. Simply save it as a .sh file and run it from the command line, like so: sh install_magick.sh

A Few Additional Notes and Resources

Hopefully this has gotten you through the bulk of upgrades needed to get back to work! But if not, here are a few other helpful resources that might help you out:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Boost Your Ruby Efficiency with Textmate

May 4th, 2009 by John Paul Narowski

Here at MetaSpring, we’re avid fans of the TextMate text editor because it makes developing web apps a breeze through the use of its hotkeys, snippets, and bundles.

TextMate comes with a plethora of basic language bundles – all of which come with their own set of custom hotkeys and snippets designed specifically for that language. These hotkeys and snippets can be customized for your preferences or you can even make your own.

At MetaSpring, we work predominately with Ruby and would like to share a few of the TextMate helpers that have made us all much more efficient developers. The following hotkeys and snippets can be found in the Ruby bundle, unless otherwise noted.

Helpful Hotkey Commands

The following commands can be found and managed by going to Bundles >> Bundle Editor >> Edit Commands.

Execute Line / Selection as Ruby

Control + Shift + E will execute a line or block of highlighted ruby code. The response will be outputted right after the executed code. This is extremely useful for testing Ruby syntax without having to switch to the IRB console.

Validate Ruby Syntax

Control + Shift + V will validate the syntax of your Ruby file. Try using this before running unit tests or reloading the server, it can save you tons of time spent repairing small syntax errors.

Run a file using Ruby

Command (⌘) + R will execute the file you are currently working on. One of our favorite features of this command is that it will also run RSpec tests if the file you have open is a spec file.

Convenient Snippets

The following snippets can be found or added to your TextMate environment by going to Bundles >> Bundle Editor >> Edit Snippets.

Create Hash Pairs and Hash Rockets

Hitting tab after entering a colon will produce a hash pair like :key => "value"
Control + L will produce a hash rocket with proper spacing =>

Params Shortcut

If you use Rails or Merb, you’ll most likely refer to a params[:x] variable frequently throughout the development cycle.
Control + P will output params[:id] where “id” is selected for editing.
Note: This snippet is included in both the Rails and Merb bundles.

Insert Comment Banners

Control + Shift + B sets up a comment block and allows you to enter the comment you want; a second tab gets you coding again.
Note: This snippet is included in the Source bundle.

Easy HTML Anchor Tags

Here’s an HTML snippet we made to make creating anchor tags a cinch.
Hitting Tab after entering an a outputs <a href=""></a>. You can then enter the link URL and hit tab to enter the link text.

To set this up in your own TextMate environment, create a new snippet with the following settings:

Anchor Snippet

Other Useful TextMate Bundles

With bundles for almost every programming and scripting language, the above examples are only a small sampling of the magic that TextMate is capable of. For more Ruby-relevant functionality, you might check out some of the following add-on bundles:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Using Rails Migrations as part of a Simple Installation Script

February 23rd, 2008 by Carson Keith

Rails Migrations provide an easy way to make versioned revisions to your database structure over a period of time. When used properly they can make it easy to make modifications to your existing database programmatically as you need to make changes. This is extremely helpful for large up-and-running projects, but what about projects that are still in development? I don't know about you but for me, after working on large project for awhile there can be a ridiculous number migrations sitting around. It's also quite possible that a good portion of your earlier migrations have been nullified by other migrations later on. When you start throwing data into your migrations this can quickly become a tangled patchwork web of evil.

While migrations are extremely helpful for making modifications on production systems, we have found that having a pile of migration revisions really doesn't serve much purpose during the development cycle. This is especially true if you are not needing to work with live data and you have access to a good code repository like SVN. So during the development cycle for most of our Rails related projects we maintain one large initialization migration, an installation shell script, and a refresh shell script. The large migration handles the standard migration goodness, any type of data import, and other dynamic data installation initialization procedures. The installation script is run once to deploy the application on a new system; it typically sets up the database, runs the initialization migration, and handles whatever other settings you need for deployment. The refresh script simply refreshes the database and reruns the initialization migration; this is used when the migration is updated.

Below is a very simple example of how we put this idea to use:


Database Initialization Migration - 001_initialize_database.rb

require 'active_record/fixtures'
 
class InitializaDatabase < ActiveRecord::Migration
  def self.up
 
    # Initialize fixture array
    # This array is used to load a list of fixtures that will be loaded into the database at the end of the installation process
    fixture_array = []
 
    # It's important to use the :force option if you are not going to drop tables in your down method
    # this forces tables to be overwritten if they are already present
    create_table :customer, :force => true do |t|
      t.column :name, :string
    end
 
    # Add to fixture array
    fixture_array << :client
 
    # CREATE REMAINING TABLES
 
    # Load fixture data
    Fixtures.create_fixtures('db/fixtures', fixture_array)
  end
 
  def self.down
  end
end


Installation SQL Script - install.sql

CREATE DATABASE database_name_dev;
CREATE DATABASE database_name_pro;
CREATE DATABASE database_name_test;
GRANT ALL privileges ON database_name_dev.* TO 'user'@'localhost' IDENTIFIED BY 'password';
GRANT ALL privileges ON database_name_pro.* TO 'user'@'localhost';
GRANT ALL privileges ON database_name_test.* TO 'user'@'localhost';


Installation Shell Script - install.sh

#!/bin/bash
 
mysql -u root --password=password -e "source install.sql"
rake db:migrate


Refresh Shell Script - refresh.sh

#!/bin/bash
 
rake db:migrate VERSION=0
rake db:migrate

Then to install on a system we simply run install.sh from the command line.

> ./install.sh

If a change is made to the schema we run refresh.sh from the command line.

> ./refresh.sh

Since refreshing the database wipes the database clean and reloads each time, its really only useful until you have reached a final stage of deployment. Hopefully by that time though you will have a relatively stable db structure and won't need to be adding a butt-load of migrations.

It's really a relatively simple concept, but I can't tell you how much time we have saved in deployment using this methodology. We'd love to hear your ideas and deployment strategies.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]