AngularJS params variables easily paramitize for http transfer to Rails, but when a collection of values is present there can be issues. This example illustrations how to form your Javascript object for AngularJS to post to Rails. object = {} object.liked_post_ids = [1,2,3,4,5]   ApiUrl.post(object) #=> response 200 #=> created 1 liked post # The way to correct this is to write the following object = {} object[’liked_post_ids[]’] = [1,2,3,4]   ApiUrl.post(object) #=> response 200 #=> created 4 liked posts :)

Rabl is one way to deliver well formatted JSON in service oriented architecture, but sometime we slack on delivering the correct data to the templates and abuse logic operators in the view. (location.id.present? ? {:location_id => location.id} : (( location_matches.any?) ? {:location_id => location_matches.first.location.id} : {} )) ).merge({ # … more hash nodes }) This type of ternary abuse bugs me. It is hard to read and traverses lines. Additionally when we start mixing it with other hash nodes it gets very dirty quickly. One solution is to check values before getting the view and then confirming all lines that will extend beyond 80 characters won’t use the ternary operator, but if else. # app/logic/location_context.rb def location if location.id.nil? locations[…]

First, my apologies for really dropping my commitment to this blog the last six months. The next six months will be better, I promise. Second, the presenter pattern we built into our latest Ruby on Rails and Backbone.js application created an opportunity for XSS attacks. XSS attacks are nasty little security holes exploited through the DOM, although not common for casual users to hack, experienced hackers can cause a ruckus on your application if found. On our application we found the security hole in an authenticated area, which is better, none the less there are probably hundreds of applications using Backbone.js where this vulnerability is serious. In a Rails application it is possible/common to setup presenters to ready your API[…]