Little Known Ways to Ruby Mastery by Jay Fields

by on October 21, 2008

A weekly series from the Ruby Masters

Welcome to the next installment of the weekly interview series on the RL blog – “Path to Ruby Mastery” – by top trainers and developers in the Ruby community, from across the globe. The interview series will provide insight and commentary from these notable Ruby trainers and developers, with the goal of facilitating and providing answers to the questions Ruby beginners face. We welcome your suggestions for interviewees and questions. Look for a new post every Tuesday!

Jay Fields, USA

This week, we’re happy to have Jay Fields from USA.

Satish Talim>> Welcome, Jay and thanks for taking out time to share your thoughts. For the benefit of the readers, could you tell us something about your self?

Jay>> Hello. I’m Jay Fields. I’m an international speaker and an author of Refactoring: Ruby Edition. I am also a senior software engineer at DRW Trading. I have a passion for discovering and maturing innovative solutions. My most recent work has been in the Domain Specific Language space where I’ve delivered applications that empowered domain experts to write the business rules of the applications. I am also very interested in maturing software design through developer testing and software testing in general.

Willian Molinari, Brazil>> How should one go about learning the Ruby language? What material (books, eBooks, online tutorials etc.) would you recommend?

Jay>> Lesson 1: Pickaxe is the name we use to refer to Programming Ruby.

Homework: Go immediately to pragprog.com and purchase either the Pickaxe combo or the pdf version. Work through the book as soon as possible.

Lesson 2: You don’t have to develop exclusively in Ruby to utilize the power of Ruby. Even if your project is in another language you can use one of Ruby’s frameworks for the other tasks that your project will require.

  • Rake: Convert your project’s build file to Rake as soon as possible. Rake is an internal DSL that allows you to create a build file with minimal effort. However, Rake allows you to use the full power of Ruby at any time if your task becomes more complicated.
  • Data Migration1: Instead of keeping your database creation scripts in .sql files, give ActiveRecord Data Migrations a try. Using Data Migrations allows you to specify the structure of your database in Ruby. Also, at any time you can generate the sql files if they are needed. (Thank you Chris Stevenson for this idea).

Homework: Find a currently ugly task on your current project and replace it with a better Ruby implementation. The task doesn’t have to be something as large as the entire build file or data migration plan. Simply replacing a problematic batch file or generating a config file dynamically are great places to start.

Lesson 3: When you want to learn more about Ruby you should pair with other Rubyists. Ruby User Groups are great places to meet Rubyists. RubyGarden maintains a list of Ruby User Groups world wide.

Homework: Meet a Rubyist at your local Ruby User Group and ask them if you can pair with them on their current open source ruby contribution. When you meet, immediately insist on driving. There’s no better way to learn than being in the driver seat.

Keith Brady, Australia>> What are the pros and cons of Ruby that are being discussed in the development community and what is your opinion on that?

Jay>> I had been doing Ruby exclusively for about two and a half years, until about a month ago. Unfortunately, Ruby is no longer an option for me. These days I’m working on applications with extremely low-latency.

There’s a fairly common debate in the Ruby community as to whether the performance is good enough. For everything I was doing over the past 2.5 years, performance was good enough, but now it’s not, and I don’t have much hope that it will be anytime soon.

I think making Ruby more performant is necessary, but very hard to achieve. Ruby does what most Ruby experts need. They aren’t greatly effected by the speed. Often the people who do want improve the performance of Ruby don’t have the skills or experience to reach that goal. Obviously, this slows the maturing process.

We are moving in the right direction, but I’d love to have something right now as an option.

Another large issue with using Ruby is integration with other tools. Ruby still doesn’t play well with all popular databases, messaging systems, etc. That doesn’t effect most people, given that Ruby is primarily used for CRUD web applications. However, it’s yet another road-block for those of us who would like to use Ruby for other things.

Ruby is enterprise ready, as long as your enterprise uses a well supported database and you need a CRUD application. The story starts to get much more bleeding edge when you step outside that world.

Again, I think all this stuff will come in time.

Jerry Anning, USA>> Can you recommend things to study after learning Core Ruby, including different frameworks, gems and external libraries?

Jay>> The single most important framework to get familiar with is Rake. Even if you aren’t doing Ruby you can use Rake. It’s significantly better than Ant, NAnt or MSBuild.

Obviously, if you need a CRUD application, Rails is absolutely the place to start. Once you understand the problems Rails is solving, then you can take a look at Merb and the other less popular web frameworks.

The testing libraries are also worth getting very familiar with. test/unit and RSpec are good frameworks for testing, and Mocha is my favorite mocking framework. Once you get familiar with the mainstream testing frameworks you can look at shoulda & expectations.

I also like to start with the general/popular and then look at the niche solutions.

Satish Talim>> Most beginners in Ruby, would like to contribute their time, skills and expertise to a project but invariably are unaware of where and how to do so. Could you suggest some?

Jay>> Contributing is easy and there’s so many ways to contribute.

  • Pick an existing project that you use and create a patch for an outstanding bug.
  • Extract something interesting from your codebase and release it as open source. You don’t need millions of adopters. If you create something valuable to 20 people you’ll gain 20 people advocating your brand.
  • Be the documentation guy. Almost all open source software suffers from poor documentation. Make it your specialty. You’ll quickly make friends if you do the work others don’t feel like doing.
  • Join a mailing list for your favorite open source project and be active. Be the guy that’s always willing to help the recent adopters.

It doesn’t matter how you contribute, just get out and start contributing.

Keith Brady, Australia>> What types of applications are currently being developed in Ruby and what changes do you foresee over the next year or two?

Jay>> I haven’t done the research, but I’d be willing to bet that 95+% of the applications being developed with Ruby are web applications, with a large number of them being not much more than CRUD. I don’t really see that changing in the next year or two.

I’m not closely following Rubinius, but the things that I’ve heard don’t make me think that it’s going to change the game for Ruby. It’s definitely a step in the right direction, but not a large enough step to alter what types of applications are built with Ruby.

I have high hopes for MagLev (Gemstone Ruby), but it seems like we might be a year or so away from having anything to work with. I think MagLev could be a game changer, but until it’s more reality and less dream, it really doesn’t matter what I speculate.

Victor Goff, USA>> How do you see the market for Ruby Programmers in the work place, and do you see it as primarily tied to Rails and Web related work? Do you see trends in administration or other work? What’s the future for Ruby?

Jay>> The market for Ruby programmers is the best programmer market I’ve ever seen. I missed the dotcom bubble, and I hear it was better back then, but not by much.

Last year, a bank offered me $174k a year to do Ruby (Rails). I know independent contractors asking for $100-$150 an hour, and getting more work than they can handle.

It’s not just about the money though, the companies that are hiring Ruby developers are usually fun, forward-thinking, and agile organizations. Even if you aren’t getting paid buckets of money, chances are the work environment is a good one.

I get several emails a week about opportunities. Most sound like great places to work, though I’m always a bit skeptical about some of the start-ups. Justin Ghetland once told me to avoid any start-up work unless there’s no doubt in my mind that the idea is going to work. I think Justin’s advice is spot on. Last year I almost joined a start-up that was going to pay me quite well, and they already had customers lined up. It seemed like a good situation, but the timing ended up being problematic. In the end, I got lucky, they ran out of cash about 6 months into it. There’s just so many great jobs out there that going with a start-up right now doesn’t seem like a risk worth taking.

If I were looking for a job right now I’d be talking to Forward, Relevance, and Hashrocket. If I were just learning Ruby, I’d be reading the blogs that those guys maintain and I’d be emailing them for ideas on how to improve.

Satish Talim>> What can / should job candidates (for Ruby) do to distinguish themselves from their competition?
Note: The candidate has done his/her homework on the company that they are interviewing with. The candidate understands what they’re looking for, and the candidate is prepared to show them that he/she fits the bill, based on the candidate’s skills and experience. What else can the candidate do, to set themselves apart from other equally well-qualified and well-prepared candidates?

Jay>> There are two things that I look for in candidates these days: Communication skills and specialization in something relevant.

Programmers are terrible communicators in general. I’m not sure why programming seems to attract introverts, but it’s bad for our industry. Great software is almost always a result of significant collaboration, and I prefer to work with people who understand and embrace that fact. I’d take a good programmer with great communication skills over a great programmer with good communication skills, every time.

A long time ago someone started telling people that they should be specializing generalists (sorry, I can’t remember who to attribute there). It was good advice, but the sheep only heard “generalist”. These days there’s loads of programmers who know a bit of everything. Which is good, but they aren’t deep in anything. They keep selling the idea of knowing a little of everything as a good thing, because they are a generalist. I’m not buying.

I prefer to compose teams of true specializing generalists. For example, if I’m building a Flex front end over a RESTful Rails application, I want everyone to be familiar with Flex, Ruby, ActionScript, REST, SQL, etc. But, I also want at least one team member to be deep with each of the key elements. I’m talking seriously deep. I want them to be so deep that they annoy the team with their “too detailed” explanations of what’s going on and what needs to be done. Those guys drive innovation in their area of expertise, and the app is significantly better because of their low-level understanding.

Pick something and learn so much about it that you start to wonder if it’s really worth going any deeper. If you start learning things that no one asks you about, you might be close to your goal. As long as you are still learning things that apply on a fairly regular basis, you aren’t deep enough yet. And, pick something generally useful: REST, Ruby metaprogramming, ActionScript, Javascript, Regular Expressions, etc. You get the idea.

Satish Talim>> Do you have any other suggestions for these participants (would-be Ruby developers)?

Jay>> Read blogs. Ruby is moving too quickly for books at this point. Some books aren’t as tied to the moving pieces, such as the PickAxe or Refactoring: Ruby Edition. But, books on evolving frameworks are likely to be out of date by the time they print. You’re better off with blog entries written within the last 3 months.

Thanks for giving me the opportunity to participate. Cheers, Jay.

Satish Talim>> Thanks Jay for sharing your views with the RubyLearning participants.

On 28th Oct. we talk to Chris O’Sullivan from U.K.

Update: This blog post is also being discussed on dzone.

Disclaimer:
The opinions expressed are those of Jay Fields and do not necessarily reflect those of www.RubyLearning.com.

The Path to Ruby Mastery Series (So Far):

Post supported by Blue Box Group: Blue Box Group is in the business of providing affordable Ruby on Rails hosting solutions! They approach web hosting, virtual servers and dedicated servers differently, treating each client as a partner and working towards the common goal of success for their business. From shared Ruby on Rails hosting to giant production clusters, they have the experience, talent and equipment to make your site a success!

Technorati Tags: , , , , ,

  1. RubyLearning’s new course Ruby with Database covers Data Migration.
Posted by Satish Talim

Follow me on Twitter to communicate and stay connected

{ 5 comments… read them below or add one }

jerry anning October 21, 2008 at 6:56 am

A lot of great specific and detailed advice. There’s a reason his blog is a must-read for so many people.

Reply

Tim Andersen October 21, 2008 at 8:59 am

Great Interview!

Scott Ambler is the guy who promoted the term Generalizing Specialist.
http://www.agilemodeling.com/essays/generalizingSpecialists.htm

Reply

Fred October 21, 2008 at 1:01 pm

Overall, he has some good points, and seems to be in tune with the Ruby community. However…

“There’s just so many great jobs out there that going with a start-up right now doesn’t seem like a risk worth taking.”

What risk is he referring to here? Having to change jobs in 6 months? Isn’t everybody changing jobs (especially the “independent contractors”) fairly frequently, anyway?

“Programmers are terrible communicators in general. I’m not sure why programming seems to attract introverts, but it’s bad for our industry.”

As an introvert, I take offense at this. Introvert does not mean bad at communicating. They’re completely orthogonal attributes.

Reply

Jay Fields October 21, 2008 at 6:48 pm

Hi Fred,
I was talking about the risk that the company is going to go under versus taking a high paying job from an established company. Start-ups are a gamble, not worth taking (at this point) in my opinion. Why gamble when other companies are offering money in the bank (or at least in your paycheck).

As far as the comments about introverts, I definitely mis-spoke. Our industry (building business software) is plagued by people who are unwilling and uninterested in high collaboration. They want to collaborate through their software, instead of simpler means such as conversation. These people are terrible for our industry (side note: they may be good for other things like open source or non-business software)

Somewhere along the way, please got used to saying “what can you expect from introverts” or other phrases that blame the lack of collaboration on being introverted.

I agree with you that they are not the same thing, and one does not guarantee the other. I’m sorry I fell into the trap of asserting that they are the same thing.

Cheers, Jay

Reply

Letícia October 22, 2008 at 7:56 am

Another great interview.

@Fred: I don’t think “Programmers are terrible communicators in general. I’m not sure why programming seems to attract introverts, but it’s bad for our industry.” should be took as an offense… He just exposed a fact: programmers, mostly, are introverted.

But that’s just my opinion. =)

Reply

Leave a Comment

{ 8 trackbacks }

Previous post:

Next post: