Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

PIVOTAL LABS
New York Standup, Overdue from the Week of 03/02/2009

Interesting Things

  • An EngineYard-hosted project had an issue with monit attempting to restart
    mongrel too often. It turned out that the mongrel processes were not
    dropping pid files soon enough. The EngineYard-suggested fix:

    • Upgrade mongrel to 1.1.5.1 (patched to drop the pid file faster)
    • Upgrade to monit 5.0 beta 6
    • Update to the latest ey-monit-scripts
  • FiveRuns dash is a cool, customizable metrics
    service. Pat created a plug-in
    for sending continuous integration stats there: dash-ci.
  • Using Cucumber to test Capistrano deployment:

    cap --dry-run will run Capistrano without completing the actual task
    (e.g., deployment). Cucumber can then be used to write some nice,
    story-like deployment expectations that search the Capistrano output to
    document your project’s deployment process and ensure the documentation
    remains valid. Something like:

    Feature: Deployment
      In order to deploy the application
      As an administrator
      I should run Capistrano commands
    
    
      Scenario: Deploying
        Given I am working from the RAILS_ROOT directory
          And the parent directory is a Git repository
        When  I run a deployment task
        Then  'scm_user' for the deployment should be derived from the Git config for the remote origin
    
    
      Scenario: Deploying to demo
        Given I am working from the RAILS_ROOT directory
        When  I run 'cap demo deploy'
        Then  the deploy should succeed
          And the deployed code matches the latest 'web/stable' tag
          And the deployed code should be marked with a new 'web/demo' tag
    

    More on this to come.

  • Using Selenium to ensure unique IDs in your DOM:

    # ----------------------------------------------------------------------
    # The examples below illustrate the technique with the Prototype and
    # jQuery libraries, respectively.  Both use Pat Nakajima's selenium
    # helper for executing javascript in the tested browser window.
    #
    # For more on that helper, see:
    # http://blog.pivotal.io/users/patn/blog/articles/run-javascript-in-selenium-tests-easily-
    # ----------------------------------------------------------------------
    
    
    # ----------------------------------------------------------------------
    # with prototype
    # note the exception catching... prototype chokes on invalid IDs
    # e.g., "invalid_id[][]"
    # ----------------------------------------------------------------------
    def assert_unique_ids
      audit_json = run_javascript <<-JS
        audit_ids = function() {
          var results = {};
          $A($$('*[id]')).each(function(element) {
            if(element.id.replace(' ', '').length > 0) {
              try {
                if($$('#' + element.id ).length > 1) {
                  if( ! results.duplicates) {
                    results.duplicates = {};
                  }
                  var count = results.duplicates[element.id] || 0;
                  count ++;
                  results.duplicates[element.id] = count;
                }
              }
              catch(err) {
                // uncomment to capture invalid IDs
                // var invalid = results.invalid || [];
                // invalid.push(element.id);
                // results.invalid = invalid;
              }
            }
          });
          return ($H(results).toJSON());
        }
        audit_ids();
      JS
      assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs')
    end
    
    
    # ----------------------------------------------------------------------
    # with jQuery
    # additionally depends on the jquery-json plugin:
    # http://code.google.com/p/jquery-json/
    # ----------------------------------------------------------------------
    def assert_unique_ids
      audit_json = run_javascript <<-JS
        audit_ids = function() {
          var results = {};
          $('*[id]').each(function() {
            if(this.id.replace(' ', '').length > 0) {
              if($('*[id=' + this.id + ']').length > 1) {
                if( ! results.duplicates) {
                  results.duplicates = {};
                }
                var count = results.duplicates[this.id] || 0;
                count ++;
                results.duplicates[this.id] = count;
              }
            }
          });
          return $.toJSON(results);
        }
        audit_ids();
      JS
      assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs')
    end
    

Help Wanted

  • One project recently moved from Rimu to EngineYard, only to find their Mongrel processes double in memory consumption. Any thoughts on why?

Comments
  1. thedarkone says:

    That is because EngineYard uses 64-bit systems.

    It’s the same problem as with Slicehost and is also the reason why Linode is so much more better suited for Rails hosting then SH:

    http://forum.slicehost.com/comments.php?DiscussionID=2875

  2. Dr Nic says:

    Testing your deploy is cool

  3. Chad Woolley says:

    Yes, testing your deploy is cool.

    Pivotal’s default template project and CI environment also does a real deploy to a ‘local’ environment as part of the CI build. It works fine, you just need to make sure you have a no-passphrase ssh key in ~/.ssh/authorized_keys on localhost.

    A little slow, but that’s why it only happens in CI. I wonder if you could leverage these tests for the real build. Testing the output of Capistrano’s –dry-run mode is surely faster and catches syntax errors, but I wonder if it could mask some problems that would show up in a real deploy (file permissions, nonexistent directories?)

    — Chad

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *