Sometimes, when designing and/or building an application interface, it helps to have mock user data. This application provides an API over HTTP to request mock or placeholder user data including:

  • User Names
  • User IDs (as MD5 Digests)
  • User Avatars
  • User Meta-Data

Along the same lines of, this is a service that provides API’s to request semi-random stubbed out user data.

The gag is that all of that user data comes from a very funny Key & Peele sketch.

Ozamataz Buckshank Enjoy.

Previously, I wrote a simple script to generate random avatars for the discerning businessperson.

Due to popular demand, I’ve now launched a web service that will allow you to request a random avatar suitable for the most demanding enterprise needs.

Point your browser to 1

The service provides an endpoint: /avatar that you can hit to get a random avatar at any specified size.

A picture of me

This is a great drop in replacement for Gravatar. We’re really disrupting the avatar space.

The avatars are provided by the amazing Real Businessmen Tumblr. Now let’s all get back to work on the internet.

  1. Perfect use case for the .biz tld. 

Blogging has mutated into simpler forms (specifically, link- and mob- and aud- and vid- variant), but I don’t think I’ve seen a blog like Chris Neukirchen’s Anarchaia, which fudges together a bunch of disparate forms of citation (links, quotes, flickrings) into a very long and narrow and distracted tumblelog. A good idea and I’m sure more of these will be showing up. Maybe you know of others?

Reminder that the format was reified by Ruby programmers.

You can still run Hobix.

The basic points behind Hobix are:

  • Your blahhg or websyht is made up of some thing.
  • That some thing might be news entries, pix, keynote addresses, spreadsheets.
  • The first page of your blahhg shows the latest some thing.
  • Any some thing can be simplified for the first page.
  • Beyond that, each some thing gets it own page.

In light of some of the recent headlines surrounding a Tumblr acquisition, I’ve just hastily written and released an update to tumblr-rb — my command line utility and library for the Tumblr API.

I’ve added a new command in this version: tumblr backup

This will download and write all of your tumblr posts, serialized into a simple plain text format, into a directory you list, or your current working directory.

Downloaded the new version with homebrew1 or rubygems, run tumblr authorize to authenticate, and then back up all of your posts in one easy command. You’ll want to give it your tumblr hostname or else you’ll be asked for it repeatedly:

$ tumblr backup ~/tumblr_backup

Open an issue on GitHub if you encounter any problems.

This script doesn’t download the associated media with your posts, just the posts themselves, in a format suitable for both humans and machines to read.

Rumoji 0.2.0 and Emoji in OS X

In the thesis that became Rumoji I made the assertion that application developers needed to be aware of emoji user input, and handle that by transcoding the Unicode codepoints that comprise emoji into their cheat sheet code counterparts and using that in some sort of html-pipeline to handle user input. By doing this, they can ensure that an end-user can see something meaningful no matter if their platform is equipped to handle these glyphs.

I’m retreating a bit from some of those assertions, specifically this one:

Do not store emoji unicodes in your database.

I’m backing away from this statement, because I think this next version of Rumoji will help you, the developer, get a much stronger grip on emoji.

Rumoji 0.2.0 has been released, and now supports the full emoji set.

Along with the new version, you also get a small bin/rumoji that is 1 line of code:

Rumoji.decode_io(STDIN, STDOUT)

This is a POC from the original Rumoji README. It allows you to do this1:

$ echo "But Rumoji makes encoding issues a :joy:" | rumoji
#=> But Rumoji makes encoding issues a 😂

You can easily use the emoji cheat sheet in your terminal to produce emoji (since they don’t make emoji keyboards… yet).

With osxsub

If you’re using osxsub to manage your OS X Text Substitutions, you’re in luck. You can now load the full emoji cheat sheet into your Text Substitution Preferences!

Download this emoji plist and run:

$ osxsub --merge path/to/emoji.plist

You’ll have access to emoji anywhere you use OS X text replacement or osxsub!

The code that generated this plist is available as a Gist.

Download Rumoji v0.2.0

Rumoji only works on Ruby 1.9.

Eventually, I see Rumoji becoming a robust drop-in replacement for Gemoji. I’ve got a lot planned for it.

Emoji is serious business 👔.

  1. A friendly reminder that if you’re not seeing certain glyphs in your browser, it’s because you’re on a platform/browser that’s not equipped to deal with emoji input. I’m working on fixing that for you. 

We need to talk about Emoji

Emoji is great, but it’s a big problem on the web.

I use emoji to, like, express myself, or whatever. I use it in tweets. Here’s a screenshot of a tweet, with emoji, running in an iOS simulator. iOS has native emoji support.

emoji in a tweet in an iOS simulator

Here’s that same tweet in Safari, running on Mountain Lion, which has native emoji support.

emoji in a tweet in Safari on Mountain Lion

Here’s that same tweet in Google Chrome, in the same operating system.

the lack of emoji in a tweet in Google Chrome on Mountain Lion

Oh no! Where’s the emoji? 😰1

Emoji is a wonderful method of expression. In this post, I’m going to propose a solution so that emoji can be displayed universally on the web. But it’s going to be a bit of work for the web application developer.

First, some background.

Emoji has been a hard target to support, because it has historically occupied a private use area of Unicode. And, depending on the implementor, be it Apple or DoCoMo or whoever else is really into to the emoji game, the ranges are always different. But now, Apple and Google have come together to formalize Emoji Symbols (warning: this is a very big page). If you look at the Character Viewer in Mountain Lion, you’ll see that the proposed emoji spec is totally implemented. What this means is that we can target specific unicode characters for being emoji.

Meanwhile, on the web…

GitHub introduced emoji pngs throughout their application, and pull requests are much better for it. Campfire supports emoji, and your professional interactions are much better for it. Both GitHub, Campfire, and others support a simple set of codes to inject these pngs into an html page. In fact, those codes have become a bit of a standard on their own. has emerged to guide users and has almost formalized how these codes should work.

It’s somewhat trivial to implement these friendly codes and images on a web app that does any kind of text formatting (and all web apps should be at the very least sanitizing input). But what if my system supports emoji natively?

A Modest Proposal

I propose that on systems that natively support emoji, instead of showing the user an image, we show them the correct emoji character. On systems that natively support emoji, when the user inputs an emoji character (i.e. from their iPhone keyboard), the web application should recognize that unicode character, and replace it with the friendly cheat-sheet code.

Do not store emoji unicodes in your database. Store the human-friendly code and support the emoji-cheat-sheet.

By doing this, you can ensure that users across devices can see the author’s intention. You can always show users an image, but you can’t show them a range of characters their system does not support.

A solution in Ruby

I’m not going to stand on an ivory tower 🗻 and propose something without offering some kind of solution.

I made a Ruby gem to transcode emoji utf-8 into their cheat-sheet counterparts! Check out Rumoji.

gem install rumoji

Here’s a screenshot in action (for the emoji-disabled):

What's happening here is, we're piping some emoji in one end, and in the other end we're getting :joy:

Note: Rumoji only works in Ruby 1.9 and has only been tested on ruby v1.9.3. Currently, Rumoji is aware of the People range of characters in the emoji-cheat-sheet.

Use this in conjunction with a tool like gemoji to support transforming raw emoji input into images that everyone can enjoy.

Now go forth, web application developers. Let’s bring the beauty of emoji to everyone, regardless of their device!

  1. If you’re following along, there’s actually an emoji right now. Depending on your system, you might not be able to see it. It’s face with open mouth and cold sweat: cold sweat

3 years ago, according to GitHub, I began my first substantial project written in the Ruby programming language: Weary. Weary is the thing driving tumblr-rb, and what allowed me to write it so quickly. Weary was the solution to a desire of mine to be able to quickly bootstrap and describe client libraries to RESTful web service API’s.

In the Spring of 2010, I announced my intention to rewrite it. Better late than never?

Today, Weary’s master branch reflects a complete rewrite from the ground up. As I prepare for the first release candidate of Weary 1.0, I want to take this time to document some intentions and invite your contributions and suggestions.

Consider the following Ruby code:

class GitHubClient < Weary::Client
  domain ""

  get :list, "/user/repos" do |r|

  post :create "/user/repos" do |r|

  get :user, "/users/{user}/repos"

  get :repo, "/repos/{user}/{repo}"

  patch :edit, "/repos/{user}/{repo}" do |r|

This is a pretty good sample of the Weary framework and DSL. This builds a client to a subset of the GitHub v3 api. Moving further with the class:

client =
client.list :username => "mwunsch", :password => "my-secret-password"
# -> returns a Weary::Request object

Every request has a #perform method that is asynchronous, and only blocks when accessed (it returns a future). You can pass a callback:

client.list(:username => "mwunsch", :password => "my-secret-password").perform do |response|
  puts response.body if response.success?

A new feature is the ability to have dynamic URL’s (using Addressable::Template):

client.user :user => "mwunsch"

But one of the things that makes this new version of Weary very powerful is that Rack is integrated deeply throughout the library. Every class that inherits from Weary::Client is a valid Rack application1. Which means you can do something like this:

# in a file called
run GitHubClient


curl "http://localhost:9292/repos/mwunsch/weary"

This means it’s really trivial to build specialized proxies to web service API’s and mount them anywhere you’d like (say, inside your Rails application).

Weary allows you to quickly build clients that take advantage of the full spectrum of the Rack ecosystem.

There’s a few more tasks to work on before getting a release candidate out, but as soon as that happens I’ll begin the work of migrating the Tumblr gem to use it.

There’s a lot more to this new version of Weary than I outlined here, so I invite you to dig into the code, fork it, and build some great things.

  1. For those newer to Ruby, Rack provides a standard interface for a web server to communicate with a Ruby application. 

A follow up on “Installing Gems”

Commentators in Hacker News said that sudo gem install was the correct way to install gems as I described in my previous post.

Here is an example of the pain that can cause (

I sudo install ronn and it is located in /usr/bin. The detailed man pages are not found. I use rvm to switch from system Ruby to Ruby 1.9.2. ronn borks. The error that is thrown is not useful.

When I install a command line tool, I really should not care what language it is written in, much less what version of the interpreter it is running on. I know next to nothing about Perl but ack appears to work just fine on my machine.

Installing tools that happen to be written in Ruby that happen to have complex dependencies happens to be a pain. I’d like to see a better path emerge.