RubyNation Mini-Interview: Hal Fulton

RubyNation (June 11-13 in Reston, VA) is coming up pretty quickly, and I've started a series of mini-interviews with speakers and organizers there to help people get a feel for what RubyNation is going to be like.

If you're interested in getting more that this little taste, I'd recommend that you go register soon. I don't think the seats are going to last long.

My first interview is with Hal Fulton (@hal_fulton). Hal's been involved in the Ruby world for a long time. He's the author of The Ruby Way. Hal currently does Ruby work for Collective Media.

---

What makes regional Ruby conferences special?

Hal For one thing, a regional conference always puts its own spin on the whole event. It's organized by local people and tailored to their own personality and environment, so it has a different flavor from the international conference.

Second, you get to meet people and hear talks that you wouldn't otherwise. A lot of these people have never made it to the "big" conference. It's great to realize that there are numerous Rubyists out there who are interesting, creative, and competent -- and you may never have heard their names before.

What makes RubyNation stand out as a regional Ruby conference?

Hal I've met several people from the area, and I think it's a definite hotspot of programming talent.

Additionally, the area itself holds a certain fascination for me -- the land of Thomas Jefferson, very near the nation's capital. I am a bit of a Jefferson fan, and in spite of everything I've always liked DC -- I was a page in the House when I was sixteen.

Other than your own talk, what are you most interested in seeing at RubyNation this year?

Hal I look forward to them all, in particular David Alan Black's talk on Ruby 1.9 -- David is an old friend, very competent and knowledgeable, and one of the earliest adopters of Ruby in the US. And of course we all have things we haven't learned about 1.9 yet, or at least things that haven't sunk in and become instinctive.

I'm not a Rails person, nor a web person in general. That said, I do look forward to Yehuda's talk -- I think Rack is a small masterpiece, and we can learn from it. Also David Keener's talk on RESTful web services catches my eye.

Your talk is on Reia, a Ruby-like language implemented on the Erlang VM. What attracted you to this language?

Hal I've played with Erlang a little, and I've seen its power. I've also seen its diffficult syntax and its overall paradigm which is (to many) bizarre and "inside out."

Reia seems like a very interesting compromise -- much of the "under the hood" power of Erlang blended with the expressiveness and flexibility of Ruby.

I think as we move closer to "real concurrency," these kinds of techniques will lead to a big leap forward in the way we write software.

What kinds of things are you using Reia for?

I'm not "using" it yet, and I'm not sure anyone is really. Let's say I'm very intrigued by its potential, and I'm studying it and playing with it.

Are there other Ruby or Ruby-like implementations that you've got your eye on?

Hal I try to keep "some" watch on all of them -- unsuccessfully of course.

For me, Matz's implementation is still "the" Ruby and will be for the foreseeable future.

But I'm also very interested in Rubinius. I haven't really touched it yet, but I do want to if I can find the time.

I haven't played with JRuby really, but I'm glad it's out there as an option. It's an important project.

Also Dave Thomas has some brilliant ideas for experimental variants of Ruby. I'd love to see some of those implemented, even if only as proofs of concept.

Click here to Tweet this article

Author Interview - The Well-Grounded Rubyist

Now that Manning has released The Well-Grounded Rubyist by David A. Black, I wanted to sit down with him and talk a bit about his new book.

His Ruby for Rails set an awfully high bar as the book that really explained Ruby to Rails users (and everyone else). The current title has been called a "reworking" of the former to remove the Rails bias.

Hopefully this interview will whet your appetite for David's new book.

---

Ruby For Rails has been one of my favorite Ruby books since it came out. I'm really excited that The Well-Grounded Rubyist is coming out in a matter of weeks. What do you think is the best thing about your new book?

David The title! Well, not really, but I do love the title, if I say so myself. (In case anyone's wondering: I did take inspiration from "The Well-Tempered Clavier".)

As for the material and the content: I have always found it gratifying when readers single me out as someone who can explain things clearly and in depth, and I believe TWGR delivers in that area pretty much throughout. I spent thirteen years as a full-time teacher, and I've been writing all my life. I love helping people understand things, and that's what I've worked most diligently at doing in this book.

You call your new book a repurposing of Ruby For Rails. How do you approach Ruby differently when writing for a Ruby developer rather than a Rails developer?

David To a large extent it's a question of the topic coverage. TWGR maintains, I think, very much the same "voice" as R4R, and addresses the reader at the same level. But the topic coverage has changed a lot — and not just because Rails has been taken out. There's material in TWGR on threads, sockets, sets, encoding, enumerators, and more, none of which were in R4R, and greatly expanded coverage of other built-in functionality include file I/O, ranges, system command invocation, and others.

Selecting topics was a big part of writing R4R, since the whole point was to write a Ruby book that was "optimized" for a certain readership. And as I started thinking about TWGR, I realized that careful, creative topic selection was important for a "just Ruby" book too. I wasn't setting out to write a complete language reference, so the process of deciding what to include loomed large.

You take a pretty different approach to explaining Ruby than most other authors/speakers. What do you think makes your approach work so well?

David Typically, introductions to class-based object-oriented languages, including Ruby, start by talking about classes, and then bring objects into the picture as instances of classes. I look at it the other way around. The object is the fundamental unit of meaning in Ruby, so why not start with that?

Furthermore, I like to put object dynamism on the radar very early — the fact that objects are not constrained to the abilities they derive from their class but can take on behaviors of their own. Of course most Ruby developers don't spend their days writing

 def dog.bark

and such. But I do believe that if you learn about objects and their life-cycle first, and then look at classes as a kind of convenience macro for spawning objects, your knowledge of Ruby will build smoothly from there, and you won't think that object-specific behavior is a blemish.

A lot of publishers are opening up the book writing process these days. How much did Manning's MEAP affect your book?

David I'll do a bit of soul-searching here, if I may. I'm a very territorial writer. I don't like the idea of leaving a paper trail showing what I later decided to change or fix or improve; I think of writing as a basically closed-door artistic process, and just as I don't want people listening in while I'm practicing the cello, my instincts run strongly against releasing unfinished written work.

I have, nonetheless, tried to get into the spirit of the open-process era, because I think it's been proven effective for technical writing and because I know that a lot of my territoriality comes from my temperament rather than from concern about the final product. Besides, even without the MEAP, the manuscript is sent out to a body of twelve or fifteen outside reviewers at three points along the way — so the "closed door" isn't all that closed anyway!

So I've participated in the MEAP, probably not plunging into it as fully as some authors do but trying to meet it at least halfway, even if it means leaving (or, perhaps, expanding) my own comfort zone. I think the book has benefited from it.

So far, you've had your hand in books, videos, conferences, and training. What does the future hold for you?

David Don't forget programming :-) As for the future: I've started working on a book for the Pragmatic Bookshelf, entitled "Rails Choices". It's a guide to how to think about and make sense of the many possible choices (and it's an increasing number, as we get toward Rails 3) that face developers and project managers when they're starting a Rails project: everything from which version of Ruby to use to which templating system to which session storage mechanism. I'm not going to try to cover every possible choice; I'm sticking to the out-of-the-box defaults plus a select handful of proven, popular alternatives. I want to get beyond the personal preference level, and help people examine the needs and priorities of their specific projects, and make choices based on that.

In general, I'm finding my multi-faceted Ruby-oriented life very rewarding and enjoyable, and I'm hoping for more of the same.

A lot has changed in the Ruby world since R4R, which of those changes are you most happy about?

David I'm happy about the fact that Ruby is in much wider and more prolific use, and that we have so many books and events. (I don't think any other language has as vibrant a world-wide conference culture as Ruby.) It's also great to see that the "What's this 'Ruby' thing?" syndrome among Rails developers has dwindled; just about everyone seems to understand from the outset how Ruby and Rails related to each other (and if R4R helped bring that about, I'm delighted).

I'm excited about the new Ruby implementations — JRuby, Rubinius, and others — and the coming-of-age of Ruby 1.9. As everyone knows who's followed along, the path to 1.9 has not always been smooth, but 1.9.1 is stable (that's the version the book addresses) and as I've delved into it more and more deeply, I've been more and more impressed by it.

Which ones impacted The Well-Grounded Rubyist the most?

David I choose:
(e) All of the above!

It's true actually. The wider adoption of Ruby is largely responsible for my enthusiasm about writing the book. The way the Rails world has come to terms with Ruby, to the mutual benefit of both, made me realize that a general Ruby book could also be "for Rails", in the sense that many Rails developers are eager to learn as much about Ruby as they can, whether every bit of it pertains directly to the bulk of their Rails work or not. The new Ruby implementations don't enter into the book directly, but it's hard not to feel inspired by that work, and many discussions surrounding implementations have touched on topics in ways that have probably affected TWGR.

And Ruby 1.9 — that's the main event, the major impetus for writing the book. It's been hard, because things have been changing a lot. Sometimes I'd write an example and then discover a few weeks later that the wording of some error message had been altered, or that something had shifted in the core class hierarchy. (I'm thinking specifically of Enumerable::Enumerator becoming just Enumerator.) It's been a moving target at times; but all the more thrilling is it for the book's timing to be such that it can address a stable 1.9 version while there's still a lot to learn and a lot of excitement.

What do you see happening in the Ruby world over the next year or so?

David Very hard to say — which is probably good, since it keeps it interesting. I think that Ruby 1.9 will achieve a lot more penetration. And we're seeing a lot more Ruby implementations, some based on the Matz code and some not. I don't just mean JRuby and Rubinius, but MacRuby, Ruby Enterprise Edition, MagLev, and others. I suspect we'll start seeing specialized subsets and forks of Ruby that aren't necessarily compatible but that are "Rubies", the way different LISP dialects are "LISPs". I think Diamondback Ruby is in that category, though I haven't looked at it closely.

In any case — here's hoping we have many more years of Ruby practice, experimentation, collegiality, and productivity. It's certainly been fun so far!

Click here to Tweet this article

Ruby Best Practices: mini-interview 3

Gregory Brown (@seacreature) recently announced two things: 1) that he's content-complete with his Ruby Best Practices book, and 2) that he's started a Ruby Best Practices Blog. Between the two, it seemed like a great time to run a third interview (you can read the first and second to catch up if you'd like).

If you're anxious to get your hands on the book (which is due to be released in June, you can always grab the shortcut straight from O'Reilly.

---

Now that you've finished the text of Ruby Best Practices what's left before we see the book hit the shelves?

Gregory Not too much on my end, which means I can come up for air a bit. We've already gone through the copyedit review, which went super smooth thanks to Nancy Kotary (@nancykotary).

So now, all that's left to do is wait for production to do all the magic that's necessary to make my manuscript into a book, and then I'll need to take a couple passes through to catch any last minute problems before the book goes off to print in June.

We will also be sneaking in a foreword at some point from a special guest, but I'm not revealing who it is just yet. The book needs some mystery, afterall.

Any time you're writing a book, you deal with constraints about what to put into it. What would you have written (more) about if you had more time/space?

Gregory With this book, I was really aggressive about making cuts. Readers will find it has a very specific 'feel' to it, and this was quite intentional. There were a lot of topics that were really valuable that I ended up avoiding because I couldn't find where to place them in the book. Basically, if I could not find enough real world examples that were clear enough to be covered in the space of a chapter while remaining non-trivial, the content didn't get written.

If I had more time, I could have probably managed to keep the performance chapter that we cut. We ran into some issues there with libraries such as ruby-prof not running on Ruby 1.9 and a lack of research material as to how to optimize code for YARV. I guess I'm not alone in building up a lot of assumptions about how to optimize Ruby based on my experience with MRI and Ruby 1.8.6, and not all of that translates directly to Ruby 1.9.1.

For almost every chapter in the book, there were extra sections I would have added. I had to cut it down to the essentials though, because I feared that 60 page chapters would anger my editor. :)

How will the new Ruby Best Practices Blog allow you to build on the foundation that the book lays?

Gregory The book doesn't really lay down a foundation, since its topics are fairly diverse. Instead, it gives you a number of different lenses to look at Ruby development through. When you combine them together, they work to fulfill the common goal of writing better code. However, as one person, the number of different vantage points I can offer are limited, even with help and suggestions from my friends.

The Ruby Best Practices blog is meant to continue this idea along, but open it a bit wider so that the necessary diversity is preserved moving forward. I'm convinced that the group I've put together will do a great job of this. As near as I can tell, best practices and idioms tend to emerge from open discussion about real problems, evolving over time as the technology and the challenges themselves change. In this sense, the RBP Blog is a logical continuation of the work I did on the book, and I'm really hoping the two can be complimentary to one another.

Any chance of seeing some of the material you cut from the book on the RBP blog?

Gregory This is a definite possibility. Unfortunately, I am a terrible historian and actually just deleted large chunks of the book when they didn't fit. That means that while the topics I cut from the book might be covered on the blog, it'll likely be new content. But I also want the blog to have a life of its own, so maybe I'll just start fresh with my posts. Time will tell.

I love the section 'Capturing the Essence of a Defect' in chapter 6. In the Perl world, there's a tool called Delta to automate some of this, but it seems like building a tool on top of the AST would be better than delta's text munging approach. How many debugging/refactoring/code analysis best practices do you think are automatable? What do we lose by automating them?

Gregory Honestly, I have no idea. It's probably not the most geek-friendly answer, and not even something I'd recommend in my book, but I very much work by intuition when debugging. I'd definitely give code analysis tools a try if they were out there, but honestly, if I really need a tool for refactoring or debugging, my code might be excessively complicated to begin with.

This isn't to say that I try to stick to simple projects or that I think I have a Herculean ability to keep all these details in my head. Neither would be true. In my current work, I'm developing a fairly massive Rails based ERP system for a food distributor. It's really a huge problem space, with all sorts of complex challenges both at the technical and business level. Maybe over time, some code analysis tools might make our life easier, but for now we're attaining simplicity the old fashioned way. By splitting up the project into various single-purpose applications that have decent test coverage and clean code, we can still rely on intuition somewhat when working through problems. The only really tricky bit is managing the interactions between systems, and maybe that's a place where some analysis tools might be helpful.

The real danger I see with using automated tools for debugging, refactoring, and code analysis is that you can become too dependent on them. This may encourage you to manage complexity rather than reduce it, and in my opinion, that's treating the symptom and not the disease.

I'm also happy to see a chapter devoted to Functional Programming with Ruby. Is a chapter enough, or should Rubyists be looking for 'Higher Order Ruby' or playing with Haskell/Scheme/OCaml?

Gregory Much of this chapter was sourced from James Gray's Higher Order Ruby blog series, which I can't recommend enough. To be fair though, the chapter is less about functional programming than it is about writing Ruby code that's inspired by functional programming techniques. Ruby is not a great functional programming language, and no amount of parenthesis will change that. However, the higher level concepts are valuable, without a doubt.

For those who wish for a more intense experience, you might want to dabble in Haskell and maybe some Erlang. I'm not very experienced with either language, but even a couple weekends of hacking in a functional language can expose you to a lot of interesting concepts that you can bring back to Ruby with you. While a direct translation will surely lead to disaster, some indirect inspiration can go a long way.

But of course, the real reason why I covered functional programming in this book is because it's a lot of fun. That's my best reason for why people should learn more about it. :)

You've been in the Ruby community for a long time, and have even been involved in some efforts to 'bring back the good old days'. What changes in the Ruby community do you enjoy/appreciate? Which changes would you like to revert?

Gregory Personally, I think it's about time we stop asking this question. That may sound like a bit of a surprise coming from me, but it is really how I feel. I've learned over the years that what matters to me most is to solve interesting problems in an elegant way while remaining in contact with bright and fascinating people. Despite all the hype, anti-hype, and anti-hype-hype, none of these things that matter to me have changed.

If we work hard, manage to be kind to one another, and share with each other, we'll have a good community experience. Nowadays, I think you'll find the old-school spirit alive and well at regional conferences, in various Ruby-based open source projects, and on the mailing lists of local Ruby users groups. With this in mind, it doesn't matter so much to me what the global state of the Ruby community is like.

One thing we did lose the ability to drink from the firehose and know everything that was going on. However, that opportunity is still available at the ground floor of a number of languages that are only on the horizon of mainstream acceptance, or off the radar entirely. I'd recommend some, but that'd sort of defeat the point, huh?

So far, you've been a GSoC student and a Mentor, the Ruby Mendicant, and now you've written your second Ruby book. What's next for you?

Gregory I'm not sure how many people know this, but I'm only 23 years old. Since about 2004, I've been more-or-less dedicating my life to Ruby. It's been a blast, but it also feels like it has isolated me a bit from the outside world. So, next on my agenda is to find a reasonable work-life balance that will be sustainable moving forward. I want to spend more times with my friends and family, and my girlfriend Jia, who I plan to marry sometime soon. In short, I want my geek hat to be one I can happily wear when I want, but hang up when I'm feeling tired.

But that doesn't mean I'll disappear. The book and new blog will need to be promoted, and my projects need to be maintained. I'm hoping to see a Prawn 1.0 by the end of the summer, which I'm sure would make a lot of people happy. I'm also going to be talking at GoRuCo this year, which I'm really looking forward to. Beyond that, I guess we'll see what happens.

Click here to Tweet this article

Lone Star Ruby Conf 2009: an Interview with Jim Freeze

With Jim Freeze' recent Lone Star Ruby Conf (@lsrc) Call For Speakers, I decided to run a quick interview with him. Jim's been a big part of the Ruby community for a long time, and LSRC seems to be one of those great regional conferences that's helping drive Ruby at the local level.

---

What motivated you to organize a regional Ruby conference?

Jim We talked about it for years, and finally one day at a Ruby lunch, we decided we were just going to do it. The scariest part was taking the financial risk. At the time we didn't know if we could get 30 people to attend. We ended up getting over 200.

Who else is/has been involved in organizing LSRC?

Jim There are quite a few individuals who have contributed significantly to the success of LSRC. I hate to mention anyone for fear of forgetting key individuals. Formally, we organized Lone Star Ruby Foundation, a non profit 501(c)(3) corporation to handle the finances of the conference. I am the President, Gerald Bailey and Mark Mims are also board members. Gerald took the place of David Bluestein last year and was, in essence, a co-coordinator.

Others who have help significantly are Mars Hall, Wayne Walker, Taylor Carpenter, Sarah Brumfield, Ben Brumfield, Alan Whitaker (and other LMP members). I know there are others, but these come to mind for helping with key logistics.

We've also had some great keynote and invited speakers. And I recognize that they have also spent their time and energy to help support our conference.

Who's the target audience for Lone Star Ruby Conf? How are you reaching out to them?

Jim Our target audience is anyone interested in Ruby. To contact people we still use email mostly, my out of date website and twitter. Others, like Damon, have been good about getting us posted on various news boards and such.

It seems like the regional Ruby conference field is getting congested. What's your take on things?

Jim Yes it does. I'm am also surprised this year that, with the economy situation, that conferences have been selling out. That tells me that Ruby is growing!

A lot of regional Ruby conference organizers tout something unique about their conference. What makes the Lone Star Ruby Conf special?

Jim We're the best! And we're in Texas! :)

Just kidding. I don't really know that we have focused on just one thing. We try to make the whole conference as good as possible. This will be our third year at the same conference center, so we keep ironing out little problems and improving them. This year, our last two major bugs to iron out are chairs and wifi. We'll be bringing in more comfortable chairs and adding more wifi points.

And while I think we have good talks, we also realize that it's the people that make the conference. We try to have a relaxed atmosphere, where people are free to socialize or code, as they see fit. And we are pretty lax with our sponsors. We like for them to be a part of the show as much as they want to be. I think employment is a good thing and like to promote the interaction between hiring parties and those that want to be hired.

My basic philosophy is to treat LSRC like a cruise — over scheduled and over fed. You don't have to attend everything, but there is plenty to do and plenty to eat. And we have had many good compliments on the food. When you consider that the conference ticket includes all meals and snacks, it turns out to be a pretty good deal.

You've had a couple of great conferences the last two years. What are your favorite conference memories?

Jim My favorite conference memories are that it didn't bomb. I'm usually too tired and doing too many things during the conference. However, I did just watch the panel discussion from last year (thank you confreaks) and it brought back some good memories. It was a great panel, but it was at the end of the conference and I think alot of people were very tired. Only the truly devoted were remaining.

One good memory we had was last year before the conference. Matz came in early and we had a chance to show him around. Took him shopping at a Western store and took as Segway tour of Austin. It was a blast riding on the Segways and hanging out with Matz.

It's one little perk that we get as conference organizers.

If someone wants to get a regional conference started, what advice would you give them?

Jim Don't....but if you insist:

• Be prepared for a lot of work.
• Start with Chad Fowler's list of things to prepare for a conference.
• Join the Regional Ruby Conference Oraganizers Google group.
• Get some volunteers.
• Have a lot of fun.

---

Click here to Tweet this article

Book Review: Beautiful Architecture

I've been reading O'Reilly's Beautiful Architecture lately. While I'm not as sold on it as editor Diomidis Spinellis earlier book, Code Reading[1], it's still a keeper.

Spinellis and his co-editor Georgios Gousios have done a good job of selecting interesting essayists and of putting their works together into a collection that feels solid. Reading it will certainly make you think more about your own project's architecture.

In the Preface, the editors put forward a collections of Principles, Properties, and Structures for architecture. These would be a great way to index the contents of the book. Chapters 3-12 (covering Enterprise, Systems, and End User Applications) each begin with a table showing which of these principles, properties, and collections they touch on. Sadly, that's the extent of use to which they're put. I would have loved to have an appendix with a guide to which sections of which essays I could go to for more detail on 'Entropy Resistance', 'Buildability', or 'Dependency'.

Like most anthologies it has some chapters that different people will like or not. To me, some of the real winners are: Peter Goodliffe's "A Tale of Two Systems", Jim Blandy's "GNU EMACS", Till Adam and Mirko Boehm's "When the Bazaar Sets Out to Build Cathedrals". There's also plenty of meat for the OS or Enterprise level if that's where you'd rather read. Which chapters stood out to you?

Whether it's something you're building on the weekends or on the job, Beautiful Architecture will certainly do your code base good.

1 I wrote about Code Reading in my blog post Three More Good Books a while ago.

Click here to Tweet this article