Mental Safari

A catalog of failure and redmeption

Defining Complicated SVG Paths for Data Visualizations

A quick hack

The data visualization fad has been running rampant for a few years now, but I wanted to detail a small SVG (Scalable Vector Graphic) hack I found helpful for those jumping on the vector train. Many of the SVG libraries available to programmers (I’m talking about Raphael, D3, Processing, etc) contain code that looks something like this:

< svg > viewBox = "0 0 1100 400" version = "1.1"
< path id = "s3" d = "M 60 0 L 120 0 L 180 60 L 180 120 L 120 180 L 60 180 L 0 120 L 0 60"
fill = "green" stroke = "black" stroke-width = "3"/ >
< /svg >

Where the path is defined by a set of letters (M – moveto, L – lineto) and numbers: “M 60 0 L 120 0 L 180 60 L 180 120 L 120 180 L 60 180 L 0 120 L 0 60” but defining all of that path logic myself just to render an octogon seems too complex, especially when considering that a more complex shape will have more complex path logic.

Finding SVG Paths in Illustrator

This is where a small hack can set you free. If you’re already design savvy, you can simply draw your shape of choice in Illustrator, hit Save As, select SVG, and hit Save. Then in the dialog box that appears, select the button that says “Show SVG Code”, and BAM! A .txt file will open up with your path defined for you.

Finding SVG Paths via the Browser

For those without Illustrator, there’s still hope. One way is to find SVG shapes that already exisit online through services such as The Noun Project where you can download an SVG file of your choice. Then open it up in your browser, inspect the element, and BAM! Your complicated SVG path logic is nested inside.


Artificial Intelligence? That’s What She Said.

Getting in the Mood

Having lived in Seattle for the better part of 6 years before moving to NY, I like to keep up on the lastest and greatest technology being developed in the tech haven that is Washington state. While Amazon is expanding and building new campuses in Seattle, and MSFT is attempting to maintain relevancy there, the University of Washington is housing two researchers armed with grant money to program an algorithm, code name: DEviaNT (Double Entendre via Noun Transfer), that analyzes harmless text to determine if adding “That’s what she said” to the end of a given sentence makes it risque. As of now, the program has a 70% accuracy rating – which is expected to reach 99.6% in the next round of code refactoring.

Going Deep

Digging through the project overview authored by the creators, I found that they had cited a Ruby gem called “TWSS” to pre-train their algorithm. Looking a bit more into what the gem does, I discovered that it intakes data via hpricot, compares that to a txt file of predetermined “TWSS” lines and a txt file of non-“TWSS” lines (my favorite of which is: “I forgot about the baby monitor”) and then writes the input to the associated file in order for the alorithm to learn. The gem then outputs “TWSS” if the input is relevant.

The Long Hard Run

While the actual UW algorithm went above and beyond the gem’s capabilities by translating assumptions about “TWSS” sentence usage to mathematical representations of “noun sexiness” and “verb sexiness,” it was still interesting to see that Ruby was at the core of all this research. It may all seem like fun and games to the reader, but the point of the research has far reaching consequences when viewed from the perspective of an AI researcher or developer. Natural human language has many nuances and subtleties that are difficult for a computer to detect. By building smarter models and algorithms that are able to diferentiate between language usage, we can ultimately build smarter programs and machines to usher us into the future we’ve all been waiting for.*

*That future is basically robots and awesomeness in case you were wondering.


Every time I successfully launch something I wrote from the command line I like to celebrate by mentally singing along to some Weird Science: “Bits and pieces, bits and pieces. It’s my creation, is it reaaaal?” And then quickly follow up with, “Yes, yes it’s real!” before manically laughing at the birth of my creation. But tonight was slightly different – Post-song, I began thinking about the process of bringing information into existence and what that means in an age when so many of us are already suffering from information overload. Where did these bits and pieces come from?

Luckily, I’m not the first to tackle such heady questions. In fact, there’s an entire field dedicated to the study of information theory. But my favorite introduction to the subject is science and technology author, James Gleick’s book, The Information. Gleick masterfully paints a picture of the rich history of information, from the talking drums of Africa, to the written word, to the telegraph, to DNA, to quantum mechanics– all while weaving in the stories of the brilliant men and woman who pioneered the field, people such as Babbage, Lovelace, Turing, and Crick. But the star of the book is none other than my favorite autodidact, Claude Shannon.

Shannon, who is credited with founding digital computer and digital circuit design in addition to information theory, ushered in the digital revolution by figuring out how to quantify information. Information, as it turns out, is a complex notion to define, let alone quantify, and yet it’s something that we all seem to naturally create. We’re all programmers in that sense, communicating in code – from creating words, to constructing alphabets, to abstracting these foundations into electrical signals. Creating information is, arguably, what we do best. The desire to create and communicate in order to manifest meaning is, well… life.

Shannon began to notice that there were inherent patterns to the way we communicate. When these patterns, or messages, were separated from their meaning they could be translated into the language of mathematics, or what he referred to as “bits”. [Note: “bits” stands for binary digit, and is a term that was coined by John Tukey, though Shannon himself was the first ever to use it in print.] Expanding upon on this observation, Shannon hypothesized that communication must be riddled with redundancy. In order to test this theory he devised an experiment in which he showed groups of people written words that were cut off at different points and asked them to guess what letter came next. By and large, people were able to guess the correct words. From this he concluded that if you were to strip away the unnecessary bits, you could compact a message and still have it be readable – much like how we now write txt msgs. Mathematically compacting a digital message in this way allows one to transmit information at a faster (and cheaper) rate. [All those compression algorithms you use everyday– yep – based on Shannon’s work.]

While Shannon’s ideas ushered in a new wave of digital communication, not all of his contemporaries were pleased with the notion of messages without meaning. Though Shannon’s work was answering a problem of engineering, the implications of applying his work to a broader spectrum of disciplines meant sacrificing “the very quality that gives information its value and purpose.” Or as cybernetics historian, Jean-Pierre Dupey puts it, “…a paradox is at work here: ours is a world about which we pretend to have more and more information but which seems to us increasingly devoid of meaning.”

This sentiment is echoed in today’s world when we talk about how technology is making us feel “alone together”, or how we speak about “unplugging” ourselves to escape information overload. And while more information may equate to more uncertainty within us, I ultimately feel that the balance between information and meaning is one we must struggle with in order to keep up with the pace of modern life.

Design is NOT for Designers

Becoming Multilingual

One thing that has always fascinated me about programming is the ability of programmers to become multilingual with their languages. You might know Ruby, but you also know quite a bit of SQL, or JS, or HTML, or even the nuances of using GitHub. The drive to learn more in order to build and communicate more is at the heart of the programming community itself. Even the structure and layout of a particular language, like Ruby, is governed by its own design language. Why then is it so freaking hard to find a nicely designed programming presentation on Speaker Deck? Seriously, I just read 13 decks and only 3 of them were acceptably nice.

Design is a Language We All Speak

You might think that design is for designers, but the truth is: we all know good design when we see it. Good design is simple, arresting, succinct, and above all communicates a SINGLE message. The same is true for a presentation: each slide should be communicating one thing. If you can’t sum up what that picture of you racing squirrels on slide 7 is doing in one short sentence – take it out. Or better yet, write that one short sentence and use it on your slide.

Blackout the Rainbow

Quit using every color Newton gave you. If you need inspiration for color swatches try Adobe Kuler or if you hate Adobe, use Color Lovers. The same lesson for colors should be applied to fonts. If you use more than two or three fonts (one for headlines, one for body, and one for emphasis) you’re doing it wrong. If you need ideas for font pairings checkout: I Font You.


If you’re still confused about what a good presentation looks like, take a look at some of my favorites from the programming community on Speaker Deck:

  1. Let’s Talk About Ruby – Ian Bishop
  2. How to Build a GitHub – Zach Holman
  3. Ruby By Example – James Hughes

Mentally Reframing Ruby – Part 2

What the What with the Gmail

After my first experiment with Ruby and Arduino, I wanted to try writing a sketch that would build off of the code I had written from the blinking LED test. Using the blinking LED as an indicator, I thought it would be interesting to see if I could get my Ardunio talking with Gmail to alert me if I had any unread inbox messages. After doing some research, I found a Ruby gem called Gmail that allows me to do just that.

Requiring the Right Gems

Here we’re going to set up the sketch with the gems we’ll be running.

require 'bundler/setup'
require 'gmail'
require 'dino'

Board in the USA

Dino requires us to define our board, tell it that we’ll be inputing and outputing data, and tell it that we’re using a serial connection (since my Ardunio is hooked up via USB). Next, we’ll be defining our LED variable, which should be easy since it was in the previous sketch.Note: Dino also offers a good directory full of example code for setting up any given component.

Setting up dino

board =
led = 13, board: board)

You’ve Got Mail

In the next few lines of code we: call on Gmail to let us access our inbox, check if our inbox is empty, set the led variable to a resting state, and define a variable equal to the number of unread emails. Note: In the code listed below, you’d actually pass in your real email address and password.

Gmail.connect("", "password") do |gmail|
puts "Total Unread Emails: #{gmail.inbox.count(:unread)}"
has_unread = gmail.inbox.count(:unread) !=0

Ruby Slippers

Now that we have access to our inbox, we can finish up this sketch by writing an if statement to blink our led when our inbox is not at zero.

if has_unread != 0
[:on, :off].cycle do |switch|
sleep 0.5

Next Steps

I’m hoping to take this further by:

  • Writting in a delay and loop so that the sketch runs every 5-10 min
  • Adding an rgbLED so that I can light up a red LED when the inbox is full and a green LED when the inbox is empty.

Mentally Reframing Ruby – Part 1

The Beginning

Coming from a design background, I have a hard time understanding how something works or its purpose until I can see it applied to a real life situation. This is how I feel about learning Ruby. While I’m becoming more familiar with the language day by day, I still needed an example of a practical application of it in order to wrap my head around when it’s used.

In order to bring it all together, I decided to turn to an area I have a little bit of know-how in: physical computing. Ever since I was a kid, I’ve wanted to take over the world – and that dream starts by having your very own robot army. While I don’t have a large army to date, I have made a few small models with various microcontrollers, specifically with the ever popular Arduino. But, the Ardunio platform is based on a language (and environment) called Wiring, which is in turn based on C++ – quite a bit different from our pretty happy friend Ruby.

Experiment 1

So, I did a bit of research and found that someone had built a gem called dino last year for the exact purpose of running ruby sketches on your Arduino. After installing the dino gem and hooking up the Ardunio, all that was left was to write a simple sketch and watch what happend.

By writing some Ruby and following a few syntax rules dino lays out, you can get an LED blinking in no time. And while this is a little underwhelming, I’m hoping to create more interesting projects with this pairing as I begin to learn more.

Here is the result of that labor: