bgror

Fáilte Orchestra Contest Winner: Daniel McOrmond’s Irish Orchestra.io Tweets »

Created at: 21.09.2011 00:45, source: Engine Yard Blog, tagged: community Contests events contest funconf php

It's with pleasure that I announce Daniel McOrmond as the winner of our Fáilte Orchestra competition.

Daniel's "Irish Orchestra Tweets" entry is a dead simple app that takes the tweet-stream from the @orchestra_io Twitter account, displays them against a cringe-worthy 'oirish backdrop, and translates them to what appears to be an American's interpretation of what an Irish accent sounds like.

I mentioned last week that we wanted the "smartest, wittiest or most-charming" app, and Daniel's entry was most fitting. We really felt that it was in the spirit of the competition: combining some nice cheesy Irish humour with a nice little application of technology. Nice work, Daniel! We'll see you in Ireland for Funconf!

Win a Trip to Ireland on Engine Yard »

Created at: 08.09.2011 23:51, source: Engine Yard Blog, tagged: community Contests events contest funconf php

As you have heard, Engine Yard recently joined forces with Orchestra. Not only was this big news for the PHP community in general, it was huge for the Irish tech community.

What you may not know is that last year, Eamon Leonard, co-founder of Orchestra co-organised Funconf with me. Engine Yard were huge supporters of Funconf last year, and their support is even more significant this year.

I'm delighted to announce "Fáilte Orchestra" : your chance to win a once-in-a-lifetime trip to Ireland.

The prize includes:

• Return Flight to Ireland (up to $1500, depending on where you are)
• A Ticket to Funconf (includes 2 nights accommodation and all food and drink, and an amazing lineup)

To be in with a chance to win, in true Irish style, we're looking for the "smartest, wittiest or most-charming" app deployed on http://orchestra.io. Here are the rules:

• The app must be your original work but feel free to make use of frameworks and libraries (e.g. CakePHP, PEAR)
• It must be open source
• It must (obviously) be deployed on Orchestra

That's it! We want you to be creative, smart, witty, interesting. What will win this will be the app, or page, or project that makes us laugh the loudest, or drop our jaw in awe, or is just plain awesome.

To enter, send a tweet (CC: @engineyard) with the hashtag #failteorchestra with a link to your deployed Orchestra app, and a link to the Github repo.

Please get your entries in before midnight on the 15th of September. The winner will be chosen and announced here on the 16th.

You have 7 days. Let the games begin, and good luck!

Engine Yard Lucky 13 Contest »

Created at: 10.12.2010 04:50, source: Engine Yard Blog, tagged: Uncategorized contest java ruby

UPDATE: The contest is closed. We will be sending shirts to everyone who tweeted before this update was added 12/11/2010 @14:00 PST. You will be notified via Twitter. Thanks so much! Attention Java and Ruby engineers: A box of snazzy new Engine Yard t-shirts just arrived at our San Francisco office. Want one? Read on puzzlers! The *Lucky 13* blog post spawned some gambling gossip. Earlier this week, eye-witness accounts reported that Charles Nutter was playing roulette with reckless abandon. Charles placed bet after bet on his lucky number *13*, ignoring the odds, and his friends' advice. Here's where you come in. It's your job to explain Charlie's payout in code. In Java, write a method that takes an argument for the size of his bet. Call the Engine Yard Roulette Wheel, which returns the winning number (okay, it's actually a string). Return Charlie's payout based on a winning *Lucky 13*. Use as few lines of code as you can. Ruby readers: same problem. Ruby. Go! To qualify for a snazzy new Engine Yard shirt, you must:

Programming Contest! And the Challenge is…Measure Rails Momentum »

Created at: 13.11.2009 03:25, source: Engine Yard Blog, tagged: Contests contest rails

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!