The Expert Ruby Programmer


#1

Hello,
What coding techniques and practices does the expert Ruby programmer
know and apply? I don’t mean being able to program in a some esoteric
domian (AI, for example) or facility in using various libraries. When
you look at a Ruby program, what criteria will you use to deem a
program as written by an expert and another by a neophyte? How does a
well-written Ruby program look like?

I am finishing my first Ruby program/system. It works, so far. But it
looks so ugly that I, myself, will not hesitate to disown it. I’m
looking for ways to make this ugly duckling show some ruby luster.

A good way to start a new year, I guess.

Thanks,
basi


#2

At 3:57 AM +0900 12/27/05, basi wrote:

I am finishing my first Ruby program/system. It works, so far. But it
looks so ugly that I, myself, will not hesitate to disown it. I’m
looking for ways to make this ugly duckling show some ruby luster.

In a related notion, I’ve been wondering if there might be a way for
the Ruby community to engage in “code reviews”, both to help given
projects and to provide an archival record of the discussions.

-r


#3

I’m not considering me as pro in Ruby (being here in ruby-land for 6
months
now)
but, judging from what i’ve seen so far the gurus are following some
simple
principles:

  • DRY - Don’t Repeat Yourself - In case you write one line twice,
    refactor. :slight_smile:
  • Keep the Code clean/understandable
    Everyone profits from that, others can extend your code easily and
    tracing
    bugs (yeah, they never die :slight_smile: is much easier - even for yourself. Ruby
    makes
    this one a priority by design [correct me when i’m wrong]
  • Let the Duck-quack-typing work for you. Don’t worry about Types, be
    happy!
  • UnitTesting - well, you can follow the Testing-crowd or not, but
    you’re
    probably better off by providing unit-tests

there are lots of other principles you could apply, and i hope that
others
write something about that topic - but these are the most important to
me.
And never forget to Document - ruby-code may speak for itself, but give
beginners something to stick to, so they can follow your code with ease
:slight_smile:

Some Tricks…

  • The real, real, real, pros (matz and co, zenspider made it quite easy
    with
    the inliner) are rewriting parts of ruby-code in C… this is only
    recommended when you are really depending on performance, because it
    breaks
    some of the nice things ruby provides.

Always remember though, your code is written by you, don’t follow
everything
you get told - it might be the best way, but you should experiment and
play
around to see what fits your way of thinking.

So long… and don’t take this text too seriously


Am Montag, 26. Dezember 2005 19:57 schrieb basi:

#4

Hi –

On Tue, 27 Dec 2005, basi wrote:

looking for ways to make this ugly duckling show some ruby luster.
You should check out the Ruby code in the standard library. You’ll
see a lot of the traditional Ruby practices in action (two-space
indenting, variable names like_this instead of likeThis, etc.).

There are also some nuby giveaways, like these:

printf("%s\n", str); # instead of puts str; also the semi-colon
array.each {|e| puts e } # instead of puts array

Everyone goes through the rite of passage of learning not to do these
things :slight_smile:

David


David A. Black
removed_email_address@domain.invalid

“Ruby for Rails”, from Manning Publications, coming April 2006!


#5

Rich M. wrote:

-r

This might not be what you realy wanted, but one (the easiest?) way
would be to post a few tens of lines here on the ML. The OP wouldn’t be
the first to do that and from what i have seen the responce is
overwhelming each and every time.

cheers

Simon


#6

http://www.rubygarden.org/ruby?RubyIdioms


#7

Hi,
Ruby for Rails looks like the book that will satisfy my current
craving. Any chance an electronic copy is available for purchase?
Thanks,
basi


#8

Thanks. Got that book. David Black’s book, as I gather, is about how to
become a better Ruby programmer for Rails.

basi


#9

On 12/26/05, basi removed_email_address@domain.invalid wrote:

Hi,
Ruby for Rails looks like the book that will satisfy my current
craving. Any chance an electronic copy is available for purchase?
Thanks,
basi

Yes.

http://pragmaticprogrammer.com/titles/rails/index.html


#10

basi removed_email_address@domain.invalid wrote:

Hello,
What coding techniques and practices does the expert Ruby programmer
know and apply? I don’t mean being able to program in a some esoteric
domian (AI, for example) or facility in using various libraries. When
you look at a Ruby program, what criteria will you use to deem a
program as written by an expert and another by a neophyte? How does a
well-written Ruby program look like?

It’s not easy to answer: the easy part is the one about Ruby idioms (see
David’s posting for example). The difficult part is the one about
general
software quality. There are some rules of thumb but from my experience
it
takes some time and coding experience to become an expert at this (don’t
get
me wrong, I don’t claim to be an expert in every aspect - I just think I
prevent certain errors nowadays that I did in the beginning).

The most important part of software engineering is about proper
distribution
of functionality across a software system. Unfortunately this is often
quite difficult because when you start out you often won’t know what’s
the
best way to do certain things. Often then refactoring or even rewriting
is
the only cure if you have to maintain something or if you have to ensure
code is maintainable. A rule of thumb that helps here is to make sure
methods are not longer than a printer / screen page.

Then of course there’s the old strategy to identify nouns in your
requirement description and make them into classes. The granularity and
extent to which you to this depends of course on the project.

Proper naming of classes and variables also helps a great deal.
Although
it’s more tedious to write longer identifiers by hand you’ll notice that
you
understand your old code quicker when you see it after seveal months of
abstinence.

I am finishing my first Ruby program/system. It works, so far. But it
looks so ugly that I, myself, will not hesitate to disown it. I’m
looking for ways to make this ugly duckling show some ruby luster.

A good way to start a new year, I guess.

:slight_smile:

Hope I could help at least a bit.

Kind regards

robert

#11

Warning: Newby’s first post.

I come out of the world of Smalltalk (with lots of frustrating stops
in between there and here) and have done a lot of OO design and
programming over the decades. I found that any non-trivial OO app had
to be rewritten twice during its early lifetime even after it was
working to achieve the kind of reusability and maintainability that
are the primary economic driving forces behind OO.

Oh, and it might at least be historically interesting to note that
one of the early Smalltalk pioneers (I think it was Alan Kay but I
could be wrong so don’t quote me) said “Any method longer than seven
lines needs to be re-thought or re-factored.” So giving yourself a
screen or printer page of space is generous by that standard!

On Dec 27, 2005, at 3:12 AM, Robert K. wrote:

The most important part of software engineering is about proper
distribution of functionality across a software system.
Unfortunately this is often quite difficult because when you start
out you often won’t know what’s the best way to do certain things.
Often then refactoring or even rewriting is the only cure if you
have to maintain something or if you have to ensure code is
maintainable. A rule of thumb that helps here is to make sure
methods are not longer than a printer / screen page.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan S.
Technology Visionary - Technology Assessment - Documentation
“Looking at technology from every angle”
http://www.eclecticity.com


#12

On Dec 27, 2005, at 12:01 PM, Steve L. wrote:

I have a big problem with a few sentences in the preceding URL. Or
at least as
I understand them. They seem to be advocating getting rid of config
files and
putting all logic in code, at least my reading of the following
quotes:

One of the design points of Rails is, “Convention over
configuration.” That means that as long as you do everything the
Rails way, it can make a lot of assumptions about what you are
building and properly configure itself for you. You can “correct”
the framework here and there, if it makes a wrong guess, but
generally it saves a good deal of work.

Despite this, a Rails application does have configuration files.
They just happen to be written in pure Ruby, which, in my opinion, is
more agile than XML. You can easily add new application based
configuration.

Walk through a couple of Rails tutorials and you’ll understand the
lines you quoted a little better. It’s not a cure-all (Rails
struggles a bit with legacy systems, for example), but it can save a
lot of repetition in many cases.

Hope that helps.

James Edward G. II


#13

On Tuesday 27 December 2005 12:11 am, Gregory B. wrote:

On 12/26/05, basi removed_email_address@domain.invalid wrote:

Hi,
Ruby for Rails looks like the book that will satisfy my current
craving. Any chance an electronic copy is available for purchase?
Thanks,
basi

Yes.

http://pragmaticprogrammer.com/titles/rails/index.html

I have a big problem with a few sentences in the preceding URL. Or at
least as
I understand them. They seem to be advocating getting rid of config
files and
putting all logic in code, at least my reading of the following quotes:

============================================
“A full Rails application probably has less total code than the XML
you’d need
to configure the same application in other frameworks.”

"Rails strives to honor the Pragmatic Programmer’s DRY Principle by
avoiding
the extra work of configuration files and code annotations. You can
develop
in real-time: make a change, and watch it work immediately.

Forget XML. Everything in Rails, from templates to control flow to
business
logic, is written in Ruby, the language of choice for programmers who
like to
get the job done well (and leave work on time for a change)."

Putting all your logic in code is nothing new. That’s how it was done in
the
60’s. By the 80’s programmers created configuration files so that a
customer
request for increasing the customer number field from 5 to 6 digits
wouldn’t
require recoding – the user could change the config file. It requires a
lot
more coding, but it makes for a much more resiliant application.

Anyone can write a “simple” app if he or she puts all the logic in code,
and
that programmer will be called every time a change is needed in that
code,
even if the change is trivial.

To me, the art of programming is anticipating likely changes and needs,
and
putting facilities for those changes and needs in config files, so that
the
change can be made with a simple tech support call instead of a code
change.

I believe in data centered programming.

Once again, perhaps I misunderstood the intent of the web page, but if
they’re
advocating moving logic from data to code, that’s some advice I will not
follow.

SteveT

Steve L.
http://www.troubleshooters.com
removed_email_address@domain.invalid


#14

On Dec 27, 2005, at 1:01 PM, Steve L. wrote:

to configure the same application in other frameworks."
who like to
requires a lot
putting facilities for those changes and needs in config files, so
follow.

SteveT

Steve L.
http://www.troubleshooters.com
removed_email_address@domain.invalid

I’ve actually used Rails in a few side projects and I have a
different interpretation of those statements. Rails packages the
most common components of web development and automatically creates
sensible defaults, which can be changed if necessary, in
configuration files. This is probably the biggest difference between
Rails and many other web development frameworks / technologies.

For example, instead of the developer maintaining configuration files
that define existing attributes in database tables, which tend to be
volatile due to customer requests, Rails just queries the table
during runtime and asks it what attributes it has. In another
example, instead of the developer maintaining a configuration file
that defines the location of my application’s templates files, Rails
creates the directories and manages the same information internally.
The default behavior in both these examples can be over-ridden, but
there’s seldom a reason to do so in the majority of cases.

Rails establishes a groovy synergy between these and other web
development components that makes developing these kinds of
applications easier. I highly recommend you try if you do any
serious web development.

~ ryan ~


#15

On Tuesday 27 December 2005 02:05 pm, J. Ryan S. wrote:

you’d need
logic, is written in Ruby, the language of choice for programmers
require recoding – the user could change the config file. It
needs, and
will not
most common components of web development and automatically creates
creates the directories and manages the same information internally.
The default behavior in both these examples can be over-ridden, but
there’s seldom a reason to do so in the majority of cases.

Rails establishes a groovy synergy between these and other web
development components that makes developing these kinds of
applications easier. I highly recommend you try if you do any
serious web development.

~ ryan ~

Thanks Ryan,

Between you and James Edward G. now I want to learn RAILS to see for
myself
whether I like it.

Everyone – what’s your opinion of the book I just dissed :slight_smile:
(http://pragmaticprogrammer.com/titles/rails/index.html). Is it a good
RAILS
guide?

Are there other good RAILS guides? Are there any excellent web resources
for
RAILS?

Thanks

SteveT

Steve L.
http://www.troubleshooters.com
removed_email_address@domain.invalid


#16

On Tuesday 27 December 2005 06:17 pm, Dan S. wrote:

FWIW, I’m a newby to Ruby but I’ve worked with several other Web
frameworks (Zope, Plone, etc.) and have written and published a few
computer books of my own. This title is one of the best-written and
clearest treatments of this kind of topic I’ve ever read. Thomas has
a real knack for making stuff clear and understandable. Highly
recommended.

With a recommendation like that I have only one option – I ordered both
the
pdf and the book. I’ll let you all know what I think in about a week.

Thanks Dan

SteveT


#17

FWIW, I’m a newby to Ruby but I’ve worked with several other Web
frameworks (Zope, Plone, etc.) and have written and published a few
computer books of my own. This title is one of the best-written and
clearest treatments of this kind of topic I’ve ever read. Thomas has
a real knack for making stuff clear and understandable. Highly
recommended.

On Dec 27, 2005, at 2:49 PM, Steve L. wrote:

Everyone – what’s your opinion of the book I just dissed :slight_smile:
(http://pragmaticprogrammer.com/titles/rails/index.html). Is it a
good RAILS
guide?

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan S.
Technology Visionary - Technology Assessment - Documentation
“Looking at technology from every angle”
http://www.eclecticity.com


#18

Dan,
I must haveI missed CLR formally welcoming an illustrious programming
language guru and writer like yourself! I still have some of your
HyperCard books. They are a classic in clear technical writing.

I’m new myself to Ruby, and I’m still looking for the ‘syntactic
essence’ of Ruby. It is that thing that once you get it, everything
else is an embellishment. Much in the sense that grasping and mastering
list manipulation in Lisp/Scheme can take you far and wide. I suspect,
in Ruby, as in other OO languagues, it is the object. I’m ready for a
Ruby book that starts with the most basic object/class and from which
most things I’d like to ‘compute’ will be shown to be mere extensions
or variations.

But back to the topic:

<<
I found that any non-trivial OO app had
to be rewritten twice during its early lifetime even after it was
working to achieve the kind of reusability and maintainability

So I’m looking to know what it is that we don’t know the first time
that had we at the time known would lessen the need for a major
redesign and rewrite?

Thanks,
basi


#19

On 12/27/05, basi removed_email_address@domain.invalid wrote:

So I’m looking to know what it is that we don’t know the first time
that had we at the time known would lessen the need for a major
redesign and rewrite?

That’s the immanent quintessential property known as ‘What The User
Actually Wanted, But Didn’t Mention At First’.
:slight_smile:


#20

On Wed, Dec 28, 2005 at 08:57:30AM +0900, Steve L. wrote:

I’ll add to that:

I have the hardcopy. I haven’t navigated through the whole thing yet,
but it is indeed one of the clearest, most useful books of its type I’ve
ever had the distinct pleasure to run across. In addition, Appendix A
the single most concise language tutorial I’ve ever seen that is
actually useful, and makes an excellent introduction to the language for
a mediocre Perl hack like myself. You, being rather more the Perl
expert than I am, may or may not find it as useful. I’d like to know
what you think.

As for Rails itself: it’s dead simple to use. I’ve always, in the past,
been disappointed by the fact that web frameworks – supposedly designed
to make web development easier – always seemed to make the overall
process of developing a serious web app more complex and tedious rather
than less (which is why I ended up using PHP for anything on the
incredibly simple end of the spectrum despite my general distaste for
the language). Rails breaks that trend rather handily, for my purposes.


Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you’re using a unixlike OS, please forward
this to 20 others and erase your system partition.