Engine Yard Cloud

Blog

Archive for 2009

Rails Roadshow Coming Home!

By | November 16th, 2009 at 5:11PM

Earlier this month, the Engine Yard crew took a quick trip around the states, stopping in five different cities to talk about Rails Performance in the Cloud. We visited Boston, Chicago, Austin, Los Angeles and Seattle, and met with a great crowd of technologists in each. We were joined by some of our favorite technology partners, who talked about cloud computing and their different performance-related products.

The Roadshow was a fantastic success; attendee feedback was overwhelmingly positive, and on our end, it was great to get out and meet folks in their home cities. Our partners enjoyed meeting existing customers, and for those who weren’t customers, we were able to present a uniquely well-rounded view of the ecosystem.

On to the point: the Roadshow was so fantastic, that we decided we ought do it one more time—this time, here at home, in San Francisco. I’m happy to announce the sixth iteration of the Rails Performance in the Cloud Roadshow, set for Wednesday, December 2nd, bright and early in the day.

We’ll be hosting right here at Engine Yard Headquarters in the SOMA part of San Francisco, and will be joined by our partners at New Relic, Pivotal Labs, Soasta and CVSDude. We’ll go from 8:15 in the morning until noon, and of course, breakfast will be served.

Space is limited, so reserve your seat today!

Popularity: 1% |

Programming Contest! And the Challenge is…Measure Rails Momentum

By | November 12th, 2009 at 6:11PM

We announced the Worst App Server Ever (WASE) contest last week, as the second in a series of Engine Yard programming contests. Since then, we’ve heard lots about your efforts to put a basic twitterbot together, and now the time has come to describe the challenge computation. Remember: you have until 5 p.m. Monday to complete your calculations!

UPDATE: Challenge calculations submissions should be in the form of a RETWEET to @engineyard of the first message in your wase program from your home twitter account.  The final WASEpoint in your program listing should be @eycontest (so we can measure who finished first). You can register your wasepoints here.]

People often talk about the momentum of intangible things, but it’s always been pretty much impossible to define. No Longer! In this contest, you’ll be measuring the momentum of Rails. How will you accomplish this, you ask?

Well, since Rails is its community, if we can measure the mass, speed and direction of the Rails community, then (clearly!) we can establish its momentum. For the purposes of this contest, and to make things easy, we will use as a rough proxy that the Rails community is everyone following @dhh on twitter.

You must perform the following tasks to establish Rails momentum:

1) Establish the mass of the Rails community: defined as looking up the locations of all @dhh followers from Twitter, geo-coding their locations, and then multiplying the number of people in each location by the average body mass of an adult in that country.

2) Establish the current location of the Rails community: defined by taking the locations and body weights from step 1, and calculating the community’s center of mass (its centroid).

3) Establish the speed and direction of the Rails community: defined by taking its current location (calculated in Step 2) and comparing it to the origin of Rails. Rails 1.0 was released in Chicago on December 14th, 2005, so in the approximately 1,430 days since then, its location has moved. This means we can calculate its average speed and direction over the last four years.

Although we will expect the answer in the form of JSON object properties, the answer (in free text) to the contest would look like:

  • Rails Momentum is 15 metric tons per hour with a bearing of 120 degrees. Its current location is latitude 38.898748 ° and longitude -77.037684°

Guidelines and Suggestions for Implementors

Please refer back to our earlier post for rules on how your entry must be structured and submitted. This description goes into details on the format of the input data and provides suggestions for WASEpoints and tips on what to avoid. A significant meta-challenge is agreeing on intermediate object formats with your fellow contestants! We have not specified what they should be.

1) Calculating the mass of the Rails community

The input data set has an array of all the twitter ID’s currently following @dhh. Twitter limits your API access to 150 calls per hour, unless you are a Twitter white-listed developer—so there is a clear opportunity for a white-listed developer to create a popular WASEpoint. If you’re not a white-listed developer, be prepared to collaborate with others to pool your twitter requests via WASEpoint chaining. We will make an exception to the standard WASEpoint rules here on “no state at a WASEpoint” and allow people to create WASEpoints for others that provide a cached location lookup for the location property of each follower.

Only about 50% of twitter user profiles have standard formatted locations in the form of [City, State], [State, City] [State] or [City, Country], [Country, City] [Country]. Location data that lacks this format should be discarded, and the corresponding followers ignored. There’s an opportunity here to write a WASEpoint that cleans and standardizes this data-set for others to use. We do not expect you to geocode imprecise location tags such as “The Midwest” or “Somewhere in the Clouds”.

There are many REST-accessible geocoding services on the web. Both Yahoo and Google have REST API’s and there are other responsive geocoding services with Ruby clients. We include a list of standardized countries and the average adult bodyweight as part of the input dataset for use in calculations. (It was actually quite surprising to see how many sources we had to go to to get this data, and it’s mostly only accurate for OECD countries—most countries simply contain weights based on an average BMI.) Bodyweights are in kilograms. This is another module of work that would make a nice WASEpoint.

2) Calculating the current location

Calculating a center of mass for a sphere like the earth would basically put Rails in the center of the earth, but we didn’t want to imply that Rails has gone to hell. Instead you are allowed to assume a flat-earth when calculating the centroid of the community, and the center of this flat mapping should be at Chicago’s longitude and the equator’s latitude. This latitude/longitude is provided as part of the input data set.

This puts the “edge” of this map approximately in western China, so India is to the “east” of Chicago, but Bangladesh would be “west” of Chicago. In this map, the center of mass for a developer in India and a developer in Bangladesh would not be on their border, it would be in the Caribbean. There is a clear opportunity here to write two WASEpoints: one that geocodes correctly and one that calculates centroids correctly.

Programming contest sample world map

(If anyone wants to tackle calculating a true 3D centroid with a projection back to the nearest point on the earth’s surface that would certainly be a strong candidate for third prize (best WASEpoint))

3) Establishing the speed and direction

Rails 1.0 was announced in Chicago (lat 41 54 long 87 39 ) on Dec 14th, 2005. If you establish that the center of the community is now in (for example) Albany, New York (lat 42 45 long 73 48), then it has traveled approximately 711 kilometers in 1,430 days, giving it an average land velocity of about 0.25 km/hr (unladen), and a final bearing of about 80°. For this part of the calculation we DO expect you to consider the earth spherical, but there are a number of handy math guides on the internets to help you calculate bearings from latitude and longitude data. This conversion alone could make a nice WASEpoint for others to use.

The Input Data Object

We have posted the input data for the challenge on web. We’re giving you two JSON files in UTF-8 format.

The Output Data Object

  • We will accept output data in whatever data format your final WASEpoint emits, but it must be obvious to us what the momentum number is and what the bearing is. We would suggest the following json format however (with sample data):

{“RailsMomentum”:{“Momentum”:{“kgs per meter per second”:15},”location”:[{"latitude":333333,"longitude":333333}],”bearing”:{“degrees”:36,”minutes”:45,”seconds”:45}}}

Simple enough, right? Well, no one every said it was going to be easy! In fact, we tried to structure this, so you’d have to compete as part of a team! Good luck—we can’t wait to see how it goes!

Popularity: 2% |

Using the Rubygems Bundler for Your App

By | November 12th, 2009 at 11:11AM

The new Rubygems bundler makes managing your application’s gem dependencies easy. And for applications with many components, it makes separating components’ dependencies easy too.

Let’s start off with a simple, two-part application. Part 1 is a Sinatra app that puts JSON-serialized messages into an AMQP queue. Part 2 is a daemon that consumes those messages.

Here’s what a Gemfile for this application might look like:

gem 'json'
gem 'sinatra'
source 'http://gems.github.com'
gem 'famoseagle-carrot', :require_as => 'carrot'

gem 'eventmachine'
gem 'amqp'

The Sinatra app starts off with these lines:

# This makes sure the bundled gems are in our $LOAD_PATH
require File.expand_path(File.join(File.dirname(__FILE__), 'vendor', 'gems', 'environment'))

# This actually requires the bundled gems
Bundler.require_env

class MyApp < Sinatra::Base
  # stuff

The daemon starts like this:

# This makes sure the bundled gems are in our $LOAD_PATH
require File.expand_path(File.join(File.dirname(__FILE__), 'vendor', 'gems', 'environment'))

# This actually requires the bundled gems
Bundler.require_env

AMQP.start do
  # stuff

However, this loads too many gems. The Sinatra app synchronously publishes its messages using carrot, so it doesn’t need the EventMachine gem or the AMQP gem. Likewise, the daemon doesn’t serve HTTP requests, so it doesn’t need Sinatra, and it’s processing messages asynchronously using EventMachine, so it doesn’t need Carrot.

This isn’t the end of the world for this set of gems; it just makes all the Ruby processes use a little more memory than they otherwise might. However, if the Sinatra app uses one gem that defines Array#foo one way, and the daemon uses another gem that defines Array#foo an entirely different way, then each component must require only its own dependencies.

Fortunately, the bundler makes this really easy: just change the Gemfile to look like this:

gem 'json'

only :app do
  gem 'sinatra'
  source 'http://gems.github.com'
  gem 'famoseagle-carrot', :require_as => 'carrot'
end

only :daemon do
  gem 'eventmachine'
  gem 'amqp'
end

In the Sinatra app, change Bundler.require_env to Bundler.require_env(:app). This loads JSON, Sinatra, and Carrot, but not EventMachine or AMQP.

Similarly, in the daemon, Bundler.require_env becomes Bundler.require_env(:daemon).

But wait, it gets better!

Bundler.require_env can be called more than once with a different environment name each time. Consider tests (which, of course, you wrote first, right?): you want to run them. Now your Gemfile might look like this:

gem 'json'

only :app do
  gem 'sinatra'
  source 'http://gems.github.com'
  gem 'famoseagle-carrot', :require_as => 'carrot'
end

only :daemon do
  gem 'eventmachine'
  gem 'amqp'
end

only :test do
  gem 'rspec'
  gem 'webrat'
end

Then, in your spec, you start like this:

require 'my_app'       # load the Sinatra app so we can test it
Bundler.require_env(:test)    # get rspec and webrat in here

describe "the main page" do
  # stuff

Now each part of your app has its dependencies neatly contained. Each part only gets what it needs, and the different dependencies can’t step on each others’ toes.

Sweet.

Popularity: 6% |

Ruby Week Startup Crawl!

By | November 11th, 2009 at 2:11PM

Startup Crawl

Next week is going to be quite the week for Ruby in San Francisco, with QCon, RubyConf and JRubyConf. Engine Yard is excited to be participating in all three events, but there’s even more to tell you about!

With so many Rubyists in town, it only made sense to find a way to have you all over for drinks and socializing. As such, we’ve signed on to participate in the RubyConf week Startup Crawl. We’re working with our friends over at Scribd, along with a host of other local startups (Zendesk, Yammer, Justin.tv and more!) and opening our doors to everyone.

The Crawl will take place Friday evening, November 20th; there will be buses leaving from the RubyConf hotel starting at 5:30 and making trips back and forth until 11 p.m. We’ll have food, drinks, giveaways, and of course Engine Yard Cloud demos for all.

If you’re planning on taking the bus, be sure to sign up at the Startup Crawl site, so we can be sure there’s enough transportation for everyone. Otherwise, feel free to walk in any time after 5:30—we’d love to meet you!

Popularity: 1% |

Nginx Security Vulnerability: SSL Man in the Middle Attack

By | November 10th, 2009 at 10:11AM

A security vulnerability in all versions of nginx (as well as several other web servers) has been reported. Attackers can exploit this vulnerability by intercepting SSL sessions and compromising encryption key renegotiation via a plaintext injection, allowing the attacker to read the plaintext of the SSL session. A patch has been released for this vulnerability.

Engine Yard customers have already been contacted via email about this issue. For Engine Yard Cloud customers, this patch will be automatically applied the next time you perform a deploy. All other customers should open a support ticket so that you can arrange an appropriate maintenance window with support.

Popularity: 1% |
« Older Entries
Newer Entries »
Connect with us: RSS Twitter Facebook LinkedIn

Copyright © Engine Yard, Inc. All rights reserved.