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?

I am web developer who specializes in Ruby on Rails contracts and works remotely from my home office. Currently looking for new projects, I’m open to conversations about new contract possibilities. My company is Silverchair Solutions, an agile web development consultancy. I have over 13 years of web development experience and two and a half years of Rails experience. Recently some of my work was published in the Advanced Rails Recipes book (Pragmatic Programmers – see the wizard chapter!). I am a former Oracle DBA and am very comfortable designing databases as well as configuring linux/mac os servers in support of my web applications.

To learn more about me, view my Linkedin profile here:

Working with Rails Profile

If you have a project that you think I may be able to help you with, please send me an email with a short description of what it is you need done and we will chat!

Thanks, Mike

Add some entries to the head section of the index page of your website

`<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://your.real.openid.com/" />'

Where, the openid.server is the url of your provider, and the openid.delegate is your real openid identity.

This trick will work with any resource you have access to on the internet, i.e. anything where you could add information to the head portion of your index page. Many thanks to Duncan Davidson for this tip

I got the germ of the idea for this one from Duncan Davidson’s blog post (which sadly is no longer available due to a server crash) of last fall where he too was longing for something like capistrano to automatically handle pushing up code updates. I will condense what I remember from his post.

At its heart, this approach starts by recognizing that Xcode allows you to keep project specific settings (kind of like environment variables) in a separate file called an .xcconfig file. For us this file will contain the version number of the code that we are going to deploy. In this technique this value will be manually editing. Everytime we want to do a deploy, edit the xcconfig file, then do a deployment. The deployed code will show up on the client with the version number you specified in the .xcconfig file.

Create the Xcode Config File

In your cocoa project, add a new file to the project (File -> New File) and select Xcode/Configuration Settings File. Call it whatever works for you. Open the file up in Xcode and add this single line to it (or more if you are using xcconfig for other things too )

WIDGET_VERSION = 0.99

(Replace WIDGET with whatever the name is of your application, its up to you, you are merely defining a variable here that you will use in your Plist ).

The next step is to make sure XCode uses the xcconfig file that we just created. To do this, select the project icon in the outline view of Xcode and hit command-I. This will bring up the project information for your project. Navigate to the build tab on this window, and at the bottom of this tab you should see “Based on:”, with a drop down to pick an xcconfig file to base this build on. Since we are going to control the version number through the xcconfig, we want to select the xcconfig file that holds our version number here.

Modify the PList file to utilize the setting from the .xcconfig file

Lets now edit Info.plist file to make use of the version number. Edit the plist so that it looks like this (I have only listed the appropriate lines, leave the lines alone)

<key>CFBundleVersion</key> <string>${WIDGET_VERSION}</string>

Save this and lets move on…

Create a new build target which does the deploy

Add a new target to your XCode project, and call it Deploy. Drag your build product under this target as well. This step will make sure that building the application will happen before deploying it (it makes it a dependency). Add a new build phase to your Deploy target, add a build phase that is of type Run Script. ” Add -> New Run Script Build Phase”. Edit this run script build phase to look like this:

if [ "Release" != "$CONFIGURATION" ]; then
    echo 'error: Package creation only works for Release builds'
    exit -1
fi

./ruby_deploy.rb $WIDGET_VERSION $CONFIGURATION_BUILD_DIR`

Create the Ruby File Which Does the Packaging

In our run script phase we just wrote, we turn around and execute a ruby script called ruby_deploy. This is a custom script that we are going to create right now. Go ahead and add a new empty file to your project, and save it as ruby_deploy.rb. Here is a suggested starting place that I use. Feel free to modify it as needed for what you are doing

#!/usr/bin/env ruby
#
#  ruby_deploy.rb
#  widget
#
#  Created by Mike Hagedorn on 12/1/07.
#  Copyright (c) 2007 Silverchair Solutions. All rights reserved.
#


require 'rss/1.0'
require 'rss/2.0'
require 'open-uri'
require 'rss'

require 'net/http'


#put your application name here
APPLICATION_NAME="widget"
#put your user name here
USERNAME="user"
#specify the appropriate server and directories here
SCP_DESTINATION="yourserver.com:the_directory_where_you_want_it_on_your_webserver/apps/#{APPLICATION_NAME}"
SCP_SOURCE="/tmp"


version = ARGV[0]
build_dir = ARGV[1]
proper_name = APPLICATION_NAME.capitalize
package = "#{proper_name}_#{version}.zip"
notes = "#{APPLICATION_NAME}_#{version}.html"
puts build_dir
`zip -r /tmp/#{package} \"#{build_dir}/PhonoscopeDialer.app\"`
url_base = "http://yourserver.com/apps/#{APPLICATION_NAME}"
dist_dir = url_base

content = ""
# raw content of rss feed will be loaded here
open("#{url_base}/appcast.xml") do |s|
    content = s.read
end
rss = RSS::Parser.parse(content, false)

package_url = "#{url_base}/#{package}"
zip_ctime = File.ctime("#{SCP_SOURCE}/#{package}")
zip_size = File.size("#{SCP_SOURCE}/#{package}")
pub_date = zip_ctime.localtime.strftime("%a, %d %b %Y %T %z")

last_item = rss.items.last

latest_version = last_item.title.split.last
if version.to_f <= latest_version.to_f
    puts "version not updated, returning"
    exit -1
end


source = "#{SCP_SOURCE}/#{package}"
dest = "#{USERNAME}@#{SCP_DESTINATION}/#{package}"
`scp \"#{source}\" \"#{dest}\"`

content_new = RSS::Maker.make("2.0") do |m|
    m.channel.title = "Your Application Log"
    m.channel.link = "#{url_base}/appcast.xml"
    m.channel.description = "Most recent changes with links to updates."
    m.channel.language = "en"
    rss.items.each do |item|
        m.items.new_item do |newitem|
            newitem.title = item.title
            newitem.link = item.link
            newitem.description = item.description  
            newitem.enclosure.url = item.enclosure.url  
            newitem.enclosure.type = item.enclosure.type
            newitem.enclosure.length = item.enclosure.length
            newitem.date = item.date
        end
    end
#add the new one
m.items.new_item do |appendedItem|
    appendedItem.title = "Your Application Version #{version}"
    appendedItem.description = "#{url_base}/#{APPLICATION_NAME}_#{version}.html"
    appendedItem.enclosure.url = "#{package_url}"
    appendedItem.enclosure.type = 'application/octet-stream'
    appendedItem.enclosure.length = "#{zip_size}"
    appendedItem.date = pub_date        
end


end

puts content_new
File.open("#{SCP_SOURCE}/appcast.xml","w") do |f|
    f.write(content_new.to_s)
end


source = "#{SCP_SOURCE}/appcast.xml"
dest = "#{USERNAME}@#{SCP_DESTINATION}/appcast.xml"
`scp \"#{source}\" \"#{dest}\"`

source = "#{build_dir}/#{notes}"

dest = "#{USERNAME}@#{SCP_DESTINATION}/#{notes}"
`scp \"#{source}\" \"#{dest}\"`

Lets step through this script. The first thing to do (and this will be custom to your application) is to set up values for a specific server on the internet where your application will be stored. The variables set up here for the location of the appcast need to match the SUFeedURL entry in your Plist file. You would have had to set that up when you integrated Sparkle. Heres an example that would match the ruby file listed above.

<key>SUFeedURL</key> <string>http://www.yourserver.com/apps/widget/appcast.xml</string>

The next thing that is done is to create the archive (zip file) of the built application. That’s why building the application is a prerequisite for the deploy step, you want to make sure you have code there to actually zip up. After you zip up the file, you store it in the /tmp directory.

Now we need to update the appcast.xml file, this is the RSS feed that your application will check to see if there is a more recent drop of the application available. The basic workflow is, go out to the internet, grab the appcast.xml feed (the xml), parse the file to find the last revision number, if the current revision is equal to the last revision, exit and do nothing. If however the revision number is greater (this should usually be the case) then go ahead and copy the zipped up code out to the server using scp, secure copy. Then you need to create an RSS item for the new current revision (the update) and append it to the collection of items in the RSS feed. Then you simply copy back the new and improved appcast.xml file out to your server. Here is a simple example of an appcast file, to get this process started you need to copy this file out to your server first (so that it can be fetched and parsed)

<?xml version="1.0" encoding="utf-8"?> 
    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle"> 
    <channel> 
        <title>Your Application Log</title> 
        <link>http://www.yourserver.com/apps/widget/appcast.xml</link> 
        <description>Most recent changes with links to updates.</description> 
        <language>en</language> 
        <item> 
            <title>Version 0.9</title> 
            <description>http://www.yourserver.com/apps/widget/widget_0.9.html</description> 
            <pubDate>Fri, 30 Nov 2007 19:20:11 +0000</pubDate> 
            <enclosure url="http://www.yourserver.com/apps/widget/widget_0.9.zip" length="1600000" type="application/octet-stream"/> 
        </item> 
    </channel> 
    </rss> 

`

Another step here that is important to the workflow is to add a release note to each drop. This is an html file that is displayed when the update is loading. The naming convention is appname_version.html. Here’s a simple example of that

<h2>Notes on version 1.02</h2>
<ul>
    <li>First Sparkle Release</li>
</ul>`

Your Deployment Workflow

Now that you have all this, how do you use it? First do all your coding, testing, etc for your next release. When you are ready to push out some changes, first create the html file listing your changes and add it to your project (so that the script can find it to copy it out to your deployment server). Use the naming convention listed above. Then update your xcconfig file with the appropriate release number. Then select the Deploy target and build. That’s it. Isn’t that cool? `

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!

It turns out that there is another way to get notifications into Growl other than the the (broken) growlnotify. That technique is to use Applescript.
Applescript allows you to do all sorts of neat things to applications in OSX but it is an arcane and hard to understand beast (at least in my
opinion – feel free to flame me ). Based on a sample from the Growl website I was able to cobble together a working solution which
restores all the growlnotify goodness we have come to expect from Autotest. The first thing is to write the Applescript which talks to Growl.

Here is what I came up with (as modified from the Growl website)

— growlNotify.applescript
–
— Created by Mike Hagedorn on 2007-10-31.
— Copyright (c) 2007 Silverchair Solutions. All rights reserved. http://www.silverchairsolutions.com
— based on script from the growl website
— works around the fact that growlnotify doesnt work on leopard

— pass in like osascript growlNotify.applescript http://www.silverchairsolutions.com/blog/2007/10/activescaffold-streamlined-woes/ http://www.silverchairsolutions.com/blog/2007/10/activescaffold-streamlined-woes/#comments Mon, 08 Oct 2007 15:34:09 +0000 mhagedorn http://www.silverchairsolutions.com/blog/?p=17 Found an interesting gotcha while trying out some of the new “User Interface in a Can” frameworks. If you use the new hasmany :through style declaration (rather than the old way hasandbelongsto_many) for modeling your many to many relationships in ActiveRecord, then that relationship cannot be editable in these frameworks. What happens is that a relationship is inferred, but since that relationship is read-only, a gui is generated which cannot edit that relationship. Which in non-geek speak means WORTHLESS. Since I was on a tight time budget on a project, I had to do something, so I am in the process of converting back to HABTM, which both frameworks happily use. I haven’t had a moment to grok why this is. But something about the existence of the :through class messes up introspecting the relationships. I am hoping this isn’t too much of a limitation, because I like overall the GUI’s that are produced. Furthermore in my work at least I haven’t had to utilize the power of a full-fledged join model in the middle, so I am hoping that this wont mess me up too much.

Has anyone else run into this?