RubyLearning Blog

Little Known Ways to Ruby Mastery by Josh Susser

by Satish Talim on January 6, 2009 · 3 comments

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!

Josh Susser, USA

This week, we’re happy to have Josh Susser from USA.

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

Josh>> I’ve been doing object-oriented programming since the mid-80s, back when hardly anyone had heard the term let alone understood what it was. I’ve worked on a wide range of object technologies, from Smalltalk applications and virtual machine code to distributed component systems to defining Sun’s JavaCard virtual machine. Now I’m a senior developer at Pivotal Labs, one of the premiere Rails consulting shops and a seriously awesome place to work. I’m probably best known in the Ruby community for my blog, has_many :through and the occasional conference presentation.

I almost started using Ruby in 2002, but I couldn’t find much documentation for it on short notice so I ended up doing the project with a combination of Perl and PHP instead. It took until 2005 for me, to really discover Ruby and what it was about. Like so many, I finally came to Ruby because of Rails, and then kicked myself I hadn’t started using it earlier. I found Ruby very easy to pick up; I had done Smalltalk development for years and some functional stuff here and there, so the basics of the language felt very familiar. But don’t worry if you don’t have that kind of background; Ruby is a very accessible language for anyone willing to make the effort.

Dennis Theisen, Germany>> Could you name three features of Ruby that you like the most, as compared to other languages? Why?

Josh>> First off, Ruby is fully object-oriented, as opposed to Java, C++ and Objective-C which are hybrid languages. In hybrid languages programs can create data values that aren’t objects but are some other kind of primitive data type. But in Ruby, every data value you can name is a first-class object. This makes programs more consistent and gives you smaller code since you can use polymorphism everywhere.

Next, Ruby is dynamically typed, also known as “duck typed”, as opposed to being statically typed. This doesn’t mean Ruby is not strongly typed. It just means that types are enforced at runtime dynamically (via dynamic binding and method lookup) rather than by the compiler. Java on the other hand is statically typed, which is great if you want to be able to prove your programs are correct, but nearly useless in most real-world programming. It just means you spend a lot of time making the compiler happy instead of getting your features working.

Finally, Ruby has a rich set of control structures and exception handling. The designers of Smalltalk decided that all control structures must be expressed as message sends. This made for very ugly if-then-else (actually ifTrue:ifFalse:) chains, and no one has ever managed to create a useful case statement. Matz rejected this ideological extremism to include special syntax for a number of control structures. As a result the code is smaller and much easier to understand. This is a big part of why I like Ruby better than Smalltalk.

Willian Molinari, Brazil>> What has been your biggest challenge while working with Ruby?

Josh>> As much as I like TextMate, I’m frustrated by the lack of a really good IDE for Ruby. There have been some decent attempts to integrate Ruby into products like IntelliJ and NetBeans, but so far nothing has even reached the point where Smalltalk was 20 years ago. Some of that is due to the extreme dynamism of the Ruby language, and how meta-programmable it is. But whatever the cause, I think we should be able to do better.

The other challenging thing about Ruby is that it doesn’t have a major corporate sponsor. Engine Yard, bless their hacker hearts, are doing as much as they can to support Ruby and its ecosystem. But languages like PHP and Python didn’t really become successful until they got a corporate sponsor who could afford to support development of the language and system libraries. It’s a testament to Ruby that it’s come so far without a Yahoo or Google to throw a lot of money and people at it. But that still leaves Ruby with some rough spots that are going to need to be smoothed over before it can live up to its potential.

Jerry Anning, USA>> What best practices are most important for a new Ruby programmer to learn and understand?

Josh>> I’m a big fan of XP so I’d generally encourage developers to adopt those practices. But specifically, TDD (Test Driven Development) is important for Ruby development. Ruby is a dynamically typed language, which means you don’t have a compiler to help you find type errors. In practice, type errors aren’t all that common, but if you want to be able to have confidence that your code is doing what you expect, TDD is the best way to get there. One of the great things about Ruby development is the ease of doing TDD. There are a number of mature and well-supported test frameworks to choose among, and good integration with the popular IDEs and code editors.

Pair programming is also a good practice to adopt, especially when learning a new language. If you can find a mentor to pair with that’s great, but pairing with someone who is also learning Ruby is a good way to go too.

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

Josh>> This question seems to be based on the assumption that you can go off and learn the Ruby language, then some add-ons, then do something with it. I think that’s the backwards way to go at things. I’d suggest finding a project that interests you and figuring out how to use Ruby to do that project. That should naturally suggest other technologies, libraries, frameworks, etc. You can even jump in on an existing open-source project, and that way you won’t have to think to hard about making those initial technology choices. My point is that learning in a vacuum is the worst way to learn. Learning by doing is more effective and also more satisfying.

That said, there are probably some good foundation libraries you’ll want to be familiar with. Learn the three major testing frameworks: test/unit, RSpec and Shoulda. Also get familiar with mocking libraries like RR and Mocha. Beyond that, most of what you’ll care about is going to be domain-specific, so there isn’t much point in answering such a generic question with likely irrelevant recommendations.

As for Ruby itself, there is a lot worth mastering in the Core and Standard Libraries (stdlib). The most high-leverage classes to learn about are String, Array and Hash, as well as the Enumerable mixin. File and IO are pretty useful too. Study and understand those classes and you’ll be well on your way to Ruby mastery.

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?

Josh>> First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too - it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

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?

Josh>> From what I’ve seen over the past year, it’s a very good market for Ruby developers. Most of the Ruby jobs are about building Rails applications or web-related things, but not entirely. I know quite a few developers building all sorts of things in Ruby that aren’t web apps. But for the moment Ruby is best suited for web development, and that’s probably going to be true for another year or two. Once we see a faster VM and better library coverage, I think you’ll see Ruby being used in a wide variety of applications. And if you want to build desktop applications, you should watch out for MacRuby.

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?

Josh>> This is getting to be a cliche, but contributing to open source projects is one of the best ways to show your stuff. You can demonstrate your technical proficiency, as well as your ability to work in a team, make decisions as a group, resolve conflicts, and deal with rejection (a big part of open source work!).

The other thing I’d suggest is to keep a technical blog. Contributing code to a project is great, but that doesn’t show the whole picture of you. If you keep a blog you can use it to discuss your contributions, document issues, and sound off about things you care about. This is a great way to let employers learn about you, and also demonstrates your communication skills (an essential requirement for almost any job).

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

Josh>> Ruby is a superb language. It is fully object-oriented, has functional language features like lambdas and higher-order functions, is very easy to meta-program, and has an accessible syntax and flexible structure. But Matz didn’t invent all those things himself. In fact Ruby is a synthesis of some of the most powerful ideas in computer science. If you want to really appreciate Ruby, you should take some time to study up on the systems from which it is derived. I would start with Smalltalk (Squeak is a free, open source implementation), then read up on Scheme or some other flavor of Lisp. If you haven’t used Perl, take a look at it just to see how much nicer Ruby’s syntax is.

And finally, get out and meet other Rubyists. A big part of what makes Ruby awesome is the community of people who use and contribute to it. Go to a local meetup or a conference and get connected to the community.

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

On 13th Jan. we talk to Thibaut Barrere from France.

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

The Path to Ruby Mastery Series (So Far):

Technorati Tags: Interviews, Little Known Ways to Ruby Mastery, Ruby, Ruby Beginners’ Questions, Josh Susser, The Ruby Programming Language

Posted by Satish Talim

{ 3 comments }

Little Known Ways to Ruby Mastery by Ilya Grigorik

by Satish Talim on December 30, 2008 · 2 comments

A weekly series from the Ruby Masters

Ilya Grigorik, Canada

This week, we’re happy to have Ilya Grigorik from Canada.

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

Ilya>> My name is Ilya Grigorik, I am a proverbial early-adopter of all things digital, and I am founder / CTO of AideRSS (a startup in Waterloo, Canada). My first website consisted of two dozen accounts on Geocities and Angelfire to host .bmp images for the images on my site – I didn’t know about compression, at the time. Since then, I’ve made my way through Perl and flat file databases, to PHP and MySQL, and eventually to Ruby and Rails. Nowadays, AideRSS is my full time job, and in between, I blog about lessons learned, software architectures, and web standards in general.

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

Ilya>> Pick a simple project that you can show off to your friends and jump right into it. There is a reason why ‘a blog in 10 minutes’ is such a popular demo for most web-frameworks – the point is not in the blog itself, but in building something you feel ownership of and can use on a daily basis. Once you show it to your friends, you’ll feel the pressure (in a good sense) to keep it working, fix bugs, and add new features, which will keep you motivated.

In terms of resources, Ruby has an astounding number of great books and online resources. I highly recommend Ryan Bates’ RailsCasts series (start from the beginning of the archive). Also, visit your local bookstore and find a Ruby book. Personally, I’m a big fan of ‘Ruby For Rails’ by David A. Black. Last but not least, get involved in the Ruby community. Join GitHub, subscribe to RailsEnvy podcast for latest news, and join the #ruby channel on freenode.net IRC server.

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

Ilya>> I know many language buffs who love diving deep into new languages just for the sake of it, but personally, I don’t subscribe to that philosophy. To me, the best way to learn a language is to align it with a personal project or a goal. (ex. a blog; a link sharing service; a command line script; a web-service to do x; etc.)

Hence, it is not about studying ‘the right framework’, instead find something that interests you, then find adjacent projects and dive right into it. My first Ruby-based web service was built directly on top of a TCPSocket class because that’s what I was familiar with at the time. I shared it with my friends and they recommend Webrick, Rails, and Camping… and down the rabbit hole I went. (and never looked back!)

Dennis Theisen, Germany>> Could you name three features of Ruby that you like the most, as compared to other languages? Why?

Ilya>> When you look at a well written piece of code, it reads like poetry. I can’t explain it, but it’s just aesthetically pleasing – it has a feeling of craftsmanship.

Ruby has stolen a lot of the thought leadership from other communities. The reason for some of the ‘unstable’ libraries is also because they’re right on the edge of the current best practices (look at rspec, and a multitude of projects that sprung up around it). I think this is one of the core attractions of Ruby, and incidentally the biggest challenge moving forward – our ability to maintain the thought leadership by attracting the people who like to push through the boundaries.

The community. Ruby gets a disproportionate amount of attention on the web, largely because of the thought leadership, but also because we’re good at promoting ourselves (one fuels the other). Look at all the conferences, meet-ups, blogs, and so on. It lowers the barrier to entry and benefits everyone involved.

Willian Molinari, Brazil>> What has been your biggest challenge while working with Ruby?

Ilya>> Beta-quality libraries. For all the hype around Ruby, a lot of the libraries are either unstable or unfinished. As Dr. Nic has pointed out, you have to be open to extending, and patching some of these libraries to get the results you desire.

Jerry Anning, USA>> What best practices are most important for a new Ruby programmer to learn and understand?

Ilya>> TDD. Now, I’m not religious about it, and will openly admit that often I don’t develop in ‘TDD mode’, but to me, it’s not the process that matters, but the philosophy behind it. Namely, you’ll find that amazing things happen when you write down the requirements first, and then dive into the code – you’ll finish faster, you’ll have a regression suite, you’ll have cleaner code.

In some ways, TDD is a close cousin of GTD (getting things done). And that’s what Ruby/Rails is all about – quick development cycle, user feedback, rinse and repeat.

Michael Uplawski, Germany>> According to you, what is a comfortable size of a Ruby/Rails-project? Why?

Ilya>> I don’t think there are any artificial constraints on the size of the project just because it’s written in Ruby. I think the more relevant question is your own comfort level with Ruby and what that means for the size of the project. If you’re just a beginner, you should start small, and as you learn the architectural intricacies of the language, as well as, develop a mental map of best practices based on experience you can start moving into larger projects.

Michael Uplawski, Germany>> Having spent some years in the I.T. industry and coming to Ruby from a different background, how do I recognize Ruby’s limitations so as to suggest a different language in such cases?

Ilya>> There is no silver bullet for this question. Get to know Ruby, as well as, other languages. Read blogs, follow industry news. There is a great saying: “If all you have is hammer, everything looks like a nail,” don’t fall into this trap.

There are many cases where Ruby might not be the best fit, but that’s also subjective and conditional on your own experience, as well as, the experience of your team. For example, lately we’ve been hearing a lot about Erlang, but if you have a team of great Ruby developers, does that mean you should dump Ruby in favor of Erlang? Probably not.

Dennis Theisen, Germany>> Do you think Ruby is ready to be used in “Enterprise applications”? Kindly justify your answer.

Ilya>> I think this question should be reversed: “Do you think the Enterprise is ready for Ruby?” As a language, I think Ruby is ready. Yes, the MRI team has had some snafu’s with their releases, but JRuby and Rubinius have made a lot of progress in the past year and I’m really glad to see that all of these projects are contributing to a greater whole: consistent implementation, a solid regression suite of tests, etc.

More importantly, I think the ‘Enterprise’ is also realizing that they have to compete in a fast pace market. Gone are the days of 50 developer teams and six months release cycles. If they want to compete on the web, they have to adopt the latest best practices – something on which, whether you like it or not, Ruby and Rails has had a big influence on in past several years.

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?

Ilya>> Ruby has to be one of the best prototyping languages, and it really shines at that. I love the readability of the code, and the fact that there are always multiple ways to accomplish one thing – I know this is controversial, but I think this one of the reasons why Ruby has seen such an uptake.

The common complaint is performance, but Ruby can’t be all things to all people. When you start with Ruby you make a conscious decision to trade off some of the optimization in favor of a quicker prototyping cycle. And for the most part, I think this is a perfectly legitimate route because you can always optimize later. Ruby plays well with polyglot architectures, and there are plenty of examples of highly optimized Ruby code out there. First, you should prove that there is a reason for the projects existence (uptake in the market, open source contributors, etc.), and then you should focus on optimizing the core.

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?

Ilya>> Once again, find something that interests you, and something that matches your experience level. Many people recommend diving into Rails, but I think there are many smaller projects which are conceptually simpler and easier to get involved with. If you haven’t already, join GitHub and do a search for a project that might interest you – chances are, you’re not the only one – then, dive right into source. Fork the project, fix a bug, send a ‘pull request’ to the original author.

If you’re a language buff, Adam Wiggins has a great how-to for getting involved with Rubinius.

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?

Ilya>> Ruby deployment is still painful, and for that reason I’m really excited about projects like JRuby, Maglev, and mod_rails amongst many others. Likewise, Merb, and other web micro-frameworks continue to innovate around Rails.

I can’t predict where we’ll be in two years, but I hope we’ll have a faster MRI, an easier deployment model, and an even larger community.

Ilya>> The future of Ruby is whatever we make it to be. Rails is why most people get into Ruby, and Ruby is why they stay in the community. It’s a beautiful language with a great community - what else could you ask for. If you want to see where Ruby is heading, visit GitHub (have I given them enough plugs yet?) and look at the recent and most popular projects. You’ll find telecom applications, midi generators, SMS gateways, web-servers… you get the point!

Ruby metaprogramming allows for very rich DSL applications, which makes it very well positioned for sys-admin, and domain specific projects. For some good examples, look at ‘Puppet’, or ‘God’ projects.

Ilya>> Remember that 10 minute blog that you built when you first started with Rails… Keep it up to date! I’ve gone through piles of resumes and in person interviews, and nothing stands out more than a personal web-site or a blog that has relevant content to the position I’m looking to fill. If you take the time to share a snippet of code, or talk about a problem you’ve overcome, you’re instantly head and shoulders above the vast majority of resumes out there.

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

Ilya>> Start a blog, join GitHub, contribute to a project, blog about it, then rinse and repeat. Before you know it, you’ll be turning down offers.

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

On 6th Jan. we talk to Josh Susser from USA.

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

The Path to Ruby Mastery Series (So Far):

Technorati Tags: Interviews, Little Known Ways to Ruby Mastery, Ruby, Ruby Beginners’ Questions, Ilya Grigorik, The Ruby Programming Language

Posted by Satish Talim

{ 2 comments }

Little Known Ways to Ruby Mastery by Yehuda Katz

by Satish Talim on December 23, 2008 · 0 comments

A weekly series from the Ruby Masters

Yehuda Katz, USA

This week, we’re happy to have Yehuda Katz from USA.

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

Yehuda>> I’m the current maintainer of the Merb project, and also work on the jQuery and DataMapper projects. Together, Merb, DataMapper, and jQuery are a killer stack that really ramps up productivity. I was an Accounting major in college, and got involved with Ruby in 2005, in the pre-1.0 days of Ruby on Rails. I love Ruby and the community around it, and believe that the future is bright for the language. I currently work for Engine Yard on the Merb project.

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?

Yehuda>> A lot of people have talked about Ruby as too slow to really be viable. I debunked that in my keynote at MerbCamp. Because Rubyists are so industrious, most of the critical path of Ruby applications have been optimized in C (with servers like Thin and Ebb and bindings to XML libraries like LibXML). People are also concerned about the development process of the Standard Ruby. On the bright side, the RubySpec project has created a runnable test suite for what Ruby is, and the alternative implementations (Rubinius and JRuby) are pushing the language forward.

What’s great about Ruby is how quickly it exposes new developers to advanced programming techniques, like lambdas. You can’t get past simple iterations in Ruby before being exposed to lambdas, and many methods in common frameworks accept blocks (one of Ruby’s lambdas). Additionally, Ruby’s mutability makes it very easy to implement ceremony-less extensions to the language that make building frameworks like Rails or Merb simple and easy to use. Compare Rails or Merb with CakePHP or Struts if you want to see what I mean.

Finally, something that isn’t really related to the language itself is Rails’ strong emphasis on the 80/20 rule and convention over configuration. While Merb tries to go even further by making it possible to opt out of the conventions more granularly, the basic idea is fairly permeated in the Ruby community. It’s very difficult to make a Ruby library popular if it requires out-of-the-box configuration and does not attempt to provide a certain amount of common defaults.

Willian Molinari, Brazil>> What has been your biggest challenge while working with Ruby?

Yehuda>> I’d say the biggest challenge of working with Ruby is how dynamic the language is. While it makes it possible to create really powerful, simple language extensions (and thus makes Rails or Merb possible), those same features allow Ruby libraries to hide complexity and changes that aren’t easy to track down. The popular alias_method_chain feature, for instance, combined with metaprogramming creates methods that run in your application but that you can’t easily look at in source. In fact, it can sometimes be nearly impossible to figure out where all the pieces even come from.

That’s the reason for the Merb rule against alias_method_chain, but you can’t really solve this problem without making Ruby significantly less powerful. It’s important for Ruby programmers to define clear APIs for libraries that they release, and try to avoid opaque magic where possible. Where not possible, library developers should clearly document exactly what they’re doing, so people trying to debug those libraries can understand the underlying codebase.

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?

Yehuda>> Merb of course! While I may be biased, the Merb project has a simple enough codebase (at around 6,000 lines for the core framework) to take a look at some outstanding tickets and dive in quickly. It’s also a relatively popular framework, so contributions you make could start helping developers very quickly. You can get information on how to get started contributing to Merb. You might also dive into other edgy projects like DataMapper or YARD. Both could use some love, but have the potential to really be game-changers to the Ruby ecosystem, so getting involved now could be a great way to get in on the ground floor. The only thing I’d add is that when getting involved in a project, make sure to understand the culture and goals of the project. Be humble while learning the rules and idiosyncrasies of the project and its team.

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?

Yehuda>> The biggest changes have to do with old Ruby infrastructure that’s being pushed to the breaking point. Rubygems, rake, and rdoc were all fantastic pieces of software during the earliest days of Ruby in the US, but the community is putting so much pressure on the projects that significant changes are afoot. Rubygems, for instance, really needs support for “packages”, a simple change that could dramatically improve the way large Ruby projects package their applications. I’d look for modifications or wholesale replacement of core pieces of Ruby infrastructure over the next year.

Michael Uplawski, Germany>> According to you, what is a comfortable size of a Ruby/Rails-project? Why?

Yehuda>> Once a Ruby projects gets larger than about 5-10,000 lines of code, I like to start breaking it up into modules. When I say modules, I mean defined sub-projects with their own external APIs that other modules connect to. This prevents the sort of intertwined Ruby projects that are extremely difficult to refactor because of how connected everything is to everything else. In a Merb project, I’d strongly recommend using slices for this purpose. Merb itself uses rubygems to separate out the core framework (around 6,000 LOC) and additional modules, which all use the same plugin API that we expect users to use in general.

Dennis Theisen, Germany>> Do you think Ruby is ready to be used in “Enterprise applications”? Kindly justify your answer.

Yehuda>> Absolutely. The productivity benefits alone justify using Ruby in the Enterprise. While certain parts of Ruby might still be rough (SOAP support is a good example), the language itself, and the frameworks surrounding it are so productive that it’s worth having to deal with the oddities of SOAP4R, for instance. Ruby is also fundamentally changing the way Enterprises should think about software. While it’s simple to think that you’re building a piece of software from the ground up with very little common infrastructure, the fact is that proprietary applications built inside enterprises are constantly reinventing the same wheels over and over and over. Since Ruby and its supporting infrastructure is open source, large companies can leverage the power of the work others are doing to avoid having to reinvent the wheel.

Additionally, as more and more large companies, like Yellow Pages, begin to use Ruby, the feedback loop becomes more powerful as more and more large companies feed back into the community. Engine Yard, the company I work for, has been on the forefront of encouraging contributions, and the ecosystem around Rails and Merb is growing every day (Gartner found that 1,000,000 developers are already using Ruby, and that number is expected to grow to 4,000,000 in just a few years).

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

Yehuda>> Don’t be seduced by the power of the dark side. But seriously, Ruby is an extremely powerful language, but you should still define clear, consistent APIs to use both internally and in libraries. When testing, test those interfaces. Avoid mocking out large pieces of the interfaces that prevent you from determining whether the full application or library works. A clear API, with only a few public parts exposed, is worth its weight in pixie dust.

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

On 30th Dec. we talk to Ilya Grigorik from Canada.

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

The Path to Ruby Mastery Series (So Far):