[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

The Expert Ruby Programmer

basi

12/26/2005 6:53:00 PM

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
36 Answers

Rich Morin

12/26/2005 7:17:00 PM

0

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
--
email: rdm@cfcl.com; phone: +1 650-873-7841
http://ww... - Canta Forda Computer Laboratory
http://ww.../Meta - The FreeBSD Browser, Meta Project, etc.

Simon Kröger

12/26/2005 9:40:00 PM

0

Rich Morin wrote:
> 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

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

12/26/2005 10:12:00 PM

0

ChrisF

12/26/2005 10:55:00 PM

0

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

>
>
>
>

basi

12/27/2005 12:16:00 AM

0

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

12/27/2005 5:11:00 AM

0

On 12/26/05, basi <basi_lio@hotmail.com> 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/...

basi

12/27/2005 10:15:00 AM

0

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

12/27/2005 11:08:00 AM

0

basi <basi_lio@hotmail.com> 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.

:-)

Hope I could help at least a bit.

Kind regards

robert

Dan Shafer

12/27/2005 5:42:00 PM

0

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

Steve Litt

12/27/2005 6:02:00 PM

0

On Tuesday 27 December 2005 12:11 am, Gregory Brown wrote:
> On 12/26/05, basi <basi_lio@hotmail.com> 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/...

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.troublesh...
slitt@troubleshooters.com