If you or someone you know needs top notch Ruby on Rails or Ember.js talent, let me know!

As an experienced developer, I’d give this course 3.5 stars if it was an option, but I rounded up because if you don’t know anything about unit testing then this course is a great overview.

The most valuable parts to me were the advanced RSpec overview and discussion of fakes (mocks, stubs). Roy covers this well, but encourages using a 3rd party mock library outside of what RSpec provides called Bogus. The reason is to allow for non-strict mock expectations, which are less brittle since they don’t complain every time a method on the object under test is called that you didn’t explicitly stub out. However, RSpec does support this with the as_null_object method so it would have been nice to not introduce an additional gem unnecessarily.

Another thing that was a bit glossed over is the fact that in (I think all) of his mock expectation examples Roy is actually using a ‘spy’ where in he does the assert AFTER the method under test is invoked. That’s a fine way to test, but it would have been useful to mention to viewers that the other (more pervasive?) way of doing it is setting up an expectation first

1

blah.should_receive(:something)

or in the new RSpec syntax…

1

expect(blah).to receive(:something)

and then doing the work on that method AFTER that expectation to determine whether or not that expectation was fulfilled. This confused me when I first got into testing since it’s backwards from the typical ‘do work’ and ‘assert a state change’ work flow, but I think there are advantages to doing mock expectations first so you end up thinking about the code you wish you had instead of checking that it was called at the end. Really, they’re both fine ways, I just wish the multiple ways of doing it were discussed in this course. Here’s a blog article that shows how to do both options in RSpec (check the Mocks:Spies section).

Another error I noticed was in the discussion of let vs let!. Roy talks about how let memoizes (caches) whatever it’s storing so that if that variable is used multiple times, it’ll just retrieve whatever was set on that variable previously. That is in fact how let in RSpec works, BUT that only happens within the current example if the let gets called multiple times. It DOES NOT memoize/cache the let value BETWEEN examples as Roy described. See the docs.

One thing I picked up that I liked quite a bit was this tip:

When describing a method on a class like Calc#add, define a method that does what you want to test below the describe/context for that method, and re-use that helper method in the tests so that if the implementation changes later you only have to update the code in one place.

Here’s an example where extracting a method called ‘adding’ could help clean up specs:

1
2
3
4
5
6
7
8
9
10
11

describe Calculator do
  context "a single number"
    def adding(input)
      calc.add(input) #calls a let defined above
    end

    it "adding 2 increases the number by 2" do
      expect(adding('2')).to eq(2)
    end
  end
end

Roy also does a good job of explaining RSpec’s ‘subject’ and ‘its’ which I never took the time to fully grok until now.

Truth be told, I didn’t watch the TeamCity stuff because I’m using Jenkins for CI on CircleCi (which I highly recommend!). If you don’t know anything about CI or want a bit more hand holding to setup your own server, then I’m sure this section is fine.

One other negative of this class was the rather lackluster production quality. It gets the job done, but the audio in the videos is not up to par with something like RailsCasts or Destroy All Software. It doesn’t appear to have been mastered at all (loudness differs vastly across the videos) and the lessons are actually all ‘live’ in that Roy was teaching a class of real people while screen recording these videos. I didn’t realize that when I purchased the course and it did disappoint me a bit when I saw that this was how the information was going to be presented. In fact, some of the Q&A sessions between Roy and the class are completely unintelligible because of the way the gate on the microphone was setup. It cut off the audience almost entirely.

Speaking of live screen recording, there were definitely a few times when Roy got bit by the ‘live demo’ demons and had to pull his chute / abandon ship / insert clever metaphor here…but it didn’t detract from the lesson too much.

All in all, I’m glad I took a few hours to go through this material. Thanks to Roy for presenting it, and to Avdi for tweeting about it to get me there.

Here are some notes I took while going through the course: https://gist.github.com/jondkinney/6674458

This year there were over 120 attendees and some 20 speakers presenting on things ranging from running a massive Java web application at scale to Single Page Applications with JavaScript. I had an awesome time meeting new people and sharing a little bit about how I run the technical and development side of Bolstr. Specifically, I talked about how we collaborate on work-flows for new features through user stories with Cucumber as we build out our Ruby on Rails web application at Bolstr.com.

The slides from my talk “How to be a One-Man Coding Army for a Startup” are available online, and if you attended the session I’d sure love it if you could leave some feedback at speakerrate for me.

Also, a big shout out to Brian Hogan for encouraging me to submit a talk and even suggesting the name. Thanks Brian!

The default Selenium driver through Firefox is the only solution for testing the DocuSign iframe that I could get working. However, the rest of the test suite that needs JavaScript testing has been working wonderfully on Poltergeist, an awesome headless PhantomJS driver for Capybara. Poltergeist was throwing errors about elements overlapping in the DocuSign iframe that I couldn’t solve but I didn’t want to abandon Poltergeist and revert to Selenium for ALL our JS testing, so I figured out a way to use both by tagging stories and using some Before and After hooks.

The rest of this post assumes you already have Poltergeist installed.

Inside of features/support/env.rb add the following hooks:

1
2
3
4
5
6
7
8

# Hooks
Before('@docusign') do |scenario|
  Capybara.current_driver = :selenium
end

After('@docusign') do |scenario|
  Capybara.use_default_driver
end

Additionally, add:

1
2

Capybara.default_driver = :rack_test
Capybara.javascript_driver = :poltergeist

…which I actually have in my Spork.each_run do block

Now by default any stories tagged with just @javascript will run through PhantomJS. If you want to use Selenium for a given test then you need to tag it with BOTH @javascript AND @docusign. Perhaps naming the tag @selenium would be more appropriate, but I only plan to use Selenium for testing DocuSign stories so this works for me for now. Note: I’m not sure why the @javascript tag is required, but it didn’t work for me unless I had both tags specified. I’m guessing @javacript sets up more than just the driver, but if anyone has more of an explanation I’d love to know.

In an effort to help other devs perhaps more quickly acceptance test DocuSign with Cucumber here are the step definitions that I came up with for our use case.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

When /^I sign the docusign document as an "(.+)" and click finish$/ do |user_type|
  sleep 3

  within_frame("docusign_iframe") do
    # Docusign disclaimer (review button)
    click_button 'ds_hldrBdy_dlgStart_startReview_btnInline'

    # Sign
    page.find_button('Sign Here').click

    # Adopt and sign (might not always need to do this step if the user has
    # already adopted his or her signature. I would have though we'd have to
    # adopt each time in the testing world but it doesn't seem to be that way)
    if page.has_css?('#ds_hldrBdy_dlgAdoptSig_btnAdoptSignature_btnInline')
      click_button 'ds_hldrBdy_dlgAdoptSig_btnAdoptSignature_btnInline'
    end

    if user_type == 'attorney'
      # DocuSign gives us .FirstPage as a class on the first page and just
      # .Page for each page after that, so this really only works if your first
      # 'Sign Here' is on the first page and there is only one subsequent one
      # within all of the rest of the .Page pages. Still, fits this use case
      # alright as long as the engagement letters in the test env fit on one
      # page so the attorney disclaimer bit is always on page two.
      within(:xpath, "//div[@class='Page' and @class != 'FirstPage']") do
        click_button 'Sign Here'
      end
    end

    # Confirm signing
    click_button 'ds_hldrBdy_navnexttext_btnInline'
  end

  sleep 3
end


When /^I choose to sign the docusign document later$/ do
  sleep 3

  within_frame("docusign_iframe") do
    # Finish Later
    click_button 'ds_hldrBdy_dlgStart_btnIntroSignLater_btnInline'
  end

  sleep 3
end


When /^I decline to sign the docusign document$/ do
  sleep 3

  within_frame("docusign_iframe") do
    # Decline to Sign
    click_button 'ds_hldrBdy_dlgStart_btnIntroDecline_btnInline'

    # Decline confirmation
    click_button 'ds_hldrBdy_dlgDecline_btnDecline_btnInline'
  end

  sleep 3
end

I also use CloudApp multiple times per day (and pay for a pro subscription) so I was encouraged when I saw an article stating that RealMac (the team behind LittleSnapper) was working on integration with CloudApp, but nothing has developed on that front in over a year and I didn’t want to wait any longer so I started down the path of solving the problem myself.

Here’s how it works:

• Configure LittleSnapper to use SFTP to “publish” locally to a folder of your choosing.
• Create a new Automator “Folder Action” which runs an AppleScript when the contents of the folder changes.
• Use the CloudApp API through a Ruby script (called by the aforementioned AppleScript) to publish the given file.

Details with Code and Screenshots

1. Configure LittleSnapper’s publishing preferences to include a location local to your machine.

   • Use your Mac username and password when setting up this connection. The “Server” is whatever shows up when you open System Preferences and choose “Sharing”. At the top you’ll see a note stating: “Computers on your local network can access your computer at: MBPr.local”. Use the full name including .local shown there (which will likely be different than mine).

   • The file path I’m using is: /Users/jon/Pictures/ScreenShots/LittleSnapper.

     • Note: I used TinkerTool to change the default location where OS X stores screenshots to ~/Pictures/ScreenShots so using a subdirectory of that folder seemes optimal.

   

2. Create a new Automator “Folder Action” which runs an AppleScript when the contents of a folder you specify changes.

   

   Filter the available Actions by searching for “Run AppleScript”, then drag that action to your workflow:

   

   Set the folder action to the same folder you chose in the above steps and paste in (and customize if necessary) the provided AppleScript

   

   AppleScript for the Automator Action:

    set cloudappSlug to do shell script "cd /Users/jon/Pictures/ScreenShots/scripts; /Users/jon/.rbenv/versions/1.9.3-p194-perf/bin/ruby cloud.rb"
    set the clipboard to cloudappSlug
    do shell script "afplay /System/Library/Sounds/Glass.aiff"
   

   Note: It’s necessary to use the full path to the version of Ruby that has the cloudapp_api gem installed under it. Type which ruby to show the full path to your currently executable Ruby and be sure to gem install cloudapp_api or sudo gem install cloudapp_api under that same Ruby version. Sudo is only required if you’re not using a Ruby version management solution and are using the default system Ruby that shipped with OS X. You can also see in the above AppleScript that we change into the folder that contains the Ruby script before calling it. Be sure to customize the script to change into the folder where you place the Ruby script if it’s different than mine.

   • After saving the Automator Action (I chose the name “Watch LittleSnapper”), navigate to the chosen folder in Finder and right click, choose Services > Folder Action Setup…

   

   • Cancel the pop up dialog and verify that your Automator Folder Action is there and checked (enabled).

   

3. Use the CloudApp API through a Ruby script (called by the aforementioned AppleScript) to publish the given file.

   • Place the below Ruby script somewhere on your machine (the AppleScript I provide assumes it’s in ~/Pictures/ScreenShots/scripts/cloud.rb).

   • Note that the first line of the Ruby script also references the full path to the version of Ruby you want to use. It will likely be different than what I show here. It should be customized the same as it was in the AppleScript above.

   • You can also see there is authentication to the CloudApp servers necessary on line 7. Customize the script with your CloudApp username and password here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#!/Users/jon/.rbenv/versions/1.9.3-p194-perf/bin/ruby

require 'rubygems'
require 'cloudapp_api'

# customize me please
CloudApp.authenticate "your_email_here", "your_password_here"

pasteboard_file = `cd /Users/jon/Pictures/ScreenShots/LittleSnapper; ls -td * | head -1`
file = "/Users/jon/Pictures/ScreenShots/LittleSnapper/#{pasteboard_file.chomp}"

@drop = CloudApp::Drop.create :upload, :file => file

puts @drop.data["url"]

• Make sure the ruby script is executable:

1
2

cd ~/Pictures/ScreenShots/scripts
chmod 755 cloud.rb

Wrapping Up

All that’s left to do is try it out!

• Take a screenshot with LittleSnapper and publish it to local folder we setup in step 1
• Wait for the ding
• Paste the new CloudApp slug to the screen shot you just uploaded!

If this all seems like a bit of a pain for something so simple, you’re right… it is. And for the vast majority of cases I still do what I did with Skitch which is to just take a screenshot of my annotated screenshot with the normal Cmd+Shift+4 shortcut which will automatically upload to CloudApp. However, LittleSnapper can also take screenshots of entire web pages (even the portion that doesn’t fit on your screen!) and sometimes I want to upload those screenshots to CloudApp too. Hopefully the Realmac team will just start providing CloudApp support natively so folks won’t have to use crazy workarounds like this!

After a bit of Googling I found this code snippet:

1
2
3
4
5
6
7

<html>
  <body>
    <script type='text/javascript' charset='utf-8'>
      parent.location.href = '/myloc';
    </script>
  </body>
</html>

Which can be implemented in a Rails controller like so:

1

render text: "<html><body><script type='text/javascript' charset='utf-8'>window.parent.document.location.href = '/myloc';</script></body></html>", content_type: :html

The above code snippet takes the place of the traditional redirect_to. The beauty of this solution is that after the signer interacts with the document and completes his or her signing ceremony, the app will act just like we had served the embedded signing iframe code directly from our own view. There isn’t a button to click that says “go to parent” or “back to home” or anything, it just works and redirects appropriately when the user is done interacting with the iframe.

I created a little utility method in the docusign_rest gem to abstract the JS portion and make it more consise. See lines 23 and 26 in the example controller code below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

class SomeController < ApplicationController

  # the view corresponding to this action has the iframe in it with the
  # @url as it's src. @envelope_response is populated from either:
  # @envelope_response = client.create_envelope_from_document
  # or
  # @envelope_response = client.create_envelope_from_template
  def embedded_signing
    client = DocusignRest::Client.new
    @url = client.get_recipient_view(
      envelope_id: @envelope_response["envelopeId"],
      name: current_user.display_name,
      email: current_user.email,
      return_url: "http://localhost:3000/docusign_response"
    )
  end

  def docusign_response
    utility = DocusignRest::Utility.new

    if params[:event] == "signing_complete"
      flash[:notice] = "Thanks! Successfully signed"
      render :text => utility.breakout_path(some_path), content_type: :html
    else
      flash[:notice] = "You chose not to sign the document."
      render :text => utility.breakout_path(some_other_path), content_type: :html
    end
  end

end

Here is the method in the Utility class of the DocuSign module that handles embedding the path in the HTML snippet.

1
2
3

def breakout_path(path)
  "<html><body><script type='text/javascript' charset='utf-8'>parent.location.href = '#{path}';</script></body></html>"
end

It’s been nearly seven months since I joined the great team at Bolstr as Chief Technology Officer and I have to say, it’s a job that gets even better with time!

Since I started, I’ve done a bunch of things:

• Made significant improvements to http://bolstr.com
• Added a ton of functionality to our main application and improved test coverage / speed
• Written a robust wrapper gem to the Docusign REST API and implemented their embedded e-signature solution into our main application
• Switched to using Tmux and Console Vim after a brief affair with Sublime Text 2
• Started a Ruby User Group in Green Bay, WI
• Completed several advanced Ruby courses to hone my code slinging skills

It’s funny how time flies when you love what you do. I’m very excited about what we’re doing and we have some amazing opportunities already lined up in the months ahead.

Keep in touch if you want to see the financial and banking industries squirm when crowdfunding goes mainstream!

Here are direct links to what is posted to date (I’ll try to keep this updated).

• It’s not enough to bash in heads, you’ve got to bash in minds…with ZSH (May 18, 2011)
• Remote Cold Boot a Mac (January 14, 2011)
• Using BIND locally on OS X for easy access to subdomains (June 2, 2010)

The only problem was that the page didn’t look very nice. I could have left it (it was working after all) but then I ran across an init script for cuke in a gist from Duff that allowed for the rewriting of the paths to the local image, JavaScript and CSS files so they at least could be referenced properly. While this worked, most of my images were specified as backgrounds in my actual CSS files so if I wanted to be able to see the page as it was intended I would need to find a way to change the paths in the actual CSS files as well.

After playing around with the idea of modifying my actual CSS files temporarily and then switching them back (and realizing that solution was full of fail) I settled on a way strip out all links to all css files and then embed the actual CSS inline in a style tag inside the page’s head tag. This way I can more easily and permanently modify the css background image paths all in a self contained HTML file. I did this by looping through a specified directory on the file system that contains CSS files and looking for any stylesheets that the user specifies and in the order that the user specifies so that the hierarchy would remain in tact when the styles were all embedded inline.

Since Cucumber’s env.rb file is auto-generated it’s a bad place to store customized configuration options. Instead I encourage you to do what Cucumber says at the top of the env.rb file and put it somewhere else. From env.rb: “Cucumber will automatically load all features/*/.rb files”

I chose to put this code in a file under the features/support directory called: open_browser_on_fail.rb. If it’s sitting next to the env.rb file itself then you have the new file in the right place.

Place the following code in that file and you’ll be good to go!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

After do |scenario|
  if scenario.status == :failed
    save_and_open_page
  end
end

module Webrat
  module SaveAndOpenPage
    def save_and_open_page
      return unless File.exist?(Webrat.configuration.saved_pages_dir)

      filename = "#{Webrat.configuration.saved_pages_dir}/webrat-#{Time.now.to_i}.html"

      File.open(filename, "w") do |f|
        f.write rewrite_public_file_references(response_body)
      end

      open_in_browser(filename)
    end

    def rewrite_public_file_references(response_html)
      # remove conditional comments/ie stylesheets
      response_html.gsub!(/<!--\[.*?\]-->/im, '')
      # remove other stylesheets
      response_html.gsub!(/<link href=(.*)\/>/i, '')

      response_html.gsub!(/("|')\/(stylesheets|images|javascripts)/, '\1' + '../public' + '/\2')

      response_html.gsub!(/<\/head>/i, "<style>#{rewrite_public_stylesheet_image_references('\/images', '../public')}<\/style>\n<\/head>")
    end

    def rewrite_public_stylesheet_image_references(regex, server_url)
      dir = "/Users/jkinney/Sites/Rails/Client/new_rails_app/public/stylesheets/"

      stylesheets = %w(reset admin main js_menu css_tabs firefox)

      css = ""
      stylesheets.each do |file|
        # puts file
        lines = []
        File.open(dir+file+".css", "r"){|f| lines = f.readlines }
        lines = lines.inject([]){|l, line| l << line.gsub(/#{regex}/i, "#{server_url}/images")}
        css << lines.to_s
      end
      css
    end

  end
end

Writing the association code yourself required some array math and it was hard to remember what order to do things in and how to exactly format it. I had to copy and paste the code in from a snippet library every time. Not only that but it was ugly and a pain in the butt to maintain, and really felt like it should be handled in the core Rails framework. It looked like this (at least my version):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#This is from an old app that managed a relationship between MetaKeywords and Pages

def manage_meta_keyword_associations(new_meta_keywords)
  current_meta_keywords = MetaKeywordPage.find_all_by_page_id(self.id).collect{|mkp| mkp.meta_keyword_id.to_s}

  meta_keywords_to_add = new_meta_keywords - current_meta_keywords
  for meta_keyword in meta_keywords_to_add
    MetaKeywordPage.create(:meta_keyword_id => meta_keyword, :page_id => self.id)
  end

  meta_keywords_to_remove = current_meta_keywords - new_meta_keywords
  for meta_keyword in meta_keywords_to_remove
    MetaKeywordPage.find_by_meta_keyword_id_and_page_id(meta_keyword, self.id).destroy
  end
end

Here’s another post detailing this requirement, but luckily as of 18 months ago (or longer) Rails no longer makes you manage that association code yourself. While this isn’t news in and of itself, it’s important if you’re working with a legacy app and you try to convert a HABTM to a HM:T and can’t figure out why it’s not working. That’s exactly what happened to me a few weeks ago after digging back into an old codebase. I needed the HM:T implementation though because I needed to add the position column to the join table to allow users to order their locations by the most recently added one. The app I’m working in has users, employers and locations. Users and locations are associated through the locations_users (join table) and locations belong to employers, thus users are associated to employers through the locations_users table.

The problem is that there was a lot of data in my existing HABTM table (locations_users) that I needed to retain and I wasn’t sure how to go about doing this. I’m also using Microsoft SQL Server 2005 with my Ruby on Rails app so that throws another kink in the mix as most google searches will only yield info for MySQL or PostgreSQL. I thought about just modifying the table directly in SQL Management Studio but that was less than desirable because it is hard to automate and hard to document. However, most .NET developers I know use “change scripts” instead of migrations like we do in the Rails world so I thought about how I could get a hybrid solution working.

I modified the table in our staging environment with SQL Management Studio, I added an “id” column, and both “updated_at” and “created_at” timestamp columns and then generated a change script. Note: it’s important that when in design mode that you click the “generate change script” button before saving the table, otherwise if you save the table before generating the change script you can’t click the change script button anymore… it gets grayed out.

Initially I tried just executing the whole change script directly in an execute block inside of self.up, which would look something like this:

1
2
3
4
5

class ModifyLocationsUsersToBeHmt < ActiveRecord::Migration
  def self.up
    execute "change script here"
  end
end

Unfortunately that didn’t work, but I did manage to figure out a way to still execute the change script incrementally. I just needed a new “execute” call for each SQL statement (which you can see in the final code example at the end of this post). The last thing to do was to try to execute this task with some sort of fail-safe so that I wouldn’t screw up my data if something went wrong. Luckily ActiveRecord supports transactions as long as your database does, and SQLServer 2005 definitely supports them. In fact they’re in the change script as “BEGIN TRANSACTION”, we just can’t execute that code directly in our migration which is why you don’t see them in the final code example.

For more discussion on transactions in Rails look at this stackoverflow thread.

1
2
3
4

#A transaction in Active Record
ActiveRecord::Base.transaction do
  execute "update users set enabled = 1 where name like 'batman'"
end

Because we want to retain all the data that exists in the join table and we’re adding an ID col with some timestamps and re-positioning the fields, SQL Server will be creating a tmp table, dumping all our records into that, then renaming the tmp table to locations_users and modifying the ID col to be a true auto-incrementing primary column. Here is the final, transactional Active Record Migration for SQL Server 2005.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

class ModifyLocationsUsersToBeHmt < ActiveRecord::Migration
  def self.up
    ActiveRecord::Base.transaction do
      execute "
      CREATE TABLE dbo.Tmp_locations_users
        (
        id int NOT NULL IDENTITY (1, 1),
        location_id int NOT NULL,
        user_id int NOT NULL,
        created_at datetime NULL,
        updated_at datetime NULL
        ) ON [PRIMARY]
      "
      execute "SET IDENTITY_INSERT dbo.Tmp_locations_users OFF"

      execute "IF EXISTS(SELECT * FROM dbo.locations_users)
         EXEC('INSERT INTO dbo.Tmp_locations_users (location_id, user_id)
          SELECT location_id, user_id FROM dbo.locations_users WITH (HOLDLOCK TABLOCKX)')"
      execute "DROP TABLE dbo.locations_users"
      execute "EXECUTE sp_rename N'dbo.Tmp_locations_users', N'locations_users', 'OBJECT'"

      execute"ALTER TABLE dbo.locations_users ADD CONSTRAINT
        PK_locations_users PRIMARY KEY CLUSTERED 
        (
        id
        ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]"


      execute "CREATE NONCLUSTERED INDEX index_locations_users_on_location_id ON dbo.locations_users
        (
        location_id
        ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]"

      execute = "CREATE NONCLUSTERED INDEX index_locations_users_on_user_id ON dbo.locations_users
        (
        user_id
        ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
      "

      execute "update locations_users set created_at = '1-1-2010'"
      execute "update locations_users set updated_at = '1-1-2010'"

      add_column :locations_users, :position, :integer
    end
  end

  def self.down
    ActiveRecord::Base.transaction do
      remove_column :locations_users, :position
      remove_column :locations_users, :id
      remove_column :locations_users, :created_at
      remove_column :locations_users, :updated_at
    end
  end
end

I googled around and found several articles that told me exactly how to get bluepill to monitor delayed job and even one for monitoring apache, but none of them seemed to give me a way to create an init script that would ensure that if the server rebooted, bluepill would start up and make sure delayed job continued to work.

It took a while but I finally found this post in the bluepill google group asking about documentation and an init script. The author (Carl) later answered his own post with this gist containing an init script for bluepill! I thought I was set, so I set out to figure out how to create an init script for openSUSE, the flavor of Linux my company uses. A simple google search yielded this great post about creating your own init script in openSUSE.

I followed it’s directions and was very happy to find that issuing the following command /etc/init.d/bluepill restart resulted in bluepill being started and then executing bluepill status revealed that the delayed job process was indeed “UP” meaning that bluepill was doing it’s job. Then I rebooted the machine and what happened next isn’t for the faint of heart… after the machine rebooted and I SSH’d back into the box to check the bluepill log and I was devastated. The logs were reporting that bluepill couldn’t start!

1
2
3

Mar  3 18:32:02 if-suse11-stage bluepilld[2344]: [application_name:delayed_job] Start command execution returned non-zero exit code:
Mar  3 18:32:02 if-suse11-stage bluepilld[2344]: [application_name:delayed_job] {:stdout=>"", :stderr=>"script/delayed_job:3:in 'require': no such file to load -- rubygems (LoadError) from script/delayed_job:3", :exit_code=>1}
Mar  3 18:32:02 if-suse11-stage bluepilld[2344]: [application_name:delayed_job] Going from down => starting

Ok, so maybe it’s not that bad but I’m not a Linux expert (I’m decent, but only because I need to know Linux to host rails) and this was my first init script so I was pretty sunk. Having nowhere else to go, I turned to the author of bluepill himself, Arya. He was very helpful in answering my questions and as it turned out, my environment variables were not setup properly. Well, really the problem was that I had two installations of Ruby (apparently) and so the script was trying to start under the wrong one (I guess). Ayra’s suggestion in the issues section of his github page was to add this code:

1

export PATH="/usr/local/bin:$PATH"

It worked and I haven’t bothered to investigate much further. Here is my full init script, hopefully this will help someone else in the future!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

#!/bin/sh

# Author: Jon Kinney
# Based on the opensuse skeleton /etc/init.d/skeleton init script

### BEGIN INIT INFO
# Provides: bluepill
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: bluepill daemon, providing process monitoring
# Description: bluepill is a monitoring tool. More info at http://github.com/arya/bluepill.
### END INIT INFO

export PATH="/usr/local/bin:$PATH"

# Check for missing binaries
BLUEPILL_BIN=/usr/local/bin/bluepill
test -x $BLUEPILL_BIN || { echo "$BLUEPILL_BIN not installed";
        if [ "$1" = "stop" ]; then exit 0;
        else exit 5; fi; }

# Check for existence of needed config file and read it
BLUEPILL_CONFIG=/srv/www/app_name/shared/config/delayed_job.pill
test -r $BLUEPILL_CONFIG || { echo "$BLUEPILL_CONFIG not existing";
        if [ "$1" = "stop" ]; then exit 0;
        else exit 6; fi; }

case "$1" in
    start)
        echo -n "Starting bluepill "
        $BLUEPILL_BIN load $BLUEPILL_CONFIG
        ;;
    stop)
        echo -n "Shutting down bluepill "
        $BLUEPILL_BIN quit
        ;;
    restart)
        ## Stop the service and regardless of whether it was
        ## running or not, start it again.
        $0 stop
        $0 start
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
        ;;
esac

When checking the event viewer on the Windows Server 2k8 box I received the following error:

1
2
3

"The login packet used to open the connection is structurally invalid; 
the connection has been closed. 
Please contact the vendor of the client library."

I was pretty sure it had to do with my locale because if that was incorrect it would make sense that the packets might be structurally invalid. My locale was set to en_US.us-ascii the default setting apparently after a clean OS X Snow Leopard install. The problem was that I couldn’t figure out how to change it. Then I ran across this archived post and I was able to temporarily change my locale by typing:

1

export LC_ALL=en_US.UTF-8

I was able to verify my locale settings by typing locale in a terminal window which yielded the following:

1
2
3
4
5
6
7
8

LANG=
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

The problem is if I opened a new terminal window my locale was back to the default ascii junk. To make this change permanent I simply had to edit my ~/.profile and add the export statement that we set earlier to the bottom of the file.

1

export LC_ALL=en_US.UTF-8

Now when I open a new window and type locale it says en_US.UTF-8 for everything. At this point I was able to continue following Ken’s guide for testing the TSQL commands and getting ruby-dbi and everything else wired up.

Now I know what you’re thinking, why not create your own cap task that is called cap deploy_production and cap deploy_staging (or whatever), but I didn’t want to muck around with that. Here is how I get Capistrano to prompt ME!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165

default_run_options[:pty] = true
ssh_options[:forward_agent] = true
# also had to set up id_ras keys for the deploy user on the production box (to itself). And setup the tunnel definition as well in ~/.subversion/config
# Local => rs_ssh = /opt/local/bin/ssh -p 2384 -l jkinney
# Production => rs_ssh = /usr/bin/ssh -p 2384 -l jkinney

set :gems_for_project, %w(highline,will_paginate,etc...) # list of gems to be installed

# Make terminal prompt us for the location we want to deploy to
set :deploy_location, Proc.new { deploy_location = Capistrano::CLI.ui.ask "Enter deploy location (stage/prod)" }

if "#{deploy_location}" == "prod"
  set :domain, "209.41.75.42"
else
  # I have ssh setup on a non-standard port for my staging box, since it's exposed to the world. Our production box required VPN or local netowrk access.
  ssh_options[:port] = 2384
  set :domain, "YOUR STAGING IP HERE"
  # note that your staging could be on the same server, just setup your application names differently then so you aren't overwriting things.
end

# prompts for a release tag, if that is your sort of thing...
set :release_tag, Proc.new { release_tag = Capistrano::CLI.ui.ask "Enter a release tag to deploy (type trunk or leave blank and hit enter to deploy from trunk)" }

role :app, domain
role :web, domain
role :db,  domain, :primary => true

set :application, "jonkinneydotcom"

set :user, "deploy"
set :password, "secret"
set :deploy_to, "/var/www/apps/#{application}"

set :rails_env, "production"

# I thought this was automatic, but I seem to need to require it to cleanup my releases
set :keep_releases, 4
after "deploy", "deploy:cleanup"

# this is using subversion, I am transitioning to GIT and will post updates when I have a modified deploy.rb
set :repo_location, "/var/svn/your_subversion_repo"
set :repository, "svn+ssh://#{domain}#{repo_location}/#{application}/trunk"

namespace :deploy do
  desc "restart passenger"
  task :restart, :roles => :app, :except => {:no_release => true} do
    run "touch #{current_path}/tmp/restart.txt"
  end

  [:start, :stop].each do |t|
    desc "#{t} task is a no-op with passenger"
    task t, :roles => :app do; end
  end

  task :after_symlink do
    run "chmod -R a+rw #{release_path}/public"

    #rcov messes with deployed apps...remove it in production
    run "rm -rf #{release_path}/vendor/plugins/rails_rcov"

    # OPTIONAL: symlink files from the FTP site's home directory to the rails_root 
    # keep them protected and use send_file to present them to the logged in user 
    # (this is more secure than hiding them in a public directory with directory listing off)
    # run "rm -rf #{release_path}/admin_files" 
    # run "ln -s #{deploy_to}/#{shared_dir}/admin_files #{release_path}"    

    #symlink the files from outside the deploy path so we can keep all the uploaded images!
    # This will allow images uploaded through an asset manager to be retained between deployments
    run "rm -rf #{release_path}/public/assets"
    run "ln -s #{deploy_to}/#{shared_dir}/assets #{release_path}/public/assets"

    # setup database for production environment (database.yml should be ignored in svn)
    db_params = {
      "adapter"=>"mysql",
      "database"=>"yourapp_production",
      "username"=>"root",
      "password"=>"secret",
      "host"=>"localhost",
    }

    # OPTIONAL: Deploy to production with a sqlite3 database...because we don't need anything elaborage. 
    # And that way we can reset the db every hour or whatever with a cron job
    # db_params = {
    #   "adapter"=>"sqlite3",
    #   "database"=>"db/production.sqlite3.db",
    #   "timeout"=>"5000"
    # }

    db_params.each do |param, default_val|
      set "db_#{param}".to_sym,
      #if you want to be prompted uncomment the line below this and comment out the one directly below that
      # lambda { Capistrano::CLI.ui.ask "Enter database #{param}" do |q| q.default=default_val end}
      param = default_val
    end

    # builds the database.yml
    database_configuration = "production:\n"
    db_params.each do |param, default_val|
      val=self.send("db_#{param}")
      database_configuration<<"  #{param}: #{val}\n"
    end

    run "mkdir -p #{deploy_to}/#{shared_dir}/config"

    put database_configuration, "#{deploy_to}/#{shared_dir}/config/database.yml"

    #symlink the database.yml
    run "ln -s #{deploy_to}/#{shared_dir}/config/database.yml #{deploy_to}/current/config"

    #symlink the production database
    run "ln -s #{deploy_to}/#{shared_dir}/config/production.sqlite3.db #{deploy_to}/current/db"
  end
end

# This is what asks you if you're sure you want to deploy to production?!?!?
before "deploy:update_code", "user_confirmation_for_production_deployment"
task :user_confirmation_for_production_deployment, roles => :app do
  if "#{deploy_location}" == 'prod'
    message = "You are deploying to PRODUCTION. continue(y/n):"
    answer = Capistrano::CLI.ui.ask(message)
    abort "deployment to production was stopped" unless answer == 'y'
  end
end



######################Custom cap tasks that I find useful
desc "Configure VHost"
task :config_vhost do
  vhost_config =<<-EOF
<VirtualHost *:80>
  ServerName jonkinney.com
  ServerAlias www.jonkinney.com
  DocumentRoot #{deploy_to}/current/public
</VirtualHost>
  EOF
  put vhost_config, "#{deploy_to}/#{shared_dir}/config/vhost_config"
  sudo "mv #{deploy_to}/#{shared_dir}/config/vhost_config /etc/apache2/sites-available/#{application}"
  sudo "a2ensite #{application}"
  sudo "/etc/init.d/apache2 reload"
end

desc "create assets directory"
task :create_assets_directory do
  sudo "mkdir -p #{deploy_to}/#{shared_dir}/assets"
  sudo "chmod -R 777 #{deploy_to}/#{shared_dir}/assets"
  sudo "chown -R deploy:www-data #{deploy_to}/#{shared_dir}/assets"
end

desc "make current development database the production database"
task :upload_dev_db_to_prod do
  put(File.read("db/development.sqlite3.db"), "#{deploy_to}/#{shared_dir}/config/production.sqlite3.db")
end

desc "run remote command"
task :show, :roles => :app do
  run <<-COMMAND
    /var/www/apps/#{application}/current/script/runner -e production 'require "pp"; pp #{command}'
  COMMAND
end

desc "run remote rake db:migrate RAILS_ENV=production"
task :remote_db_migrate do
  run("cd #{deploy_to}/current; /usr/bin/rake db:migrate RAILS_ENV=production")
end

Hopefully this has been helpful. I know Capistrano can be somewhat of a black box for people, so if you have issues with my deploy.rb or need any help feel free to contact me or post in the comments!

Enable the cron.log for Ubuntu

By default, Ubuntu disables the cron log, so you need to turn it on, and additionally create the log file before you can start tailing that log.

Use these steps to get your log on:

Create the cron.log file

1

touch /var/log/cron.log

Edit /etc/syslog.conf and uncomment the line starting with cron.*

1

vim /etc/syslog.conf

Restart sysklogd

1

$ /etc/init.d/sysklogd restart

Restart cron

1

$ /etc/init.d/cron restart

Then to watch your cron jobs execute this command:

1

$ tail -f /var/log/cron.log

Here is a PDF of the sideshow: Advanced CSS Presentation which has a lot of great resources for everyone to use. The links inside the PDF are also clickable so that should work out great.

I posted my demo files in a zipped folder and also put them up in HTML format so people could view them that way if desired. I would recommend downloading the zip and viewing the source code in the following order as my comments in the HTML and CSS go from the most detailed to the least (in hopes that you don’t need a ton of comments each and every time! We are learning after all right?!?! :)

DEMOS!!

• 2 column with floating and negative margining
• Footer stick
• Form
• CSS Tables
• Newspaper 3 columns
• Newspaper 3 columns that auto match the height of each

Thank you very much everyone for coming and for the kind words! I would definitely be interested in presenting again if there is a topic that I know about that the rest of the group has interest in.

Fast forward 2 years and now I’m deploying servers in a mater of minutes, not days thanks to the deprec gem (using mongrel and nginx) and VMWare Virtual Center which allows us to store templates of our production rails servers. But VMWare VC isn’t the only Enterprise product that we’ve integrated with our rails development, we can deploy to Windows with IIS (though it still isn’t highly recommended because of performance concerns), OS X Server, and our de-facto favorite Linux Ubuntu.

Not only can we deploy the rails code on a solid hosted virtual private server (VPS), but we can also tie into a lot of the existing corporate Microsoft stack. This very blog has a SQL Server back end and authenticates against Inacom’s Active Directory with SSL over the LDAP protocol.

The bottom line is that Rails is ready for the enterprise, and it’s only getting better. Rails 2.2 will be thread safe, a feature that has been cause for some concern over the years, and it should allow for much better raw performance.

To check out some of the “rails applications that scale” see Rails in Action: The 56 Best RoR Driven Sites.

In the next few articles we’ll be detailing how we setup our production Linux server for this blog on Ubuntu 8.04 LTS and got it communicating with SQL Server via FreeTDS and the new awesome ActiveRecord ODBC adaptor written by Tim Haynes. But next, check out how we set up Active Directory authentication for this blog with a small mod to the the restful_authentication plugin.