Chris Ferguson, Development Manager for Active.com, and I have been at Techcrunch Disrupt in San Francisco this week. We're here to stay in touch with the latest in technology and to spread the good word about The Active Network. Yesterday Mark Zuckerberg was scheduled to speak at 2, and this was his first public speech since Facebook went public earlier this year. We knew his would be a popular session, so we got to the conference early in order to score a good seat. Our sacrifice paid off as we were 5 rows from the front of the stage (about 30 feet). And to put this into context, there are about 200 rows setup in the conference hall.
The place was packed, and people were crowding toward the front of the stage as they would if we were at a Pearl Jam concert. Zuckerberg does enjoy rockstar status after all. Here's a shot I took looking backwards from my seat.
When the CEO of Facebok finally took stage, I was able to snap a great picture with my iPhone.
Michael Arrington interviewed him. Arrington is by far the best interviewer at the conference this year. I agree with one attendee when she tweeted "I wish @arrington did all the interviews. He's like the Jon Stewart of Startups". As for me, I felt like a school girl seeing Justin Beber in person for the first time. Regardles of how insightful his first public appearance in recent months may have been, it was amazing to be in the presence of such an influential technologist.
Three of the products I run technology for are built in Ruby on Rails. Two of those projects use HAML as the view templating language, while the third is in ERB. In an informal effort to explore the pros and cons of each to determine if standardization across teams was necessary I ignited a religious war. Some are passionately pro-HAML, while others are passionately pro-ERB. Today, in order to be more objective about things, I held a meeting with all of the Ruby developers to compare the two. Here's what we came up with:
And here's a translation (black - "pro", red - "con")
Close to HTML
Close to CSS Syntax (+1)
ERB is applicable to all view files (via extension)
Value given to Whitespace (+2)
Value given to Whitespace (yes, someone argued this as a positive)
HTML is Error Prone (i.e. missing closing tags)
Tendency to Over Use Divs
Closer to what the Browser Sees
Closer to other languages (+1)
Learning Curve (+1)
Ruby Conditional Statements cannot be Intermixed withing JS blocks
Not standard and likely won't be
Forces succint Views
Follows the spirit of Ruby (beautiful code)
Looks like Perl with Excessive Symbols
"Shells" out to other languages
Given this list, we had a healthy debate about the value of each templating language. In the end we decided the differences between the two weren't great enough to refactor our code in the name of standardization. But we did decide to use ERB as the default, namely because of its proximity to other languages (i.e. PHP) and the correlating low ramp up time when training new developers in Ruby on Rails (including HTML/CSS developers). So, with any new project we initiate in Rails there has to be a good reason not to use ERB, and a discussion will ensue to make a decision about which is best for said project.
I like to think we're somewhat of an eccentric crowd here at Active, at least on the engineering side. Case in point, watch our very own Marc Leglise, blackbelt and Senior Software Engineer, break bricks while still a student at UCSD:
Our very own Marc Leglise brought a new toy to work today to harass his co-workers with. Check out this Parrot AR Drone 2.0 in action flying over desktops and skimming people's heads here in the office.
Our Results development team has spent the past few months building a brand-spankin' new product to replace the old one. And in order for this brand-spankin' new product to work properly, we need to move data into it from the old database. Well, they decided to add a little liveliness to an otherwise boring exercise which can be witnessed below:
We've been proud users of Google Maps on Active.com for 3.5 years. We used them to show where events are happening and provide driving directions to participants. Underneath the hood, we used Google's Geocoding API to discover the latitude and longitude for events so we could properly render them on maps. Geocoding also enabled searching by location on Active.com Search.
But then, on 26 October, 2011, a date that will live in infamy, Google announced usage limits on Google Maps. The new terms limited websites to 25,000 free map renderings per day. And Google reserved the right to put ads on those using maps for free. Or, websites could negotiate a usage-based deal with Google should their volume exceed 25,000 per day. In our case, we were looking at millions of renderings per day.
We scrambled for options.
Our first was to approach Google and try to work out a deal. After several email exchanges and phone calls, we just couldn't justify paying hundreds of thousands of dollars per year for maps. Second, we looked at Bing's offering and found their terms to be similarly disagreeable.
Then we found OpenStreetMap. And after more digging around, we discovered that MapQuest was huge proponent of OpenStreetMap (God bless 'em), which lended credibility to the service (as did recent accusations of Google's tampering with OpenStreetMap data). MapQuest had developed an open service called Open Platform Webservices which was built on top of OpenStreetMap's abundant data sources. The platform offered to free access to what are called "tiles" - images pieced together to render a complete map. It also offered access to a service called Nominatim, which could geocode our events like the Google Geocoding API used to.
Armed with a good alternative we set forth and worked to replace Google Maps with MapQuest's offering. In the spirit of being good citizens and not overloading MapQuest's "open" servers, we did the following:
Nominatim is our primary geocoding provider. We fall back to other commercial offerings when Nominatim is unable to deliver the precision (address-level) we need. Geocoding is abstracted by an internal service.
I think it's a good move for Google to look for financial compensation with its Maps product. I'm sure they ran the numbers and expected some developers, like us, to jump ship while others would embrace their new cost structure. In our case, the numbers didn't make sense, especially with a great alternative like MapQuest on OpenStreetMaps.