Programming Contest! And the Challenge is…Measure Rails Momentum

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.

(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.

• TwitterList.json= An array of twitter id’s of everyone following @dhh
• WeightbyCountry.json = An array of Countries with their Bodyweight Values.

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!