[Update: if you liked this post, please take a second and upvote it on HN]

As I write this, I’m sitting in my father’s TV-watching chair as my son plays with the various and sundry toys he’s accumulated over the holidays. Not that long ago I’d have regarded this scene as improbable at best, as my father and I rarely see eye-to-eye on much of anything, and haven’t for years. For a number of reasons, this is the first Christmas I’ve been to my father’s in quite some time, but chief among them is the persistent notion I have that while my father and I rarely agree, it doesn’t have to mean one of us is wrong. If there’s one thing being a parent has taught me, its that maybe Dad was right about a few things as well.

And if there’s been one theme I have kept seeing popping up in 2011, its the idea that more and more in the Ruby and Rails world have started noticing some of the problems in Rails. Steve Klabnik’s most recent post is the latest salvo in a long string of high profile Rubyists noticing that what we’ve been doing for the vast majority of applications isn’t working anymore.

Love at first sight

Like Steve, and many others, my first impression of Rails was formed in large part by the ease of using ActiveRecord to get at my data. No more hand-forming SQL and manipulating cursors! No more rolling my own ORM layers in every application! I fell in love at first sight.

My exposure came through reading a copy of Agile Web Development With Rails, 1st ed. I found in Barnes and Noble while I should have been studying for a Biochemistry exam early in 2006. The more I read the more I wanted to read—finally I felt like someone had crystallized all the essential elements of creating web apps into a great framework with a hell of a learning curve driven mostly by learning what basic problems you don’t have to deal with anymore.

And so it had, to some degree. The clusterfuck that every PHP app eventually degenerates to was gone, replaced with a well-organized codebase where every most ideas have a home. Early scalability criticisms focused on the ability of a Rails app to withstand high levels of traffic, and solutions and “best practices” began to develop, allowing bigger and bigger apps to be built easily and quickly.

And then the underwear comes out

But like all love-at-first-sight relationships, reality eventually sets in. Solving the traffic scalability problems eventually leads to a much more insidious problem: design scalability. The more we demonstrate an ability to solve Big Problems™, the more we’re called on to solve Bigger Problems™—but the tools in our kit aren’t evolving.

Does it ever strike you as odd that we’re basically using the same patterns that Visual Basic used to create UIs that map directly to database records? Yes, the mechanisms have changed, and we’ve found new and interesting ways to introduce HTTP into the mix, but even today most Rails applications map a database record to a form view with a CRUD architecture. Why, when we abstract the hell out of everything else, do we fail to break this mental model of shoveling data directly into a data store?

I frequently talk to developers maintaining apps with hundreds of models in monolithic apps. Nobody sets out to do that—its an outgrowth of the Big Ball of Mud pattern. Does it strike anyone as a good idea? I think not. But there it is—reality intruding into our cozy ActiveRecord world.

Back to the parents…

Until fairly recently, Rails was largely the province of startup developers who made their own rules about the companies they were creating. HR? Fuck that noise, I never want to work at a company big enough to need it. EJB? Who needs it? If your environment is so complicated that your IDE has to create code for you, you’re Doing It Wrong™.

This is mostly my opinion, but a lot of us let our rejection of enterprise culture lead to rejection of “enterprisey” design patterns, many of which developed in order to solve problems we’re now encountering in the Rails world as we tackle problem domains that are not only non-trivial but exceedingly complex. This is not accidental—as we’re making deeper and deeper inroads into the enterprise world, by hook or by crook, we’re being called on to use architectural patterns that have demonstrable value there.

But this is also an opportunity to create new growth in the enterprise. ORM’s cause as many problems there as they can in non-trivial Rails applications. They’re just a much more configurable animal, and thus, a much bigger pain in the ass to use. Ruby’s huge productivity boost can help enterprises get more done with less, and many of the ideas of the Rails world (like convention over configuration) can drive those productivity gains even further. If there’s one overriding idea from the Rails world that I think should be promoted far and wide, its this: it shouldn’t be this hard.

In other words, Dad wasn’t wrong about everything… but neither am I.

Where do we go from here?

Over the next few weeks and months, I’m going to be blogging a lot about a couple of topics in particular: CQRS and Event-sourced Data. These two patterns go together like peanut-butter and jelly, and I think they have a lot of potential to form the basis of an evolved Rails stack, or perhaps a different beast altogether.

These ideas are mostly used in the .Net (and to some degree, Java) world, and there’s a bit of a cognitive load to using them, especially if your only exposure to OOD is through Rails’ idea of modelling with ActiveRecord. But the benefits in design and flexibility I think make it well worth it, especially in the enterprise where heterogenous and polyglot stacks are far more common.

Briefly, CQRS (Command Query Responsibility Separation) is an idea that has grown out of Domain Driven Design, and it promotes the notion that your domain models can and should be separate from your read models which are consumed more directly by your application. In practice, writes happen through commands, typically with a Command object that works directly with the domain model, and changes are reflected for reads through the use of events (which is where the event-sourced data comes in). One of the key points is that your domain objects are basically PO*Os (Plain Old [insert language of choice here] Objects), and you model your domain with back-to-basics object oriented modeling techniques.

This is but one possible path of many, but its the one I’m most interested in exploring right now. I think the flexibility and meta-programming features of Ruby have the potential to make these patterns exceedingly easy to access, just as ActiveRecord (the library) made the ActiveRecord pattern trivially easy to use. I’m also really interested to see what else the community cooks up over the next year, because I think we’ve been resting on our laurels for a bit too long now, and we’ve still got plenty of room to grow.

I tried to migrate all my old posts from Posterous, but that was a great big fail whale for some reason (I keep getting 410-Gone for the http error; if you know what I’m doing wrong, drop me a line in the commnts.) I’ll have to migrate that stuff manually, I suppose—good thing I didn’t spend much time blogging in the last couple of years or I’d have a lot more work to do there.

Since we started PublikDemand a little over a month ago, things have moved at a lightning pace, but nothing like its about to be moving. Product? Almost there. Funding? Check. Check. Awesome cofounder? Check. Ridiculously supportive wife? Check, check, checkity check.

Right now I’m thinking about the multitude of boxes to check off before we can launch. Design. That last teency-tiny raft of actual features. Invitations. Admin features. Customer features. Analytics. Ad network. Rent out my house so I can move if we get into an incubator. Figure out how I’m going to pack said house.

OH MY GOD ARE WE F’ING CRAZY?

Don’t they know I’m a fraud? Don’t they know the chances of success are only slightly better than those of Ron Paul actually winning a nomination? Don’t they know I’m almost 35?

This is never going to work. We’re insane for even trying.

I’m putting my family’s financial future on the line for this. I’m letting friends count on me for their own. Its going to blow up. Everyone’s going to hate me.

I can’t even get this blog entry out the way I want it. How the hell am I going to build a company that can sell millions in inventory every year?

Take a breath. Go outside. Smoke a cigarette. Remember why you don’t smoke. Have a screwdriver for breakfast.

Now: Man. The fuck. Up.

You are not Mama’s precious snowflake. You are not special. You are not a thought leader, a rockstar, or a ninja. Your Klout score sucks. Guess what?

You’ve still got to get it done.

Stop reading HN and freaking out about every funding-crunch-of-doom article. Stop thinking about valuations and how much equity you’re going to have to give away and when. Stop worrying about this design decision or that one and flip a fucking coin, because you don’t have enough traffic for either of them to matter. Stop dreaming.

Start building. And get the fuck over yourself, you’re not that important.

My big problem was not being able to use the debugger in the environment, since the use of the Passenger callbacks means you have to use Passenger, which doesn’t work with the ruby debugger. Even using Passenger in standalone mode (passenger start) forks the environment, which means the debugger is out.

So here’s my somewhat hackish solution:

Its short, sweet, and probably oversimplified. Stick that in your lib folder and require it in your AMQP initializer. If anyone has a better way of pulling this off, please point me towards the better solution in the comments.

The Man Who Almost Invented the Vacuum Cleaner

The man officially credited with inventing the vacuum cleaner is
Hubert Cecil Booth. However, he got the idea from a man who almost
invented it.

In 1901 Booth visited a London music-hall. On the bill was an
American inventor with his wonder machine for removing dust from carpets.

The machine comprised a box about one foot square with a bag on top. After watching the act – which made everyone in the front six rows sneeze – Booth went round to the inventor’s dressing room.

“It should suck not blow,” said Booth, coming straight to the
point. “Suck?”, exclaimed the enraged inventor. “Your machine just moves the dust around the room,” Booth informed him. “Suck? Suck? Sucking is not possible,” was the inventor’s reply and he stormed out. Booth proved that it was by the simple expedient of kneeling down, pursing his lips and sucking the back of an armchair. “I almost choked,” he said afterwards.

When you’re engaged in an endeavor that someone else has already tried, its important to remember that the details count. Small differences may seem trivial at first, but the smallest twist on an idea can make the difference between Friendster and Facebook. Timing can be the difference between MP3.com and Apple’s iCloud or Amazon’s Cloud Player.

Just because someone else did it first doesn’t mean you won’t be the first to do it right.

But something I see over and over again is emails from different recruiting agencies successively recruiting for what is clearly the same position at the same company. Company calls recruiter, works with them for two or three months unsuccessfully, then moves on to a new agency, hoping for different results. I’m not sure why they think that’s going to make a difference—I would hope everyone realizes at this point that the recruiters are probably targeting the same population.

Got a job to fill?

Judging by my inbox, your process looks a little like this: 1. Open position lands on your desk 2. Email said position to mailing lists and database of names you have from… somewhere. 3. ???? 4. Send suitable applicants to company (or hiring manager if you’re internal) 5. Collect recruiting fee or keep internal recruiting job.

What’s step 3, the astute reader asks? For many, it seems to be mostly filled with waiting, hoping, and praying. I hate to be the one to tell you this, but you’re going to have to work harder than that.

You’re probably laboring under a false assumption—that your job is filling jobs. Its not. Yes, I realize you’ve probably been doing this job for years, and based on my totally unscientific research of recruiters I’ve met, talked to, and worked with, there’s even a 30% chance you’re good at it. Who am I to tell you what your job is?

I’m the guy you’re trying to hire.

Your job is not filling jobs. Your job is creating relationships. Mostly, you need to be creating relationships between yourself, and people in technology, across the country. Candidates is such an aseptic word, so we’re going to call the latter category ‘friends’. When you have a job to fill, you use those relationships to create a new relationship between your client and your friends. And like your everyday friends, you should care enough to know a few things about your geek friends. Here’s why: in technology today, there are more jobs than qualified people to fill them, and that problem seems to be getting worse. So chances are, you’re going to have to convince someone to leave their current job and go to a new job. If your friends like their job, you’re going to have to convince at least one of them that this job offers them more. You do that by selling them on the idea that the new job is going to be better than the one they have, and to do that you have to know what “better” means to them. Maybe its money; maybe its free time. Maybe its company culture, or the chance to learn something new or work on an interesting problem.

Whatever their weakness is, its your job to know it.

When I come to you as a client, I’m not paying you 5, 10, or even 20% commission on their first year’s salary to send a bunch of emails. I’m on all those lists and I can do that myself. What I’m buying from you is your network, and it damn sure better be better than mine, or you’ve got a problem. Because if its not then that means that your client can do your job better than you can.

So, how do you get there? If you’re in any kind of market with a tech scene, you had better be a part of it. Here in Austin, we actually have technical groups negotiating with each other for who is going to meet on what night, because there are so many groups of us meeting that we have to try to minimize scheduling conflicts between groups with overlapping membership. If you’re a recruiter in Austin and you’re not spending at least two nights a week going to these groups and getting to know the members, you’re Doing It Wrong™.

When I say “getting to know the members” that needs to really sink in. That doesn’t mean you stand up at the beginning or end of the meeting and say “Hi, I’m so-and-so, and I’m hiring for a bunch of clients so if you’re looking, please come talk to me.” When you do that, you’re asking me to get to know you and what you’ve got to offer. Most of us aren’t actively looking, and we’re not going to come ask you who you’re hiring for, because we probably don’t care. That doesn’t mean we can’t be made to care.

When I say “getting to know the members” that means you get to know us. You engage in conversation. You listen to conversations, find out what we’re interested in (side note: that means you also need to know at least a bit about the technologies we’re interested in.) You know who’s got families and is risk-averse with respect to their employment. You know who’s young and ready to try new things and might be willing to work for a startup who can’t pay as much. You know who’s not altogether unhappy at their job but seems bored. You know who’s been working on side projects with a new technology and isn’t quite comfortable with their knowledge (but who is probably ready to work with it full-time). If you’re really good, you know about that one guy who’s about to have to put his parents in a nursing home and could use some extra cash.

You know this, because these people are your friends.

Let’s face it: half of us probably should get a new job, we just don’t know it. We’re complacent, happy enough that we don’t feel compelled to look around. But if the perfect job landed on my desk, coming from someone I know and trust (and maybe even like) who says “Hey, I know you’re not looking, but I really want to talk to you about this position and I think you ought to at least think about it, so let me buy you lunch or a beer and tell you about it.” I’d listen. Because you’re my friend, and you know what makes me interested.

Conversely, when you send me (a longtime Rubyist and Rails developer) a Java or PHP position, that tells me something—that you don’t know the first thing about me as a potential hire, and that you’re just doing the spray-and-pray thing that so many of your peers do. But we know you now, and we don’t call you back or respond to your emails. You’re lucky if we don’t add a filter to send your email to the trash. If this describes you, you are not my friend.

Gary Vaynerchuck sometimes talks about what he calls the “give-a-damn” economy (which he later revised to the The Thank You Economy), where companies are in business because they really, sincerely care and are grateful for their customers business. As someone recruiting to fill a position, this had better describe you, because we can smell it a mile away when you don’t really give a damn.

And we remember when you do.

By the way, if you’re a company looking to hire in technology, this all applies even moreso to you. Most of the technical groups I referred to above are educational in nature—so you ought to be encouraging and rewarding your employees for going to them. The companies around Austin that are actually managing to fill positions are the ones who we all know from meetings. We know the employees and that they like their work. We know the people we’d be working for, because we get together and have a beer with them at least once a month. If you have an open position that no recruiter seems able to fill, why don’t you try doing it yourself? If you still can’t fill it, cast a wider net: be open to remote employees, offer relocation, travel to some regional conferences and network. We’re not coming to you.

And if you’re someone looking (which deserves a post of its own) remember—these groups are where you’re going to find your dream job. if you live somewhere there isn’t a group, show some initiative and start one—not because you need a job, but because you give a damn about technology. If you have them and don’t go, you’re missing out. Not only on potential work, but on making a lot of honest-to-god friends you’d jump at the chance to work with.

Be a part of the community, and the community will be a part of you.