The Napkin ~ A Blog By Highgroove Studios

Atlanta Startup Weekend Nov 13-15

Fri, 23 Oct 2009 09:57:00 EST

Alanta’s (3rd?) Startup Weekend is on Nov 13 – Nov 15 at ATDC.

We’re big fans of Startup Weekend for a couple of reasons:

the constraints—successful businesses are built on limited resources. A single weekend to come up with ideas, plan, execute, and launch a business is a daunting and fantastic lesson for anyone interested in starting a business.
the people—what happens when you get 15 crazy developers, 20 biz-dev folk, sprinkle in some opinionated graphic designers and some marketing know-it-alls? Sheer madness, of course! I don’t think you could build a better simulation for working with a diverse team towards a common goal.
the camaraderie—the business(es) coming out of Startup Weekend may not ever become the next Google (or Skribit), but the ideas and lessons learned by all are sure to make the tide rise here in Atlanta!

A very big thank you to our friends at The Kauffman Foundation, ATDC (and all the other sponsors) for their support of this Atlanta event.

Part II: We Just Undid Three Months of Dev work. Here's What We Learned.

Tue, 20 Oct 2009 19:38:00 EST

We published Part 2 of our lessons learned from undoing 3 months worth of development work on Scout, our server monitoring service.

As developers, we love technically beautiful solutions. But sometimes the best features are the ones that get the job done—and prove themselves by providing real business value.

We hope you enjoy us sharing these lessons, if so: up-vote us on Hacker News and be sure to subscribe to the Scout RSS Feed or Follow Us on Twitter.

We Just Undid Three Months of Dev work. Here's What We Learned.

Wed, 7 Oct 2009 13:22:00 EST

Scout, our server monitoring service, has grown quite a bit in 2009.

We’ve documented 2 big lessons we’ve learned on the Scout Blog.

If you find it helpful, give us a vote on Hacker News.

Teaching Ruby on Rails

Sat, 22 Aug 2009 17:27:00 EST

At last month’s Atlanta Ruby User Group (Meetp), I gave a presentation on “Teaching Ruby on Rails.”

I’ve taught Ruby on Rails for the Big Nerd Ranch for almost 4 years now, and given on-site trainings all over the world, from Wells Fargo to the New York Times, to startups and even government agencies. I’ve also done this talk before at the first Acts As Conference (Ruby on Rails local conference in Orlando, Florida), but I have refined it a bit based on more experience teaching Rails at various organizations.

Being an effective teacher, and thus, Teaching Rails (and for that matter, any real technical programming language and framework) boils down to 4 main points:

Define Your Purpose
Know Your Audience
Give Relevant Examples
Teach How to Learn

We’re hoping to get video of the presentation up soon, but if you just want access to the slides with notes, I’ve provided them in the footnotes.

Lessons from the Trenches at Acts As Conference Highgroove Article on Acts As Conference Talk
Teaching the Rails Slides and Notes from Atlanta Ruby User Group Talk

Apache Page Caching and Multiview

Tue, 4 Aug 2009 17:24:00 EST

I just wanted to post a quick note to anyone searching for problems with Rails Page Caching with Apache.

We just helped a client through a tricky issue that manifested itself through some strangely generated cached files.

The Problem

A visit to the resource:


http://example.com/articles

Would correctly generate the page:


/path/to/app/public/articles.html

Subsequent visits would load the cached page.

However, if you then tried to visit a page like:


http://example.com/articles/2

Where a route used that for pagination, or simply any action off that resource, you apache would try and request a file like:


/path/to/app/public/articles.html/2.html

This is problematic, and does not work.

If, however, you removed the cached file and instead created the directory first, like so:


/path/to/app/public/articles/

When you requested the resource:


http://example.com/articles

it would correctly generate an index file:


/path/to/app/public/articles/index.html

And then correctly generate any cached pages inside the directory like 2.html, 3.html for pagination (if setup in rails routes correctly).

The Solution

The problem was that Apache has the MultiViews option turned on.

We changed the server configuration file from this:


<Location />
Options All FollowSymLinks MultiViews -Indexes
</Location>

to this:


<Location />
Options All FollowSymLinks -Indexes
</Location>

When you remove this option from the configuration, you get the correct caching behavior, which is that requests to:


http://example.com/articles

Still generate the cached file:


/path/to/app/public/articles/index.html

But now, requests to the slash-ending url and resources off that route:


http://example.com/articles/
http://example.com/articles/2

Now correctly generate a folder with an index.html and 2.html, which caches just fine.

I hope this helps someone else out!

References

How to update a Facebook Page Status using the Facebook API

Sun, 19 Jul 2009 19:33:00 EST

For a client’s application, we needed to programmatically (without user-intervention) update the Status (Wall) of a Page for a Company. After researching the API and several guides, you would think it was just not possible..

In fact, there’s even a forum post on the Facebook developers forum on How to update facebook page status from 3rd party application where a Facebook employee explains that it is impossible (as of 2007, at least).

The good news is, it is not impossible (as of right now). Here’s how to update the Status of a Facebook Page Programmatically, through the API.

What you’ll need:

Ruby and RubyGems
A Facebook Account
A Facebook Page
A Facebook Developer Account/Access (we’ll go through setting this up)
A Ruby or Rails app with access to the facebooker library (either as a gem or using the Rails plugin).

Update: As pointed out in the comments, publishing through Facebook using the method described below does place content on the fan page, however, it is not displayed in any user’s feeds or streams, which makes it not quite so useful. We have since opted to go with the uber-cool ping.FM service and we even wrote a little ping.fm ruby wrapper library for their API.

Facebook’s API is really meant for the web—it’s a session-based API that relies on a browser being opened, being redirected to the Facebook site, and authorization happening in their walled-castle.

Just for reference, and to show the differences of posting a tweet through the Twitter API (with the use of a Twitter Ruby gem for a truly fair comparison):

1) Authorize using HTTPAuth:


Twitter::HTTPAuth.new('yourusername', 'yourpassword')

2) Create the “post” (or “tweet”):


twitter_client = Twitter::Base.new(httpauth)
twitter_client.update("this is a post to twitter!")

Very easy, and very straightforward. Sure, there’s some abstraction hidden here, but it’s an HTTP POST of XML or JSON to a status update action, and an XML or JSON response. It’s truly stateless, and can be done in one call, you could even do this using curl (an http library) in one-line.

OK, now that we’ve seen how easy it could be, let’s do the equivalent on Facebook.

To post an update to a Page with Facebook, it requires a bit more prep work.

0) Signup as a Developer, by visiting:

http://developers.facebook.com/get_started.php

Click the button to “Add the Facebook Developer App” which is confusing, but cool that being a Developer on Facebook requires you to install the “Developer” Application:

You will see a interstitial, click allow:

1) Create an Application. You can name it the same as your Page:

Here are the steps you definitely need to complete:

Grab your API Key and Secret Key (not shown in this screen capture):

In the Authentication Settings, make sure this application is installable to Pages:

In the settings, create a Canvas page URL, even though we won’t need it:

You can put in a Canvas Callback URL, but it doesn’t matter.

2) Publish your Page, and your Application. Now visit the Profile Page for the Application:

Add the Application to the Page:

You may have to click the “More” actions tab to find the link to “Add to my Page.”

3) Let’s generate a “token” which is the equivalent of an “infinite” session that will allow us to programatically make calls to the API, even if we’re not actively logged in as the owner of the Page. The procedure is documented here: http://www.emcro.com/blog/2009/01/facebook-infinite-session-keys-no-more/

I’m sure this could be done through the API itself, but since it’s a one-time thing, we can do it ourselves, through our browser.

3a) First, log out of Facebook and hit this URL:


http://www.facebook.com/login.php?api_key=YOUR_API_KEY

Note that you will be redirected to your canvas page with a auth_token parameter:

3b) Now, visit this page to generate the token:


http://www.facebook.com/code_gen.php?v=1.0&api_key=YOUR_API_KEY

You should see your new auth_token on the next page:

3c) Now, you can generate a session using this token that should never expire.

Here’s how to do that using the Facebooker library for Ruby. In script/console:


fb_session = Facebooker::Session.create
# => #<Facebooker::Session:0x330cf0c ....

fb_session.post "facebook.auth.getSession", :auth_token => "YOUR_GENERATED_TOKEN" 
# => {"session_key"=>"xxxxxxxx", "expires"=>"0", "uid"=>"yyyyyy"}

If you look at the session returned, you’ll see a session_key and see that the “expires” is set to 0.

If you have a library that lets you “set” the session key, you’re good to go. You can use that session_key until it is revoked (since it does not expire).

If you’re using the Facebooker library, since it has been built to “authorize” users through the web and store a facebook session along side a normal web/app session, you actually can’t do this. In the library, the session_key is an attr_reader (meaning, a read-only attribute for the Facebooker::Session instance).

And even though the guide above (facebook-infinite-session-keys-no-more) tells you to use that session_key, it is perfectly valid (and I assume more appropriate) to just use the auth_token instead, every time.

So, now we’re down to this for logging in:


fb_session = Facebooker::Session.create
fb_session.auth_token = "YOUR_GENERATED_TOKEN"

Note, if you’ve setup Facebooker using the plugin, it loads your api key and secret key using the configuration yaml file. You could also be explicit:


fb_session = Facebooker::Session.create(Facebooker.api_key, Facebooker.secret_key)
fb_session.auth_token = "YOUR_GENERATED_TOKEN"

4) Now, time to post something to the page. We’ll use the Facebook API feed.publishTemplatizedAction method, using the page_actor_id parameter. As of right now, the documentation states correctly that this method “is deprecated for calls made on behalf of users. This method works only for publishing stories on a Facebook Page that has installed your application.”

Here’s a sample call in Ruby:


fb_session.post("facebook.feed.publishTemplatizedAction", :target_ids => "", :title_template => "Testing a News Feed post on a Page posted by {actor}", :title_data => "{}", :body_template => "Check it out yo says {name}.", :body_data => "{\"name\": \"cbq\"}", :body_general => "Here is the body.", :page_actor_id => "YOUR_PAGE_ID")

A couple of things to note. Facebook requires that you put the {actor} variable in the title, so you’ll have to come up with something clever to do with that. You can also put data in the title for replacement, just like you can do with the body. Above, the example has a {name} variable replaced in the body, but you don’t have to add any body data to replace. The above example shows passing variables and not passing variables for reference.

The page id should be easy to grab from any of the URLs of your Page.

You should be all set, and see your posts on your page momentarily:

References:

Facebooker Ruby Gem Documentation
Facebooker Tutorial on Facebook
Posting Updates to Facebook Fan Pages – API Supports It – a post on Ping.FM re: success using API.

Rails Rumble at Highgroove HQ

Fri, 10 Jul 2009 13:57:00 EST

If you’re thinking about doing this year’s Rails Rumble, Highgroove HQ in Atlanta (map) is offering up our office space for any teams in the Atlanta area for the competition (Aug 22 – Aug 23).

Highgroove has a team, and we know of a few more folks seeking teams. Ping us if you’re interested in joining or forming one. Registration ends soon (this weekend)!

Writing Ruby Extensions in C the Highgroove Way

Fri, 10 Jul 2009 13:56:00 EST

Trying to handle image manipulation, creating PDFs, or in-memory caching in pure Ruby is like trying to win the Tour de France on your hipster single-speed bike. The single-speed works 90% of the time, but when you have demanding performance requirements, it’s not good enough. Many popular Ruby libraries, such as MySQL/PostgreSQL, RMagick, and most of the webservers Ruby applications are deployed on (like Passenger, Mongrel, and Thin), harness the blazing speed of the C language and libraries to handle the heavy lifting and performance-intensive business that Ruby can’t keep up with on its own.

In some of my recent work, I had the opportunity to delve into and expand on a Ruby extension written in C for looking up geographic information based on IPs. This library was vital to one of our client’s projects that has immense performance requirements without the possibility of full request caching. By utilizing the existing GeoIP C library for accessing their special in-memory binary database, we were able to keep up with the demand the application would be seeing.

As is common at Highgroove Studios, along with making sure our contributions to the library were open sourced, I took the lessons and experience gained from this unusual endeavor and presented them to our local Ruby User Group here in Atlanta. I focused more on exposing the bridge between the Ruby and the C environments and understanding the internals of the Ruby language from a C standpoint. However, armed with this knowledge, any Rubyist is able to open up most any Ruby extension or even the Ruby language implementation itself and understand what’s going on. My goal was to get the developers over the initial hurdle of being able to read the code and understand it enough to investigate further.

Personally, I gained from this experience a better appreciation for the real beauty of the Ruby language and the effort required to make it as fluid and dynamic as it is as well as having a more thorough understanding of the internal workings of the language. Working this close to the language core has also made a difference on my Ruby style, both in trying to fight the language less but to also use it more efficiently and effectively.

For more information, check out the presentation slides¹ and some of the C examples I wrote for the presentation². Also check out the GeoIP I contributed to which inspired this whole adventure³.

¹ http://www.slideshare.net/maraby/writing-ruby-extensions

² http://github.com/mtodd/ruby-c

³ http://github.com/mtodd/geoip

Highgroovers are fans of Sinatra

Wed, 1 Jul 2009 10:30:00 EST

Both James Edward Gray II and Matt Todd were quoted in Satish Talim of Ruby Learning’s Poll: 20+ Rubyists are using Sinatra – Do You?

Sinatra is a Ruby framework for quickly creating web applications with minimal effort—a DSL for the web. We use Sinatra for several client projects, and it is also an integral part of Scout.

Check out Sinatra Documenation
Learn more about how Scout uses Sinatra

Scout Goes Deep! and Robust! and More!

Tue, 26 May 2009 23:21:00 EST

Scout got a major facelift today, to show off all the new features we’ve launched over the past few months.

To learn more about many of the new features, including:

Deep Rails Instrumentation
Triggers and Trends
The New Daemon-based, Robust Agent
The Improved, Easier API and Developer Resources
and our new Pricing Model

head on over to the Scout Blog to read all about it.

Now with deep Rails Instrumentation, triggers, a more robust agent, and more