Skip navigation

I put together a presentation this past week about building small, fast websites with Ruby and Sinatra, and then deploying them on Heroku. I had less-technical users in mind with this presentation. If you're a hardcore developer you have no problem setting up a web server from scratch. This is geared more towards designers who can make beautiful sites but aren't used to making them dynamic or pushing them public to the world.


You can download the sample code used in the presentation from here:


1,977 Views 0 Comments Permalink Tags: development, leg, web, ruby, sinatra, heroku

iPhone App Revisited

Posted by RobCameron.2.16b Mar 19, 2010

Screen shot 2010-03-19 at 12.21.01 PM.pngWe launched our iPhone app last week and it was greeted with less than stellar reviews. One reviewer complained of bugs, another about the lack of saving tab order, another about sluggishness. I wanted to explain the non-traditional approach we took when developing this app and what we're doing to improve the experience for those less-than-satisfied customers.


We built this app using a new tool called Titanium. It was created by Appcelerator as a way to write iPhone apps without using XCode, Objective-C or Cocoa. You write your apps using Javascript and several libraries they make available to add the same functionality as if you had written a native app--UI controls, the camera, a local database, and lots more. A very ambitious project that looks like it's off to a good start. Unfortunately, being an early adopter means you're going to run into more bugs and unexpected behavior than with a well-established toolkit. We wanted to get the app out to people quickly and our internal testing didn't show any of these bugs that are popping up in the wild so we felt we were ready to go.


We wrote the first version of ActiveReader against a beta release of Titanium--0.8.3. Development of Titanium itself was happening very rapidly and new SDKs were being released every few weeks. Documentation was okay, but they had a thriving community which the developers participated in regularly. If you had a problem you could usually get it answered within a couple of hours. However lots of functionality was still missing from the API, and bugs were being found on a daily basis.


Titanium is now in 1.0.0 (as of two weeks ago) and the API has changed quite a bit. They are now doing as much as possible in "native" iPhone views rather than everything being a "webView."  While webViews are easier to code using their Javascript/HTML/CSS paradigm, they are really, really slow (one of the major complaints about the current version of ActiveReader). They (Appcelerator) neglected to mention this prior to their decision to overhaul the API. The apps that the new version of Titanium creates *are* much faster.  Appcelerator has also announced their business model for Titanium--charge for premium support and access to analytics about your app. What this means the thriving community is now almost purely supported by the users themselves. The devs don't appear as often and I can only assume this is to encourage us to upgrade to premium. Also, the documentation is even spottier than it was for the beta release. So for now help is being provided only by other users who are also confused and picking their way through the code just like you.


So, what have we done to get the app more stable?  We were able to migrate the app from the 0.8.3 framework to the 1.0.0 framework over the past week and it is currently being reviewed by Apple to be added to the app store. We expect that to happen early next week at the latest. The loading times for the app are orders of magnitude faster. Previously you would be staring at the splash page for 10 seconds or more while waiting for articles to come down from the cloud. Now the loading screen is up for 1-2 seconds and you see a list of articles immediately. Viewing an article is faster as well.

We also removed offline access to articles for the time being. This is another of the major performance problems with the current version and we want to revisit the database storage issue in-depth. We felt that lack of offline access wasn't a deal-killer to getting this new version out the door in the hopes that it addresses most people's concerns.


It may turn out in the end that Titanium just won't fit our needs as a rapid iPhone application development environment. The Light Engineering Group's mission is to find new technologies that help us get to the market faster than ever and we hoped Titanium would be another way to do this. While it's true that we are able to develop apps quickly, it may not be worth the tradeoff of stability and lack of support. We may end up going back to the drawing board and instead build the app out from scratch using the good old fashioned tools that Apple intended for us to use in the first place. Time will tell!


We appreciate everyone that's downloaded the app so far and given great feedback on Facebook and Twitter. We won't leave you guys hanging -- we'll get you a great reader one way or another!

3,530 Views 1 Comments Permalink Tags: development, leg, iphone, activereader

Active Realtime

Posted by BrianActive Mar 10, 2010

Active Realtime is the newest addition to our product incubator  Every day thousands of people are searching and registering for things to do at Active.  The idea behind Active Realtime is to provide a window in to actual user activity,  giving a sense of whats happening right now at Active.  We also aggregate popular activities on a local level, which reveals favored events and activities in a region.  We also have the opportunity to look at trending topics over time, which will perhaps yield new insight into what is keeping us Active.




Presently data for Active Realtime is provided by our newly launched search engine .  In the future we hope to include realtime data from other parts of Active, such as event registration openings or community posts.  Keeping this in mind, we designed a technical infrastructure for Active Realtime that would allow us to add additional sources of data in the future, as well as allow other applications at Active tap into the information.



To accomplish this, we used  XMPP Publish Subscribe, an addition to the venerable IM protocol.   Using XMPP PubSub, we are able to keep Search and Active Realtime loosely coupled, so each service can be independently maintained and scaled.  Additionally, we developed a Search Logger, which acts independently of the Search site.  The Search Logger acts as the Publisher, and pushes search data over the XMPP bus.  Any interested part of the Active infrastructure may subscribe to receive these updates, and the Realtime application is just that.  The Realtime architecture includes a Ruby daemon that acts as Subscriber, registering an interest for search activity and receiving data accordingly.  This data is recorded into the Realtime database, which  then can be displayed on the Realtime site.  A diagram showing the architecture is included to the side.



The payoff for investing the time to create this architecture, rather than just querying the search infrastructure directly, is twofold.  First, it provides a simple and scalable way for future datasource  additions to be made to the Realtime application.  Secondly, it de-couples realtime with each of the data publishers, allowing all systems to function and scale independently, without having an impact on one another.



I hope you enjoy this window into Active.  The data on Active Realtime is generated by Active users, so perhaps another like minded person will help you to find a great local activity to participate in.
2,903 Views 1 Comments Permalink Tags: active, architecture, widgets, leg, product_development, cloud_computing, labs, realtime, xmpp

Active just officially released our first iPhone app—ActiveReader. This app lets you read all the articles from in a mobile-friendly format. It also stores those articles on the phone itself so you can still read them, even if you're offline. Articles are organized by activity like running, cycling, baseball, or you can search our site for articles.





Technical Stuff

This app was created with a tool called Titanium Developer which allows you write both desktop and mobile apps in HTML/CSS/Javascript rather than the technologies specific to that platform (in the iPhone's case that means Objective-C and Cocoa).  Behind the scenes we're using some new technology for us to store and serve the articles—CouchDB. Couch is a schema-less, document-oriented database which stores JSON and speaks HTTP. So rather than using a database driver to query your data, you send a regular old HTTP request, just as if you were accessing a webpage. The iPhone sends this request and stores any new articles in a SQLite3 database in the phone itself. This allows you to read even when you're offline (although you can't search because that goes to our live site).


This is only the first of many new mobile apps you'll be seeing from us. Stay tuned!

2,333 Views 0 Comments Permalink Tags: leg, mobile, iphone, activereader, couchdb, sqlite

At 1:30 PM PST on 2 March, 2010 we flipped the switch and started serving through Akamai.  We then watched our average load time and bandwidth consumption stats decrease as the DNS change propogated across the world.  The end result has been significant.  Below are just some of the improvements we've noticed. homepage load time reduced from 6 seconds to less than 1 second

Community homepage load time reduced to an average of 2 seconds


Datacenter bandwidth consumption reduced by at least 30%


Concurrent sessions on our webservers reduced by 45%



There's still room for improvement with our load time averages.  Apache Bench tests show HTML-only load times for the homepage to be under 100 milliseconds.  The program that generated the chart above also downloads CSS, Javascript and 3rd party collateral.  Regardless, we're excited about this change.

2,728 Views 1 Comments Permalink Tags:, speed, improvements, akamai

Active Widgets

Posted by RobCameron.2.16b Mar 1, 2010

Hi, I'm Rob and I'm a Software Architect on the Light Engineering Group here at Active. LEG, as we call it, was modeled after the LED group at LinkedIn. LinkedIn was looking for a way to rapidly prototype new technologies and architectures with Ruby on Rails. Their first product was Bumper Sticker which at one point was the mostly highly trafficed Facebook application in existence! You can find many of the fruits of LEG's labor at


This morning we officially launched our new Active Widgets site at This was a quick two week project to create an embeddable window into's thousands of registerable events. The idea being that the blog you write about running/cycling/baseball can show a list of upcoming marathons/track events/Little League games in your area. The widget is customizable as far as what activities it displays, where it displays them, whether or not the user can change those settings, as well as the size and color of the widget itself. Once your done just click a button and you're given a couple of simple Javascript tags to drop onto your site wherever you want the widget to appear. And since the widget is written out onto your page like any other HTML, you can further customize it using your own CSS.




The Technical Stuff

This customization site (known as The Configurator) is a Sinatra application written in Ruby. There is no database—the data store is a single YAML file which defines a widget and what about it is customizable. The widget itself is written in Javascript and after minification with the YUI Compressor, the whole thing is 14K (for comparison, the Google homepage is 47K).


Since we planned on having the widget be embeddable on any website we couldn't use Ajax to pull in the event listings. Ajax is subject to strict cross-domain security policies set by your browser—you can only access servers in the same domain that the page itself was served from. This is quite a problem since search results are coming from  The workaround for this issue is to make server calls with <script> tags and then wrap the resulting code in a function call known as a callback. When the <script> tag is added to the page the browser immediately executes it as valid Javascript. Since this Javascript contains a function call (the callback) it looks a function you've already defined with the same name and calls it, passing in the returned data.


The server itself is an Amazon EC2 instance running in their cloud infrastructure. This allows us to quickly react to any scaling needs by simply spinning up a new instance of the same server and deploying the code to it. Nearly half our division's products are now running on EC2 and we're moving more there every day. We've found it be an fast, secure and cost effective way to get our applications live.


Stay tuned for more exciting projects from the LEG team!

2,231 Views 0 Comments Permalink Tags: events, widgets, leg, cloud_computing, amazon, ec2, labs, ruby, sinatra

Following up on my post from Friday, below is a video showing what our daily Scrum meetings are like.  Scrum meetings are normally 15 minutes, and you'll see we go into a "16th minute" conversation, where where we talk about topics peripheral to the daily Scrum meeting construct:


1,570 Views 0 Comments Permalink Tags:, agile, product_development