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

Book Review: Real World Haskell

"Real World Haskell? Isn't that an oxymoron?" I heard the question asked in one way or another many times as I lugged the book between meetings (looking for spare minutes to read it). As the authors explained in my Real World Haskell interview, Functional Programming languages generally and Haskell specifically, might have once be confined to the ivory tower but no longer. And this book is one great way to help bring the benefits of haskell to your coding projects.

I'm still not sold on Static vs. Dynamic Typing, and Ruby remains my language of choice, but I've got to say that Haskell is not nearly as intimidating as it once was. Maybe with enough intentional use it will be a tool I reach for more often without having to think about it.

Real World Haskell is a big, solid book with a lot to commend it. It's well organized, easy to read, and loaded with good examples. Best of all, it's written by long-term members of the Haskell community, so you're getting idiomatic code and well reasoned explanations by guys who have been there. The only down side is a somewhat weak index.

If you're a rubyist looking to understand more about Haskell or Functional Programming in general, this is the book for you. In fact, if you're a rubyist, you should be looking at this kind of book in general. I can't wait to see RWH reading groups start up within Ruby Brigades ... it will certainly make us better programmers.

Click here to Tweet this article

---

This post is sponsored by Cowork Utah, a member-based alternative for “cubicle adverse”solopreneurs, writers, web developers, designers and other independents who prefer working in a stimulating environment away from home. We’re free agents who collaborate while maintaining our autonomy. Specifically, our primary focus revolves around web 2.0 social media tools and strategies.