When done well, metaprogramming enables a very high-level, expressive style of coding. Some of the real gems of the Ruby ecosystem - like activerecord and rspec - lean heavily (and mostly successfully) on metaprogramming. It’s a powerful technique, but easily misused. Here’s what I’ve learned about metaprogramming so far - both the how-tos and and when-not-tos.

TracePoint is a uniquely powerful sledgehammer for introspecting Ruby programs. In this post, we’ll take a look at what tracing can do by sketching a couple utilities.

Nods to Foxy Shazam for the title and development soundtrack

This morning, I realized I was tired of typing docker-machine ip $FOO. So I wrote a thing to route requests to http://$NAME.dock:$PORT on to the docker-machine running at docker-machine ip $NAME.

Sitting here atop my pile of yak hair, I’d like to a take a minute to reflect on what I built and - more importantly - what I learned along the way. I’ve long been intrigued by Pow and know that I learn with my hands, so digging in and building something similar sounded exciting. Here’s what I found:

I’m an unabashed fan of Haskell. When I mention that (as I am wont to do), people tend to dismiss it: “oh he’s one of those academic types, he would like Haskell.” And I’ll admit – I wrote my master’s on monads, and stumbled in to Haskell when someone told me that you could actually use monads to do things (pun very much intended). Yes, that’s how I got to Haskell – but I’ve stayed because I believe it’s a great step in solving several of the software industry’s hard problems.

I recently had a very interesting conversation with Chris Hoffman at DCRUG, talking about how to explore the object graph of a highly complex Rails app. I’ve been mulling over some of his ideas and found myself with a few hours to kill on a flight from Austin, so I dug in and did the following rather enjoyable bit of spelunking.

TuneYard is a lightweight gem providing a Sonic Pi remote, and letting you embed snippets like their provided examples inside any arbitrary Ruby code. My intention is to use this to power an upcoming Iron Yard class project that I’m particularly excited about, but let me know if you have something else in mind; I’d love to support more general use.

I remember how I felt the first time I made an API call - like a caveman who has just created fire.

A student made that comment (modulo paraphrasing) during my last Rails class at The Iron Yard. I know exactly the feeling he’s referring to - that sense of having grappled, built, and conquered. Those are the moments that got me hooked on programming. As cerebral as software engineering is, it’s a strangely primal feeling.

I want each of my students to have that viscerally satisfying experience of creating fire themselves, and I’ve been thinking about how I can make that happen. I think the trick is in the tools - don’t give them a lighter, give them flint and kindling.

Growing up, I played a lot of tennis. My serve has never been the strongest part of my game, but I do remember one game in particular where I felt like I was hitting significantly better than usual. I was playing against my dad and must have been around twelve at the time. He won (he always did back then), but I was feeling pretty proud - many of the points had progressed into solid groundstroke rallies, and I didn’t have many of the halting starts and frustrating self-defeats of double-faulting away a point or game. After the set, Dad had a simple comment that changed the way I thought about the game - “you’re not double faulting enough”.

One week ago today, I started teaching Ruby on Rails at The Iron Yard. Three days before that was my last day at Emcien. It’s been a whirlwind and I’ve barely had time to catch my breath, but today John Saddington reminded me how important it is to take time to reflect, so I’m doing that.

I’ve long been intrigued by Haskell and recently have been reworking some existing apps in Yesod to get more hands-on experience (most notably, working on the Pi-Base). There’s a lot to like - the type system offers some pretty strong correctness guarantees, but more significantly, it makes refactoring and developing feel a whole lot less like work and a whole lot more like playing with Legos. But coming from Rails and the ridiculously helpful Ruby ecosystem, I’ve struggled to find replacements for a few of my workhorse gems.

For the home server I’ve started working on, I found myself needing to do some periodic background tasks, which probably means forking off a clock-worker. While there are lots of different ways to approach this, this is essentially a solved problem in the Rails world; you should pretty much be able to drop in any one of several gems and call it a day. I’ll admit I’m new to the Haskell ecosystem, but it doesn’t seem as cut and dried here. In fairness, this could be in part because the pieces are all already there and assembling them yourself isn’t all that bad.

In which I wire up Twilio to my lights, in an effort to appease my neighbors…

It’s alive! Go look!

The π-Base is a database of topological information, similar to Steen & Seebach’s classic Counterexamples in Topology, but with automated deduction and powerful search. It is the tool that I wished existed when I started looking into cozero complemented spaces, replacing a stultifying literature search with the following process:

• Add the cozero complemented property
• Record its relationships with other known properties: perfectly normal, completely regular and ccc
• Let the site deduce what it can about the examples it knows about
• Query for spaces which are not determined by the known theorems

Video of this talk available on Youtube, with thanks to Frank Rietta

See pt. I for background discussion

Okay. Worker platform: selected. Let’s do this.

(In the Background)

Basic apps are often alive only inside the request-response cycle: a user asks your server for something, the server does its thing, sends back some HTML, and sits there waiting for the next user. Breaking out of that loop means one of two things, tautologically - starting before getting a request, or continuing after returning a response. The specifics vary from app to app, but there’s usually quite a lot that goes on that your users really shouldn’t have to wait on.