Pushing Squares - The Squarepush Blog

Released Divining Rod Library

2010-02-24T00:00:00-05:00

We just released another iteration of our mobile device profiling library, Divining Rod. Divining Rod hopes to simplify the process of determining which mobile devices are visiting your site or web application, and their capabilities.

Unlike more complicated solutions, such as WURFL, we wanted to make the solution both simple to implement and easy to customize, a feat we think we’ve accomplished with Divining Rod.

Read more about Divining Rod here, or download it from github.

Don't put another dime in the jukebox

2010-02-23T00:00:00-05:00

Or how I stopped writing regular expresssions to parse user agents

Just want the code? Head over the Github and grab it!

Beneath every good mobile app, lies the ability to easily and accurately determine the make and model of the user’s mobile device. And up until a month ago we hard coded this into our apps. But like everything, as time passed, what seemed like the simplest solution began to morph into a complex web of regular expressions and conditional statements.

And we’ve seen a fair number of solutions to the problem. Some clients come with their own complex sets of mobile matching algorithms, while other rely on open source solutions like WURFL. At Squarepush we began to wonder if it was all really necessary.

The problem for the majority

If you’re looking to deliver Java jar files to every Nokia made since 1994 and need a reliable way to determine exactly which phone you’re dealing with, this isn’t the library for you. But according to AdMob, 91% of mobile traffic in North America consist of iPhones, Android, and Blackberry, in that order. So if you’re simply wanting to build the best possible web experience for the majority of your users, something easier is in order

Divining Rod - A magical stick for mobile profiling

When we looked at the current solutions for profiling phones, we noticed a lot of repetition. Most of the phones out there have similar user agents. For example, both the Apple iPhone and the Nexus One have a user agent with the words ‘Apple’, ‘Mobile’, and ‘Safari’.

The other problem was defining capabilities. Both Android and the iPhone are capable of showing videos on YouTube, but the geolocation javascript hooks are slightly different. What we needed was a way to tag multiple mobile devices and not be forced into an absolute hierarchy.

Enter DiviningRod

DiviningRod lets you do something like this:

DiviningRod::Mappings.define do |map|
    map.ua /Apple.*Mobile.*Safari/, :format => :webkit
                                  , :tags => [:webkit, :safari, :youtube_capable] do |webkit|
      webkit.ua /Android/, :name => 'Android', :tags => [:android, :google_gears]
      # Apple iPhone OS
      webkit.with_options :tags => [:apple, :iphone_os] do |iphone|
        iphone.ua /iPad/, :tags => :ipad, :name => 'iPad'
        iphone.ua /iPod/, :tags => :ipod, :name => 'iPod Touch'
        iphone.ua /iPhone/, :tags => :iphone, :name => 'iPhone'
      end
    end

    map.ua /BlackBerry/, :tags => :blackberry, :name => 'BlackBerry'
end

So when we see an Apple iPhone user agent like this:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7D11 Safari/528.16

We can go ahead and tag it apple while continuing to look for more specific matches, in this case the iPhone match.

And when we profile that request with DiviningRod, we get to do this:

profile =  DiviningRod::Profile.new(request)

# Notice that the tags aggregate. This is the only hash value that doesn't override.
profile.tags #=> [:webkit, :safari, :youtube_capable, :apple, :iphone_os, :iphone]

# Which we can ask about
profile.iphone? #=> true
profile.apple?  #=> true

# and retrieve arbitrary hash values, like :name, and :format
profile.format  #=> :webkit
profile.name    #=> 'iPhone'

Where we’re headed

Right now it’s a really simple but powerful library, and while we want to keep it as extensible and intuitive as possible, we also want to make it dead simple to get it configured for most applications.

The next step is building out the definitions, and including them in the gem for easier use. Ultimately, we’d like to build one master set of user agent definitions that cover 95% of the mobile apps out there, while still allowing for customization. We think we’re pretty close to that goal.

Released PingTags

2010-01-16T00:00:00-05:00

PingTags.com is our latest project demonstrating what can be done current QR Code technology. We’re able to capture some exciting metrics, such as the exact location of the user, from a wide variety of devices.

Check out our blog post about it for more information, or try it out for yourself.

The economics of Mechanical Turk

2009-08-26T00:00:00-04:00

This is part of a series of Mechanical Turk blog posts – check out more at Mechanical Turk in Ruby, Mechanical Turk Pages in JQuery, and Building Mechanical Turk into Rails(coming soon).

In this post I want to go over just a few tips about deciding how much to pay and how to structure your HITs on Mechanical Turk for the best and most cost competitive results.

The business behind the HITs

At the heart of it, Mechanical Turk tasks are completed by real people, so unlike the other Amazon services, the pricing isn’t so simple. So when you start to place tasks on the network, it’s completion is dependent upon several factors, the largest being:

Price
Complexity
Number of tasks
Time of creation

The first two are obvious, but the combination of all three can make for a tricky time figuring out what to offer.

Number of tasks

The more task available the less reward you can offer. This works because a worker is looking at this from two angles:

How long will it take to learn to complete the tasks?
And how long is each task going to take to complete?

The first question is the biggest barrier to getting someone to work on your HIT’s. If the first few take quite a while to learn how to do, and their only 20 available, it’s not going to be very rewarding.

However offer 1000 and you can probably discount your price significantly, so submitting your HITs all at once has a tendency to encourage acceptance and completion.

Time of creation

Although there are people all across the globe working on Mechanical Turk, if your task requires a decent grasp of English, or knowledge of western culture(eg. Read this newspaper article and tell me if it’s positive of negative), you’re workers will primarily come from the US and Canada. This of course means that you need to schedule your HIT’s accordingly.

A reasonable person would expect that HITs in the system get randomly cycled through listing page, however the truth is that they are listed chronologically, and this means that if you don’t get them completed within the first hour, it’s unlikely they’ll be completed at all.

Complexity

There’s two types of complexity you need to worry about, but both have the tendency to chase away perfectly good workers.

The first is task complexity. Distill your task down to the most basic parts, and don’t expect everyone to understand your instructions. The wording should be simple, clear, and concise. You should be able to look over it and immediately understand what it is you’re asking for and how it should be done.

The second is UI complexity. A worker wants to be able to load up new tasks and complete them as fast as possible. What they don’t want is a website that slow, or javascript magic that doesn’t work in their browser. And don’t assume someone has the lastest browser when designing your external HITs. Make the design simple and easy to use. And for god sakes, don’t get crazy with the JS – the goal is a web application page that works well for the worker and allows them to use the key binding and events they are used to. Especially if it’s data entry, make sure the tab navigation works.

Price

The easiest way to figure out what your tasks are worth is to build a baseline guide. Start with a few(less than 20) and pick a price which seems inline with similar tasks. Also ask that each task be completed 4 times to ensure that it’s not just one worker doing it. Then posts the jobs, and check the response. If you don’t have them all completed within a few hours, cancel them and raise the price. Likewise if they’re competed quickly, it may be a sign you’re paying too much. You’re only going to figure this out through a little trial and error, and maybe a little gut instinct. You’ll get better an estimating the appropriate reward as you get more experience

Putting it together

It always looks easier than it is, but in this case we’ve got a lot of different variables to work with. The first step is to establish a price and build from that. You can also attempt to fit more than one task into a HIT; if they are simple, you may lower your cost per HIT by allowing workers to spend more time on the HITs and less on page reloads.

Integrating Mechanical Turk can be a daunting task – let us build a solution that’s easy to administer and get Mechanical Turk working for you and not just sucking up your time. We built and maintain the only open-source Ruby library for Mechanical Turk, so why not let us do the hard part. Give us a call!

2D Barcode size and experiences

2009-08-25T00:00:00-04:00

I went to see District 9 the other day, and while I was in the lobby I noticed the new poster for Tim Burtons ‘9’ movie. If you haven’t seen it, I’ve included it below

In the center of the poster is a type of 2D barcode called a QR code, which the consumer can scan with a cellphone camera(with software) and be sent to the URL encoded in the barcode. This article assumes you already know a little about these.

The first thing I noticed of was the unusually dense barcode. Normally I’d expect a barcode to look like this

Which is 21×21 blocks of data. But the QR Code on the ‘9’ poster was 29×29, a huge difference. Why does it matter? You see currently when you use a QR Code in todays market, a disproportionally large number of your ‘clicks’ will come from iPhones. And since these are phone without an autofocus lens, you have can’t get them too close to the code you’re reading or the image will be blurry and you’ll be unable to scan the code. In this case the poster was large enough that it could be read by an iPhone, but the more dense the barcode the harder it is to read and the longer it takes. The phone processor has 841 blocks to deal with rather than 441, a 91% increase.

What’s the solution

Well here’s the embarrassing part for Hyperfactory Ltd, the company that built the mobile campaign – the poster’s code above and the smaller example below it are the same. They resolve to the same URL, work on all QR code readers, and both meet the Denso Wave standard – with one exception, I uppercased all the characters in the URL on the smaller one. That’s right, by using only uppercase ASCII characters, I reduced the complexity of the barcode by 47%. The reason, when using only uppercase ASCII characters, the encoding method reverts to a simpler character set which results in more compression.

Now I can’t fault Hyperfactory too much; it’s a new technology and a market that’s greatly misunderstood. But now their users have to deal with scanning a more complicated barcode, and the likelihood successful scans decreases. So it’s still a costly mistake none the less.

QR Codes are actually quite simple

Actually, ridiculously simple. In fact there are only 2 rules you need to know when generating your own codes

Use only uppercase characters in the URL, and avoid complicated URL’s. By complicated I mean URL’s with ‘?’ or ‘&’ in them, which force the barcode complexity to increase dramatically. This usually happens when you have a long URL that includes extra data, such as a Google Map’s URL. Simply run these through a service like bit.ly. Note: You’ll need to use the custom address feature and give it a name with all uppercase characters, as bit.ly is case sensitive
Keep it under 25 characters but don’t worry about getting it as short as possible. A 14 character URL results in the same 21×21 barcode as a 25 character URL. So instead of making it cryptic and small(e.g. http://9.msite.tv/qr1), use the space to build a nice looking URL. For example, in this case, HTTP://M.9THEMOVIE.COM/1 – where 1 is your tracking number for the poster.

Resources

Need to quickly generate a QR code, check out these resources:

The Google Charts API – Free and fast, but requires some basic web knowledge. It’s a great solution to integrate into an existing web application, and that’s why it’s our personal favorite.
INVX encoder – This is a the more user friendly of the two; it allows you to quickly generate 2D barcodes on the fly. Just plug in the URL and go. Better than the Kaywa encoder in my opinion, as Kaywa tends to add unnecessary error correction to the codes.

Don’t get fooled by the marketing firms that make QR codes and mobile campaigns seem difficult. If you have any questions about QR codes, and how to integrate them into you web application, give us a call. We can usually build a solution in a matter of days that get the results you need, without a lot of extra work. Really, it’s that simple!

Mechanical Turk in Ruby

2009-08-11T00:00:00-04:00

This is part of a series of Mechanical Turk blog posts – check out more at Economics of Mechanical Turk, Mechanical Turk Pages in JQuery, and Building Mechanical Turk into Rails(coming soon).

If you’ve used Mechanical Turk, you already understand some of the initial challenges of getting a successful process in place. Even without getting into the development side of it, Mechanical Turk involves a great deal more than a technical problem that can be solved by a good API.

There’s the issue of payment, task design, and processing the results. It’s actually an incredibly challenging problem, which we’ve had fun solving. The variable list is huge, and eventually you start asking yourself questions like “What’s the best time to request a task if the ideal worker is in the Phillipines?”

I’m going to first touch the basics, then move into code and development using our RTurk ruby gem.

What is Mechanical Turk

Simply, it’s a service where you can ask a human worker to perform a task. It can be anything, quite literally. You can ask them to verify a picture is not vulgar, or call and do phone number verification. So when I go through some of the details I’m going to give some easy sample problems we can solve and narrow down the complexity.

How it works – Worker side

When a worker logs in, he sees a list of tasks available to him, the price and a basic description of the task to be performed. He clicks on one that he prefers and looks at the actual task. He can then choose to accept it, or go back to the list and choose a different task. At this point if he accepts the HIT he’s perform it and submits the answer.

Let’s have an example:

The task is to look at a picture and select if it’s vulgar or inappropriate. On his end all he sees is the Mechnical Turk website with a page framed with the question. It’s a simple iframe with the page inside detailing the task, showing the picture and asking for a response and submission. It’s your basic HTML form and it can be hosted on Amazon or offsite. Surround the the frame is the MTurk site with information like how much you’ve made and other metrics.

How it works – Requester side

You can use Amazons question builder, which uses a template and a simple web GUI editor to build a question for a worker, but we’re developers and doing this in Ruby, so lets ignore that since it’s quite trivial.

What you need to know is that there are two ways to submit a HIT. Submit an XML document with the questions, requirements and layout information, which Amazon will transform into an HTML form which they host locally. Or submit a URL which Amazon will place via iframe inside their own site.

I’m not even going to touch the XML route. In my opinion it’s far more complicated than it needs to be and doesn’t give you near the freedom to build the form how you wish. The ‘external HIT’, as Amazon refers to it, gives you an incredible amount of freedom to craft the task page and even use javascript UI tweaks.

When you make a request, you’ll send up the external HIT url, the requirements, and reward amount in a restful request. Your external page should include a form, obviously, that posts to Amazon’s external hit submission url, and one of your fields should include the AssignmentID so Amazon knows who it’s from.(It’ll be passed to you in the URL)

Let get to the code

I’m going to keep this simple, so the example task will be to flag a picture if it’s vulgar. And I’m going to use static page external HIT. In this case we are going to drop the Turker(Amazon’s term for the workers) to a page hosted on s3 at http://s3.amazonaws.com/squarepush.com/turk/picturerate.html

On the request side

It’s as simple and writing up the properties and creating the HIT.

Some things to note

We are passing the picture_url parameter along with the URL
MaxAssignments lets more that one person perform this task(ie. let 3 people rate the same picture)
You’ll see we have a reward and qualifications of 90% approval rate
In this case the turker will be directed to http://s3.amazonaws.com/squarepush.com/turk/picturerate.html?picture_url=example.jpg&AssignmentId=abcd12345 where you’ll be able to get the AssignmentID from the URL and place it in the form to be submitted.

require 'rturk'

props = {:Title=>"Tell me if this picture is safe for general audiences", 
         :MaxAssignments=>1, :LifetimeInSeconds=>3600, 
         :Reward=>{:Amount=>0.05, :CurrencyCode=>"USD"}, 
         :Keywords=>"twitter, blogging, writing, english", 
         :Description=>"I need to know if this picture is vulgar or adult only",
         :RequesterAnnotation=>"Example1",
         :AssignmentDurationInSeconds=>3600, :AutoApprovalDelayInSeconds=>3600, 
         :QualificationRequirement=>[{
           # Approval rate of greater than 90%
           :QualificationTypeId=>"000000000000000000L0", 
           :IntegerValue=>90, 
           :Comparator=>"GreaterThan", 
           :RequiredToPreview=>"false"
           }]
        }

@turk = RTurk::Requester.new(AWSAccessKeyId, AWSAccessKey, :sandbox => true)
page = RTurk::ExternalQuestionBuilder.build(
  "http://s3.amazonaws.com/squarepush.com/turk/picturerate.html", :picture_url => 'example.jpg')

# Turkers will be directed to http://s3.amazonaws.com/squarepush.com/turk/picturerate.html?picture_url=example.jpg&AssignmentId=abcd12345

@turk.create_hit(props, page)

Want to know more about the landing page for the Turker – I put it in a separate article – “Mechanical Turk External HIT Pages with JQuery”

Getting the results

After you’ve created your HIT’s it becomes a waiting game. Turkers will look for promising HIT’s that they believe are worth their time, open them up to preview them, then accept and complete them.

If you’re having multiple Turkers do a single task(getting more than one opinion of the picture for example), you’ll have multiple assignments attached to that HIT.

Amazon has what I consider to be a pretty goofy format for the answers, which come in the form of escaped XML, inside of a wrapper XML document. Yes, you read correctly – an escaped XML document inside of an XML document. I’ve taken the liberty of having the RTurk library go ahead and unescape it and pull it in as a hash. I hope you don’t mind.

Again, lets have an example (You’ll need to have saved each HIT id from the creation, which I usually put in a database, but I won’t go into that now)

@turk = RTurk::Requester.new(aws['AWSAccessKeyId'], aws['AWSAccessKey'], :sandbox => false)

answers = []
@turk.get_assignments_for_hit("ABCDEFG1234356789").each do |assignment|
   answers << assignment['Answer']
end

You should get answers that look something like this:

 [‘inappropriate’ => ‘yes’, ‘assignmentId’ => ‘12345abcde’]

At this point you can decline to pay the worker if you feel the task wasn’t completed correctly, or let the worker get paid automatically (set via the ‘AutoApprovalDelayInSeconds’).

Tips and Tricks

Keep it external and build your own submission page. This could be a page on a rails app, or a simple HTML page with javascript. But keeping it external gives you the ability to customize as you see fit.
Pass a unique record id with each HIT. You can’t assume that every incoming Turker completes the task, in fact many return it. Pass in an identifier to each HIT created and let Amazon deal with the messy details of returned HIT’s and previews.
Make sure the page is easy to read and loads quickly. This will encourage Turkers to select and complete the HIT, and at lower prices.

Need Help?

Although we wrote and open sourced the RTurk gem with the intention of giving everyone easier access to Mechanical Turk, it’s still a complex system with a steep learning curve. Give us a call if you need help – we’re the Ruby experts when it comes to Mechanical Turk.

Mechanical Turk External Page with JQuery

2009-08-11T00:00:00-04:00

This is part of a series of Mechanical Turk blog posts – check out more at Economics of Mechanical Turk, Mechanical Turk in Ruby, and Building Mechanical Turk into Rails(coming soon).

If you lazy, and all good programmers are, you don’t want to spend too much time building the external pages for your Turkers to land on. Ideally you’d like to be able to simply pass in a variable, have them perform the task, and submit it – all without you having to be involved.

Amazon currently uses a static page with javascript in it’s example ruby pack, and while it’s a perfectly acceptable example, I prefer to use JQuery when I’m doing any significant page manipulation. So what I’ve done is rewrite the page in a more unobtrusive manner and using some tried and true tools to get the work done.

Get to the code already!

<!-- This file needs to be hosted on an external server.  -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
  <title>Title, an XHTML requirement. This message brought to you by the W3C</title>
	<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js" type="text/javascript"></script>
	<script src="http://projects.allmarkedup.com/jquery_url_parser/jquery.url.packed.js" type="text/javascript"></script>
</head>
<body>
<form id="mturk_form" method="post" action="http://www.mturk.com/mturk/externalSubmit" onSubmit="return validFormCheck()">
<input type="hidden" id="assignmentId" name="assignmentId" value="" />
<h1>Is this picture inappropriate?</h1>

<h2>Criteria</h2>
<ul>
  <li>Look at the picture and tell me if it's inappropriate</li>
</ul>   
<div id='picture'></div>                                 
<input type="radio" name="innappropriate" value="no" />No<br>
<input type="radio" name="innappropriate" value="yes" />Yes<br>
<p/>
<input id="submitButton" type="submit" name="Submit" value="Submit" />
<p/>

</form>
<script type='text/javascript'>
    /*<![CDATA[*/
 		// From the Jquery plugin - http://projects.allmarkedup.com/jquery_url_parser/
		var assignmentId = $.url.param("assignmentID");
  	$('#assignmentId').value = assignmentId;


    //
    // Check if the worker is PREVIEWING the HIT or if they've ACCEPTED the HIT
    //
    if (assignmentId == "ASSIGNMENT_ID_NOT_AVAILABLE")
    {
      // If we're previewing, disable the button and give it a helpful message
      $('#submitButton').disabled = true;
      $('#submitButton').value = "You must ACCEPT the HIT before you can submit the results.";
    }
		//
		// Now show the image
		//
		$('#picture').append($('<img>').attr('src', $.url.param("picture_uri")));



    /*]]>*/
</script>
</body>
</html>

What’s going on here:

First we disable the submit button to keep the user from submitting it without first accepting the assignment. This happens when a Turker is previewing the task.
If they’ve accepted it, and we have an AssignmentID, we go ahead and put the AssignmentID in the form. This is the only way Amazon can know whom the submission belong to.
We grab the picture URI from the URL params and display it to the user via JQuery. Obviously we’re assuming that your task will pass a picture_uri parameter.

Jekyll Sitemaps

2009-08-10T00:00:00-04:00

We build and deploy this site with Jekyll, and one thing I haven't seen written about is a sitemap for Jekyll. Sitemaps are really simple and obvious, but it should save you about 15 minutes if your looking to do a quick sitemap in jekyll. Here's what we currently use for this site.

---
rooturi: http://squarepush.com
---
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
      <loc>http://squarepush.com/</loc>
      <lastmod>{{ site.time | date: '%Y-%m-%d' }}</lastmod>
      <changefreq>weekly</changefreq>
      <priority>1</priority>
   </url>
   <url>
      <loc>http://squarepush.com/contact.html</loc>
      <lastmod>{{ site.time | date: '%Y-%m-%d' }}</lastmod>
      <changefreq>weekly</changefreq>
      <priority>0.8</priority>
   </url>
   <url>
      <loc>http://squarepush.com/about.html</loc>
      <lastmod>{{ site.time | date: '%Y-%m-%d' }}</lastmod>
      <changefreq>weekly</changefreq>
      <priority>0.8</priority>
   </url>
   <url>
      <loc>http://squarepush.com/ps/</loc>
      <lastmod>{{ site.time | date: '%Y-%m-%d' }}</lastmod>
      <changefreq>daily</changefreq>
      <priority>1</priority>
   </url>
{% for post in site.posts %}
   <url>
      <loc>{{ page.rooturl }}{{ post.url }}</loc>
      <lastmod>{{ site.time | date: '%Y-%m-%d' }}</lastmod>
      <changefreq>weekly</changefreq>
      <priority>0.8</priority>
   </url>
{% endfor %}
</urlset>

Time Taken - A git time tracker

2009-08-06T00:00:00-04:00

If git is such an integral part of your day job, and you work on the clock, wouldn’t it be nice to combine tracking time with your git commits? Tracking time can be difficult when you have such a different system. I still use a timer to keep track of what project I’m working on, but inherently there’s a disconnect from the code. If you’ve got more technically savvy clients that like to keep track of the git log, combining time tracking also allows them to get an idea or how long something takes and set future expectations.

But where do we log the time. You could quickly look at a days logs and tally up the time, but with all that data you should be able to mine it for a little more insight than just billing. This is where Google Spreadsheets comes into play. If you weren’t already aware, Google Spreadsheets now allows you to create a html form for your spreadsheet and let people enter information into it from any website. While this is a cool feature in and of itself, it has the sideeffect of letting of simple ‘get’ or ‘post’ information from anywhere: the command line, curl, net/http in ruby. By now, where I’m going with this is pretty obvious.

A post-receive/post-commit hook – what I want is to be able to add time taken to a git message like this:

 git commit -a -m "Added a user method for activation [TT 30m]"

Then when I send it up, or commit it(depending on your setup), I should see log entry for that time show up in my Google spreadsheet.

Here’s the post-commit script

#!/usr/bin/ruby -w

# Time Taken
# A ridiculously simple way to track time in git using Google Spreadsheets
# Copyright: 2009 Mark Percival - SquarePush LLC - squarepush.com
# License: MIT

# Installation
# 1. Create Google spreadsheet and update configuration
# 2. Copy this file to .git/hooks/post-commit in your project
# 3. chmod +x .git/hooks/post-commit

# Usage:
# git commit -a -m "Updated to rails 2.3.2 [TT 30m]"
# git commit -a -m "WTF? No 'goto' in Ruby? [TT 2.5h]"
# git commit -a -m "Switched back to Merb [tt 1.25H]"  <--case insesitive

# How to set this up
#
# Start by building a spreadsheet with the following columns
# Client | Project | Minutes | Message | Commit | Committed By
#
# Then create a form for it and go look at it
# Inside the form source you'll see the post URI
# It should look something like this
# http://spreadsheets.google.com/a/mpercival.com/viewform?hl=en&formkey=dDVWVTZvYmg45ExeVEp0Z0RlN3lCcWc6MA..
# This is all we need to talk with google - The rest should be pretty self explanatory

# Configuration
# The only stuff you need to worry about
# ------------------------------------------------------------------------
form_post_uri="http://spreadsheets.google.com/a/mpercival.com/formResponse?formkey=dDV2VTZFYmg3ME7PVEp240RlN3lCcWc6MA.."
client='Github'
project='Speed improvements'
committer='Mark Percival'
# ------------------------------------------------------------------------



last_log = `git log --pretty=oneline -n1`
last_log.strip.match(/^([0-9a-z]+)\s(.+)$/m)

commit = $1
message = $2

if match = message.match(/\[TT\s(.+)(.)\]/i) 
  time = match[1]
  unit = match[2].downcase
  case unit
  when 'm'
    minutes = time.to_i 
  when 'h'
    minutes = (time.to_f * 60).ceil
  else
    puts "Error logging Time Taken \"#{match[0]}\" \n"
  end
end

if minutes
  # Require only if we have minutes to log, since this is the slowest part
  require 'net/http'
  require 'uri'
  require 'cgi'
  client = CGI.escape(client)
  project = CGI.escape(project)
  message = CGI.escape(message)
  committer = CGI.escape(committer)
  puts "Logging #{time} #{unit == 'h' ? 'hour' : 'minute'}#{time.to_s == '1' ? '' : 's'} to #{client} - #{project} \n"
  begin
    Net::HTTP.get(URI.parse(
    "#{form_post_uri}&entry.0.single=#{client}&entry.1.single=#{project}&entry.2.single=#{minutes}&entry.3.single=#{message}&entry.4.single=#{commit}&entry.5.single=#{committer}"))
  rescue Exception => e 
    puts '*' * 50
    puts "There was an error updating the spreadsheet - #{e.message}\n"
    puts '*' * 50    
  end
end

# Fin
exit(0)

Pushing Squares - The Squarepush Blog

Released Divining Rod Library

Don't put another dime in the jukebox

Or how I stopped writing regular expresssions to parse user agents

The problem for the majority

Divining Rod - A magical stick for mobile profiling

Enter DiviningRod

Where we’re headed

Released PingTags

The economics of Mechanical Turk

The business behind the HITs

Number of tasks

Time of creation

Complexity

Price

Putting it together

2D Barcode size and experiences

What’s the solution

QR Codes are actually quite simple

Resources

Mechanical Turk in Ruby

What is Mechanical Turk

How it works – Worker side

How it works – Requester side

Let get to the code

On the request side

Getting the results

Tips and Tricks

Other Reading

Need Help?

Mechanical Turk External Page with JQuery

Get to the code already!

What’s going on here:

Jekyll Sitemaps

Time Taken - A git time tracker