Working with LimeSurvey’s RemoteControl2 JSON-RPC API in PHP

Recently, I needed to switch away from SurveyMonkey, which, while still a useful free service for quickly collecting some basic Survey results, leaves much to be desired in terms of what they offer in their basic version. Of course the fully paid versions offer significantly more functionality, but the upper-end of the pricing schemes that do everything I needed are just way out of my price range for small individually-funded and/or non-budget independent projects.
This lead me to LimeSurvey (formerly PHPsurveyor), the leading open source web-based Survey data collection software, with a back-end written entirely in PHP.
Getting LimeSurvey installed on my own server was incredibly easy, just download the latest release version and upload the files via FTP. Then load the installation script and it will guide you through the remaining install steps (which are basically just setting a username/password for the administrator account, as well as database configurations such as connection info, table naming, etc). Pretty standard fare for a long-running open source PHP project with a solid development community in place.
What really set LimeSurvey apart from the alternatives though, was the extensibility offered by its API, dubbed RemoteControl2 (with support for both XML-RPC and JSON-RPC).
I had initially started out with XML-RPC since I’m kind of a nerdcore “semantics” guy, and favour XML over JSON for most server-side integration use cases (unless I’m publishing data for client-side consumption, then I almost always favour JSON). The reason, well there simply are way more tools and methodologies already in place for XML than JSON and the reliability mechanisms built into XML such as well-defined schemas (DTD/XSD) which provide data validation, namespsaces (ns) which prevent conflicts in name/value label namings and help ensure you get the right values when parsing, stylesheets (XSL/XSLT) which allow for on-the-fly transformations, query languages (XPath and XQuery) which simplify data filtering and extraction tasks, and XML security mechanisms such as Digital Signatures which enable better security. However that’s all sure to start a debate on here.
The point is, I wanted to go XML-RPC, I really did! However I have to say, the simplicity of their JSON-RPC API which seems particularly well-implemented won me over.
So here’s what I made, a simple Survey response submission script that I call “limesurvey.collector.php“:
Read the rest of this entry »
HTML5 Radio Tuner (powered by ShoutCast API)

Since I wrote about Skeumorphs last month, I thought I’d include this piece I had worked on. This is an older idea I had that I’d done the initial design for but forgot (ahem… procrastinated) to do the coding for back when I had the idea. The general concept was to replicate the look of an old-school needles and knobs analog radio.
I’ve always sought to bring more humanity to the online content experience. If we have to be forced to sit in an office or stare into a screen for most of our waking lives, just to be considered “modern and relevant” and have a chance to compete in this global marketplace, then the experience might as well feel natural and familiar to our interactions with the real world. It might as well be a pleasant co-existence with technology, rather than a mechanical, robotic, in-human and uncomfortable one.
So enough of that esoteric philosophy nonsense and on to the interesting stuff. The concept is that I missed the radio dial on my grandfather’s old analog radio. As a child, I used to play with the knobs and enjoy tuning into many different stations. It was a long-range radio so on a good day in my teenage years, I could even tune into the Howard Stern show broadcast from New York and some of the more edgy french stations from Quebec. Even my grandfather’s gone digital now though, so I figured the fond memory of this technology from the past might as well too.
There were 5 main components to this project:
Read the rest of this entry »
The Getting Started in JAVA Guide (That I Wish I Had In University)

History | Language | Installing | Examples |
---|---|---|---|
Compiling | Running | Programs | IDEs |
The Java programming language is one of the most widely used and widely supported programming languages in the world (in terms of total number of devices and systems running it). Since its inception, it has also been the subject of several major lawsuits (i.e. Oracle .vs. Google, Google .vs. Oracle countersuit, US Gov .vs. Microsoft, Apple .vs. Android OEMs – Samsung, Motorola, HTC and Sun .vs. Microsoft) due in no small part thanks to its aforementioned widespread use in just about every major device from mobile phones to back-end server infrastructure and from individual desktops/laptops to large-scale distributed computing grids (like Amazon’s AWS & EC2).
Java didn’t set out to be a better C for every programmer, and in fact had an identity crisis early in its life. It started out in 1991 as a language called “Oak”, part of a small project called the “Green Team” initiated by Patrick Naughton, Mike Sheridan, and James Gosling, who is primarily credited with the design of the language that became Java. (Bryan Youmans has a page on the history of Java, with some interesting thoughts on the language design. There’s also an official version of the history from Sun/Oracle.)
Sports Stats API feeds evaluated: ChalkGaming wins

Well, I’ve decided to give this one away in the title, since the good folks over at ChalkGaming helped me out quite a bit while consulting with a big client who wanted to integrate Sports Stats into their Online Newspaper properties.
Requirement
Create a sports widget to display quality sports data (including: schedules, box scores, standings, betting odds, league news, trade and injury reports) for the top 6 big leagues (NHL, NBA, NFL, CFL, MLB, MLS) and ensure it is scalable to display as many other sports as possible. When thinking of how to solve this problem, I quickly checked out each of the major leagues’ sites for their terms of use to see if a quick scraping solution was practical (or even legal).
One possible solution would be to scrape the required data directly from each of the Big Leagues’ own website:
Problem
The problem with this of course, is that each site has a very different format (many custom parsers required to get and present the data) and vastly differing licensing terms (some allow data reuse and even encourage caching rather than straining their site, such as MLB). However, most don’t allow reproduction of their site in any form; meaning most would probably not allow scraping or caching sports stats and other data from their server onto your own server, so you could at best display the content in an iframe and be extremely limited in terms of display options for the end-user.
Solution
WordReference API – AJAX SDK & Widget

Yesterday I wrote about the Google API shutdown. It seems that I was wrong in that post about Wordreference not having an API, just a few days earlier founder Michael Kellogg announced the introduction of the brand-spanking new Wordreference API.
Like a dunce I contacted Michael by email to learn about this new revelation without double-checking the site itself (I knew in the past they didn’t have one, as I had checked just a month or so before out of curiosity). It seems that the API was in-development for quite some time, but was rushed out the door on the news of the Google Translate API shutdown. I can easily say that nothing was lost in the final rush, the API is excellent! There are both HTML or JSON versions of the API currently supported and the RESTful URIs make the whole thing quite intuitive to work with.
- A request can be made as follows, to search for the English-to-French translation of “hello world”:
http://api.wordreference.com/API_KEY/enfr/hello - While the same request with just pure JSON data returned would be:
http://api.wordreference.com/API_KEY/json/enfr/hello - For French-to-English, simply use fren as the dictionary, as follows:
http://api.wordreference.com/API_KEY/fren/hello - *Don’t forget that you’ll need to append your own WordReference API Key (previously userID) by adding it to each request in the URL path before the return format, dictionary type, or word/term being looked up. You can sign up for your own API Key using the following form:
http://www.wordreference.com/docs/APIregistration.aspxFor now your userID obtained from viewing your profile after registering and logging into the WordReference Forums can still be used, but later the API will switch over to API Keys only.
- Maybe the coolest thing about the API, is that it supports JSONp callbacks, as in the following request:
http://api.wordreference.com/API_KEY/json/enfr/smile?callback=translate
Awesome! So, feeling a bit dejected earlier this week, yet today having newfound hope for the future of online Translations, I’ve decided to build an SDK and example Widget for the newly released WordReference Dictionary API. I wanted to show multiple ways of interacting with the Translation API (including JSONp, jQuery, YQL, Server Proxy, Cache, etc) all directly via JavaScript. Also, with the completed Widget example, I wanted to show how you can use the API to simulate a full-text translation in real-time, without there being a full-text machine translation feature supported by WordReference (which works on words or phrase lookup only, since it is primarily a dictionary, not a translation service). The only downside of this approach, is that it may result in ALOT of requests to the API.
The CSS presentation styling is extremely minimal, but in the near future I’d consider adding more CSS3 hip features like text-shadows, gradients, transitions/fades and rounded corners. In the meantime, we get this basic CSS:
Read the rest of this entry »
BC$ = Behavior, Content, Money

The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.