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.
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
···
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.
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.
* Keep the Code clean/understandable
Everyone profits from that, others can extend your code easily and tracing
bugs (yeah, they never die 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
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
~~~~manveru
···
Am Montag, 26. Dezember 2005 19:57 schrieb 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.
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
···
On Tue, 27 Dec 2005, basi wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
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.
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.
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"
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?
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:
···
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
============================================
"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.
That's the immanent quintessential property known as 'What The User
Actually Wanted, But Didn't Mention At First'.
···
On 12/27/05, basi <basi_lio@hotmail.com> 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?
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.
Very kind of you to say, basi...and for that matter to remember me! I am becoming quite intrigued with Ruby and Rails as I study them in tandem. They just "feel" right.
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.
AH, yes, l'essence d'objects! I have a vague sense that the class library for Ruby may not yet have settled enough to be the subject of a book, that such a book would be obsolete before publication even if it were made available as an eBook.
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?
Nothing generic and therein lies the rub. If you really grok design patterns and can map the domain you're working in against those patterns, that seems to reduce the *number* of times you have to revise code almost completely, but the need never seems to go away, at least in my experience. This seems to me to be the gestalt of OO programming and I consider it a Good Thing. Refactoring is pretty easy with the right tool and refining the design as you learn is a good way to mimic nature, which is one of the reasons OO programming works so well to begin with.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan Shafer
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
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
···
On Dec 27, 2005, at 12:01 PM, Steve Litt 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:
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 ~
···
On Dec 27, 2005, at 1:01 PM, Steve Litt 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:
============================================
"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.
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
Of course by then you may be an 80-year-old programmer.
Ryan
···
On 12/27/05, Wilson Bilkovich <wilsonb@gmail.com> wrote:
On 12/27/05, basi <basi_lio@hotmail.com> 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'.
Yes, and the variation on that theme, "What the programmer saw at 3 a.m. just as he closed down his editor for the evening and couldn't remember the next morning."
···
On Dec 27, 2005, at 7:36 PM, Wilson Bilkovich wrote:
On 12/27/05, basi <basi_lio@hotmail.com> 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'.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan Shafer
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
Are there other good RAILS guides? Are there any excellent web resources for
RAILS?
Thanks
SteveT
Steve Litt
slitt@troubleshooters.com
···
On Tuesday 27 December 2005 02:05 pm, J. Ryan Sobol wrote:
On Dec 27, 2005, at 1:01 PM, Steve Litt 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:
>
> ============================================
> "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
> slitt@troubleshooters.com
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.
