PLANET RUBY ON RAILS

In between posts that I write, I try to share links here to other cool articles around the web about MongoDB. The problem is that up until now I have felt like I needed to write a whole post about the link, which usually means it takes me longer to get the post up here.

In the interest of lowering the barrier of entry, I have added a link type. Links will be simple a title, url and short description. You probably have noticed a few come through already tonight. I hope this makes it easier for me to get you interesting information and that you find it useful. Also, if so desired, you can still comment on the links here with questions and opinions.

From now on, I will do my best to curate interesting links about MongoDB in a timely fashion and occasionally drop some of my own knowledge in more full posts. Now back to our regularly scheduled program…

A “massively multiplayer”, online crossword puzzle. Uses MongoDB’s geospatial indexing. The creators posted Building a Scrabble MMO in 48 hours if you are curious about how they did it. Crazy!

Kristina Chodorow is on a roll posting about Mongo’s assumptions, history, sharding, and now an introduction to mongosniff.

It's been a great year for Ruby on Android, but no one knows it. You can start writing Ruby apps for Android devices TODAY. You don't need to install any SDK, you don't need to install some giant Eclipse IDE, and you certainly don't need to write any Java.

Mike Leone

In Turn your Android Phone Into a Remote Spy Camera with Ruby in 15 Minutes, Mike Leone demonstrates how to use Ruby, Sinatra and Scripting Layer for Android (SL4A) to build and deploy a phone-hosted "spy camera" Web service.

SL4A is a system that allows you to run "scripting language" scripts and interactive interpreters on the Android platform. It currently supports JRuby, Python, Perl, Lua, JavaScript, BeanShell, and Tcl. Mike demonstrates how to set up a Sinatra project to use SL4A to run on an Android phone using JRuby. Upon receiving a request, Mike's app takes a picture using the phone's camera and serves it back over HTTP. He has also released the source code to a larger Ruby app called Broadcast that implements general Android device management functionality over HTTP.

Even if you don't want to build a "spy camera", Mike's walkthrough is a must-read if building Web services in Ruby that can run directly on the Android platform is of interest to you.

Technorati Tags: Clojure, Python, RPCFN, Ruby Challenge, Ruby, Programming

An introduction to clojure.test is easy, but it doesn't take long before you feel like you need a mocking framework. As far as I know, you have 3 options.

1. Take a look at Midje. I haven't gone down this path, but it looks like the most mature option if you're looking for a sophisticated solution.
   


2. Go simple. Let's take an example where you want to call a function that computes a value and sends a response to a gateway. Your first implementation looks like the code below. (destructuring explained)

   (defn withdraw [& {:keys [balance withdrawal account-number]}]
    (gateway/process {:balance (- balance withdrawal)
                      :withdrawal withdrawal
                      :account-number account-number}))

   No, it's not pure. That's not the point. Let's pretend that this impure function is the right design and focus on how we would test it.
   
   You can change the code a bit and pass in the gateway/process function as an argument. Once you've changed how the code works you can test it by passing identity as the function argument in your tests. The full example is below.

   (ns gateway)
   
   (defn process [m] (println m))
   
   (ns controller
    (:use clojure.test))
   
   (defn withdraw [f & {:keys [balance withdrawal account-number]}]
    (f {:balance (- balance withdrawal)
        :withdrawal withdrawal
        :account-number account-number}))
   
   (withdraw gateway/process :balance 100 :withdrawal 22 :account-number 4)
   ;; => {:balance 78, :withdrawal 22, :account-number 4}
   
   (deftest withdraw-test
    (is (= {:balance 78, :withdrawal 22, :account-number 4}
     (withdraw identity :balance 100 :withdrawal 22 :account-number 4))))
   
   (run-all-tests #"controller")

   If you run the previous example you will see the println output and the clojure.test output, verifying that our code is working as we expected. This simple solution of passing in your side effect function and using identity in your tests can often obviate any need for a mock.
   


3. Solution 2 works well, but has the limitations that only one side-effecty function can be passed in and it's result must be used as the return value.
   
   Let's extend our example and say that we want to log a message if the withdrawal would cause insufficient funds. (Our gateway/process and log/write functions will simply println since this is only an example, but in production code their behavior would differ and both would be required)

   (ns gateway)
   
   (defn process [m] (println "gateway: " m))
   
   (ns log)
   
   (defn write [m] (println "log: " m))
   
   (ns controller
     (:use clojure.test))
   
   (defn withdraw [& {:keys [balance withdrawal account-number]}]
     (let [new-balance (- balance withdrawal)]
       (if (> 0 new-balance)
         (log/write "insufficient funds")
         (gateway/process {:balance new-balance
                           :withdrawal withdrawal
                           :account-number account-number}))))
   
   (withdraw :balance 100 :withdrawal 22 :account-number 4)
   ;; => gateway:  {:balance 78, :withdrawal 22, :account-number 4}
   
   (withdraw :balance 100 :withdrawal 220 :account-number 4)
   ;; => log:  insufficient funds

   Our new withdraw implementation calls two functions that have side effects. We could pass in both functions, but that solution doesn't seem to scale very well as the number of passed functions grows. Also, passing in multiple functions tends to clutter the signature and make it hard to remember what is the valid order for the arguments. Finally, if we need withdraw to always return a map showing the balance and withdrawal amount, there would be no easy solution for verifying the string sent to log/write.
   
   Given our implementation of withdraw, writing a test that verifies that gateway/process and log/write are called correctly looks like a job for a mock. However, thanks to Clojure's binding function, it's very easy to redefine both of those functions to capture values that can later be tested.
   
   The following code rebinds both gateway/process and log/write to partial functions that capture whatever is passed to them in an atom that can easily be verified directly in the test.

   (ns gateway)
   
   (defn process [m] (println "gateway: " m))
   
   (ns log)
   
   (defn write [m] (println "log: " m))
   
   (ns controller
     (:use clojure.test))
   
   (defn withdraw [& {:keys [balance withdrawal account-number]}]
     (let [new-balance (- balance withdrawal)]
       (if (> 0 new-balance)
         (log/write "insufficient funds")
         (gateway/process {:balance new-balance
                           :withdrawal withdrawal
                           :account-number account-number}))))
   
   (deftest withdraw-test
     (let [result (atom nil)]
       (binding [gateway/process (partial reset! result)]
         (withdraw :balance 100 :withdrawal 22 :account-number 4)
         (is (= {:balance 78, :withdrawal 22, :account-number 4} @result)))))
   
   (deftest withdraw-test
     (let [result (atom nil)]
       (binding [log/write (partial reset! result)]
         (withdraw :balance 100 :withdrawal 220 :account-number 4)
         (is (= "insufficient funds" @result)))))
   
   (run-all-tests #"controller")

In general I use option 2 when I can get away with it, and option 3 where necessary. Option 3 adds enough additional code that I'd probably look into Midje quickly if I found myself writing a more than a few tests that way. However, I generally go out of my way to design pure functions, and I don't find myself needing either of these techniques very often.

While Twitter may see traffic spikes during Apple events, we see quite the opposite:

cached-commons: API for Common Javascripts and Stylesheets Cached and Optimized:

You probably already use Google’s AJAX Libraries as a CDN for your JavaScripts. But what do you do when Google is slow to add your favorite JavaScript library? Lance Pollard has created Cached Commons, an API for common Javascripts and stylesheets, cached and optimized on GitHub’s CDN.

Cached Commons lists dozens of scripts under categories like visualization, Ajax, syntax highlighting, HTML5, Flash, and testing, complete with links to project sources, demos, even documenation. Don’t see a script you want? Just fork the project and your script for everyone to share.

It looks like CSS libraries are on the TODO list, just like I had asked of Google in Episode 0.3.2!

[Source on GitHub] [Homepage]

• Hacker News | Ask HN: Are there any good online communities for UX design?
  Links to good UX communities

Mastering Node: Open source eBook for Node.js:

GitHub is for more than just code you know. It’s a great collaboration tool for hackers. Nathan, Chris, and I use GitHub as a big part of our workflow for our upcoming book.

TJ (do we really have to say his last name by now?), of Express and now Sencha wants you to Master Node.js by reading and hacking on his own community-driven ebook.

The book will walk you through Node step-by-step from installation to topics like EventEmitter:

Typically an object inherits from EventEmitter, however our small example below illustrates the api. First we create an emitter, after which we can define any number of callbacks using the emitter.on() method which accepts the name of the event, and arbitrary objects passed as data. When emitter.emit() is called we are only required to pass the event name, followed by any number of arguments, in this case the first and last name strings.

var EventEmitter = require('events').EventEmitter;

var emitter = new EventEmitter;

emitter.on('name', function(first, last){
    console.log(first + ', ' + last);
});

emitter.emit('name', 'tj', 'holowaychuk');
emitter.emit('name', 'simon', 'holowaychuk');

Go ahead, fork it, contribute, and add ePub support.

[Source on GitHub]

Episode 0.3.3 - Node Knockout:

Micheil and Wynn caught up with Gerad and Visnu from the Node Knockout to talk about the 48 hour Node.js development competition and its entries.

Download MP3

Items mentioned in the show:

• Lone Star Ruby Conference - Texas’ regional Ruby conference in Austin
• Mike Perham - The awesome Rubyist whose name gives Wynn fits
• Node Knockout - The 48 hour Node.js coding competition
• Rails Rumble - Ruby’s own 48 hour coding bash
• Gerad - of Gerad & Visnu, the “data-y” and “product-y” guy
• Visnu - the “developer-y” and “designer-y” guy
• Fortnight Labs - the proper name for Gerad & Visnu, Inc.
• List of great Node Knockout Judges
• Joyent & Heroku are great places to host your Node.js apps.
• Express High performance, high class web development for Node.js
• Connect - high performance middleware framework for node featuring robust middleware for serving static files, advanced routing, cookie and session implementations, error handling and much more.
• npm is a package manager for node. You can use it to install and publish your node programs. It manages dependencies and does other cool stuff.
• Node Inspector is a web inspector based Node.js debugger
• Go vote for your favorite entries!

dalli: High performance memcached client for Ruby:

After maintaining memcached-client for a couple of years, Mike Perham decided it was time to build a new Ruby client for Memcached from the ground up. Dalli aims to be a simpler, high performance client for Memcached the simple, ultra-fast in-memory key value store.

Among the improvements in Dalli:

• Use of the faster binary Memcached protocol vs. the slower text protocol
• Almost 500 fewer lines of Ruby
• Monitoring hooks for tools like New Relic and Rack::Bug
• SASL support for managed environments

To get started, just install the gem

sudo gem install dalli

You can then write to and read from your cache:

require 'dalli'
dc = Dalli::Client.new('localhost:11211')
dc.set('abc', 123)
value = dc.get('abc')

[Source on GitHub]

GitHub launched with a simple pull request system on day one. You've used it to send 200 thousand pull requests in just over two years. Now we're taking it to the next level with a re-imagined design and a slew of new tools that streamline the process of discussing, reviewing, and managing changes.

As of today, pull requests are living discussions about the code you want merged. They're our take on code review and represent a big part of our vision for collaborative development.

Know What You're Sending

Sending a pull request is simple. Browse to the branch or commit with your recent work and hit the button. You'll be greeted by a brand new screen:

Pull requests are now fully revision aware and take into account not only what you would like pulled but also where you intend those changes to be applied. They even work when sending from and to the same repository, making pull requests just as useful in scenarios where a team is working out of a single shared repository as they are in the fork + pull model.

When you send a pull request, you're starting a discussion.

Some back and forth is typically required before a pull request is accepted. The maintainer needs clarification, or the change doesn't conform to the project's coding conventions, or maybe someone was able to take a concept 80% to completion and needs help working through the last bits.

The discussion view makes pull requests the best place to have these types of conversations. Anywhere. Here's why:

The discussion view presents all pull request related activity as it unfolds: comment on the pull request itself, push follow up commits, or leave commit notes - it's all interleaved into the discussion view as it happens.

Revision Aware

The discussion view is perfect for watching changes evolve over time, but it's equally important to know exactly what modifications would be made if the changes were accepted right now. The Commits and Files Changed tabs are quickly accessible and show the cumulative progress of the pull request:

Look familiar? It's a miniature compare view.

Visible, Linkable, Archived

Anyone with access can browse a repository's pull requests by visiting the repository's Network ⇢ Pull Requests page.

Every pull request has a URL so you can link to them. They're archived forever and indexed by search engines.

An Issue at heart

Pull requests are tightly integrated into GitHub Issues. When you see an icon in the issues list, it means there's a pull request attached.

Don't use Issues? No problem. You still get awesome pull requests.

Pull Request Dashboard

The pull request dashboard gives a high level view of all pull requests across every repository you or your organization is involved with.

What are you waiting for?

Pull requests sent prior to today are not automatically imported into the new system. If you have outstanding requests, use them as an opportunity to try out revision aware pull requests today!

Technorati Tags: Ruby, The Ruby Programming Language, Ruby Programming Challenge For Newbies, Programming, RPCFN, Dr. Bruce Scharlau