Ok we’re a few days late, but http://www.sharespost.com has just launched. Citrusbyte helped the company get to an internal beta in only 6 weeks with a lean team of two. We then ramped in their new internal developer who pushed the site to live.

Check out more about the company here: http://www.crunchbase.com/company/sharespost

And the press: http://www.sharespost.com/pages/press

SharesPost makes private equity liquid by efficiently matching buyers, sellers of private company stock and giving them the information, tools and process to make transactions easy and safe. At SharesPost you can download research reports and corporate documents for hundred’s of private companies, including Facebook, Twitter and LinkedIn. Plus, see prices from previous transactions. When you’re ready, connect directly with buyers and sellers of private company shares without brokers or their commissions. SharesPost provides you with automated contracts and integrated e-signature and escrow services to handle transfer restrictions like company rights of first refusal and help process your transaction.

Meet Joe, the gem publisher

Joe builds on top of Thor’s awesomeness to take you from a gem specification to world domination in a single step:

$ thor joe:release

Given that you have a gemspec in place, Joe will build your gem and release it to RubyForge right away. The necessary steps to achieve this are broken up as Thor tasks just in case you need any of them separately. Check out the README to find out more.

What about Hoe?

Of course, there’s Hoe. But it introduces another level of indirection by adding a number of artifacts to circumvent actually writing a gemspec. If you want to have a code generator and a bunch of *.txt files instead of a simple and streamlined gemspec, by all means make sure to give Hoe a try. Chances are you already have it installed: until recently, Hoe used to produce gems that depended on Hoe itself. That’s why you’re likely to get something out of gem list hoe even if you’ve never used it to write a gem. Yeah, creepy.

Otherwise, spare yourself the hassle and try Joe, a guy that honors your gemspec and does the work for you. After all, maintaining your gemspec is not that hard.

Getting started

Check out Joe’s homepage in our labs and start rolling.

Feature: Search
  As a user
  I want to find information
  So I can learn more

  Scenario: Find what I'm looking for
    Given I am on the Google search page
    When I search for "rspec"
    Then I should see a link to RSpec-1.2.4: Home

Then you need to write your “step” files, where you add blocks with regular expressions that must match your plain English user stories and user acceptance tests. Inside those blocks you add your actual Ruby code. If you are using Cucumber for testing Rails or Sinatra, then your step definitions will look like this:

Given 'I am on the Google search page' do
  visit('http://www.google.com/')
end

When /I search for "(.*)"/ do |query|
  fill_in('q', :with => query)
  click_button 'Google Search'
  selenium.wait_for_page_to_load
end

Then /I should see a link to (.*)/ do |expected_url|
  click_link expected_url
end

Now that you have your plain English features files and your step files, you can finally run your tests. As a result, you will get a nice output of the user stories and user acceptance tests in plain English. But just to clarify that: the output is the same plain English stories you wrote at the beginning. The cost for this is to keep in sync two files for mostly the same thing.

In Citrusbyte we have a different workflow. We agree on the user stories with the client, and we put into instructions the user acceptance tests. We do that using Stories, which is a small add on for Contest. It allows you to declare user stories, scenarios and steps using Webrat. The same example, this time with Stories, would look like this:

class SearchStoriesTest < ActionController::IntegrationTest
  story "As a user I want to find information so I can learn more" do
    scenario "Find what I'm looking for" do

      visit "http://www.google.com/"

      fill_in "q", :with => "Citrusbyte Stories"

      click_button "Google Search"

      assert_contain "citrusbyte's stories"

      click_link "citrusbyte's stories at master - GitHub"

      assert_contain "Stories and User Acceptance Tests"
    end
  end
end

When you run that with the stories runner, you get this output:

As a user I want to find information so I can learn more
  — Find what I'm looking for
      Go to “http://www.google.com”
      Fill in “q” with “Citrusbyte Stories”
      Click “Google Search”
      I should see “citrusbyte's stories”
      Click “citrusbyte's stories at master - GitHub”
      I should see “Stories and User Acceptance Tests”

Now you can redirect that output to a text file and email it to your client, or you can use the stories-pdf runner, send the PDF straight to your client and get a delicious cake in return. Don’t believe me? Check this post.

You will have all your tests in one place, you will be writing Ruby, your clients will be happier than ever and the overhead will be minimal. Grab the gem from github and start impressing your clients today!

Test::Unit

Test::Unit is old and well tested, comes with the standard library ,and is easy to pick. The downside is that after using Shoulda and RSpec we fell in love with nested contexts - without them the code gets too large and not DRY. It leads to pulling out lots of helpers to reuse in your tests, which in turn takes your context setup away from your tests (a similar problem to what occurs with fixtures). As a test suite grows larger, the helper suite grows in a different place and it leads to hard-to-maintain tests.

RSpec

RSpec adds a magic syntax for no good reason. For example, compare these two assertions:

With RSpec:

@user.should have(4).friends

With the rest, using plain old Ruby:

assert @user.friends.size == 4

Or using a helper assertion:

assert_equal 4, @user.friends.size

While the magic syntax is helpful for getting into the BDD mindset, once you get it you can do BDD with any similar tool.

Another point against RSpec is the fact that its codebase is big and somehow unstable. Even if the developers are fast at patching bugs, the testing framework is a place where you really don’t want to deal with bugs. A larger codebase also means that you need more time to understand its internals in case you need to patch it yourself. Finally, RSpec is the slowest of the lot, and with large test suites the difference can amount to many seconds.

Shoulda

Shoulda provides what we want, but also provides features we don’t want to use. We don’t want macros, before_* statements, Rails or ActiveRecord integration. We want our testing framework to test our code, not code from other libraries.

In the end, Shoulda and RSpec give us roughly the same power (in terms of testing, ignoring that spec/mocks is included in RSpec), and Shoulda provides it with far less overhead (code that might need debugging but is difficult to understand). Shoulda forgoes the `foo.should be_valid?` syntax in order to avoid a couple of code smells. See the Shoulda announcement for more information about these code smells and the differences with RSpec.

We found that we actually really like RSpec and Shoulda because of BDD, but not because of their particular functionality or DSLs.

Our Ideal Framework

Reflecting on all these facts, we agreed that our ideal framework should have nested contexts to suit our BDD needs, be as small as possible, stable, and have no unnecessary magic.

As we looked at our needs for a framework, we realized that while RSpec and Shoulda are powerful, we could just add nested contexts to Test::Unit and that would fulfill our criteria. We did that with less than 100 lines of very simple code and called it “Contest”.

Here’s a quick sample of how it looks like:

require "rubygems"
require "contest"

class Array
  def rotate_left(n = 1)
    n.times { push(shift) }
    self
  end

  def rotate_right(n = 1)
    n.times { unshift(pop) }
    self
  end
end

class TestArray < Test::Unit::TestCase
  context "Array" do
    should "rotate elements to the left when sent rotate_left" do
      assert_equal [2, 3, 4, 5, 1], [1, 2, 3, 4, 5].rotate_left
    end

    should "rotate elements to the right when sent rotate_right" do
      assert_equal [5, 1, 2, 3, 4], [1, 2, 3, 4, 5].rotate_right
    end

    should "rotate elements to the left 2 places when sent rotate_left(2)" do
      assert_equal [3, 4, 5, 1, 2], [1, 2, 3, 4, 5].rotate_left(2)
    end

    should "rotate elements to the right 2 places when sent rotate_right(2)" do
      assert_equal [4, 5, 1, 2, 3], [1, 2, 3, 4, 5].rotate_right(2)
    end
  end
end

Contest is available in our labs and at github. Feel free to use it!

Left to right: Will Jessup (Citrusbyte CEO), Eric Galen (MusiKontrol CEO), David Appelbaum (Citrusbyte Project Manager)

Created by music industry professionals in Los Angeles, CA, MusiKontrol.com will soon launch a new artist development platform to help independent artists, writers and musicians succeed in the new music business. Eric Galen, its founder and CEO, says “We’re really excited to be working with Citrusbyte as our technology partner. We needed the best, and we found them.”

And in true Citrusbyte style, Eric and Will duked it out on their motorcycles in the Malibu canyons to see who would be baking who a cake.

And now, let’s see who won.

Thanks to MusiKontrol for the delicious cake!

Ok folks, one of our clients is hiring their full-time team to take over the work that we’ve done for version 1 of Causecast. The Senior Developer position is a great opportunity to drive efforts to build their internal tech team and to get a chance to play with the technology we put in place. The junior position provides a chance to be one of the FIRST developers at Causecast and learn from and work with CitrusByte’s first-class team.

About Causecast: Causecast CEO Ryan Scott is a developer himself who built and sold his last company NetCreations. He currently leads Causecast on a daily basis as well as invests in a number of great companies (Tesla Motors among them). Causecast provides a one stop shop for all things cause, giving nonprofits, leaders, and members opportunities to collaborate, share their experiences, and promote the causes they care about. Causecast launched at TechCrunch50 and received lots of praise, (”I would die to invest in Causecast” — VC Loic Le Meur). The mission they’re chasing down is good, being done the right way, and will make a nice business. Causecast is located in the Mahalo offices in Santa Monica, LA’s web hub.

Currently, there are 5 Citrusbyte guys working with Causecast on this. We’ve put in place some seriously robust technology. Initially, you’ll be working as part of our team while we ramp you into the code-base over the next few weeks/months.

Along with great technology ( RoR, RSpec, REST, jQuery, Alchemist, Sinatra, HAML, SASS and a slew of others), Causecast is using a full agile SCRUM process to run the project. The ideal candidate will be jumping into a well-built code-base and a great team.

Qualified candidates will:

* Have at least 2 years of web development experience
* Understand and believe in Agile web development principles.
* Be able to relocate to Los Angeles, with help from Causecast.

Please send resume + relevant experience building web applications, if your resume is up to par we’ll be in touch shortly.

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

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.

  ServerName  myrailssite.com
  ServerAlias www.myrailssite.com

  DocumentRoot /var/www/rails-project/current/public

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.