Its not hard to set this up (ok its a bit tedious), but as Mike Subelsky noted in his blog post, its not really written up elsewhere in one compact recipe. I wanted to take a slightly different approach than what Mike took, in that I wanted to disturb the default OSX install as little as possible. Since OSX includes an apache webserver, the idea is that you have that webserver proxy all the SSL details and then pass off control to your development instance running on localhost:3000. The built-in instance of apache can be turned on and off in OSX by going to the Sharing control panel in your System Preferences. If you mark the checkbox named “Web Sharing” apache is on and running, and off if the checkbox is off. You can verify this by turning it on then browsing to http://localhost, you should see an apache screen.

Step 1 – Configuring SSL Encryption

Note that this recipe is a condensed version of what is found here, but I have cut out all the commentary. You will be using terminal for all the rest of this. Also I am using OSX Leopard * Shut down your local apache server either turn off web sharing or

sudo apachectl stop

• Create a Working Directory

  mkdir ~/Desktop/KeyGen; cd ~/Desktop/Keygen

• Create the RSA private key

  openssl genrsa -des3 -out server.key 1024

use a passphrase here as directed (and remember it )

• Create the CSR (Certificate Signing Request)

  openssl req -new -key server.key -out server.csr

This signing request you will sign yourself (for development only of course). For this CSR enter ’127.0.0.1′ for the prompted “Common Name – i.e. for the appropriate server”

• Create a Certificate Authority (CA) to sign the key

  openssl genrsa -des3 -out ca.key 1024
  

use a passphrase here again

• Create a self-signed CA certificate using the key you just made

  openssl req -new -x509 -days 365 -key ca.key -out ca.crt

in the “Common Name” field enter your name, because you are the dummy certificate authority and you are the one signing it.

• Download the latest mod_ssl distribution It can be found here. Look in the pkg.contrib subdirectory and copy the file sign.sh to your working directory. Then you have to make the file executable, and sign the csr.

  chmod +x sign.sh ;./sign.sh server.csr

Enter ‘yes’ for all the prompts, and you will have a directory full of files, representing the signed csr.

• Put the signed files where apache can use them

  sudo mkdir /etc/apache2/ssl.key

Move all of the contents of your working directory to the ssl.key directory you just made.

sudo cp -r * /etc/apache2/ssl.key/

• Remove the passphrase from the server key (DONT DO THIS FOR A PRODUCTION SYSTEM)

  cd /etc/httpd/ssl.key
  sudo cp server.key server.key.original
  sudo openssl rsa -in server.key.original -out server.key
  

Step 2 – Modify the Apache config files

• First, back up the existing apache config file for safety

  cd /etc/apache2 sudo cp httpd.conf httpd.conf.backup

• Then use your favorite editor to enable the appropriate LoadModule statements. (you are going to have to use sudo (‘sudo vi’) to open this file in order to save it). Search for a line that looks like this:

  LoadModule sslmodule libexec/apache2/modssl.so

and make sure that the # at the beginning of the line is not there (i.e. the comment indication), if it is there remove it. Likewise remove # from this line a bit farther down

Include /private/etc/apache2/extra/httpd-vhosts.conf

and this…

Include /private/etc/apache2/extra/httpd-ssl.conf

• Back up your extra/httpd-ssl.conf

  sudo cp httpd-ssl.conf httpd-ssl.conf.original

• Comment out the following line by putting a # at the beginning of it (we are putting this setting in the httpd-vhosts.conf file)

  Listen 443

• Remove the Virtual Host

Then remove all the lines starting at

    <VirtualHost _default_:443>

and ending at

    </VirtualHost> 

We are going to define all our virtual host stuff in the httpd-vhosts.conf file, so its not needed here.

• Back up your extra/httpd-vhosts.conf and edit it

  sudo cp httpd-vhosts.conf httpd-vhosts.conf.original

I pretty much deleted everything in my vhosts file and replaced it with the following content

Listen 443

SSLCertificateFile /etc/apache2/ssl.key/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

CustomLog logs/ssl_request_log  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

<VirtualHost *:80>
 ServerName localhost
 ServerAlias 127.0.0.1

 ProxyPass / http://localhost:3000/
 ProxyPassReverse / http://localhost:3000
 ProxyPreserveHost on
</VirtualHost>

<VirtualHost *:443>
 SSLEngine On
 ServerName localhost
 ServerAlias 127.0.0.1

 ProxyPass / http://localhost:3000/
 ProxyPassReverse / http://localhost:3000
 ProxyPreserveHost on
 RequestHeader set X_FORWARDED_PROTO 'https'
</VirtualHost>

And thats it. Go to your Sharing control panel and turn on Web Sharing. You should see https requests being forwarded correctly to your rails application (assuming that its listening on the default mongrel port of 3000).

Capistrano is a powerful deployment tool that is considered ‘state of the practice’ by anyone deploying Rails applications to Unixy type systems. But what about if you need some of that same Capistrano fu on a windows server. Can it be done? In my case I really needed a way to build my database schema on the deployment target as soon as the application was deployed (cap deploy with migrations basically). This isnt such an easy thing to do as I found. I was going to deploy via JRuby/Goldspike in a War file format (the standard java deployment package), so I dusted off my arcane Java knowledge and came up with a solution to load the schema.rb file as soon as the war file loads. Read on for details.

The trick here, was that I needed the “migrate to current” process to run only once, when the Rails application loads. When you deploy the web application via the Goldspike Plugin, you end up with a pretty standard Java Web Application WAR file (i.e. Web ARchive). WAR files have a very well defined set of hooks for startup and teardown, which of course would directly correspond to the startup of the Rails application that we are deploying inside of that WAR file. So the basic trick, is to leverage the startup hook of the WAR file (In Javaland this is called a Context) and run the appropriate logic for creating database schema on the deployment box. You could of course do arbitrary other things as well, but thats a talk for another time.

We want to do this in such a way that we are writing a minimum of Java code, and pushing most of the work of doing this off to Ruby. The first thing we have to do is create the Java class which runs when the Context loads (i.e. the Rails application). This is done by creating a ServletContextListener, an interface in Java. Here is an excerpt of the class I wrote (showing only the important bits)

`

    public void contextInitialized(ServletContextEvent event) {
  try {
      final ServletContext context = event.getServletContext();
      // create the pool
      initiallizeJrubyEnvironment(context);

      //this is defined in the web.xml
      commandFile = context.getInitParameter("command-file");


      System.out.println("Entering: MigratorContentListener.contextIntialized \n");

      thread = new Thread(new Runnable() {

          public void run() {
              try {
                  // wait for a little while before starting the task
                  // this allow the app server to start serving requests before initializing all tasks
                  Thread.sleep(100);


                  runOnce(context);
                  System.out.println("Exiting: MigratorContentListener.contextIntialized \n");
              } catch (InterruptedException e) {
                  // break out of loop
              } catch (Exception e) {
                  context.log("Could not start " + commandFile, e);
              }
          }
      });
      thread.start();
  } catch (ServletException ex) {
      Logger.getLogger(MigratorContextListener.class.getName()).log(Level.SEVERE, null, ex);
  }}'

‘
private void runOnce(ServletContext context) throws Exception {

    try {
        String rootDir = context.getRealPath("");

        Ruby runtime = null;
        try {

            String script = readFileAsString(rootDir + "/" + commandFile);
            context.log("executing "+script);
            runtime = (Ruby) getRuntimePool().borrowObject();
            runtimeApi.eval(runtime,"ENV['RAILS_ROOT'] = '" + rootDir + "'");
            runtimeApi.eval(runtime, script);
            getRuntimePool().returnObject(runtime);
        } catch (Exception e) {
           context.log("Could not execute: " + commandFile, e);
            getRuntimePool().invalidateObject(runtime);
          context.log(commandFile + " returning JRuby runtime to pool and will restart in 15 minutes.");
            try {
                Thread.sleep(FIFTEEN_MINUTES_IN_MILLIS);
            } catch (InterruptedException ex) {
            // can't do much here ...
            }
        }


    } catch (Exception e) {
        e.printStackTrace();
        context.log("Could not execute: " + commandFile, e);
    }
}`

The J2EE application server will call the contextInitiallized method shown above when the WAR file loads. In the 4th line of that method, notice that I get the name of the ruby file to run, its passed in via a parameter defined in the web.xml file. More on that later. Basically this class executes the “runOnce” method one time, in a separate thread, as soon as the context loads. Really all the runOnce method does is pass the name of the method to run to the Ruby runtime that has been set up via the magic of JRuby.

In order to get this file to get loaded by the Application Server, you need to make two entries in the web.xml file. The first one, which tells it to attach a listener to the Context, looks like this

<listener> <listener-class>org.jruby.webapp.MigratorContextListener</listener-class> </listener>

where the MigratorContextListener is the Java class that contains the logic listed above. The second entry that you need to put into the web.xml file is what the ruby file is named that you want executed. Here is that entry

<context-param> <param-name>command-file</param-name> <param-value>migrator.rb</param-value> <description>Run this file to execute an initial migration (for deployment to new platforms)</description> </context-param>

The migrator.rb file, the one that gets executed on startup (and found in the root of the application), looks like this

load('db/schema.rb')

Once this executes, the production database indicated in the database.yml will get the schema.rb file applied to it. It would have been much cooler to actually run a migration, but by the time you deploy to production, your schema has probably settled down anyway, so applying the schema.rb file is probably sufficient. I guess the bigger point is, you can do arbitrary things at install time with this.

I bundled all of this up into a plugin called “migrate_war”, one of the things this plugin includes is a jar file which contains the ContextListener, you have to tell the GoldSpike plugin about this jar file so that it includes it in the WAR file it generates. To do this edit the config/war.rb file and add this to the end:

include_library 'migrator-rails' , '0.9'

When you install the plugin, it will copy that jar to lib/java and the include_library command will find it there and pull it into the generate WAR file.

Once you have installed the plugin and made the include_library addition shown above, go ahead and generate your WAR file using Goldspike.

After that finishes you can edit the web.xml file found in WEB-INF/web.xml (Goldspike generates the WEB-INF and everything below it) with the xml edits shown above (for the listener, and the command-file). Then you need to run it again to generate the WAR file with the modified web.xml included (if the WEB-INF directory already exists the Goldspike plugin won’t clobber this directory unless you tell it to, so its cool to edit these files before generating again, Goldspike will use whats in WEB-INF).

You can install the plugin by entering

script/plugin install http://svn.silverchairsolutions.com/migrate_war/.

Hope this helps someone!

Update: Its important to note that this will apply the schema.rb file directly to your database. This will blow away the schema contained within (and any data found there). So if you need to save the data, you should export it then reimport it after the schema gets built. It would be much cooler if migrations were run on this. Anyone care to try?

My first problem was, how do I dynamically create graphs? This was solved when I found out about this: Graphviz, an open source graph visualization language that many software packages understand. There are stand-alone graph readers available as well as tools like OmniGraffle for the mac which can read this format. We will create our diagrams in this format (.dot).

My solution was inspired by Dave Thomas and his annotate_models plugin. I created a plugin that is triggered as a rake task, i.e. rake annotate_states I used Dave’s code to guide me on how to step through all the model classes, then I added additional logic to filter out all model classes that didnt use actsasstate_machine. I then introspected on the remaining list and got a list of states and transitions so that I could build the diagram.

You can install the plugin in the usual way, navigate to the root of your application and type script/plugin install http://svn.silverchairsolutions.com/annotate_states.

After installing the plugin (and checking that it lists as a rake task by typing rake -T) you can create the .dot files for your application by typing rake annotate_states. Each model file in your application that uses acts_as_state_machine should produce a state transition diagram in the root of your application.

Hope you enjoy it!

Has anyone else run into this?

ActiveRecord#save(false) you can force active record to save and ignore validation errors

ActiveRecord#update_attribute This does the same thing as above, but on a per attribute basis

Very handy. And yes.. I know that this is “breaking the rules” because I am skipping validation. But in this particular case.. it makes sense

Furthermore I was hosting at a shared host, and things like memcached just aren’t going to happen. I had already got bitten once by assuming distributed ruby, drb would run at my shared host, and when it came to deploy time I was in for a rude awakening. Since then I have set up a virtual server at SliceHost, and so I control whatever is on that box. Memcached suddenly looked like a viable solution.

Here is what I did to set it up on my MacBook Pro. Since OSX by default has some issues with some of the binary releases available, Geoffrey Grosenbach has written a script which downloads, patches and compiles all the right stuff. Get the script here. This script will create binaries in /usr/local/bin, so make sure that is in your path.

after downloading the script, cd to a directory of your choice (I created a directory “memcached” in my development folder) and run the script. It should happily churn while you are getting your coffee.

At the conclusion of the script, you need to edit your .bashprofile to include EVENTNOKQUEUE=1. I am not sure what voodo this does, but its required . Go ahead and pull that configuration into your current environment by entering $ source ~/.bash_profile

Next you’ll need to install the Ruby memcached client. This allows the rails application to put and get things from the cache. Install it with:

$ sudo gem install memcache-client

Now that the client and server is installed, you can start doing some basic testing. To start the server type:

$ memcached -vv

( the -vv means verbose output)

Once the server is up and running, you have to tell your rails application how to find your distributed cache. On both my development and production environments, my cache will be running on localhost, so my configuration won’t change when I deploy. For that reason I will put the necessary rails configuration information in the generic config/environment.rb file rather than the more specific config/environments/development.rb (or production.rb). Configure the memcached client by adding the following lines to the end of environment.rb:

CACHE = MemCache.new :namespace => "myapplication", :cthreshold => 10000, :compression => true, :debug => false, :readonly => false, :urlencode => false

CACHE.servers = '127.0.0.1:11211' ActionController::Base.sessionoptions[:expires] = 1800 ActionController::Base.sessionoptions[:cache] = CACHE

(you could of course have run the memcached server on any arbitrary address, and included that address in the servers parameter shown above)

Now that this information is entered, you can test the basic operation of the cache from the rails console and observe inbound requests from the memcached process you started earlier. Enter the following from the rails console:

$ script/console Loading development environment

CACHE["test"] = "my cool cached info" =>"my cool cached info" CACHE["test"] =>"my cool cached info" CACHE.delete "test" =>"DELETED\r\n" CACHE["test"] =>nil

and thats pretty much it! To use it in your controllers or models simply put objects in the cache using CACHE[] = object or CACHE[] to retrieve.