Object Notations beyond JavaScript

JavaScript Object Notation is a data interchange format based on a subset of JavaScript. The beauty of JSON is in identifying a subset of language constructs which are safe for data interchange. For instance the following snippet represents a valid JavaScript but it’s unsafe for data interchange and is invalid JSON.

{"body" : "Chunky " + "Bacon"}

On the the other hand, the example below is using String literals is safe for data interchange and is valid JSON.

{"body" : "Chunky Bacon"}

This simple idea goes a long way. Instead of defining our own format for data interchange, we are using subset of a language for exchanging objects by computer programs and since it’s represented in JavaScript, it’s easy for programmers to understand. Once you think about safety, it’s intuitive to see the subset of language constructs useful for data interchange.

The idea behind JSON employing JavaScript is analogous to REST employing HTTP. This makes JSON natural format for RESTful services and typically RESTful services provide data in JSON and XML formats. However, often working with Ruby and PHP, I find neither JSON nor XML, particularly enjoyable for hacking services. I would much prefer REST services data in the native format of language I am working with. From service provider point of view, it’s worthwhile to target other dynamic languages like Ruby, PHP, Python, etc. This leads to the generalization of Object Notations which involves identifying a safe set of language constructs and using them for data interchange. For instance the Ruby and PHP Object Notations for above snippet can be represented as:

Ruby Object Notation:

{:body => "Chunky Bacon"}

PHP Object Notation:

array("body" => "Chunky Bacon")

Service provider who provide formats like XML and JSON,

should also consider other object notations like:

Object notation with padding is the generalization of JSONP where the Object Notation is passed as argument to a specified function which allows programming REST easier than just returning them as values. For RESTful services, JSON and other object notations are better fit than XML. For an example in action, check out http://github.com/rubyorchard/geoip-rest for GeoIP City and Country REST APIs which offer object notation in Ruby, PHP, JSON and XML formats.


New Relic RPM to monitor memcached

New Relic Infrastructure Agent now can be used to monitor memcached farm. It runs stats on configured memcached nodes periodically and ships data to New Relic RPM. The stats are reported  for each node and also aggregated stats are reported for all nodes. Check out the source at github.

List Accumulators

Suppose we want to separate  a container type object into its component parts. Accumulators provide an elegant solution to this problem. We create a list of accumulators and traverse through the original list and collect each element into the appropriate component. In Ruby, we can use inject method to implement accumulators. Suppose we want to split a list of integers into two lists of even and odd numbers. We create two empty accumulator lists for even and odd numbers.

(5..30).inject([[], []]) do |evenOdds, n|

=> [[6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30], [5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29]]

Accumulators fit naturally into functional programming language. Here is an Erlang code to do the same.

-import(lists, [reverse/1]).
even_odds(List) ->
even_odds(List, [], []).
even_odds([H|T], Evens, Odds) ->
case (H rem 2) of
0 -> even_odds(T, [H|Evens], Odds);
1 -> even_odds(T, Evens, [H|Odds])
even_odds([],Evens, Odds) ->
[lists:reverse(Evens), lists:reverse(Odds)].

acc:even_odds(lists:seq(5, 30)).


Blog at WordPress.com.