The experience

The event was amazing —  I’d expected (and found) talented speakers giving great talks to cool fellow attendees;  what surprised and impressed me was the enthusiasm of the conference organizers, expressed through the incredibly detailed theme of the conference.  The  berries on the tables, the flying pink unicorn on stage, animations at the breaks, the T-shirts, yard decorations, conference booklets: the Railsberry spirit was organic, genuine, and infectious, and quickly spread to the audience. (Did I mention the delicious raspberry vodka?)

It’s hard to describe in text the cumulative effect of all this effort.  It was magical, in a way I didn’t expect a conference (even a Rails conf) could be.

A dump of unlabeled photos of Krakow

The setting matched the conference: Kraków is beautiful.  I’d never been to Poland before, and I was impressed.  The streets are lined with Altbaus; the people are friendly; the old town absolutely gorgeous and  scenic; the castle  huge and satisfied towering above the city; the food delicious.  (If you go there you must go to Miod Malina.  Don’t argue, just do it.  You won’t regret it.)  That everything was significantly cheaper  than even Berlin was a nice bonus, too.

Honestly,  Kraków felt much more like my vision of “central European city”  than almost everywhere I’ve been.  I’m excited to go back someday to see the salt mines and explore the the surprisingly alive Jewish sector, which we barely got to.

The Conference

Among all the meeting of cool new people, eating of delicious food, drinking of tasty beverages, and exploring of scenic streets, I did manage to learn a few things.

Tom Stuart gave the talk that most impacted my thinking, on “developing from the outside in”.  He spoke about the value of building systems not from the inside (database schema as, models) but from the outside (the external libraries that use it with mock responses etc. then controllers and routing).  It’s a logical and effective way to approach certain design, and I’m excited to try it on some suitable problems in the near future.

A number of other talks also stuck with me:

• Yehuda Katz on why Rails is hard, a reminder of the difficult challenges the framework handles under the hood (for instance, string encoding and CSRF) and why the extra size and complexity of Rails is often justified.
• Konstantin Haase and Josh Kalderimis on Travis’ new pull request testing and on their funding model — such an amazing project.  I’ve been using it for Koala for nearly a year, and it’s made such a huge difference.  (I’m slightly ashamed to say, I still need to contribute.)
• Tammer Saleh on service oriented architecture antipatterns,  a very timely talk  given our recent work at 6Wunderkinder.

It looks like slides and video aren’t up yet, but when they are I’ll link them.

Lightning

At the conference I had the opportunity to give a lightning talk, which as always was fun.  I spoke about some experimentation I’d done with Rails’ render method to inject certain options into your API on a consistent and universal level.  Check it out:

Click here to view the embedded video.

Slides here.

The coolest part came afterward: I mentioned in my 5 minutes that I wasn’t sure about the approach, and Yehuda (yes, wycats) came up to me afterward.  His first reaction, he told me, was the same as mine: wrapping render seemed like a bad idea.

After thinking about it for a moment, though, he realized it was fine: Rails Metal overrides render, and if the framework does that, it’s okay for app developers as well.  Moreover, the signature of render is stable, so this approach won’t make your code brittle.

This was awesome: clearly I done something interteresting and my approach was right (a big relief since I’ll be talking in more detail on API uniformity in Barcelona in September).

In conclusion

Conferences are great.  I’ll be going to three(!) more this year, and will post more about that  and over the next few months.

Cheers,

Alex

For an American in Europe, stores close early and often.  In some cities this is so pronounced it can be difficult for a working stiff to shop: in Amsterdam (hardly a backwoods) most grocery stores pack in in around 5.  Here in Germany, fortunately, hours are reasonable, and loosen up as you go further north — grocery stores in conservative Munich often close at 8, while the same chain may close at 10 PM in Köln (aka Cologne), and in freewheeling Berlin are sometimes open till 11 PM or even midnight.  (All this is a gross simplification, of course.)  At some point at night, though, everything does close, and pity the newcomer who forgot to buy Sunday’s groceries on Saturday.  There’s nothing here akin to the 24-7-365 American hypermarkets like Walmart or that fantastic CVS (nee Longs) on Pleasant Valley Road in Oakland.

Overall, I’ve always liked these restrictions; having where shopping is off the table forces me to focus on the things I have and on what I can do with friends.  (Yeah, it’s cheesy, but it’s all about attitude.)  Unfotunately, such philosophical benefits don’t help when you run out of beer at midnight on a Friday night.  Enter, in Berlin, the Spätis.

Meaning “late selling”, Spätverkaufs — never referred to as such, always Spätkaufs or simply Spätis — were a feature of East Berlin, which after reunification spread into the West (a rare case, like the Ampelmann) of a good feature being picked up from life under communism.  There’s not a lot of history online, but apparently they were originally established in industrial and farm towns for shift workers who would otherwise come home too late to shop (link).

Open late, often all night, Spätkaufs serve a selection of alcohol, food staples and snacks, household necessities.  They also sometimes offer coffee or Internet access and printers, which can be insanely handy if (to take a totally hypothetical example that probably didn’t just happen to me tonight) you have a train to catch the next morning and forgot to print your ticket.  Prices are, of course, higher and selection smaller than regular stores, so you don’t got to a Späti when there are other easy options, but the neighborhood Spätkauf hugely beats finding a gas station (24/7, terrible selection) or trekking down to the train station (Sundays, better selection).

tl; dr: after living in Europe for a while, I really appreciate being able to walk three blocks to a Spätkauf at 11 PM to buy eggs and beer.

A Spätkauf in Prenzlauer Berg, Berlin

Happy spring!  I’m excited to announce the release of Koala 1.4.0.

What’s New

The big update in 1.4 is OAuth#exchange_access_token(_info), which allows you to extend access tokens you receive.  (Thanks to etiennebarrie for the pull request.)  If you haven’t heard about the new exchange mechanism, which replaces offline access, read more about it here.

Other updates:

• HTTPServices#encode_params sorts parameters to aid in URL comparison (thanks, sholden!)
• get_connections is now aliased as get_connection (use whichever makes sense to you)
• Fixed typos (thanks, brycethornton and jpemberthy!)
• RealtimeUpdates will no longer execute challenge block unnecessarily (thanks, iainbeeston!)
• Added parallel_tests to development gem file
• Fixed failing live tests
• Koala now tests against JRuby and Rubinius in 1.9 mode on Travis-CI

Speaking of thanks, I’d also like to thank banane, who’s been very active here in the Koala user’s group.  It’s awesome to see an active community, and it’s been a huge help to me over a rather busy last few months.  I really appreciate everyone who’s taken the time to share their knowledge here in the user’s group!

The changelog is here, and the complete diff since 1.3.0 is here.

Have you seen this bug?

alecnmk recently reported an issue where Koala will stop returning results when paging through a GraphCollection — the first page or two will give a full set of results, then you’ll get a small result set, then nothing. I’d run into this myself but thought it was Facebook until I saw the bug report, where he shows that other Facebook libraries return more paging information in these instances.  Unfortunately, I now can’t reproduce the issue myself.

If any of you see this issue on a publicly accessible Facebook object, please let me know!  (You can just add it to the issue.)  If we can reproduce it, we can fix it.

Are you parsing Facebook’s cookies?

Some of you may have seen a recent Facebook blog post stating that from now on, the cookie format used by their Javascript SDK should be considered an implementation detail, and that third party SDKs like Koala, in effect, shouldn’t provide support.  (Instead, we should all be using the OAuth redirect flow.)  It’s a complicated topic (fit for a later blog post), though in my opinion there are real benefits to the cookie-based authentication flow that the book blog post and subsequent replies to comments don’t adequately discuss.

I’ve been in touch with a few people at Facebook about this, and would be very glad to add your voices and your thoughts.  Are you using the Javascript SDK to log users in and set cookies, and then reading those on the server?  What do you think of the proposed alternatives (either using redirects or implementing your own secure cookie format)?

It goes without saying that Koala will support cookie parsing now and in the future, regardless of Facebook’s position.  Facebook has no immediate plans to change their cookie format, so we should be in good shape, and if any changes are made, we’ll be able to port them from the PHP library easily.

What’s next

Bug fixes, answering questions, and keeping up with API changes.  Nothing big planned.

Happy coding!

Alex
http://github.com/arsduo/koala

wooo

Happy February!  I’m excited to announce the release of Koala 1.4.0rc1.

What’s New

The big update in 1.4 is OAuth#exchange_access_token(_info), which allows you to extend access tokens you receive.  (Thanks to etiennebarrie for the pull request.)  If you haven’t heard about the new exchange mechanism, which replaces offline access, read more about it here.

Other updates:

• HTTPServices#encode_params sorts parameters to aid in URL comparison (thanks, sholden!)
• get_connections is now aliased as get_connection (use whichever makes sense to you)
• Fixed a readme typo (thanks, brycethornton!)
• Added parallel_tests to development gem file
• Fixed failing live tests
• Koala now tests against JRuby and Rubinius in 1.9 mode on Travis-CI

The changelog is here, and the complete diff since 1.3.0 is here.

Have you seen this bug?

alecnmk recently reported an issue where Koala will stop returning results when paging through a GraphCollection — the first page or two will give a full set of results, then you’ll get a small result set, then nothing. I’d run into this myself but thought it was Facebook until I saw the bug report, where he shows that other Facebook libraries return more paging information in these instances.  Unfortunately, I now can’t reproduce the issue myself.

If any of you see this issue on a publicly accessible Facebook object, please let me know!  (You can just add it to the issue.)  If we can reproduce it, we can fix it.

Are you parsing Facebook’s cookies?

Some of you may have seen a recent Facebook blog post stating that from now on, the cookie format used by their Javascript SDK should be considered an implementation detail, and that third party SDKs like Koala, in effect, shouldn’t provide support.  (Instead, we should all be using the OAuth redirect flow.)  It’s a complicated topic (fit for a later blog post), though in my opinion there are real benefits to the cookie-based authentication flow that the book blog post and subsequent replies to comments don’t adequately discuss.

I’ve been in touch with a few people at Facebook about this, and would be very glad to add your voices and your thoughts.  Are you using the Javascript SDK to log users in and set cookies, and then reading those on the server?  What do you think of the proposed alternatives (either using redirects or implementing your own secure cookie format)?

It goes without saying that Koala will support cookie parsing now and in the future, regardless of Facebook’s position.  Facebook has no immediate plans to change their cookie format, so we should be in good shape, and if any changes are made, we’ll be able to port them from the PHP library easily.

What’s next

If everything looks good with this rc, I’ll bump it up to a final release in a week or two.

Going forward, we’ll go for quicker, more frequent updates whenever new Facebook features come out or as bug fixes come in, rather than the huge multi-month projects of the last several releases.

Happy coding!

Alex
http://github.com/arsduo/koala

wooo

Happy new year!  I hope you’ve all had a great start to 2012 — and what better way to kick the year off than with a new version of Koala?

Goodbye, REST API, someday

Facebook has finally ported over the last of the REST API functions to the Graph API, meaning that anything you can do with Facebook you can do through the newer interface…and that it’s time for them to deprecate the REST API.  No need to rush — the older interface will still be around for a while and Koala of course will support it till the end — but you should start migrating over if you’re still using any REST API calls.

Documentation!

Koala is now completely documented; information on every public method and class is available on rubydoc.info.  I know everyone loves rummaging around in source code, but if ever you feel like you just want a concise, useful writeup of the methods available to you, check it out here.

Other improvements

Here are the biggest changes since the last release:

• New OAuth#url_for_dialog method creates URLs for Facebook dialog pages
• New API#set_app_restrictions handles JSON-encoding app restrictions
• New GraphCollection.parse_page_url now exposes useful functionality for non-Rails apps (see this issue)
• Utils.deprecate only prints each message once (no more spamming!)
• OAuth#url_for_access_token and #url_for_oauth_code now include any provided options as URL parameters
• OAuth#get_user_info_from_cookies returns nil rather than an error if the cookies are expired (thanks, herzio!)
• TestUsers#delete_all now uses the Batch API and is much faster
• Fixed bugs, reorganized file and class structure non-destructively, expanded/improved test coverage

The complete changelog is here, and the diff since 1.2.1 is here.

What’s next

Nothing much, actually.  Koala is stable and recent Facebook changes haven’t required any new code on our end (which we’re very excited about).  We’ll keep an eye on the FB developer blog and update Koala as the API changes; in the meanwhile, feel free to submit any pull requests if there’s code you want to add or improve.

Have a great 2012!

Alex
http://github.com/arsduo/koala

Fresh like a crepe off the pan comes Koala 1.3rc2 to fill your stomach and brighten your day. (The holidays really seem to bring out the food imagery, don’t they?)

Documentation!

Koala has always had a thorough wiki, but until now you’ve had to look at the source code to see what methods are available and what they do.  No more!  The library is now completely documented; information on every public method and class is available on rubydoc.info.  If you don’t feel like rummaging through the source code for the method signature of a particular method, you no longer have to.  (Not that there’s anyone here who doesn’t like digging through the code of their libraries, I’m sure.)

Winter cleaning

With the holidays approaching and the relatives coming over, it was to give Koala a long overdue housecleaning.  The lib/koala/ directory was getting a bit crowded, so I’ve reorganized, moving a number of files into the new the api/ and http_service/ subdirectories.  I’ve also updated the class structure largely to match, putting classes and modules in more logical places.

Don’t worry, though — for each move there’s an alias to ensure your existing code doesn’t break, and there’s even a legacy spec to really ensure all the old references work.  (If you’re directly referencing any of Koala’s more internal classes in your code — MultipartRequest,  Response, UploadableIO, BatchOperation, or GraphCollection — check out the legacy spec for more details.)

Other updates since 1.3rc1

• RealtimeUpdates#subscription_path and TestUsers#test_user_accounts_path are now public methods
• TestUsers and RealtimeUpdates methods now take http_options arguments
• All methods with http_options can now take :http_component => :response for the complete response object
• Fixed bugs in RealtimeUpdates and TestUsers

Installation

As always:

[sudo|rvm] gem install koala --pre

Or with Bundler:

gem "koala", "~> 1.3.0rc2"

What’s next

Assuming I don’t come up with any other projects like documentation and cleanup, I’ll release 1.3 soon.  After that, we’ll just kick back, enjoy the holidays, and update as needed to stay current with the Facebook API.

Have a great week,

Alex
http://github.com/arsduo/koala

wooo

I’m happy to announce the release of Koala 1.3.0rc1!

New Features

1.3.0rc1 provides support for several new Facebook features, a number of bug fixes, and other improvements:

• API#set_app_restrictions uses the new Graph API to set Facebook app restrictions
• OAuth#url_for_dialog builds the URLs for the various Facebook dialogs
• GraphCollection.parse_page_url now exposes useful functionality for non-Rails apps
• OAuth#url_for_access_token and #url_for_oauth_code now include any provided options as URL parameters, allowing you to specify display and other options
• API#fql now uses the Graph API FQL endpoint internally
• Utils.deprecate only prints each message once (no more spamming)
• Expanded/improved test coverage

The changelog is here, and the complete diff since 1.2.1 is here.

Mockfacebook

If you haven’t seen Ryan Barrett’s mockfacebook,  a standalone HTTP server that implements Facebook’s FQL and Graph API, check it out.  It’s a great tool for testing your application against a realistically-mocked subset of the Facebook API, and it’s really easy to use with Koala.

Koala’s on Facebook and Twitter!

Follow Koala on Facebook and Twitter for SDK updates and occasional news about Facebook API changes.

Installation

As always:

[sudo|rvm] gem install koala --pre

Or with Bundler:

gem "koala", "~> 1.3.0rc1"

What’s Next

We’ll be releasing 1.3 later this month, assuming no big bugs are discovered.  After that, we’ll continue updating Koala as the Facebook API continues to change and evolve.

As always, if you have any ideas, issues, or suggestions, feel free to let me know on Github!

Have a great week and happy coding!

Best,

Alex
http://github.com/arsduo/koala

wooo

Hey everyone,

I’m excited to announce the release of Koala 1.2!  This is a big update with a lot of cool features, plus support for Facebook’s upcoming authentication changes.

Read through this rather long announcement at your leisure and enjoy the new version

October 1st

Koala 1.2 supports all of Facebook’s new authentication schemes, which will be introduced on October 1, 2011; the old Javascript library and older authentication schemes will be deprecated at the same time.  If you have the appropriate calls to get_user_info_from_cookies (apps using the Javascript SDK) and/or parse_signed_params (for Canvas and tab apps), your application should work without a hitch.

To test your application ahead of time, upgrade to Koala 1.2 (see below) and configure your application according to Facebook’s OAuth 2.0 and HTTPS Migration guide.

Note: in their new secure cookie format, Facebook provides an OAuth code, which Koala automatically exchanges for an access token. Because this involves a call to Facebook’s servers, you should consider storing the user’s access token in their session and only calling get_user_info_from_cookies when necessary (access_token not present, you discover it’s expired, every 30 minutes, etc.). Otherwise, you’ll be calling out to Facebook each time the user loads a page, slowing down your site.

Faraday

With 1.2, Koala uses the Faraday library to make HTTP requests, replacing our homebrew Typhoeus and Net::HTTP adapters. This is a big change, so let’s go over it in detail.

What’s this about?

Faraday is a modular framework, patterned on Rack, which makes it easy to control how your app makes HTTP requests.  By switching to Faraday, we get Koala out of the business of choosing which libraries and features to support, giving you more choices and letting us focus on building the best Facebook library we can.

How does this affect me?

Good news! Based on the 1.2 betas, this change should be non-breaking for almost everyone. All the old settings are still supported, though you’ll see deprecation warnings. There’s now only a single Koala::HTTPService module, which handles all communication.

Almost everyone?

Since Faraday settings are global (affecting other gems that use it, like Twitter), Koala no longer uses Typhoeus by default.  To use that or any other supported library instead of Net::HTTP (the default), just set the default Faraday adapter:

# this could go in an initializer
Faraday.default_adapter = :typhoeus

Also, if you’re hooking directly into Koala’s HTTPService framework, you’ll probably have to make some changes; check out the Extensions wiki page to learn more about the new internals.

People like options, right?

Faraday gives you a huge range of options, which you can provide either per-request or globally by setting the new Koala::HTTPService.http_options hash. The format for the hash maps directly to what Faraday expects, so if you haven’t used Faraday, check out the Koala wiki for some examples.

We still support all the old individual options on Koala.http_service (proxy, timeout, etc.), which read from and write to the new hash.

Even more sweetly, with Faraday you can write your own middleware to really fine-tune how your requests are made.  (To take just one example, I recently wrote a module to log and analyze Facebook requests made through Koala — easy as pie.)  Koala provides a default middleware stack with everything you need, but you can specify your own using Koala::HTTPService.faraday_middleware.

Learn more

For more information and a complete list of how to migrate old settings, check out the HTTPService wiki page. If you have any questions, feel free to write to the Koala user’s group.

API

Koala::Facebook::API class is now the main API class, containing both Graph and REST API methods. Since the GraphAndRestAPI class showed it’s possible to offer all methods from one object, there’s no reason to force you to keep track of and instantiate three different classes to use the Facebook API. All three old classes are now aliased to API, and will remain available for the foreseeable future.

api = Koala::Facebook::API.new(my_token)
api.get_object("me")
api.fql_query("select first_name where uid = me()")
# you can even use the new Timeline API
# see https://developers.facebook.com/docs/beta/opengraph/tutorial/
@graph.put_connections("me", "namespace:action",  bject => object_url)

Other changes

• Koala is now on Travis, passing all tests under JRuby, Rubinius, and REE, as well as Ruby 1.8.7, 1.9.2, and 1.9.3!
  
• (My favorite update:) The live test suite now runs by default against test users, so you can run it as frequently as you want without having to update facebook_data.yml.
• To run it against a real user, add your OAuth token/session key/OAuth code to the YAML file.
• TestUsers#update lets you update the name or password of an existing test user
• API.get_page_access_token lets you easily fetch the access token for a page you manage
• API.put_picture now accepts URLs to images in addition to files
• GraphCollection use is smarter, fixing a problem with the Ads API

Check out the changelog for a complete list of changes. The diff since 1.1 is available here.

Thanks to…

Thanks to marcgg, johnbhall, and Will S. for their help with bugs and in keeping up with Facebook changes, and to Chris and everyone at Context Optional for their support, help, and feedback.

Installation

As always:

[sudo|rvm] gem install koala

Or with Bundler:

gem "koala", "~> 1.2" 

What’s Next

With 1.2 out we’ve completed most of the work we had planned for Koala; in the immediate future we’ll be working on a few remaining features, bug reports, and keeping up with Facebook (did we mention Koala already supports publishing to the Timeline?).

If you have any ideas, issues, or suggestions, feel free to let us know on Github.

Have a great week and happy coding!

Best,

Alex and the Koala team
http://github.com/arsduo/koala

Extreme Specificity

So, another project that I am working on has some specificity issues. Take a look at this selector:

.col-left div.topic-unit ol li div div.topic-unit-ol-image div

The stylesheet uses these types of selectors everywhere. The problem is that if someone comes in and tries to add a “div” as a child to the last “div”, they need to reuse the entire selector and add another bit to the end or there is a chance that their styles will be overriden by one of the previous “div” selectors.

Using element level selectors are good for certain situations but mainly for adding just a bit more specificity. A solution would to be to just use the classes from above to specify where you are at.

In my humble opinion, I find this to be a little excessive. This tells me that the page has some pretty specific and complicated CSS going on. More to the point, I feel pages that contain such selectors need some massive refactoring to simplify selectors.

Today’s wisdom: Keep it simple

Font-size and Inheritance

I’ve been working on this project recently and have had some problems with font-size inheriting. After a few minutes of investigation, it turns out that the following rule was being declared (unfortunately in a place where I can not touch it):

html, body, div, p, h2, h3, h4, ul, ol, span, a, form, img, li { font-size: 12px; }

I believe this was a desire for a CSS Reset. Unfortunately, this declaration forces all those elements to have a font-size of 12px. It is easily possible to override this style with more specificity. The overall problem, however, is the amount of overrides needed to change an entire area’s font-size.

For example,
Say you had that CSS and this HTML.

<div id="navigation_area">
<span class="title">Nav Title</span>
<p class="witty_title_description">I am witty</p>
<div id="navigation_area">
<a href="somepage.html" class="navigation_link">Some Nav Link</a>
</div>
</div>

My desire is to set the entire Navigation Area to have a font-size of 14px. When I apply the following style nothing happens

#navigation_area { font-size: 14px; }

Because each element has been assigned a value of 12px in that reset style, I would have to reapply a font-size specifically to each of them to override it. Like so:

#navigation_area div { font-size: 14px; }
#navigation_area span { font-size: 14px; }
#navigation_area p { font-size: 14px; }
#navigation_area a { font-size: 14px; }


Our canon decrees, for good reason, that font-size should inherit.

Today’s wisdom: Keep inheritance functioning in your stylesheet!