This following list is probably a subset of a bigger one, but I’ve composed it based on my experience using BackboneJS + Rails on the current project at work. So, here goes the list: ###Designing Granularity of the API### Using RESTful API, it makes sense to have separate API methods to repesent each type of resource. However, to construct a meaninful UI for the end user, often time we need to represent multiple resources on the same screen.

Wanted to share my thoughts on ActiveRecord Callbacks. I’d like to know your thoughts if you disagree. Please use the comments. Only use them when the behavior is must have under all situations, including your tests. For example, we know email addresses are case-insensitive. So no matter what, we may always want to store a lower cased version in the db. #Good class User < ActiveRecord::Base before_save :downcase_email def downcase_email email.

… is as right as “the weather will be bad today because it wasn’t any good yesterday”.

The question is, should we use the third-party ActiveRecord Query Enhancers like SearchLogic/Squeel/MetaSearch? Quoting from Squeel’s Github README page, Squeel lets you rewrite... Article.where ['created_at >= ?', 2.weeks.ago] ...as... Article.where{created_at >= 2.weeks.ago} This is a good thing. If you don't agree, Squeel might not be for you. At work, we are migrating a Rails 3.0 project into Rails 3.2. We used MetaSearch in the project quite extensively and now discussing if using Squeel (successor of MetaSearch for newer Rails versions) would be a good decision.

I find the MongoDB API is abusing JSON in a really bad way. JSON is probably a good format for storing the documents in MongoDB, but using JSON for it’s weird API is simply a terrible idea. Here’s an example from the SQL to Aggregation Framework Mapping Chart db.orders.aggregate( [ { $group: { _id: { cust_id: "$cust_id", ord_date: "$ord_date" }, total: { $sum: "$price" } } }, { $match: { total: { $gt: 250 } } } ] ) I find the UI of this query to be distasteful at the best.

Often times the business requirements demand for database features that aren’t easily achievable using a single type of database. And now we have quite a few options to choose from, for example Key Value stores, Document databases, Relational databases etc, each providing some mutually exclusive features from the rest. So, it can be tempting to introduce multiple databases to rip the benefits of each. But, it comes with a few gotchas that are worth knowing.

Input validation is often required to safe guard against inappropriate use. For example, consider the following API: class TransfersController def create() from_account_id, to_account_id, amount = params[:from_account_id], params[:to_account_id], params[:amount] from_account = Account.find(from_account_id) to_account = Account.find(to_account_id) @transfer = Transfer.create!(from_account, to_account, amount) redirect_to @transfer end end In this case, the API is expecting a from_account_id which we know, can be easily exploited unless a validation is performed on the server. Say, a simple validation would do this:

I like the idea of learning one new programming language every year. This is also mentioned at The Pragmatic Programmer Book. I’m now looking for a new language to learn. In 2011, I learned F#, my first functional programming language experience. It’s a really nice language, especially if you’re familiar with the .Net class library and the windows development echo system in general. This was really fun, learned the basic concepts and building blocks of functional languages.

TL;DR; It’s not one assert per test, rather one logical path per test. I find this to be a classical example of how an inappropriate choice of terminology leads to huge confusion. In trying to find the original source of the “one assertion per test” quote, google came back only with a bunch of confused blog entries :( Without much ranting, lets see a code example to start with:

From my experience with writing/reading unit tests for years, here’s a little guideline to keep ’em readable: A unit test needs to fit entirely (including setups) on a screen without scrolling. It is OK to have a little bit of duplication in unit tests for readability. Avoid nesting of contexts beyond 2 levels. Instead, use methods to setup and flatten. Do not use if/else/loops in a unit test. If your test needs too much setup/mocking/stubbing, time to refactor the code.