We also have to thank Rubicon for hosting the 10th meetup. They had an amazing looking location, and it even has a bit of Hollywoodesque history associated with it. Apparently, their space was used for the show 24, and we got to see Jack Bauer’s office which is pretty damn cool. We also overheard that Snoop Dogg laid some tracks down in one of the other rooms. Rubicon is definitely one of my favorite web-venues that I’ve seen.

The following was presented at the meetup:

Ari Lerner - Auto-Scaling cloud-computing on amazon EC2 + S3

Nick Merwin - Rolling with Red5 (open source Flash server)

Erik Osterman - Faster Response Times By Using the Starling Queue Server

To get the slides and example code, check out this post in the meetup boards.

Each presentation was equally entertaining and informative. Thanks for providing quality content to the community guys!

Here’s a photo I found off the meetup group for your enjoyment:

Jack Bauer's office is the office on the top right in this image

Looking for some videos? Why of course!

What are people saying?

The meeting was great, all the presentations were very informative and interesting, good choice of topics. The new format definitely work, let’s keep it. The Rubicon office was pretty fancy and served good food ;-) Thanks to Will for arranging this event, it was very well organized, like usual. - Oleg Baranovsky

I enjoyed this event very much! Thanks Will for organizing this event! The presentations were engaging, and it was great meeting all of you web gurus! The food and beer was awesome too! :) - Rob Stathem

Take a look at our meetup page for more details.

Were you able to attend the meetup? What did you think of it?

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Ari Lerner of CitrusByte and among other things, creator of PoolParty, a framework for maintaining and running auto-scalable applications on Amazon’s EC2 cloud.

…

FiveRuns: Amazon + Rails seems to be a prevalent choice right now, looking way back to the first instances as early as 2006, and seeing how far we have come. Can you talk a little bit about the benefits and challenges here?

Ari Lerner: Amazon’s Web Services is probably the technology that excites me the most at the moment. The unprecedented flexibility enables developers to play, explore and harness the growing landscape of cloud computing. The last time I felt the joy of working with a new technology, I was writing ‘Drug Warz’ on my Ti-83. If you have not yet looked into it, I highly suggest you take a peek.

Now to answer your question!

Cloud computing is all the rage today. Just as Rails revolutionized the web development framework, cloud computing is the next logical step in hosting, but it’s not going to solve all hosting issues. The non-technical challenge is to recognize it is just another weapon in your development tool-belt. The developer is the real secret sauce.

The largest technological challenges are configuration and maintenance of the EC2 instances. there is software on all sides of the spectrum that can aid in automating this process, from my own open-source PoolParty to commercial RightScale that aids in support.

Amazon’s EC2 makes it tempting to throw away proven techniques of deployment and management, but breaking the encapsulation of the methodologies just spells disaster. I am always in favor of using all the right tools available, but in their proper place.

I think it would be a mistake to have your application aware of its own hosting environment. You don’t want your software knowing it is running on a cloud, it should do what it does best… be the application.

That’s just a snippet of the interview. Go ahead and take a look at the full interview here.

Phusion Passenger is super easy to install and setup as an Apache mod and immediately simplifies the deployment of rails. It allows you to deploy a rails application without splitting your attention between the web server and app server, such as Nginx and Mongrel. You literally upload a configuration which looks like the following block of code to Apache and it manages your rails application for you.

<VirtualHost *:80>
  ServerName  myrailssite.com
  ServerAlias www.myrailssite.com
 
  DocumentRoot /var/www/rails-project/current/public
</VirtualHost>

Passenger gives rails the same ease of deployment as mod_php and mod_perl. And when you want, it will automatically reload your app if you deploy changes.

But the real gem is using Phusion Passenger with Ruby Enterprise Edition, which is a rewrite of the Ruby MRI with optimization for mod_rails in mind. The initial benchmarks show that using both together results in lower memory usage and increased requests per second. Since then, passenger has had a myriad of early adopters reporting their results. DreamHost praised Phusion for finally solving their rails deployment, after complaining only 4 months earlier of how rails deployment options were a joke. Other websites have boarded the Phusion Passenger train too, reporting easy setup and even easier deployment.

The results look good: Dead easy rails deployment with great performance.

So how do you get started? For dead easy server provisioning, check out Sprinkle, a gem which provisions servers for you. I’ve been hard at work implementing new features and patches to Sprinkle, which you can see in my fork. I have already created the sprinkle scripts to automatically setup this entire stack on a fresh ubuntu server:

• Rails (and Ruby, Rubygems)
• sqlite3 or mySQL
• Apache2
• Phusion Passenger (mod_rails)
• Ruby Enterprise Edition

If you’re interested in the automatic setup solution, I recommend checking out the screencast I made detailing the entire process. It requires a custom version of the sprinkle gem (from my fork), which the screencast covers.

If you plan on trying it out and have any questions, leave a comment or feel free to contact me at mitchell.hashimoto [at] citrusbyte [dot] com and I’ll happily provide any assistance you may need.

Luckily, it is hosted at github and they have an API to access their changesets. Now, on PoolParty’s website, I am surfacing the latest changeset’s time, message and author as well as a link to the changeset.

How?

Code (shortened for brevity purposes):

$:.unshift(File.dirname(__FILE__))
require "rubygems"
require "yaml"
require "open-uri"
 
class Grab
  @url = "http://github.com/api/v1/yaml/auser/pool-party/commits/master"
  @refresh_after = 20
 
  def self.latest_commit_object
    o = yaml["commits"][0]
    {
      :message => o["message"].gsub(/\n/, "<br />"),
      :date => Time.parse(o["committed_date"]).timeago,
      :by => o["committer"]["name"],
      :url => o["url"]
    }
  end
end

The github api is slick. As you can see from above, the format for the api url looks like

http://github.com/api/version/format/username/repository/type/object

Where the variables there correspond to:

• Current version: v1
• Acceptable formats: json, xml, yaml
• Acceptable types: commits, commit

Grabbing the latest changesets from the url as YAML format, we can quickly and easily parse the message into a useful hash.

I personally like the “# hours ago” syntax that 2.0 sites are popping up with everywhere, so I just added a timeago method that is very similar to the one included with rails. The source is attached.

Since I don’t want poolpartyrb.com’s load time to be dependent upon how fast it can hit github, I cache the variable so every 20 views it refreshes.

Use in Rails

Save both the files (attached below) to your lib directory.

Add this to your environment.rb

require 'grab'

Then add this helper to your application_helper.rb

  def show_latest_commit
    @latest_commit = Grab.latest_commit_object
 
    <<-EOS
      <div class='note'><strong>Latest commit</strong><br />
      <a href="#{@latest_commit[:url]}">#{@latest_commit[:message]}</a>
      <div class="highlight">by #{@latest_commit[:by]}</div>
      #{@latest_commit[:date]}
    EOS
  end

How to use in sinatra

I use this on poolpartyrb.com, which is a sinatra site. I do basically the same as above, but generally render the code in haml instead

  $:.unshift(File.dirname(__FILE__))
  require "sinatra"
  require 'grab'
 
  get '/' do
    @latest_commit = Grab.latest_commit_object
    haml :home, :layout => :layout
  end

Then in my home.haml

  .note
    %strong
      Latest commit
    %br
    ==<a href="#{@latest_commit[:url]}">
    = @latest_commit[:message]
    </a>
    .highlight
      == by #{@latest_commit[:by]}
    = @latest_commit[:date]

Get the code here

edit: updated location of code

Is your EC2 server pool starting to look like this?

PoolParty can help you turn it into this:

Why would I need PoolParty?

Amazon’s Elastic Compute Cloud has made it cheap and straightforward to run your own server pool, but there are various issues with volatility, lack of load balancing between instances, no persistent instance storage (currently in private beta). Also there is no mechanism for scaling your instances dynamically (ie, adding or removing instances as your load changes).

That is all taken care of by PoolParty, a recently open sourced Ruby gem and the brainchild of fellow CitrusByte developer Ari Lerner. PoolParty takes care of the following:

• Automatic scaling based on demand and load
• Starting/stopping instances
• Self-healing
• Provisioning and bootstrapping initial software
• Setting up S3Fuse
• Load balancing with HAProxy
• Built-in monitoring
• Plug-in architecture for extendability / customization

How?

PoolParty is based on established open source technologies that have been widely used in production. It takes your EC2 server pool, and invites S3Fuse, monit, and members of the High Availability Linux Project . Now you don’t just have a pool. You have a rocking pool party. All you have to do is sign those invites! (In other words: just provide a config file and you’re done).

More Information

You can check it out at the official PoolParty website. Tutorials, walk-throughs and articles are coming soon.

If you are interested in active development, check out the source at github. Active discussion is on the PoolParty Google Group

Here are the slides from the talk Ari gave at RailsConf sessions (also available here):

The format is as follows: we’ll present a problem, then everyone will try and write the most idiomatic, concise code that solves the problem in a readable fashion. This is not meant to be a golfing competition, nor an optimization one. However, we will benchmark the solutions for a rough idea on how different styles affect performance. For every installment we’ll have a performance winner for fastest time and a ’style’ winner for the most elegant code.

This gives us at CitrusByte a better understanding of each other’s coding styles, and stimulates discussions about little tricks we may not be aware of. Best of all, it’s fun as heck to be a part of.

You can get involved too! Leave a comment with your solution if you think you can best the ones listed here. We also encourage you to propose a simple problem (less than 20 lines of code to solve) for the next instalment in the series.

Since this is the first time we’re doing it, we’ve picked a very simple problem to solve as a quick warm-up.

Problem: given a string ’str’ of the format

"a10 b20 c25 d40"

convert it to a hash

{'a' => 10, 'b' => 20, 'c' => 25, 'd' => 40 }

Note that the values of this hash are integers, not strings. If the string is

"a10 a20"

the output should be

{'a' => 20}

.

Leaving some spoiler space in case you want to try it on your own. Below are selected solutions from our team.

Spoiler space

Solutions

Michel

Hash[*str.scan(/(.)(\d{2})/).map { |k, v| [k, v.to_i] }.flatten]

Time taken: 9.99s

Tim

Hash[*(str.scan(/(\w)(\d+)/).map {|k, v| [k, v.to_i] }.flatten)]

Time taken: 9.40s

Tim’s comments: the splat operator has low precedence so the outermost set of
parantheses are redundant, but I felt it’s better to have them there to make it
very obvious what’s going on.

Nicolas (winner: speed award)

str.scan(/\s*(\D+)(\d+)/).inject({}) {|h,(k,v)| h[k] = v.to_i; h }

Time taken: 7.19s

Nicolas’s comments: I like inject/reduce/fold, whatever you call it. It’s
concise and usually a perfect fit for constructing enumerable data structures.

Martin (winner: style award)

str.split.inject({}) {|h,i| h[i[/^\D+/]] = i[/\d+$/].to_i; h }

Time taken: 8.75s

Ari

hash = str.split.inject({}) do |set, h|
  set.merge( {h[0].chr => h[1..-1].to_i} )
end

Time taken: 23.02s

Ari’s comments: I knew everyone else would be strutting their one-liners, so I went for as much clarity as possible. I feel this code not only solves the problem, but also makes it very apparent what the desired solution is.

Benchmark code

require 'benchmark'
 
ITERATION = 400
 
def measure(&block)
  ITERATION.times { block.call }
end
 
str = ''
5000.times { str << ('a'..'z').to_a[rand(26)] + (rand(90)+10).to_s + ' ' }
br = Benchmark.bmbm do |b|
  b.report("Running #{ITERATION} times on string of length #{str.length}") do
    measure {
      #### Code to measure goes here
    }
  end
end

Conclusion

Lots of interesting styles here. We have two ways of creating hashes: with the Hash[ [key =>|, value]* method and with inject().

We’ve also seen various ways of breaking up a string: with scan(), with split(), and with regex arguments to a string’s [] method. While we cannot come to definite conclusions about performance (since the code that is being compared doesn’t differ just in one area), we can see a couple things going on:

• running Hash[] on an array as opposed to creating it directly via inject hurt Michel and Tim’s performances compared to Martin/Nicolas
• merge() seems to be significantly more costly than straight addition/replacement of hash keys. If you’re ever injecting into a hash it may be wiser (if your problem allows) to follow the { hash[key] = value; hash } format instead of merging.

We’ve picked Martin as the style winner for the elegance of his code which fit of the string parsing inside the inject block as opposed to the scan-based solutions which did some of it outside in the scan. The h[i[/^\D+/]] = i[/\d+$/].to_i portion was the clearest signal of intent for the contents of the hash.

Meanwhile, Nicolas is the performance winner by a mile, coming in more than 20% faster than the nearest competitor.

Congratulations to Martin (style) and Nicolas (speed) for being the winners of the inaugural CitrusByte Ruby TMTOWTDI. Stay tuned for the next episode!

EDIT

Additional comments by Nicolas:

Anyway, after thinking about it, even if I like inject a lot, there’s one big gain for the Hash[*...] as Michel posted. It
transmits intent better, in a way.

You look at that and the entire code sequence is a Hash construction, plain and simple, even if you ignore the subexpression in the middle, you know the outcome. And if you look one character into the brackets, then you know it’s constructing a hash from some transformation of an existing enumerable. Bah, just something that responds to #to_a.

Instead, using inject, the code flows (at least in my head) nicer as you don’t have to parse subexpressions, but it’s not immediately obvious what’s it about.

Hm, actually, depends on what intent is better to show. I mean, the objective is something like “to transform a string in a certain format into a more traversable structure” or “to create a hash out of a string in a certain format?”

That (not so) subtle difference might make me decide about which way is better, but then the description of the problem is not descriptive enough. Good, that means that the problem lies in the exercise’s designer. I can sleep well :P

(Probably there’s a third approach that to a degree involves a recursive lambda and someone flying over a desktop yelling “stand back! I know hash construction”, but my ninjitsu is not good enough for that yet) ]]> http://blog.citrusbyte.com/2008/06/02/ruby-tmtowtdi-episode-1/feed/ http://blog.citrusbyte.com/2008/06/02/ruby-tmtowtdi-episode-1/ http://feeds.feedburner.com/~r/Citrusbyte-Home/~3/358912246/ http://blog.citrusbyte.com/2008/04/18/bnet-interview-building-successful-web-companies/#comments Fri, 18 Apr 2008 23:06:47 +0000 Daniel http://localhost/wordpress/?p=26

Will Jessup is a founder and Managing Member of CitrusByte, a forward-thinking web application development business. Jessup talks about his company structure and how it attracts the best unique talent for his clients.

AOL is the sponsor of this months meetup on April 22nd at 8pm. We’ll get between 50-75 developers together and go over some quick presentations about new cool stuff , eat some pizza and chat. The presentation format is 5-10 minutes on something that web application developers should know, followed by 5 minutes Q&A. There are four open slots right now, so please send me your proposals for a presentation!

When?: Tuesday, Apr 22, 2008, 8:00 PM

Where?: AOL, 331 N Maple Dr, Beverly Hills, CA 90210

Join us at Los Angeles’s biggest meetup for web application developers. Find out what’s new in development for the web. Presenters will allow you to pick up a few tips and tricks and find out about new tools. After our presentations enjoy refreshments (and beer) and network with other local developers.

http://web.meetup.com/34/

The trouble w/ fixtures

I don’t use fixtures in my specs. At all. The fundamental issue with fixtures is that they setup a state for your database as a whole (or at least the tables you loaded). So when you use fixtures all your specs are running against essentially the same state. As you build your application and things get more complex your fixtures become more complex and your state grows and grows. The needs of your specs, however, should pretty much stay the same. So when you go back and track down an issue causing some spec to blow up you have to deal with that spec running in a state that’s way beyond it’s needs.

Brittle specs

For example, lets stay I’m writing a spec to ensure that book.authors.living does not return any deceased authors. The state that I need to spec this is very simple: 1 Book with 1 living Author and 1 dead Author. Then I just need to make sure that when I run book.authors.living I don’t get the dead Author back. It might look something like this:

describe Book do
  describe "with authors" do
    fixtures :books, :authors
 
    it "should only find living authors" do
      Book.find_by_title("Foo's Diary").authors.living.should == [Author.find_by_name('Jim')]
    end
  end
end

Assuming I know that Jim is alive this would be a good spec. The problem is as I write specs I’m going to add more and more authors and this spec will quickly blow up. It’s not blowing up because the .living method broke though, it’s just blowing up because it’s no longer running in the state it expected.

Kill your fixtures

Without fixtures I would do something like:

describe Book do
  describe "with authors" do
    before :each do
       @book = Book.create! :title => "Foo's Diary"
       @book.authors << (@jim = Author.new(:name => 'Jim', :dead => false))
       @book.authors << (@jeff = Author.new(:name => 'Jeff', :dead => true))
    end
 
    it "should only find living authors" do
      @book.reload.authors.living.should == [@jim]
    end
  end
end

Now my spec will always run in the state I gave it. So the things I setup for my other specs won’t come back and blow this spec up. Furthermore, the state isn’t buried in multiple fixture files. It’s defined plainly right above the spec(s) which use it.

Simplify your life even more

Once you ditch your fixtures you’ll find a new love for writing specs. There’s a couple handy tools to simplify your life further though:

Factories

Dan Manges blogged about using factories to simplify creation of classes and to provide defaults. Since then there’s been a few plugins developed for quick and easy factories. We’ve been using Scott Taylor’s Fixture Replacement.

add!

add is similar to the << method of has_many associations except it sacrifices chainability in order to return the concatenated object. add! goes a step further and throws an exception if the concatenation failed. This is useful in specs because the exception (probably due to a validation error) will occur in your state setup and you will see the error message in your output when you run your specs. So the reason your spec just blew up is displayed for you.

With Fixture Replacement and add! the example above would look something like:

describe Book do
  describe "with authors" do
    before :each do
       @book = create_book :title => "Foo's Diary"
       @jim = @book.authors.add! new_author(:name => 'Jim')
       @jeff = @book.authors.add! new_author(:name => 'Jeff', :dead => true)
    end
 
    it "should only find living authors" do
      @book.reload.authors.living.should == [@jim]
    end
  end
end

Adding instead of concatenating

Using book.authors << Author.new(:name => ‘Geoff’) returns true or false forcing you to do something like book.authors << (geoff = Author.new(:name => ‘Geoff’)) to maintain a reference to the new object. Using .add you can do geoff = book.authors.add Author.new(:name => 'Geoff')

No really…add!ing

Perhaps even more helpful (especially in specs) is the add! method. add! acts just like add except it raises a RecordInvalid exception on failure. So you can do geoff = book.authors.add! Author.new(:name => 'Geoff') and have your execution (or your transaction) halt if Geoff messed up and wasn’t valid.

Blowing up your specs

This comes in handy a lot in your specs as exceptions will be displayed as the reason for failure. So if you were to add a validation to your Author class that caused all the Author’s you were adding to Book’s all over your specs to be invalid, you would see it (along with your validation’s helpful error message) when you ran your specs.

The goods

Just drop this in a file in your /lib folder and require it in an initializer.

module ActiveRecord
  module Associations
    class AssociationCollection < AssociationProxy #:nodoc:
      # works just like << except returns the added records instead of self, so
      # it's not chainable but allows you to do something like:
      #   @jim = Book.authors.add Author.new(:name => 'jim')
      # (often saving a whole line of code!)
      def add(*records)
        self.<<(*records)
        unarray_if_lonely(records)
      end
 
      # works just like add except raises an exception on error
      def add!(*records)
        raise RecordInvalid.new(*records) unless self.<<(*records)
        unarray_if_lonely(records)
      end
 
      # if the given object is an array of size 1 then it returns the only
      # element itself (w/ no array), otherwise it just gives back object
      def unarray_if_lonely(object)
        (object.is_a?(Array) && object.length == 1) ? object.first : object
      end
    end
  end
end