Get a random avatar, in a variety of sizes. An easy shell one-liner. Will print out a list of URLs.
curl -s 'http://realbusinessmen.tumblr.com/api/read?type=photo&num=50' | ruby -r'rexml/document' -e 'puts REXML::Document.new(STDIN).elements["tumblr/posts"].to_a.shuffle.pop.map(&:text)'
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:
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).
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
The code that generated this plist is available as a Gist.
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 👔.
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. ↩
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.
Here’s that same tweet in Safari, running on Mountain Lion, which has native emoji support.
Here’s that same tweet in Google Chrome, in the same operating system.
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.
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.
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. http://www.emoji-cheat-sheet.com/ 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?
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.
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):
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!
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: ↩
Here is an example of the pain that can cause (https://gist.github.com/1139435):
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.