Elliott is interested in providing the connective glue necessary within every team. His wide areas of interest imply that he can “speak the language” of many and varied technical fields. He'll be useful anywhere there are new things to be created. :)
Click the ↓ to begin!
I’m familiar with quite a lot of tools, programming languages, systems, and frameworks. To be honest, I’m a little obsessive about learning new things; so I’ve done my best to keep this section as short and relevant as possible. That is, however, a lofty goal, given how much I know… so please, keep an open mind! ;)
(Use the focus bar below to reduce the deluge of content.)
When all is said and done, I’m primarily a developer: I love to create things, write tools and applications that change how people interact with their computers and each‐other; if it ticks, I want to know why, and then make it tick better.
I’ve written hundreds of distinct libraries in more languages than I can count. I tend to abstract everything into portable libraries; it enables code reuse (upon which I heavily depend for my productivity.)
I’ve been in on the node.js party since the very beginning. The moment I started digging into it, I knew it, and things like it, was the future of web development. Asynchronicity is where it’s at! :D
Redis is another technology that quickly caught my eye. I expect to find many wonderful uses for this tool in quite a diverse array of projects; I find it plays especially well with Node.js.
I’ve been using OS X and Apple’s hardware for half a decade, and I’ve always had a hacker’s spirit. There’s really not a lot that I don’t know about them, anymore.
While I’m an OS X devotee, a properly tuned and maintained Linux system can easily be just as beautiful. I love to create and maintain such systems.
Cloud computing (all silly buzz aside) really is the future; and Amazon was, essentially, there first (at least, on that sort of large scale.) I’ve been using them since 2007, and tend to work ephemeral cloud‐based instances into aspects of many of my tasks and projects.
While I may be a programmer, I still have quite a taste for clean, minimalist design. There’s a reason I use Apple’s computers and software, despite my comprehensive knowledge of more ‘true’ UNIX systems. My design skills will bring a touch of elegance to your development project that may otherwise be lacking; a feel for putting the user’s experience first… whether that ‘user’ be a visitor to your website, or a developer applying your APIs to some task.
Yes, I realize that ‘XHTML5’ is simply HTML5 serialized as XML. I feel that the distinction is, however, fairly important. I believe nesting SVG and XHTML offers some of the most interesting design solutions we’ve seen in the last decade.
I love beautiful type. I find it extremely gratifying to see a page that one’s eyes can just… drink in; a page begging to be absorbed. Honestly put, I believe typography to be the single most important element of any design; after all, ‘content is king,’ right?
I create things. I create a lot of things. I produce tons of designs, and I write an unbelievably large quantity of code. I recently rang it up: approximately as of this writing, among the 23 most laterally‐active of my ~100 repositories, I had nearly 100,000 lines of impact, across around 2,000 commits.
Seriously. That’s a lot of code.
In addition to that, I don’t write a lot of code I dislike: I’m an extreme perfectionist, possibly even OCD in my devotion to creating beautiful code; thus, I found it very difficult to select a reasonably small selection of examples of my work. I strongly encourage you to peruse the rest of my public GitHub repositories, if only because I’m extremely proud of most of the things presented there.
That having been said… the following are a few of my most interesting or impressive creations; I anticipate them providing you with a clear overview of my style, abilities, and tastes, as they pertain to programming and design.
My latest and most ambitions open‐source project to date, Paws, is a new sort of programming language, designed from the ground up with an eye for heavily distributed codebases oriented towards the web. It’s massively concurrent, and extremely friendly towards asynchronicity; heavily inspired by JavaScript/node.js in spirit, as well as Ruby and Io in style.
This particular project has broadened my ANSI C horizons farther than I ever expected to take them. As some mad hybrid between a designer and a developer, I wouldn’t have predicted myself delving this deep into “The Stack;” however, it’s been a fortunate turn of events, as I’ve discovered a deep love for C itself, as well as designing and developing low‐level systems’ architecture.
Paws.c — /Source/Paws.c/Paws.c
As usual, I’m heavy on the conceptual documentation; I love to explain *why* I’ve structured some part of the code the way I did, in hopes that some reader will learn something useful from the sweat and love I poured into creating that structure.
Paws.c — /Source/Paws.c/Types/list/list.c
This is the declaration of one of Paws’ most basic datatypes, infrastructure list.
This particular snippet demonstrates my fairly unique style of C, revolving around
structs of function pointers to namespace “methods” relating to a specific datatype,
and pointers to structs as the datatypes themselves. This also happens to exhibit my
proclivity towards abusing C’s preprocessor to modify the code.
Paws.c — /Source/Paws.c/Types/Types.h
Another very unique element of my approach to large C projects; this is Paws’ thing
struct. It’s, essentially, an annotated pointer type, created to allow me to pass
around pointers to any of Paws’ core datatypes, without caring which datatype
we’re passing around. This is exactly the sort of system I absolutely love to engineer.
Paws.c — /Source/Paws.c/Ancillary/Magazine/Magazine.c
Some more meaty implementation source‐code, to counterbalance the declarations exhibited above. This is one of the most inherently gnarly pieces of code in the Paws codebase as of this writing; as such, I put quite a bit of work into making the implementation as absolutely clear as possible to offset the inherent complexity of that system.
Paws.c — /Source/Paws.c/Ancillary/Threading/Pool/Pool.c and /Source/Paws.c/Ancillary/Threading/Thread/Thread.c
These files reveal my tendency to massively re‐wrap any library which has an API I dislike; here, I
created a completely unique internal threading API (implemented as Pool and
Thread) to abstract away the (as I consider it, anyway) absolutely terrible
pthread.h API.
Paws.js — /Packages/Paws.js/Things/list.js
The first example from the Paws.js codebase; this codebase is slowly starting to age,
as I’ve been focusing quite intensively on abstract Paws design and the Paws.c
implementation; however, there’s still plenty of good code in here. This snippet applies closures
and prototypal inheritance to positive effect, wrapping some data unique to a specific descendant
of the prototype object. It evidences my tendency to prefer to play to a language’s strengths,
rather than simply fall back to what I know: in this case, JavaScript’s prototypal inheritance
system is quite beautiful, and I use that to my advantage instead of relying upon a classist
abstraction.
Paws.js — /Packages/Paws.js/Things/list.js
Another snippet exhibiting copious description of the reasoning behind an implementation prior to the implementation itself.
Another one of my very ambitious and interesting projects; I found that none of the testing or code specification systems out there really facilitated the way I liked to develop. Specifically, they required too much additional documentation of the operation of your code, when I felt that the code should be documenting itself. This implementation was for Ruby, and involved a trio (or a quartet, depending on how you look at it) of separate projects.
This project really exhibits my taste for modularization; the core system itself was spread across only two individual classes and files; all extraneous functionality was added to other libraries that extended the core library.
/lib/speck/check.rb
The majority of the meat of Speck’s implementation fits into these ~10 LoC. This piece of code is quite exemplar of my programming style within Ruby; short, succinct. Nothing beyond what is necessary.
/specifications/speck/check_specs.rb
A testament to its flexibility, I tested and specified Speck entirely, utilizing only the tools provided within Speck itself.
/lib/slack/mixins/object.rbOne of my smallest and most interesting projects; this was the first thing I actually made with node.js; it’s a simple and uniquely semantic short‐URL service for Twitter statuses.
/server.js
The entire server / application is only ~75 LoC; it ties into a Redis database to store and retrieve tweet IDs and their respective owners. It then 301‐redirects that URL to the relevant tweet on http://twitter.com/.
I created this pair of projects to allow me to intricately introspect JavaScript objects from node.js at the command‐line. Yarn provides an extremely robust styled‐string printer that utilizes ANSI escape codes to style output on the command line, while Percival is responsible for actually introspecting JavaScript objects and datatypes, and turning them into Yarns for display.
/lib/Yarn.js
A very quintessential piece of my JavaScript; almost all of my libraries follow this basic form. I rely on the prototypal nature of JavaScript to do my work for me, and focus on implementing the aspects of my interfaces that I want to expose to the library’s user.
/lib/Percival.js
This is the core of Percival’s functionality; it allows me to extend Percival with custom ‘lenses’ for any imaginable custom JavaScript object. I also bundle in ‘lenses’ for each of JavaScript’s core datatypes. Yet again, presenting evidence to support my obsession with abstraction.
A huge array of shell scripts, that work together with the Amazon EC2 APIs to remotely construct and package up “AMIs” (Amazon Machine Images), built using my favourite ultra‐elegant and clean Linux distribution: Arch Linux.
/bundle.sh
This is a single massive shell script that manages the host systems (instances) utilized during the construction process. Other shell scripts from the project are executed by this script, remotely, on those hosts, to preform the actual system construction and bundling. Far from the prettiest code I’ve ever written, but what do you expect out of a shell script this monolithic and complex? :]
EnvironmentedProc and LobbyThese are some of the oddest, most tricky, and interesting Ruby code I’ve ever written; I feel it’s fairly important to include them here, as they expose my taste for curious and unusual hackery.
environmented_proc.rb
This is quite possibly the single most useful, yet small, pieces of Ruby code I’ve ever written. As with several of the above examples, the trickiness of the code is directly proportional to the quantity of documentation / explanation I provide; in this case, well over half of the document is explanatory material.
lobby.rbWhile these aren’t exactly capable of fitting into either of the above categories, I feel they are relevant enough to merit inclusion. They give you an idea of who I am, which is critical to understanding whether or not I’m a match for your team.