The Expert Ruby Programmer

[basi]

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

 

[Rich Morin]

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

 

[Simon Kröger]

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

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

 

[dblack]

Hi --

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.

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


David

--
David A. Black
(e-mail address removed)

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black

 

[Chris Ferrell]

------=_Part_3034_18340486.1135637694675
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

------=_Part_3034_18340486.1135637694675--

 

[basi]

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

 

[Gregory Brown]

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

 

[basi]

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

basi

 

[Robert Klemme]

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.

Hope I could help at least a bit.

Kind regards

robert

 

[Dan Shafer]

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!

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 Shafer
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
http://www.eclecticity.com

 

[Steve Litt]

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 Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[James Edward Gray II]

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 Gray II

 

[J. Ryan Sobol]

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 Litt
http://www.troubleshooters.com
(e-mail address removed)

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 ~

 

[Steve Litt]

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 ~

Thanks Ryan,

Between you and James Edward Gray 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
(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 Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Dan Shafer]

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.

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

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan Shafer
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
http://www.eclecticity.com

 

[Steve Litt]

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

 

[Chad Perrin]

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.

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.

 

[basi]

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

 

[Wilson Bilkovich]

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'.

 

[Ryan Leavengood]

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

Hehehe, that is certainly true, but really I think when it comes to
software development, like anything else, you learn mostly from
experience. So if you are writing a particular kind of application for
the first time, you just don't know what the best approach will be
until the end, and of course by then you probably have an entire
program taking the wrong approach

My only advice would be to branch out and code as many different kinds
of applications as you can, and then eventually you just know how to
code everything :-D

Of course by then you may be an 80-year-old programmer.

Ryan