FiveRuns Blog

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, we’re happy to be joined by Mike Gunderloy, noted developer and creator of the popular blog A Fresh Cup.

FiveRuns: Welcome Mike! Let’s get started. Our own Adam Keys recently gave a talk at RailsConf titled Oh, the Fail I’ve Known. In the talk, Adam outlined a few different kinds of fail: learning failure (the knowledge was available but you didn’t have it), technological failure (you did have the right tool), problem failure (barking up the wrong tree), and so on. If you don’t mind, give us an example of the fail you’ve known?

Mike Gunderloy: After fifteen years in this industry what fail have I not known? But there are a few that stand out.

Too many times I’ve had a little knowledge (which we all know is a dangerous thing) and mistaken that for knowing everything. It’s very easy to have this overflow into a sort of technological hubris, where you assume that your chosen language and platform are good for solving every possible business problem. If you still think this, either you haven’t had a really wide exposure to the varieties of business problems out there in the world, or you’ve not yet faced your first serious threat of lawsuit. With most of the technologies I’ve worked with in the past, I’ve had the misplaced confidence that I could walk into any customer’s office and use my Awesome Code to solve their problem. In one case I especially remember, my partner and I spent a couple of months on analysis and spikes before we realized that we were in way over our heads, that our current platform was never going to do what the customer wanted, and that we should flee with all possible haste. Fortunately our lawyer was better than the client’s.

Another key failure that I see over and over again in the development community is the cavalier dismissal of business – as if we software people should not sully our hands with the details of doing business. I’m not talking about the details of analyzing your customer’s needs; I’m talking about running your own business. At this point, I’m convinced that you have only three choice. First, you can learn enough about running your own business and take it seriously enough to have an actual corporate structure, an attorney, an accountant, a banker, and an insurance agent. Second, you can pay someone else to handle all this non-coding stuff for you (by taking a salary and letting your boss make a profit from you in return for handling the business side of things). Third, you can code along in blissful ignorance until you get sued into oblivion or hounded by the IRS. Personally, I recommend alternative number one, but then, I’ve been freelancing for decades.

FiveRuns: Now that the Rails repository has been moved over to git, can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Mike Gunderloy: The obvious connection has been remarked on before: your SCM system can be a source of friction when you’re trying to do agile development. This is no different from any other “high-ceremony” system: if there are n steps that you have to take to branch your code, you won’t branch your code as much, you’ll be inhibited from trying quick code spikes, hair will grow on your palms, and so on.

But there are a few other things to say about the Rails community’s current infatuation with git and the wider topic of SCM.

As more and more Rails projects move to git, the barrier to contributing to the Rails ecosystem gets lower and lower. Even if you don’t have an idea for building your own plugin from scratch, you can find one where you’ve hit a pain point, fork the code, and then send your changes back upstream as a pull request. After a few successes with this pattern, any developer will feel more like a part of the wider community. This is a good thing that hasn’t been emphasized enough – and, in fact, it’s one of the areas where Github could use improvement. The overall process of getting a fork of some repo on to your local hard drive, synching it properly, branching, sending pull requests and (on the receiving end) dealing with the pull requests needs to be better documented, and it would be nice to see it streamlined as well. (I know, I know – if I feel pain here, I should take care of it myself. Perhaps I will.)

We also ought to recognize that git isn’t perfect for everyone. It has an excellent feature set, and it excels at what it does. But the collection-of-twenty-command-line utilities approach to building a SCM won’t click with everyone, no matter what homage we pay to the ideals of “small pieces loosely joined.” For wider scale acceptance and easier usage, we could use some better GUI front ends to git. Gitnub is a start for OS X users, and the git bundle for TextMate helps, but the state of the GUI art for git is far behind that for subversion. Some of this, I suspect, is because many Rails coders (and core Linux coders, which after all is where git originated) still have the attitude of “we don’t need no steenkin’ GUIs” and enjoy the feeling of masculine triumph over the world that they get from figuring out how to use a complex tool based on confusing documentation. I’d prefer that properly using SCM not be regarded as a rite of passage.

Finally, beware of Not Invented Here attitudes when it comes to SCM. Yes, git is great, and in many ways it’s an advance over subversion or CVS. But what do you know about other SCM and ALM systems? Have you worked with Team Foundation Server? Perforce? How about some of the big commercial ones like AccuRev or Razor? As we debate the minutiae of git vs. subversion vs. mercurial, we miss the chance to bring in innovations from outside the open source universe that could be exceedingly helpful.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Mike Gunderloy: Well, more than dabbled in – before I resolved to switch to Rails in late 2006, I had spent years working in .NET, running a successful .NET web site, writing books and articles about it, and generally making noise in that community. And I’ve lost track of the number of languages I’ve worked with over the past quarter-century, though some stand out – the careful design of VAX/VMS assembler, the elegance of Lisp, the utter pain of RPG II, and so on.

Right now I’m in an odd place as far as languages go: I’m spending much of my learning time immersed in Ruby and Rails. Now that I’ve made a reasonable contracting success with the platform, it’s time to bring my knowledge up to the next level (which is not to know everything, but to know where to find everything). So my “backpacking” is very close to home; more like a visit to the park down the street.

But I have learned a few things about this process over the years. I do think that any good developer should constantly be dabbling in new things; even if you’re not planning a career or language switch any time soon, you need to stay aware of what’s happening in the competitive landscape, lest you end up in a dead end (I knew some exceedingly successful xBase developers back in the day).

It’s tough, though, to get a really good idea of how a new language works on any but the most superficial level without a lot of experience. When I started working with Rails, I wrote a good deal of C# code in Ruby – and before that, I wrote a good deal of VB code in C#. Don’t mistake a superficial acquaintance with a language for a deep appreciation of its idioms and best practices. It’s useful to play with Haskell enough to get an idea of what functioning programming is all about, and to see if there are any patterns you can steal for your Rails work – but that’s not the same as really learning Haskell.

My own personal approach is to cast a fairly wide net of technologies that I’m interested in enough to keep an eye on, and to track a lot of things for later use; that’s part of what drives my blogging at A Fresh Cup. But I tend to not actually buckle down and learn things in depth until I have clients who are ready to pay me to do so. Consultants abhor a billable vacuum.

FiveRuns: We’ve blogged a little bit about this in the past, but do you have any experience that you can share from playing around with Phusion Passenger? What about best practices generally for deployments? What about migrations?

Mike Gunderloy: I recently switched a bunch of Rails servers (internal and client) from nginx + mongrel to Apache + Passenger. It’s been a very positive experience for me: the hit on server resources is, if anything, less than it was. But even better: the hit on my mental ability to keep track of everything is a whole lot less than it was. With nginx and mongrel I had reached the point of being able to deploy a server with reference to notes, judicious use of Google, and copying from what I’d done before. With Passenger, on the other hand, I can get a new server up and running easily by running one executable and editing a couple of files. In fact, if the resource usage were 10 or 20% higher I’d still go with Passenger, just to get away from the endless fiddly bits and mystery breakages of the previous solution.

I’m no Apache expert by any means, but there is a whole lot more Apache expertise out there than there is nginx expertise. That means that if you need to do something outside of the mainline of nginx deployment – say, adding a subdomain served by a PHP application to your Rails application – you’ll spend more time looking for answers with nginx than you will with Passenger. As someone who prefers his time as a developer to his time as a sysadmin, this strikes me as a good thing.

One of these days I’d like to figure out why it’s so hard to find freelance sysadmin contractors to complement freelance developer contractors. If I could contract this stuff out, I would. Meanwhile, I learn just enough to get by, and the benefit of Passenger is that it’s made that “just enough” smaller for me.

FiveRuns: Obie Fernandez’s company, Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. What are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Mike Gunderloy: I’m in the second or third wave of Rails developers; I haven’t 100% drunk the 37Signals Kool-Aid, I don’t necessarily think the 37Signals applications are all best-of-breed, and I think the success of Rails and “getting real” has to do with marketing as well as with superior code. I strongly suspect that folks like David Heinemeier Hansson, Obie Fernandez, and other Rails luminaries could be successful using any of a wide variety of languages, frameworks, and workflows.

Having said that (and probably completely blown any credibility I might have in the Rails community), I’ll add that the problems that interest me are not so much those of making the developers at the top of their game even more productive, as those of making sure that things work as well as they possibly can for the average developer. To some extent, Rails is a victim of its own success: the high-profile nature of the framework has caused a lot of business folk to say “I’ve got to get me some of that Rails stuff,” which in turn draws in more developers. Rails makes it easy for these developers to get started, but does it make it easy enough for them to learn how to do things well? Or are we going to see an increasing wave of C# and Java applications written in Ruby and Rails?

The blogging and mentoring that seems to be a core part of the Rails community helps a good deal in this regard. So too do some of the excellent books coming out (though we’re also starting to see some “me too” second string books, another inevitable consequence of popularity). But I’m not convinced that Rails has made the transition from being a close-knit band of top coders to being a good framework in widespread use. Yes, there is widespread use, but the Rails used by Joe Coder who is doing his first web application for the plumbing supply shop down the street is not the same Rails as used by those we all know and love from RailsConf and other high-profile venues.

What can we offer those starting (with Rails) developers in terms of getting ultra-productive? I think it’s not so much the model of 37Signals or HashRocket as it is a continued string of guidance. The fact that Rails is opinionated software is good in this regard; it makes it harder to write Rails applications that don’t work the Rails way. But it’s not enough; there is plenty of room for better documentation, better videos, more user groups, and so on. Writing the next complicated plugin as a tour de force of metaprogramming may be more fun, but if we’d like to see the community (as opposed to a relatively few developers) become supremely productive with Rails we could use a bit more concentration on the knowledge transfer side of things.

Mike Gunderloy, a former .NET developer, has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.