Saturday, December 29, 2012

Using GitHub As Your Blog

I just put an entire blog post, including an ad for my book, inside the comments for one of my projects on GitHub. Technically it only happened because I was writing this comment and I was on a roll, but I predict absurdly intricate code comments will become the bold new startup marketing move in 2013.

Wednesday, December 19, 2012

Guest Post Today On The Code Climate Blog

The conversation around DCI and concerns in Rails continues today with blog posts from David Bryant Copeland and Jim Gay, author of Clean Ruby.

Last but not least, the conversation also continues with a guest post I wrote for the Code Climate blog, entitled DCI, Concerns, And Readable Code. Code Climate is a web app which provides the best way to ship better code faster. My blog post examines David Heinemeier Hansson's recent post on concerns, and shows how that post links this ongoing debate to a major theme from my book: that Rails makes fluid API design its main priority, and owes a lot of its success to that.

Although there is some funny sarcasm, because I just can't resist a good punchline, I'm aiming on the whole for a more elevated level of discussion than in the past. Here's an excerpt:

Finding “just the right amount of abstraction” requires more than just defining the most readable possible API. It also requires balancing the most readable possible API with the most comprehensible possible domain model. There’s an analogy to human writing: you can’t just write beautiful sentences and call it a day. If you put beautiful sentences on pages at random, you might have poetry, if you get lucky, but you won’t have a story.

Every Rails developer who wants to write good code can get something valuable from this post.

Sunday, December 16, 2012

Saturday, December 15, 2012

Jekyll Custom Output Directory ("destination") Quirk In _config.yml

It appears that if you want to specify a custom output directory with Jekyll's destination: parameter, in its _config.yml file, this destination: line should be the first line.

In my personal experience, today, this caused the creation of both a custom output dir and Jekyll's default output dir _site:

destination: foobar/

Whereas this produced only the custom output dir:

destination: foobar/

Thursday, December 13, 2012

Requiem For A Temporary Autonomous Zone

One of the big author names to drop in the 1990s, besides the cyberpunks, was Hakim Bey, a philosopher who wrote Pirate Utopias and The Temporary Autonomous Zone. Temporary autonomous zones empowered the kinder, gentler post-modern anarchist to create safe havens of sane behavior outside the restrictions of hegemonic societal control. The archetypal TAZ was a rave, a momentary bubble of peaceful anarchy, but other implementations existed (most obviously Burning Man and Usenet).

Another big author name to drop in the 1990s: the brilliant Benoit Mandelbrot, who remains more worth reading than almost anyone since Shakespeare. You can also find Upski's name on that list too, but only in an alternate universe ruled by truth and light.

If it seems maudlin for me to dredge up forgotten underground literary heroes, I have a reason. Anil Dash wrote a wonderful post dredging up a forgotten underground World Wide Web, one whose businesses and communities respected crucial principles of online culture like data interoperability, user privacy, pseudonymity, microformats, and remixing.

It's not a coincidence that this WWW is the one which flourished after the collapse of the first dot-com boom, nor is it a coincidence that this is the WWW which birthed Rails. Nothing made the Web a better, more idealistic, or well-built place than the venture capital exodus of the early 2000s; nothing sent more programmers off to live in their moms' basements, either.

Dash seems defensive to me:

This isn't some standard polemic about "those stupid walled-garden networks are bad!" I know that Facebook and Twitter and Pinterest and LinkedIn and the rest are great sites, and they give their users a lot of value. They're amazing achievements, from a pure software perspective. But they're based on a few assumptions that aren't necessarily correct. The primary fallacy that underpins many of their mistakes is that user flexibility and control necessarily lead to a user experience complexity that hurts growth. And the second, more grave fallacy, is the thinking that exerting extreme control over users is the best way to maximize the profitability and sustainability of their networks.

The first step to disabusing them of this notion is for the people creating the next generation of social applications to learn a little bit of history, to know your shit, whether that's about Twitter's business model or Google's social features or anything else. We have to know what's been tried and failed, what good ideas were simply ahead of their time, and what opportunities have been lost in the current generation of dominant social networks.

I'm sorry to say that my take on this is more fatalistic; in my opinion, many of the functions of the venture capital system actively thwart the production of good software, but perform marvelously if you view them as a bridge for transferring the population of an aristocracy from positions which control the social and economic systems of the past to positions which control the social and economic systems of the future.

In my opinion, another dot-com crash would purge VC influence from the Web, restoring some measure of sanity to it, and allowing it to regain many of the virtues Dash eulogizes; however, that crash would have a pretty severe downside for many people. Anarchists throw incredible parties, but they're less effective at organizing stable social systems.

Wednesday, December 12, 2012

Rails Developers Should Take DCI Seriously

I recently wrote an ebook about Rails. It covers the ways Rails breaks OOP theory, where this creates problems for Rails developers, where it reveals flaws in OOP theory, the core strategies that make Rails so delightful and powerful, and what you can learn from it all to write better code yourself. This involved crystallizing opinions I've formed while hacking Rails apps since late 2005, as well as new research. One thing I learned from writing my ebook: a lot of the strongest OO thinking on how to use Rails converges on the DCI pattern.

The idealistic perspective on DCI is extremely worth considering. DCI stands for Data, Context, and Interaction. Jim Gay's writing a book on the topic called Clean Ruby, and it really does teach an excellent new way to think about OO software. I recommend it very highly.

But there's also a cynical perspective on DCI.

You would expect to hear the cynical perspective on DCI from DCI's critics, but what you get is too weak to qualify. David Heinemeier Hansson, creator of Rails, mocked unnamed object-oriented purists on the 37Signals blog:

Inheritance is always bad, only composition can be our true savior! Only standalone command objects can give us the reusability this application needs!

Turning patterns into articles of faith takes them out of the realm of rational discussion. Code either adheres to the holy patterns or it doesn’t. If it does not, the programmer must first repent, say his 25 rose-delegations, and then swear never to let an opportunity for a policy object extraction pass by him again!

37Signals dev Jeremy Kemper joined in with a snarky tweet:

This argument is simultaneously indisputable and weak. It's a truism that you have to exercise judgement when deciding to use or not use any toolset or mental model for coding. But it's irrelevant because there aren't a whole lot of single-minded OOP zealots in the world of Rails developers. Rails takes significant liberties with OOP, so you can't really build a career on Rails development unless you're flexible about that.

So why did Hansson and Kemper even bother to post this? I was egotistical enough to imagine this served as a response to my book, and/or Clean Ruby. It's almost the argument my book makes; in some of the places where Rails violates traditional OOP rules, the smart thing to do is throw out those rules. (That's some of those places; not all.) But I soon learned the real story. It all came about as a result of some kind of kerfuffle on Twitter between Hansson and the Ruby TDD evangelist Corey Haines.

Rails developers sure love to get their kerfuff on:

For a longtime Rails developer, it looks pretty weird. Where Hansson once employed brilliant, acerbic wit to attack over-engineered failures like J2EE, back in 2005, he's in this case hobbling together a lackluster and irrelevant argument so he can put down a guy who makes Rails easier to understand and use.

The Rails world features a lot of drama, and I've been foolish enough to participate in it myself in the past. The noise factor doesn't make it any easier to hold serious conversations about the best way to use the flawed yet fantastic toolkit which Rails offers developers. (Hint: avoid STI.) It's not so much a situation where the emperor has no clothes as a situation where the emperor will make fun of you for wearing pants.

Camel corduroy pants

But however snarky these very talented and accomplished coders at 37Signals were, they didn't attack DCI head-on. You won't find a lot of substance in the 37Signals post, just nonspecific mockery, as if plausible deniability mattered more in architectural discussions than clarity.

So remember the question of the cynical perspective on DCI? You'd expect to find it here, but ironically, the 37Signals blog post fails to consider the cynical perspective on DCI. It doesn't even mention DCI. If you didn't know the context, you wouldn't be able to make the connection without Kemper's tweet. And this is the downside with Rails drama; it's tiresome, yet if you don't track it, you don't know what the blog posts are really about.

So we have an interesting blind spot. The idealists are not considering the cynical perspective, because they never do, but the critics are not considering it either, because they're too busy hand-waving the entire question away.

So, be warned. Here comes the cynical perspective on DCI. I'm not endorsing it at all, I'm just bringing it to the table: DCI is a bunch of jargon we're forced to resort to because Rails, in a paradoxical twist on the way it creates beautiful code DSLs, has created a mangled nightmare of a DSL when it comes to the actual English vocabulary Rails developers use, when we actually speak to each other with human words.

Specifically, we have obliterated the distance between ActiveRecord, the Ruby gem, and Active Record, the design pattern. Here's the pattern, which Martin Fowler identified, and which Hansson named ActiveRecord (the gem) after:

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

Interesting question: is belongs_to domain logic? If you use ActiveRecord "models" only as data objects, and wrap those in classes which you treat as The Real Models™, are you implementing Active Record?

Prior to the discussion around DCI, many Rails developers began exploring and praising the peace-of-mind benefits which you obtain when you use ActiveRecord as a data object factory, and compose your domain logic in wrapper classes. DCI allows you to put that logic in modules and apply it to your ActiveRecord models as needed; however, in either case, you're putting domain logic somewhere other than ActiveRecord subclasses inside /app/models, and doing so to avoid monolithic Rails apps (or monorails, as they're known). Other approaches use wrapper classes in /app/models or /lib, but with DCI, you take your domain logic out of ActiveRecord classes when writing the code, store it in modules instead, and mix those modules back in to ActiveRecord objects as needed (and only as needed). So when it comes to files on a filesystem, you're not using ActiveRecord to implement Active Record, but when it comes to the action of the system and the objects in memory at runtime, you are.

Remember the pattern's definition?

An object that... adds domain logic [to] data.

So you're going to add domain logic to data. When? Most object-oriented thinking suffers from the legacy of primitive, clunky languages which could not differentiate objects from the classes they instantiated. Thus many ideas which claim to be object-oriented are really only class-oriented, and the naive interpretation of "adding domain logic to data" assumes you could only ever do that at the point in time when a class is defined. But Ruby, with its near-infinite flexibility, can add domain logic to data at any time, and Ruby DCI implementations make use of that.

Even though it has a great pedigree, DCI is an emerging trend among Rails developers. It's not the official solution. Rails officially handles bloated models with a clunkier but not useless concept known as concerns, which live in /app/concerns. DCI is basically just a smarter, better-structured replacement for Rails's haphazard and off-the-cuff concerns idea — kind of like the relationship RSpec has to "pure" Rails testing. The major difference between Rails concerns and DCI modules is that Rails concerns fail to differentiate indirection from abstraction, while DCI modules make that semantic distinction clear.

Zed Shaw wrote the post which I linked to just now, about differentiating indirection and abstraction. I hate to even link to a Zed Shaw post, because he is in my personal opinion a maniac, and it's a verifiable matter of provable fact that he blogged a description of me, Giles Bowkett, engaging in sexual activities with a dog, which was libelous, inaccurate, and, in my personal opinion, also rather disturbing. This is related to my personal opinion regarding his sanity, but I think there's enough of this type of discussion in the Ruby world as is, so rather than explain my conclusions about his mental state — which are probably obvious anyway — let me just say that whatever strange, unwelcome, and surprisingly detailed opinions Shaw might have about my penis, when it comes to the difference between indirection and abstraction, he actually makes sense for a change.

Wag the Dog

It's very important to prioritize abstraction over indirection. It's the difference between re-organizing your desk by creating a system to finish all your tasks — that would be abstraction, and DCI — vs. "re-organizing your desk" by taking everything on the desk, throwing it in a box, and then hiding the box in another room. That would be indirection, and Rails 3 concerns. I would add the caveat that indirection sometimes helps you discover the abstractions you need, but overall, it's a good point.

To recap, DCI uses ActiveRecord to implement Active Record — sort of, in a sense. It avoids creating the gazillion-line User models we all know and loathe, because it puts domain logic in modules instead of on the actual Active Record (or domain-logic-enabled data object), and only mixes that domain logic in to the Active Record when the Active Record operates in a context where it needs such logic. The domain logic lives on the object, but not in the ActiveRecord class file, and only lives on the object when actually needed. Other strategies for de-bloating gigantor User models involve isolating ActiveRecord objects within wrapper classes, and considering those wrapper classes to represent the real domain model — in effect, refusing to use Active Record, the design pattern, while happily choosing ActiveRecord, the library itself, over alternative Ruby ORMs like Sequel or DataMapper.

This means ActiveRecord must logically not be an implementation of Active Record. How can it? If ActiveRecord actually implemented Active Record, it would be impossible to use ActiveRecord without using Active Record. But you can. Not only that, it might be a very good idea.

Instead of claiming ActiveRecord implements Active Record, it would be more accurate to say that ActiveRecord provides a data object which you can use to implement Active Record, if you want.

It makes Hansson's blog post pretty ironic:

Turning patterns into articles of faith takes them out of the realm of rational discussion.

He's describing the mistake that he himself made when he named ActiveRecord after Active Record. Naming gems after design patterns takes those design patterns out of the scope of architectural discussion.

But I'm not just posting this to dick around and win points in an Internet argument. Say you need to discuss this with your teammates on some project, for serious reasons. How do you have that conversation? "We need to use Active Record, but not ActiveRecord." You don't have that conversation, because you don't want to sound like Abbott and Costello. "ActiveRecord?" "No, Active Record!" "Who's on first?" Next somebody starts throwing cream pies and the dancing bear steals your bicycle.

Bears on bikes

Instead, even though The Rails Way (written in 2007) briefly discusses breaking models into modules, and even though James Golick advocated the wrapper classes approach in 2010, and even though Rails 3 provided concerns, the conversation didn't really gel (in my opinion) until people started talking about DCI. That's because DCI provides an interesting way to think about code which makes it easy to solve the problem. Before this, you could hardly even talk about the issue without sounding silly.

So here's the cynical perspective on the cynical perspective: DCI must be bullshit, a crutch, if people are only digging up DCI because Rails uses an inaccurate vocabulary to describe itself. But the idealistic perspective on the cynical perspective is to say that digging up DCI means digging up buried treasure.

Treasure Chest

The guy who created DCI also created MVC, and, as part of a team, he also created Smalltalk. Since Ruby is mostly Smalltalk on a command line, he's almost one of the people who created Ruby. Maybe not a grandparent, but at least a great-uncle.

So "buried treasure" is probably the correct interpretation. Exhibit A: the book Clean Ruby. You should read it.

You should totally read my book, too. The content is just like this, except with greater distance from Rails drama, and a greater insistence on accurate thinking and clarity. I also tell you an interesting story about the unusual life, and sexual problems, of a talking rhinoceros. It's kind of like the infamous Mr. Shaw, but without the terrible social skills, or perhaps _why the lucky stiff meets Hunter S. Thompson.

Here's what people are saying about it on Twitter:

That's right, folks, master poet T.S. Eliot himself commented on my book from beyond the grave. And that's just a sampling; there are many more I didn't post.

Even the creator of Rails has an opinion! Check out what Hansson himself had to say about my book on the 37Signals blog:

If that's not an endorsement, I don't know what is.

(And finally, if you're curious, but not ready to buy, you can download a free excerpt.)

Friday, December 7, 2012

GitHub vs Skyrim

In my opinion, GitHub does the best original thinking on the Web about how to run a tech company, and Clay Shirky is right to call them one of the most important companies in the world. Also in my opinion, Ryan Tomayko wrote one of the best "how GitHub works" posts ever:

What we're learning at GitHub is that opting in to open source project constraints often results in better natural survivability characteristics for many types of business, product development, and operations activities.

It shouldn't be a surprise that a company which specializes in tools and workflows for open source development, and hires based on open source participation, finds the tools and workflows for open source development useful in its day-to-day operations. However, in Tomayko's post, he explains that GitHub, like Valve, successfully escapes the Dilbert-hell resting state which many people assume all startup activity converges to, that GitHub does so using GitHub, and that he believes other tech companies can do the same thing.

Tomayko's post includes a 43-minute presentation from a conference, and it's worth watching, although a little overlong in my opinion. In the presentation, he highlights a traditional corporate org chart:

He then compares it to a chart of open source activity in the Perl community which was generated by software which measured and correlated interaction using the GitHub API:

He says GitHub is more like the second chart, and I believe him. However, I think any healthy company is more like the second chart; the first org chart represents a dreamworld cooked up by overpaid aristocrats, pitifully focused on their hierarchy, whereas the second is founded on measurement and observation. (You don't need my political point of view to look at the first org chart and notice that it is an absurdly simplistic model for any human social system.)

Every company with more than one person working there will feature some tension between the rules people set out and the way people actually behave. Healthy companies have very little of this tension; dysfunctional ones have very much. GitHub throws away the traditional social fiction and mostly focuses on the reality. I say "mostly" because Tomayko explains that GitHub does present one new social fiction: in their recruiting, they claim they have no managers, but what that really means is that everyone is their own manager, and by signing on, you accept the responsibility of managing yourself.

I definitely recommend reading Tomayko's post and watching his presentation. If this was the type of dipshit mating-honk you sometimes find on Hacker News, I would go on to further tell you that GitHub's way of organizing projects is The Way and/or The Future. But I'm going to stop short of that, and simply call it one way and one future (albeit maybe the best way and the best future), because of an extremely powerful counterexample: Skyrim (and World of Warcraft).

Modern fantasy role-playing video games feature incredible gamified to-do lists. Their effectiveness is far beyond any to-do lists which exist in the real world. If I ever figure out how to make my own real-life to-do lists feature the same compelling blend of enticement, reward, and repetition, I'll become so productive that people will suspect me of being an entire army of clones who all happen to share the same name.

It's incredibly easy to sit down to play one of these games and not stand up again until six or eight hours later. The whole time, you're telling yourself that you're just going to go and do this one other task. People have spent entire years of their lives in these games, accomplishing far more in the fantasy worlds than they do in reality (and sometimes literally starving to death in reality as a consequence). It sounds crazy to say it, but for a very large number of people, having a computer tell you what to do next must feel really good.

I'm not the only one who wonders what it would be like to gamify my to-do lists. And because the group raids aspect of Warcraft requires a great deal of planning and coordination, fans of the game -- including Joi Ito, the entrepreneur, investor, and director of MIT's Media Lab -- claim that it's not only entertaining, it's great training for project management, including project management in technology companies:

I am in awe of Persimmon who is our raid leader. She works in a hospital in real life. She is the stabilizing force during the raids, supporting the class leaders, nudging the conversation and keeping the raid moving as fast as possible without moving too fast. I find that she reminds me of many successful open source project leaders or Jimmy Wales of Wikipedia, except that what she has to do happens much faster and in real-time. Without her fully customized user-interface and scripts she would never be able to manage what she does...

The structure and the organization required to complete missions or quests in WoW adds a great deal of focus and complexity to the community compared to a chat room and the communications and management begins to feel much more like collaboration in a work environment. I think that the ever-evolving user interface and communication tools that we are developing might impact the future of management in the real world. My feeling is that what we are doing in WoW represents in many ways the future of real time collaborative teams and leadership in an increasingly ad hoc, always-on, diversity intense and real-time environment.

Although Ito compares running a raid to running an open source project, it's clear that his model implies managerial responsibility. But if you read Tomayko's post and watch his presentation, you'll witness a strong argument against the use of any managerial staff in technology projects:

Avoid synchronization / lock points when designing process. This is DVCS writ large. We don't have a development manager that grants commit bit to repositories before you can do work, or a release manager that approves deploys, or a product manager that approves work on experimental product ideas. Work toward a goal should never be blocked on approval. Push approval/rejection to the review stage or automate it, but surface work early to get feedback.

Another major contrast between Ito's post (made in 2006) and Tomayko's is that Ito praises always-on communication, and treats its usefulness and primacy as a foregone conclusion, while Tomayko recommends that it be strictly optional.

The reason why?

This is [distributed version control systems] writ large.

Distributed version control systems decouple collaboration from coordination. This is the same benefit which Wikipedia provides to archivists and Twitter supplies to activists. It explains why Clay Shirky likes GitHub, too, because it's the same dynamic Shirky explores in his terrific book Here Comes Everybody. He finds the act of decoupling collaboration from coordination -- and removing authority figures, by removing synchronization -- at the heart of a huge range of online and social phenomena, and identifies it as the aspect of the Internet most likely to transform society permanently (just as the printing press eventually did).

It's a brilliant idea. It's an idea whose time has come. And it obviously works for GitHub. But I'm not sure how to reconcile Shirky's very compelling arguments or GitHub's wonderful success with the sheer, dimwitted enjoyment I get out of being told repeatedly to go over there and kill another orc. Again.

One thing which makes it tricky is that when you participate in open source projects on GitHub the site, you're doing the same essential process that working at GitHub entails, and all the working parts of that process are exposed. You can track issues, commits, and pull requests, and you can see how everything fits together. But in games like Warcraft and Skyrim, although the task lists are impressively addictive, whatever makes them that way is hidden below absurdly primitive user experiences. Nobody will ever hold up the Warcraft quest log as an example of beautiful UI.

A lot of companies are working on ideas like gamifying the workplace. I think a lot of them will fail, and that they will look stupid in the process, because most of these companies don't seem to think very hard about what "gamifying" means, and they don't seem to think about what "the workplace" means at all. It's possible that GitHub and Valve represent the first wave of what will become a normal, predominantly office-free way of living and working for the same people who would have been called "office workers" throughout the 20th century.

If that's the case, then the whole concept of "gamifying the workplace" might be irredeemably fucked, because "workplace" might not even be a meaningful term in a few decades. It certainly won't refer primarily to physical locations; for many people today, it already doesn't. I think a lot of these companies are putting futuristic lipstick on a Steam Age pig. Adding badges and meaningless points to a process which feels antique is no way to create the future.

If there is any future to ideas like "gamifying the workplace," it's in some merger of elements from GitHub and Skyrim, but I'm still not sure which elements, or in which proportion.

Saturday, December 1, 2012

Underpromoting Information Products For Fun And Profit

On the night before Thanksgiving, I released an ebook on Rails, covering how Rails breaks with traditional OOP theory, where I think that creates problems for Rails developers, and where I think that reveals flaws in orthodox OOP thinking.

In the past I've aggressively promoted my information products, with cheesy titles like "Secrets Of Superstar Programmer Productivity," hype-generating moves like preview videos, countdowns to product launch dates, and trolltastic rants, plus artificial scarcity tactics like only offering my products for sale during a brief window (e.g. one weekend).

With this product, I wrote Peter Cooper a brief email, telling him I'd written an ebook -- but not what it was about, or even what it was called -- and did nothing else to promote the book except offer free copies to people who I had quoted in the book, and retweet people who praised the book. Peter included a link to the book in his newsletter Ruby Weekly, but since I hadn't actually told him anything about it, or given him a review copy (something I've since rectified), the blurb in the newsletter basically just made fun of me and said "there's a book, I don't know what it is, but it's got something to do with Rails, and Giles wrote it."

This minimal and even somewhat embarrassing approach to marketing still sold around 100 books -- I think the exact number is 94 -- while I was enjoying a Thanksgiving vacation in New Mexico at my parents' Earthship. I'm pretty sure I spent more time exploring the art galleries of Santa Fe's Canyon Road and creating a pair of simple paintings in acrylic on small 6"x9" canvasses (which I gave to my parents) than I did promoting the book.

I will of course market my book some more in the near future, probably in a much more serious and energetic way, but I want to recommend underpromoting your information products for the feedback factor. Word-of-mouth marketing is the best kind; when people tell their friends to buy your stuff, you know you've got something worthwhile. It's kind of like the Google Ads market research phase which so many marketers recommend, but with income.

When you sell with hype, your sales tell you how good your hype is. When you sell via word of mouth, your sales tell you how good your product is. This is of course a massive oversimplification, but as long as you remember to take it with a grain of salt, it's true enough that you can feel a little extra proud of your product when it sells without hype.

I also want to say that if you're building on ideas which you got from other people's work, giving them free copies of your product is a great way to not only get tweets and mentions from them, but also to find out if what you said actually makes any sense in the first place. I think the latter benefit is more worthwhile. Any time you create a book or a video or whatever, you're participating in an ongoing conversation, and the more you contribute to that conversation, the better off you are, both in terms of verifying that what you want to sell is worth paying for, and in terms of karma.

(Finding out if your product is worth paying for is harder than it sounds, because a good book has to enlighten the ignorant, without boring the well-informed.)

Anyway, expect hype in the future, because it works, but for now, just check my Twitter favorites if you want to see some hype of the classic, Web 2.0 flavor.