Forum: Ruby The Expert Ruby Programmer

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
basi (Guest)
on 2005-12-26 20:59
(Received via mailing list)
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 M. (Guest)
on 2005-12-26 21:20
(Received via mailing list)
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
Michael F. (Guest)
on 2005-12-26 22:05
(Received via mailing list)
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:
=?ISO-8859-1?Q?Simon_Kr=F6ger?= (Guest)
on 2005-12-26 23:41
(Received via mailing list)
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
unknown (Guest)
on 2005-12-27 00:14
(Received via mailing list)
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 :-)


David

--
David A. Black
removed_email_address@domain.invalid

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
Chris Ferrell (Guest)
on 2005-12-27 00:57
(Received via mailing list)
basi (Guest)
on 2005-12-27 02:18
(Received via mailing list)
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 B. (Guest)
on 2005-12-27 07:13
(Received via mailing list)
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
basi (Guest)
on 2005-12-27 12:19
(Received via mailing list)
Thanks. Got that book. David Black's book, as I gather, is about how to
become a better Ruby programmer for Rails.

basi
Robert K. (Guest)
on 2005-12-27 13:14
(Received via mailing list)
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.

:-)

Hope I could help at least a bit.

Kind regards

    robert
Dan S. (Guest)
on 2005-12-27 19:45
(Received via mailing list)
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
Steve L. (Guest)
on 2005-12-27 20:03
(Received via mailing list)
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
James G. (Guest)
on 2005-12-27 20:42
(Received via mailing list)
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
J. Ryan S. (Guest)
on 2005-12-27 21:06
(Received via mailing list)
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 ~
Steve L. (Guest)
on 2005-12-28 00:49
(Received via mailing list)
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 :-)
(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
Dan S. (Guest)
on 2005-12-28 01:19
(Received via mailing list)
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 :-)
> (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
Steve L. (Guest)
on 2005-12-28 01:58
(Received via mailing list)
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
Chad P. (Guest)
on 2005-12-28 03:02
(Received via mailing list)
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.
basi (Guest)
on 2005-12-28 03:29
(Received via mailing list)
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 B. (Guest)
on 2005-12-28 05:38
(Received via mailing list)
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'.
:)
Ryan L. (Guest)
on 2005-12-28 06:38
(Received via mailing list)
On 12/27/05, Wilson B. <removed_email_address@domain.invalid> wrote:
> 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'.
> :)

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
James B. (Guest)
on 2005-12-28 07:35
(Received via mailing list)
Ryan L. wrote:
...
> 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.
>

Ah, but an 80-year-old who can *kick ass* in Ruby!

James

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Dan S. (Guest)
on 2005-12-28 09:27
(Received via mailing list)
On Dec 27, 2005, at 5:27 PM, basi wrote:

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

> 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 S.
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
http://www.eclecticity.com
Dan S. (Guest)
on 2005-12-28 09:27
(Received via mailing list)
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."

:-D

On Dec 27, 2005, at 7:36 PM, Wilson B. wrote:

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

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan S.
Technology Visionary - Technology Assessment - Documentation
"Looking at technology from every angle"
http://www.eclecticity.com
Chad P. (Guest)
on 2005-12-28 10:51
(Received via mailing list)
On Wed, Dec 28, 2005 at 02:34:08PM +0900, James B. wrote:
> Ryan L. wrote:
> ...
> >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.
> >
>
> Ah, but an 80-year-old who can *kick ass* in Ruby!

. . . like O Sensei, aka Morihei Ueshiba.

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

"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham
Jeremy H. (Guest)
on 2005-12-28 14:43
(Received via mailing list)
On 2005-12-28, Chad P. <removed_email_address@domain.invalid> wrote:
> On Wed, Dec 28, 2005 at 02:34:08PM +0900, James B. wrote:
>> Ryan L. wrote:
>> ...
>> >Of course by then you may be an 80-year-old programmer.
>>
>> Ah, but an 80-year-old who can *kick ass* in Ruby!
>
>  . . like O Sensei, aka Morihei Ueshiba.

Ruby, the official language of Aikido?

Jeremy
Robert K. (Guest)
on 2005-12-28 15:40
(Received via mailing list)
Chad P. <removed_email_address@domain.invalid> wrote:
>> Ah, but an 80-year-old who can *kick ass* in Ruby!
>
> . . like O Sensei, aka Morihei Ueshiba.

Didn't know O Sensei was doing Ruby...  If I'm not mistaken he died
before
Ruby was conceived.

Anybody else in here doing Aikido?

    robert
Al Gordon (Guest)
on 2005-12-28 16:40
(Received via mailing list)
On 12/28/05, Robert K. <removed_email_address@domain.invalid> wrote:
> >>
> >> Ah, but an 80-year-old who can *kick ass* in Ruby!
> >
> > . . like O Sensei, aka Morihei Ueshiba.
>
> Didn't know O Sensei was doing Ruby...  If I'm not mistaken he died before
> Ruby was conceived.
>
> Anybody else in here doing Aikido?
>
>     robert

I used to, and need to get back into it.  Might be a good New Year's
resolution...

--

  -- AL --
Steve L. (Guest)
on 2005-12-28 17:22
(Received via mailing list)
On Wednesday 28 December 2005 08:37 am, Robert K. wrote:
> Chad P. <removed_email_address@domain.invalid> wrote:
> > . . like O Sensei, aka Morihei Ueshiba.
>
> Didn't know O Sensei was doing Ruby...  If I'm not mistaken he died before
> Ruby was conceived.
>
> Anybody else in here doing Aikido?

I do Tai Kwon Code

SteveT
Stephen Webb (Guest)
on 2005-12-28 18:35
(Received via mailing list)
On Dec 28, 2005, at 3:50 AM, Chad P. wrote:

>>
>> Ah, but an 80-year-old who can *kick ass* in Ruby!
>
> . . . like O Sensei, aka Morihei Ueshiba.
>
> --
> Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
>
> "Real ugliness is not harsh-looking syntax, but having to
> build programs out of the wrong concepts." - Paul Graham
>
Okay, now that is interesting.  I had no idea O'Sensei was a fan of
Ruby.
Robert K. (Guest)
on 2005-12-28 18:38
(Received via mailing list)
Steve L. <removed_email_address@domain.invalid> wrote:
> On Wednesday 28 December 2005 08:37 am, Robert K. wrote:
>> Chad P. <removed_email_address@domain.invalid> wrote:
>>> . . like O Sensei, aka Morihei Ueshiba.
>>
>> Didn't know O Sensei was doing Ruby...  If I'm not mistaken he died
>> before Ruby was conceived.
>>
>> Anybody else in here doing Aikido?
>
> I do Tai Kwon Code

Ts ts ts - these martial arts spring into existence like flowers on a
fruitful soil these days... :-)

    robert
Jason S. (Guest)
on 2005-12-28 18:57
(Received via mailing list)
On 12/28/05, Robert K. <removed_email_address@domain.invalid> wrote:
> Anybody else in here doing Aikido?
>
>     robert

4 years in college.  3 more years about 10 after that.  Our dojo shut
down so now I participate in my daughters Taekwondo class instead (and
managed to break and sprain my ankle two months ago :( ).  I
definitely miss the grace, wonder and beauty of how Aikido works, much
like Ruby :)


Regards,
Jason
http://blog.casey-sweat.us/
Stephen Webb (Guest)
on 2005-12-28 22:41
(Received via mailing list)
15 years here.  The dojo is a short walk from my house :)

Steve
Chad P. (Guest)
on 2005-12-29 00:45
(Received via mailing list)
On Wed, Dec 28, 2005 at 09:42:53PM +0900, Jeremy H. wrote:
> Ruby, the official language of Aikido?
That works for me.  I love 'em both.

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

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
Chad P. (Guest)
on 2005-12-29 00:48
(Received via mailing list)
On Thu, Dec 29, 2005 at 05:40:34AM +0900, Stephen Webb wrote:
> 15 years here.  The dojo is a short walk from my house :)
>

I've got a similar situation with a Krav Maga and Kapop studio near me.
I'm thinking of going there twice a week next year.

Of course, now I'm wondering what language-to-martial-art
correspondences there are, aside from aikido and Ruby.

--
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.
Chad P. (Guest)
on 2005-12-29 00:51
(Received via mailing list)
On Thu, Dec 29, 2005 at 01:35:07AM +0900, Stephen Webb wrote:
> Ruby.
Okay, that's twice so far I've seen someone say something like this.
I'll take this at face value for a moment:

I was making a comparison to a well-known and much beloved octogenarian
that could kick ass, not saying O Sensei knew/liked Ruby (though, if he
were a programmer with a chance to "meet" Ruby, I daresay he might
have).

I no return you to your regularly scheduled . . . whatever.

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

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
Chad P. (Guest)
on 2005-12-29 01:46
(Received via mailing list)
On Thu, Dec 29, 2005 at 07:49:30AM +0900, Chad P. wrote:
>
> I no return you to your regularly scheduled . . . whatever.

Now.  I now return you.  Sheesh.

--
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.
Jeremy H. (Guest)
on 2005-12-29 14:38
(Received via mailing list)
On 2005-12-28, Robert K. <removed_email_address@domain.invalid> wrote:
> Anybody else in here doing Aikido?

I used to.  Reached blue belt.

Cheers,

Jeremy
This topic is locked and can not be replied to.