April 02, 2010 -
0 Comments -
ruby
facebook
I recently encountered a need for a minimal wrapper for Facebook’s API, so I wrote SimpleFacebook. Clocking in at just 56 lines, it’s perfect for interfacing with Facebook via Ruby, and nothing more. This is not intended as a replacement for Facebooker or RFacebook. It doesn’t provide any explicit Rails integration, such as controller filters for gating users. It only does the dirty work of putting together a valid API request and returning the results, deserialized from JSON. Example usage:
What is it useful for? My use case was an asynchronous worker which needed to grab some data from Facebook to be stored in a database somewhere. A Rails process was not necessary to do this, so loading up Facebooker or RFacebook seemed like overkill.
Someone else might find it useful, so I’ve released it under the MIT license. Everything is up on GitHub, which you can download and install as a gem (using rake install). The code is fairly simple, and fleshed out with specs.
Read more…
November 06, 2009 -
0 Comments -
ruby
tools
bluepill
god
At Serious Business, we’ve been using God to monitor long-running background tasks and other daemonized processes. While God provides a nice DSL for configuration, it has issues with memory leaks which forced us to keep a close eye on it (meta-monitoring?) and reboot it periodically via cron.
To remedy the problem, a few of the guys got together over a weekend and wrote Bluepill, a replacement monitoring tool with a DSL inspired by God, but written for low memory consumption. Check out Arya’s blog for a detailed explanation and breakdown of Bluepill’s features. See the graph comparing Bluepill and God memory consumption over time. You’re sold.
September 21, 2009 -
0 Comments -
tdd
Lately in test-driven development, I’ve noticed that I tend to write tests against invalid input before I get to tests against valid input. This is a subtle technique which I think merits some discussion.
One of the big wins with TDD is the way that it forces you to think about the problem in terms of the API; this pushes the engineer to design to an interface, not an implementation, which is one of the major takeaways from the original Gang of Four book on design patterns. And I think the higher-level concern that designing to an interface facilitates is the process of knowing the problem domain, which leads organically into the process of dividing up responsibilities between discrete classes and modules.
In many ways, a problem domain can be defined not only by what it’s supposed to do, but also by its constraints, the cases in which it should fail. Thinking about these cases upfront, testing against invalid or nonsensical inputs, leads to software which is more resilient to misuse and unexpected scenarios.
I find that defining these c…
Read more…
