Today's interview is with Jeremy McAnally, the author of the Humble Little Ruby Book. Jeremy, would you mind introducing yourself?
Jeremy: My name is Jeremy McAnally, and I'm a 20-something developer, designer,and author. My wife and I live in Knoxville, TN, where we are studying the Bible and Theology at Johnson Bible College. I've been programming for about 10 years now, starting with Visual Basic 3 (who didn't start that way, right?) and moving through the language web up to dynamic languages most recently. You can visit my blog (which I try to update at least once per millennium), the book's page, and my rarely used but ever present "personal" page.
How did you discover Ruby?
Jeremy: I was working on a project for my last staffed development position; it needed to take data received from fob scanners that were hooked into the serial port and behave differently depending on which scanner was scanned (e.g., some needed to were posted by doors that they needed to unlock while others needed to simply note the scan in a database). The existing version was in Java, very annoying, and impossible to maintain. I started rewriting in C#, but ran into the hurdle of a dire lack of reliable serial libraries mostly because I was using Mono rather than the "official" .NET and opening the serial port as a file was unreliable. I looked at a few languages, and then ran into Python. The dynamic language paradigm struck a chord with me, and so I looked into a language that didn't require whitespace. I love Python, but I was very frustrated by the prospect of having tabs delimiting my code. I found Ruby and toyed with it, but at the time the speed was a hindrance to actual use (i.e., having 800+ people scanning across four scanners within two to three minutes was a daily occurance; speed was essential). I settled on Python, but didn't forget Ruby. After I finished that project, I was shopping around for a PHP alternative, found Rails, and never looked back.
What role does Ruby play in your day to day work?
Jeremy: I develop Rails applications for contract clients and my college. I've developed a number of Rails applications (including some for myself) and a good deal of Ruby applications of varying complexity (all for contract clients).
Recently I've been using Ruby in the graphics design shop I work here on campus, namely using acts_as_taggable to create an image tagging database. We have thousands of images floating around, and the only way we can navigate them is the filesystem (which is very one-dimensional, and very static). I decided to create a richer interface for locating images, and Tagbit was born. I've also used Ruby to automate a number of processes down there, such as processing our yearbook mugshots and a few little other things that were mostly 5 minute hacks to save my fingers.
How have other folks reacted to having Ruby brought into the mix?
Jeremy: Great, actually. Most of them aren't tech savvy and never notice, but those that do notice are really fascinated by the syntax. "It's like I can read it!" It's neat to be able to explain what's going on and they actually understand it.
How did you come to write a book about Ruby?
Jeremy: When I learned Ruby and Rails, I had to pony up for the PragProg books at $40 each. That was expensive, especially to a struggling college student. I had been rolling around the idea of creating eBooks and using Lulu to print them, but I had never taken it seriously until I realized the potential impact of a low-price, beginner's minded Ruby book. I asked a few people about interest, received a very positive response, and began work immediately.
Why did you choose to self publish?
Jeremy: First and foremost was cost. I wanted to keep my book affordable to keep the entry barrier low for those who wanted to learn. I get frustrated when I see books (or even more appalling, Bibles) that are $40 because I know that production isn't that expensive in most cases, but then again, I also must weigh the fact that they have a full-blown staff behind that book that has edited, typeset, and designed all of it. So, I realize the reasons for the cost of traditionally published books, I just don't think they're completely necessary (especially for some projects).
Secondly, I liked the idea for a community controlled and, essentially, produced book. I e-mailed a number of people and asked what they would like to see in another Ruby book, what could I do differently? I put up a bugtracker during the "beta" stage where people could open issues and I would fix them. I proposed a number of font and cover options to development-savvy designers. Nearly every part of the book (outside of actually writing it) was a collaborative effort with someone, and that made me confident that I was producing something that people would be interested in. I couldn't do that sort of thing with a traditional publisher. Of course, I also left the security of an advance and promise of marketing, but I felt that if people were so willing to invest themselves in it, then they would probably invest a small bit of money and time to promote it also.
Another factor I considered was agility. With self-publishing, you get the luxury of being in full, flexible control of every part of the process. Obviously, this means that you can write a book on a very timely subject, such as the new features in Rails 1.2 or Ruby 2.0, and still get published (because you choose the books you publish), but it also means that you can publish these books and keep them up to date. You can't do that with a typical traditional publisher. If something changes with what you wrote on, no problem; simply update the book and it's up to date. You avoid hassles with production channels, schedules, etc. Of course, existing print copies won't be up to date, but the e-books are. And using most POD services like Lulu, future purchases of print books are up to date, too. This flexibility is a God-send if you have errata (and who doesn't?) that you want to fix. Fix the PDF, update it on the access channels, and you're done.
How do you feel about the growing competition in this free to low cost niche?
Jeremy: I say bring it! :) Really, though, I think this is the future of tech publishing for the most part. I think it's awesome to see people weighing between the community and money, and choosing the community. Even so, people are smart, and much more so than publishers give many of them credit for. People are now turning to this area, this self-published, do-it-for-the-love-of-the-language niche, and realizing that they can contribute without the approval of a publisher and without a middle man. I think it's great to see more people like Geoffrey Grosenbach and the Little Book of Ruby folks producing stuff that is top-quality, but doing it without the "help" of publishers.
Regardless of the popularity of these books, there will still be the bastions of technical writing that are the huge publishing houses with meticulously reviewed books and very shiny graphics, but I think that this low cost, grass roots produced way of doing things is much closer to the heart of the Ruby and Rails communities. The postmodern culture shift has brought about sites like Digg and Reddit, where everything is community driven; I really think that is where technical publishing in general is (and should be) drifting.
Traditional publishers seem to balance the desire to fix problems with the ability to maintain versioned editions/printing of their books. How do you plan on dealing with that, or is it a non-factor to you (and if so, why?)?
Jeremy: I really think that's not that much of a factor for me; the way I understand traditional publishing, they print books at huge quantities at a time and then serve orders and distributors from a warehouse. That's fine for them; they get faster order service and distributors can have immediate access to their books. The huge stock, though, is the biggest reason that publishers push for seldom updates and fewer editions (I believe); you have to make sure that the book you're printing is something you can sell 10,000 copies of (or whatever). Publishers need to minimize errata and problems at each printing. If they pop up, they have to wait until the next printing because they don't want to shovel out the cash to do 15-20 printings a year just to fix little things. Using POD, though, if big things or little things pop up, they can be fixed. You're afforded the flexibility to be self-published and self-sufficient, which is essential since most of us don't have a full editorial staff and typesetting department in our garage.
Of course, I also see the merit in saying, "Well that was a problem in the first edition, but the second edition fixed that" or "That information was added in version 2." It keeps some sanity in trying to deal with an error here and an update there, but I think that in general, most books don't have enough errors or updates (without a significantly huge update such as from Rails pre-1.0 to Rails 1.2) to really warrant that sort of structure. I plan on setting up a place with errors and when they were fixed very soon (I've only had one be pointed out to me, thankfully, but surely there are more). The biggest reason I see is the money, time, and effort, and it's a very understandable concern for them.
What sets your book apart, why should people buy it?
Jeremy: I wrote my book with Kernighan & Ritchie in mind: be concise, get the idea across, and explain concepts. In covering the language, I covered only what was necessary and left the syntactic wizardry to the blogs and reference manuals. I tried to cover libraries that I found to be adaptable; that is, libraries that I thought once you learn these, you can build a lot of applications that use them. I avoided providing too much in that regard, given that there are websites such as http://www.rubymanual.org/ and http://www.ruby-doc.org/ that essential serve that sole purpose. In laying everything out, I've tried my best to have every chapter cover only the essentials and continue to build on the previous chapter, which builds on the one before it, and the one before it, and so on. I spent probably the first month thinking about and laying out all of the pedagogics of the book before I even wrote a single word, so I hope people find it to be a very refined, very intuitive learning experience.
I want to provide something that the community can fall back on when the PickAxe is out of someone's range, whether in comprehension or price. I don't think I necessarily compete with the PickAxe; they're two different volumes, with two different targets, and two different voices. They're targeting more of a reference manual seeking seasoned developer who has every printing of the Perl Cookbook on his shelf simply because he liked to pick out the errata. On the other hand, I see myself as targeting the person who knows a little about programming maybe but might be weak in some other areas. I'm targeting the guy who just doesn't get object orientation right out of the box and needs just a bit more more coddling. I also target those who already know how to program, but my primary audience is those who don't or have never programmed in a dynamic language before. I try to spend at least a little bit of time explaining concepts behind what is going on, something I feel is lost in some of today's technical writing.
Lastly, I tried to make my book fun. A lot of people mistake my writing style for _why's (and I do kind of see the similarity), but I've been writing "like that" for a long time, long before I even encountered Ruby. My apologies to the conspiracy theorist who accused me of actually being _why.
Now, back to the style. I love _why's book. A lot. I used to sleep with the first page of it tucked under my pillow, hoping that some of its delicious knowledge would seep into my brain. I learned a lot from it when I first starting picking up on Ruby. But a lot of what I heard when I initially asked about writing this book is that his book is _too_ fun, that there's _too_ much chunky bacon (like that's even possible), and people wanted to see a "middle ground." So, I've tried my best to strike a good signal vs. noise ratio in being fun while also being informative.
So, if you're looking for a concise, well-paced book with a fun feel that resembles a fiesta at dawn featuring Ricky Martin, Ricky Ricardo, and Ricky Scaggs, then buy it. If you're looking for a bean burrito, then go to Taco Bell.
I love the anachronistic 'feel' of the book (I wonder whether I could bind a copy in a slightly ratty hardcover like you'd find in a thrift store).
Jeremy: Haha, that would be awesome. I think I might try that when I get my copy.
How and why did you settle on it?
Jeremy: Well, I knew that I wanted something that wasn't your typical tech book. I slapped a centered image on there will some plain text and looked at it and decided it didn't fit with me and definitely didn't fit with the text. I wanted something that created some visual and mental tension to make it interesting and set apart. Who learns to program from a book that looks like it came from the 1600's? So I put together a few typesetting comps and started showing them to people. People really liked the "OldStyle" font that I picked initially, but I found it to be pretty hard to read at the text size, so I changed it to Lido. Lido is a great font because it's readable and bold without being too generic and too "in your face." It's a good balance.
You mentioned the cover design was a collaborative work, can you tell us the story of how it came to be?
Jeremy: Sure. I came up with the idea to do something "old" as I mentioned above. I threw together something really quick from some medieval woodcarvings and other various medieval images that I found in a stock library and some I scanned from old theology books we have in our library. I liked it OK, but I decided that maybe I wanted something a little "prettier." Tan and black aren't 'pretty' (even though I do plan to use that cover for the final binding of the Ruby AND Rails book, but for this one I wanted something different). So, I made a few concepts and posted them to various forums and lists and let people give me input. As people gave me input and ideas, the concept started taking its own shape. "What about how old biology diagrams kind of have those 'tag' things that come in from the side?" "Paisley is an old looking pattern...that's my favorite classical pattern." "Use an older looking set of Garamond fonts to get a better effect." As we tweaked it together, it finally took shape into its current form. It turned into something that was built by a great number of people together with me.
If a publisher were to approach you to do a 2nd edition of your Humble Little Ruby book, would you do it? What do you think are the tradeoffs that would affect your choice?
Jeremy: The financial security would be great; I put my wife and I through a great deal of financial duress during the writing of this book. I actually only worked half-day during the summer, which put us in a tight spot. Now that the book is out and selling, it's been slightly easier, but it's never easy when you're both in college and you have bills.
It would also be nice to actually let an editorial team go to work on the text. I always freak out that I've made a bunch of errors, so having someone finally make that decision would be a great comfort. :)
Of course, the notoriety and resume fodder would be a great benefit. Being young with no degree but having experience hasn't gotten me far (at least in the jobs I've been able to apply for); having a book credit under my belt with a publisher would make it tempting.
But even with all of that, I would never give this book over to a publisher. I want this to be something for the community, and I feel like most publishers would take that away.
What other books are you reading right now?
Jeremy: Nothing Ruby related right now, I'm sad to say. I can't really afford them new, and my local used book store hasn't stocked any Ruby books for a long, long time. I just finished Ender's Game, which I read in 2 days, and I've about finished Speaker for the Dead (which I started yesterday). I'm not sure why, but I'm on this strange sci-fi kick now; I haven't read sci-fi since middle school. Now I'm reading Speaker for the Dead, Foundation, and I, Robot. I'm also reading some interesting books on Paul's epistles and re-reading Donald Miller's book on Christian spirituality, Blue Like Jazz.
Since you're studying the Bible, what verse(s) have impacted you the most as a developer, designer, writer?
Jeremy: Man, that's a tough question. Always on my mind is 2 Thessalonians 3:10: "For even when we were with you, we gave you this rule: 'If a man will not work, he shall not eat.'" ;)
All joking aside, I think that the most impacting is probably Romans 12. It talks about being a living sacrifice, and giving your whole being and life as worship to God. That permeates everything I do; I feel like Moses, "God, I can't do anything!" But somehow, God makes it happen.
This verse also reminds me to be humble, no matter how much praise I receive or how great I am. My work is merely a piece of the body of Christ, moving in unison for him; I'm no better than another Christian who writes or one who can't. We're all the same in His eyes.
What are your favorite five Ruby libraries?
Jeremy: I think Rails is a given, so I'll name five others. My most recent toys have been a few linguistic libraries, the newly released text and the Ruby Linguistics Framework. Both are really nice; I'm a bit of a linguaphile, so this is pretty cool.
In that same line, I just picked up rparsec this week and played with it. I want to do some interesting stuff there...maybe next summer when I really have time to build something of use. ;)
RMagick is quickly becoming one of my favorites; it's much more intuitive than many of the GDI+ functions I'm used to from C#. I'm interested to see what I can do with it when used with one of the GUI frameworks.
Ruva, the pure Ruby JVM, knocked my socks off the other day. It's not something I'll really _use_, but it's something that has been teaching me a good bit about how to construct a simple VM. My lack of formal CS education cripples me at times such as this year's ICFP competition. It's really cool to see people pushing the limits of the language, breaking out of the box, and doing something totally off the wall but still beneficial.
Lastly is probably _why's sandbox. I love that thing. I've been using it on a new project I'm working that is supposed to help people learn Ruby better; I'm integrating it in as part of the course software.
What's next for you?
Jeremy: Right now I've got a bunch of projects competing for attention; we'll see which one comes out on top. First, I'm writing the Humble Little Rails Book of course. Next in line is a book about the other Ruby and Rails "stuff" that no one really thinks about when learning the language, like testing, deployment, metaprogramming, etc. It will be targeted at people who know the language, but may not understand why this other stuff is important.
I'm also working on the above mentioned Ruby learning project; I'm developing a college-targeted Ruby course with illustrated workbooks, course software (which may be driven by a Rails site...not sure yet), and lesson by lesson coursework. It will be based off the Humble Little Ruby Book, but more "academic."
What do you think is next for Ruby?
Jeremy: I'm very interested to see where it goes in the enterprise. People have been sort of flirting with dynamic languages for a while now, and I think that things like Rails are pushing it even further into the mainstream. Hopefully we'll hear about a Ruby-solution soon, but I don't think that will happen until we 1) get a definitive learning course down and certification program, 2) teach people the power of dynamism as opposed to static languages (metaprogramming, flexibility, and so on), and 3) be patient. :) I think things like this take time; look at how C++ and then Java took over. Their rise to power was slow and hard fought against the onslaught of COBOL, FORTRAN, and C zealots. I think we are at a tipping point, but we just have to be patient and see if the world takes to Ruby like we have.
I think Ruby can also be used in other areas, such as embedded scripting. Python has been used this way in a number of areas, but I think that Ruby would be better suited in places where people's technical knowledge is almost guaranteed to be weak. Ruby's syntax is a bit easier to grasp than Python, so I think in areas like scripting graphics design applications, office applications, you could use Ruby to get the power of a decent language (rather than a crappy BASIC variant) but still have something that's usable and very teachable.
I think the language itself is about as beautiful and elegant as you can make it, but then again, I look at the upcoming changes in 1.9 and it makes me drool. I always hated the verbosity of C# and PHP, so to have a language that wants nothing but to be usable and elegant is a God-send.
Technorati tags:
Ruby
interviews
. Sadly, I hit my seat on the plane and fell asleep before we got off the ground. The review will have to wait, but you don't need to ... It's a great book, you should go buy a copy now. (If you're at RubyConf, I think Hal brought some copies to sell.) You can even read a 