Sunday, August 28, 2016

Solving Phone Number with Elixir and a lexer

With Elixir Conf less than a week away, it's time to prepare! And James Gray's email about his Elixir training couldn't be any more timely, especially the part about being comfortable solving problems on First, let me say that I had not heard of this site prior and wow is it fantastic and a great way to jump into a new language!

After solving the Hello World exercism I moved on to Phone Number. Phone Number is fairly simple, or so I thought. The basic idea is to take a string and parse out the phone number. If the input is invalid, return zeroes. Since Exercism defines all the tests, not only was I able to TDD the solution, but it was very clear what was expected.

My first cut explored using binary pattern matching to extract the number. That got me so far, but I had trouble handling the error conditions and non digit characters. So I looked into using regular expressions. In particular, could I use a regex to pattern match method arguments. Turns out, no you can't. However on my quest I ran across a great post on using regex's in Elixir and using them to route behavior. This post became the basis for my second approach. The idea was to transform each character of the input into a tuple that identified what it was based on a regular expression.

However, when I reached the test for treating input that included letters as invalid, I was stuck.

My solution was not setup to handle it and I wanted a way to exit early if the data was identified as bad. So I looked around for more ideas and found myself rereading the first post I found about regular expressions, except this time I read the whole thread, including the part about lexers.

Yes, compiling the regexps with a tool like leex[*] will generally produce a much faster program for doing this type of thing because:
It will only make one pass over the string you are testing irrespective of how many regexps you are testing it against. The other alternatives here will test your string against each possible regexp one at a time, this irrespective of whether they are hard-wired in a cond or defined in some nicer way.
That the leex version can do this partially depends on the regexps it allows are more restricted, amongst other things they never need backtracking which Perl and PCRE regexps may need.
For this type of usage we don't have to actually generate a "token" as such just some tag indicating what we found.
It is honestly quite easy to write a tool which generates an input file for leex from a set of regexps and return values. It is compile time but it is not that difficult to fix it so you could handle changing the regexp set dynamically and recompile your "scanner", though you wouldn't want to do it too often.[**]
[*] Leex is based on the same principles as other scanner generating tools like lex and flex. Where did we get the name from? It leaks tokens. :slight_smile:
[**] There are programs which handle configuration data in this way, they dynamically compile a new config module containing the config data instead of keeping it in a database. Quite cool actually.
So I did my homework on lexers and leex  (helpful, and also helpful) and wrote my own lexer grammar to tokenize the raw input.

My goal was to identify characters the problem said were valid. This is important, because I initially identified characters that were invalid also. Not only was writing the regex to define illegal characters ugly, but more importantly if a lexer fails it returns a beautiful { :error } message so now I could route to an overloaded method that knew how to handle { :error } and another one that knew how to handle { :ok } messages. This was pivotal in cleaning up my solution. Not only did I now have all of my digits being tagged as :int and return, but I also immediately knew if invalid input was being passed in.

All that remained was inspecting the length and doing a little formatting:

Looking back I believe I could also handle the length in the lexer definition as well, but I'll save that for another day. For now I'm going to find another problem on to solve!!

Sunday, October 25, 2015

Would you pair program with Stan Lee?

Ever wonder what it would be like if Stan Lee joined your engineering team? Well, I do.

Back in 1978, Stan Lee and John Buscema (both comic legends) wrote a book about "How to Draw Comics the Marvel Way" where they emphasize simpler is better. Sound familiar?

So what is simpler? What is better? Stan Lee says, "A work of art must have a magical ingredient of correct composition." He continues, artists must "compose something that is both pleasing to the eye and gets the message across clearly and interestingly." We've all seen and can identify code that is unpleasing to the eye. And I'm sure most of us can also identify code that clearly states it's intent. So far Stan Lee is preaching to the choir.

How does the man, the myth, the legend suggest we accomplish composing something that is both pleasing and gets it's message across? He says there is one main rule, "the simpler, the better." I agree, simpler is better. But how do we know it's simple?

In the book, Stan and John describe how important elements are grouped together to form prime shapes. These prime shapes should give viewers the best possible shot of the action. They also group together important elements and make it easy for the viewer to understand what is happening. Artists should also never squeeze elements into a prime shape and should remove important areas that fall outside of the prime area. Sounds to me like Stan and John are suggesting good object composition.

Stan Lee states that artists "sense" good composition and sketch in prime shapes before drawing the detail. Much like an engineer would use BDD to specify the outermost behavior and then work their way in. Good panel composition as well as good object composition leads the reader's eye and conveys an interesting message.

And sometimes after shapes are identified and the picture is drawn, too many important elements fall outside the basic shaded area and  the panel needs to be redrawn. I believe us engineers call that refactoring :)

But what if my objects don't have a simpler form or fit into nice prime shapes? Then change the camera angle!  For example, here we have Jonah Jameson yelling at Peter Parker on the phone.

Sure it shows what is happening, but look at how much better the second drawing delivers the message. It's extremely clear what is happening and all that changed was the camera angle.

But there are no cameras in code you say. You are correct, but there are different ways to look at solving a problem. Sometimes it requires deleting code, walking away, and revisiting the problem, but there is always another way. It takes practice, creativity, and a good pair always helps. Even explaining the problem to somebody else can help you see and understand a new way of approaching the problem.

To emphasize the point further, which figure more clearly demonstrates what is happening? A or B?
While A does show the viewer our hero is blasting a foe with a laser blast from his eyes, B does the same thing much more clearly and interestingly. Everything in B demonstrates intense action. There are elements in A that suggest that maybe certain components aren't needed. A also makes our hero look weak and somewhat unsure. When it comes to stating intent clearly I tend to refer back to three things, Avdi Grimm's Confident Ruby, Object Thinking by David West, and Tell Don't Ask. Each of them reinforce the importance of your objects communicating clearly what they do, just like B demonstrates that our hero's entire body is involved in emanating a laser blast from his eyes with confidence!

While Stan Lee may not have experience writing code, he sure has a firm grasp on telling a good story in a way that is clear and interesting to the reader. So yes, I'd love to sit down and craft amazing adventures in code with Stan Lee! As software craftsman, isn't that what we do everyday? We craft code. Code that tells a story. And while the story arc may vary, they are all still stories. Let's all put a little more amazing into our stories the MARVEL way!

Wednesday, February 18, 2015

Coach taught, player learned

Earlier today there was an email exchange amongst the Enginerds at Usertesting about pairing on deploys. Part of the exchange reminded of an article I had recently read by John Kessel. John Kessel is the Director of Beach Volleyball, Education and Grassroots Programs as well as one of the most sought after lecturers by coaches world wide. He is also somebody who has a direct positive impact on my own coaching philosophy. (For those who aren't aware, I coach High School and 12U Boys Volleyball and have found it highly relevant to what I do day to day on a software engineering team as a Team Lead)

So this article, "Coach taught, or player learned" (link below), highlights 5 things John has learned about learning:
  1. Athletes learn when they are SELF-motivated; intrinsic learning and guided discovery are vastly superior for retention/learning.
  2. The reward of athletes is achieving the goal, so take advantage of that in your teaching process.
  3. Deliberate practice, aka focused on what THEY are interested in, maximizes the learning process.
  4. Coopetition, cooperation and competition, makes for the best learning by athletes. We learn best, and the most, when we collaborate with others.
  5. That which you teach, you learn. The more athletes have to explain something to others, the better they get it.
It was thing #5 that I related to the earlier email exchange, "That which you teach, you learn. The more athletes have to explain something to others, the better they get it." I think the "explain something to others" is and should be an important part of our teams culture. It's why when Suan Yeo suggests pairing with somebody familiar with code to pair on deploys, I think "Maybe not. Maybe they should pair with somebody who doesn't know the code on deploys".

Sometimes as developers we make assumptions  (we are only human :) ) . And often times those assumptions are incorrect. It's through explaining something to somebody else that we realize fallacies in our reasoning. And through that explanation we learn and grow as a team.

With that said, I would encourage everyone to take the time to explain the Why, the How, the What to somebody else unfamiliar to not only learn yourself, but to also teach others.

I highly recommend reading this article when you have 10-15 minutes and are looking to further your understanding of learning:

Special thanks to Paul Hepworth for asking me to explain my understanding to him, thus ironing out assumptions I had made about our environments and leading to further learning.

Friday, October 24, 2014

How to make a Haunted Basement without using real ghosts

This story starts 3 years ago when I designed a haunted house for my kids in our basement for their birthday party. At the time they were turning 6 so I kept it light and it was a lot of fun. Ever since then they've asked me to build them a new one for their birthday. This year I obliged and here is what and how I did it. Enjoy!

Location, location, location

My basement is unfinished and the kids play everything from Nerf War to Baseball in the basement. So for the Haunted House I wanted to create a place they didn't even recognize. That means building walls and disorienting the kids. I want them to be so in awe of their surroundings that they forget they are in their own house. This of course is going to result in bigger, yet fun, scares .... or so I hope! (They still haven't seen it yet!)

I started by creating a "floor plan" by laying out some 2x4s in places I wanted to create temporary walls. Temporary meaning I could take them down at some point, but strong enough to stand up and not be knocked over. I also figure that once halloween is over, we can remove the decorations and they can use the walls for a nerf war zone!

My original designs included hanging chains and a well for a monster to hide in. Those ideas transformed into other things, but still were important to helping form my ideas. Not only that, but I have some great ideas for next year!!

The Tree!

The spooky tree was by far one of the ideas I found most inspiring, but I was concerned it might consume too much time. In the end, it really didn't and was fairly simple to create.

Thanks to Croglinvampire for sharing his technique and process on how to create one of these trees! I'm not going to reiterate what he has already explained, but I will mention a few "aha" moments I had while creating the tree.

I bought the cheap foam from Walmart, don't! Go to Lowes and get the 'Great Stuff' expanding foam. It's the same price as the Walmart stuff and works way better! The Walmart foam didn't setup right and was difficult to spray.

Leave the saran wrap on until the foam dries completely. It will pull right off. And what doesn't you can use a lighter to burn off.

Getting an awesome mask is crucial in my opinion to making the whole tree look really great! I searched for masks made for people but didn't find anything I liked. I found much better solutions when I started searching for "tree sculptures". Here is the mask I ordered:


The Ghost!

I saw some amazing ghosts on a blog and just had to give them a try. I did some googling and found how to make a cast of a person using packing tape. You basically wrap a person in packing tape with the sticky side out and then wrap them in more tape sticky side down. And voila!

I tried saran wrap under the packing tape which helped cut the person out of the tape cast, but it was annoying when putting lights inside the cast.

Do the bottom and lower halfs separate and tape them together afterwards.

These are the lights I used inside the cast:

Have your volunteer go pee before you start taping!

Spooky Candles

This was a fun project! Basically just cut up PVC, add hot glue, and paint/stain them! They look great! There is a great tutorial on how to make these. Thanks Xipotec!

You will use a lot of glue sticks! About 3-4 per candle!

These are the tea light candles I used:

The Fireplace

I saw a picture of a fireplace while looking for inspiration. I decided a great way to enter the haunted house would be through a secret passage in the back of a fireplace! The fireplace was a refactoring of a rocket ship I had made for the boys when they were much younger. I just added some textured spray paint to it and cut it in half.
I followed this tutorial to make glowing coals kids would have to climb over and a cheap backdrop for behind the mantle. The fireplace actually leads to a caged in tunnel!

Zombie Danger!

No Haunted House is complete without Zombies! So i mounted some skids, added a few fence boards, attached some body parts from the dollar store and added some red light for dramatic effect.

I did add some gray spray paint to the hands to "dirty" them up a bit and make them look more realistic.


The Spider Cave!

I was originally going to create a creepy room with a well, but it has turned into a room full of spiders and hanging skulls!! I created the effects with black lights, skulls from the dollar store, and lots of fake spiders and spider web.

Not done just yet!!

There are a few more surprises in the works! Including a caged monster and draculas's chambers! I'll post more pictures as the Haunted House is completed!

Happy Halloween!

Thursday, May 8, 2014

Versioning your API

Who has not written or used an API? If you answered no, then this article is not for you and honestly I question how you ended up here. APIs are all the rage these days and everyone has an opinion on what an API should look like. Even more controversial is how do you version your API.

It depends on what you believe.

1. Do you believe in Roy Fielding's REST architecture?
2. Do you believe that accept headers describe how you'd like the resource returned?

If you subscribe to REST (and not Rails version of REST), then you acknowledge that the URL is a permalink to a resource. A location where that resource can always be found. Specifying a version number in that URL suggests that each version is an entirely different resource, not the the same resource presented differently.

And just as the semantics of HTTP verbs make sense, so the semantics of HTTP headers. In the request header I am describing how I want my resource returned. Do I want it returned as XML, JSON, HTML or even a PDF. In addition, maybe I want version 1 of that resource as JSON. This can all be done using the Accept and Version headers of an HTTP request.

(There some arguments for including the version number in your hypermedia type as well. I have not fully subscribed to that approach, but it does make some sense.)

For those of you who have not fully subscribed to RESTful APIs and HATEOAS, I highly recommend taking the time to read through the sites linked below and consider unlearning the older ways of implementing APIs and consider learning why adhering to HATEOAS is important and beneficial.

And honestly, if you didn't believe in separation of concerns, why do you adhere to MVC?

Path to enlightenment

HATEOAS 101 - Brian Mulloy put together a great video presentation of what is HATEOAS
Why build hypermedia APIs - Great review of the why and how of hypermedia in respect to Rails.
Haters gonna HATEOAS - Steve Klabnik explaining the HATEOAS
REST APIs must be hypertext-driven - Fielding himself highlighting what makes up a REST API

For those working in Ruby

Grape - Gem, DSL for describing your API
Roar - Gem, presentation DSL for your resources
Swagger - Document your API
Postman - Chrome extension for testing your API

Wednesday, April 2, 2014

Note to self: Machine Setup

Every few years us developers find the need to recreate their precious development environment on new hardware. It's an exciting time, because "Hey, new hardware!" However we always find ourselves copying bits and pieces from the old hardware while trying to reconstruct our development environments. Some of us take good notes, I myself have been slacking. I had some notes, but not all. So I took this opportunity to make a note to self so that next time I can cruise through this process much faster.

Let's get started!

Package Manager

Previously I have always rolled with MacPorts. I'm finally caving. Install Homebrew
ruby -e "$(curl -fsSL"


You can't build a whole lot without it
brew install apple-gcc42
sudo ln -s /usr/local/bin/gcc-4.2 /usr/bin/gcc-4.2
sudo xcodebuild -license

RbEnv or RVM

I recently switched to RbEnv from RVM and am sticking with it.
brew install rbenv ruby-build
rbenv init
With RbEnv you need to install a shim to make life easier when referencing ruby:

echo 'if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi' >> ~/.bash_profile
echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
Install Ruby!
rbenv install 2.1.1

Version Control

Visit Git and download the DMG installer. Then generate your RSA key and attach it to your Github account.

ssh-keygen -t rsa -C ""

Don't forget to make branch creation and deletion much easier and follow this great tutorial from Scott Bradley.

Also don't forget to configure your .gitconfig. Mine is saved in a repo on Github with my bash_profile and bashrc.

Rack server

Use pow, thank me later.
curl | sh
Don't forget to install the powder gem for ease of use.

Editor of choice

I choose you Emacs! And let's setup and use Cask with Pallet to manage packages.
Download and install the dmg from

Install Cask (curl worked better than homebrew IMO)
curl -fsSkL | python

Download my .emacs.d repo into ~/.emacs.d to configure all the awesome packages and Cask. The setup is loosely based on this post.

Run Cask within the .emacs.d folder to install all of the packages listed in the Caskfile

Bash prompt

I like my prompt to tell me a little bit about the directory I'm in. Especially if it's a Git repo. Follow this easy tutorial to setup a clean prompt that renders VCS info.

And for even more cool bashness, install autojump! I highly recommend cloning the repo and installing it manually.

And install iTerm2

Within my .bashrc I've setup some aliases for running Emacs locally as a server so I can work entirely within iTerm while developing. I prefer alternating tabs in iTerm vs alternating between GUI Emacs and the terminal.

See you again in 1-2 years!

Monday, January 6, 2014

Carrying on great conversations #hashu

Some of the best conversations are usually unplanned and they tend to happen when I surround myself with smart people that I've just met. This usually occurs at a conference or meetups over beverages and/or grub. However I'm terrible at remembering names.

That's where Hashu comes in. One day while pairing with Andre Ortiz he mentioned an approach he took to starting conversations and recalling them at SXSW. He had written a web app that leveraged Twitter and the power of the #hashtag to keep a record of people he met at SXSW. It was a great idea! So we teamed up and put together Hashu!

The Nickel Tour

To use Hashu all you need is a Twitter account and a Twitter client, that's it! Then just follow these 3 quick steps:

1. Use your phone, iPad, laptop, etc etc to open in a browser and follow the prompts to authenticate with Twitter.

2. Send a tweet and mention somebody you found interesting and tag the tweet with #hashu

3. Return to at a later time to view all your tweets tagged with #hashu

3a. Aside from showing you your tweets in a cool tiled format with images and Google maps, it will also show you the profiles of all of the people you have mentioned.

The Technical

Hashu is a Rails 4 app, using Ruby 2 and Mongo. My original intent was to demonstrate modeling for NoSQL and Riak, but given budgetary constraints and that I was using Heroku's free tier for hosting I switched from Riak to Mongo. However I chose to model as I would for Riak and used Braintree's Curator gem so at a later date and time we could easily switch back from Mongo to Riak.

The code is public and can be found on Github. Please don't go stealing our ideas! We're so cool we opened up our code so you could have a peak under the hood :)

The Extra Credit

I'll be attending CodeMash this week and plan on using Hashu throughout the week. Don't be surprised if I #HashU! If you'd like to chat about Hashu, Riak, pair or have a beer at CodeMash just send me a tweet (@msnyder) or look for the guy who looks like me. And for those attending CodeMash, you can also access Hashu at

The Leftovers

This is the first production iteration of this application and Andre and I are working to improve it. We'd like to add in some cool per conference branding, better parsing of tweets, and some other coolness. If you're interested in helping out or have some feedback for us, send us a tweet or leave a comment on the CranialPulse blog.
Enjoy using Hashu!