Today I rediscovered the truth of that very important saying in software
developement: “Make it work, make it right, then make it fast.”
In my project at work, I spent too much time trying to perform file scanning
operation fast: by reading it backwards until it determined that it didn’t need
any more information, then committing to the database.
I’ve now done what I should have in the first place: read the file forwards,
grabbing all the information, and then updating the database as necessary.
This involves grabbing potentially 99% redundant information from a HUGE file,
then comparing against lots of info in the database before knowing what to
commit. It’s a dumb approach, but it’s more reliable (no dependence on smarts
to determine when to stop scanning), and more flexible (can run it on old files
usefully and safely). In the end, it was these features I needed, so I
scrapped my “optimised” approach that I had spent perhaps a week on a few weeks
ago.
Furthermore, the same degree of “optimisation” can be achieved by controlling
an external factor: restarting a certain process every night so the log file
doesn’t grow too large. Then the original “need” to read it backwards (itself
an expensive task) vanishes.
Oh well, lesson learned. And although this has nothing directly to do with
Ruby, I share it herre in the hope that by warning others, I can balance my
karma and not have it happen to me again
Oh well, lesson learned. And although this has nothing directly to do with
Ruby, I share it herre in the hope that by warning others, I can balance my
karma and not have it happen to me again
If you have time, read “Code Complete” from Steve McConnell
(1-55615-484-4) it will tech you this and other interesting tricks…
Sometime, I think ruby is too clever. It automatically expand cmdline.
For example:
myprog *.txt good
in a language like c or pascal, argv[0]="*.txt" argv[1]=“good”, but in
ruby, all txt file in the directory is put into the command line. This
may be good, but a drawback is it is not convenient to get the second
parameter, because ARGV.length is variable… What do you think?
“Gavin Sinclair” gsinclair@soyabean.com.au wrote in message
news:140701c296ef$8538af70$436032d2@nosedog…
Folks,
Today I rediscovered the truth of that very important saying in software
developement: “Make it work, make it right, then make it fast.”
and D. Knuth: “early optimization is the root of all evil”.
I see your point, but I disagree to some extend. The approach is right, but
using a plain stupid algorithm that doesn’t scale is generally bad. Things
get abused and used in ways you can’t imagine.
It can take a looong time to get code sorted out once in production and it’s
difficult to make fundamental changes. Today IBM developer works weekly
letter had a point about “no amount of work can compensate for an intially
bad design”, drawing parallels to an exploding turkey (the editor is
obviously insane).
Intelligent design is good. Overoptimization and unnecessary complexity is
bad.
To put this back to Ruby - it’s fine to start out in Ruby, make it work and
work right, probably plenty fast, otherwise you already have the right,
intelligent approach that can be optimized in a faster language.
I really appreciated this lesson learned about the development process
and thank Gavin Sinclair for posting it. As a neophyte programmer,
what I take from this is the following:
(1) Try to remember to follow general rules and principles in
development;
(2) If you forget to follow (1) above and run into difficulties, see
(1) above;
(3) Reflect on your programming habits every once in a while and see if
any of them seem to recur in association with problems (I don’t do this
yet because I don’t have enough experience – all of my programming
efforts are associated with problems to be solved);
(4) Step back every once in a while and ask yourself – do I need to do
this or can I do something else to solve a more general problem;
(5) Extensive experience and past success will reinforce both good and
bad habits and approaches – so everyone will have the opportunity to
learn from experience on a regular basis.
I hope I’ll see more stories like this, that I’ll learn something from
them and that I’ll have my own stories to contribute over time.
···
On Thursday, November 28, 2002, at 10:05 AM, Gavin Sinclair wrote:
Folks,
Today I rediscovered the truth of that very important saying in
software
developement: “Make it work, make it right, then make it fast.”
In my project at work, I spent too much time trying to perform file
scanning
operation fast: by reading it backwards until it determined that it
didn’t need
any more information, then committing to the database.
I’ve now done what I should have in the first place: read the file
forwards,
grabbing all the information, and then updating the database as
necessary.
This involves grabbing potentially 99% redundant information from a
HUGE file,
then comparing against lots of info in the database before knowing
what to
commit. It’s a dumb approach, but it’s more reliable (no dependence
on smarts
to determine when to stop scanning), and more flexible (can run it on
old files
usefully and safely). In the end, it was these features I needed, so I
scrapped my “optimised” approach that I had spent perhaps a week on a
few weeks
ago.
Furthermore, the same degree of “optimisation” can be achieved by
controlling
an external factor: restarting a certain process every night so the
log file
doesn’t grow too large. Then the original “need” to read it backwards
(itself
an expensive task) vanishes.
Oh well, lesson learned. And although this has nothing directly to do
with
Ruby, I share it herre in the hope that by warning others, I can
balance my
karma and not have it happen to me again
Sometime, I think ruby is too clever. It automatically expand cmdline.
For example:
myprog *.txt good
in a language like c or pascal, argv[0]=“*.txt” argv[1]=“good”, but in
ruby, all txt file in the directory is put into the command line. This
may be good, but a drawback is it is not convenient to get the second
parameter, because ARGV.length is variable… What do you think?
I think that you are playing too much with your shell :
oct@Colibri ~ % ruby -e “p ARGV” *.doc
zsh: no match
Whereas:
oct@Colibri ~ % ruby -e “p ARGV” “.doc"
[".doc”]
My shell does the “*.doc” expansion if I forget to protect the *.
between quotes. Yours has probably the same feature activated…
Try and ‘ruby myprog “*.txt” good’ …
···
On Fri, Nov 29, 2002, Shannon Fang wrote:
–
Pierre Baillet
Avec un escalier prévu pour la montée, on reussi souvent à monter
plus bas qu’on ne serait descendu avec un escalier prévu pour la descente.
Devise Shadok
