On motivating a Ruby nubie

ruby-talk
21

Why I want to learn Ruby is a pretty complecated topic. There are
subtleties of philosophy which I appreciate more than the other
things I've read through. The atmosphere of programming is something
I could readily cite.

Learning to program is a matter of finding myself increasingly
frustrated at using the solutions made by others. There are things
I'd like learn to do myself.. of note, I want to make a life manager
-- a to do list, with requirements and such which also acts like a
mind mapper, a wiki, etc.

···

On 4/13/05, Joe Van Dyk <joevandyk@gmail.com> wrote:

Why do you want to learn Ruby? Why do you want to learn to program?

--

On 4/13/05, James Toomey <jamesvtoomey@yahoo.com> wrote:

In my experience, the motivation comes from choosing something that you
really think would be neat and want to accomplish, not just a pretend
goal.

An excellent point, and I agree. The problem is when my ideas are a
LOT bigger than I could possibly begin working on. Right now, my
problem is with taking a huge and motivating idea and breaking it
into sensible chunks.. so I can work on small things which pay off now
while working towards something larger. I am having a hard time
envisioning the process. I keep stumbling over ideas which are too
intimidating to my skills or ideas not motivating for me to learn for
or from.

Therefore, I've found that you should do one of two things:
1) Create something that's very personal and enjoyable;
2) Create something that helps you do a needed task.

This seems to be the general concensus. I suppose what I need to define is:

Which of my problems,

* is small enough for me to understand a solution for
* is personal to me enough that I desire a personal solution

which has,

* other peoples' solutions for which I can model my own solution after

I'm not sure this thinking is complete..

I don't think I need to bother to think in terms of if I can learn
something valuable from a project like this.. it appears that
learning is a byproduct of the effort and shouldn't be directly
focused on. Heck, I should probably just have fun with the senseless
butchering of code and produce something useful as a byproduct.

It's those dead-end
points where you really learn, because that's when you web-search, and
ask questions, and web-search some more, and drop by Barnes & Noble to
browse the books, and stay late into the night taking "just one more
crack at it," and eventually you get it right, it feels great, and
you've learned a lot.

Strangely.. I've done this. I remember playing around with a mud
client which used a restricted tcl scripting command set. That was
fun, but I ran into many barriers for various reasons.

The other neat thing about designing a website is the minimal cost. You
can find a webhost who is Ruby-enabled and it probably wouldn't cost
more than $10-$20 a month, plus $10 for a domain name, and that's it!

Free. Without a doubt, I'd host it all myself. That's another
learning experience I'm beginning to appreciate. Yes, I'm looking at
web-enabled applications too.. I used to think that maybe that was a
big step for me, and yet I'm inspired by seeing things like Rails.

---

On 4/13/05, Chris Pine <glyconis@gmail.com> wrote:

Well, I did create a tutorial especially for nubies...

You're already high on my reading list. =)

the code samples are run every time you request the webpage

I *LOVED* this idea. That's just the kind of functionality I'd love
to see in a ruby wiki.

I think that, for me, it's a matter of taking any
tedious aspect in my life, and trying to see how programming could
help do that for me.

A few people have mentioned this. I can certainly see how this is a
good motivator. I myself slaved for far too many hours on a 4dos
script which learned the type of an archive and simply extracted it.
Yes, with thousands of archives and back in the day when there were
various kinds.. I wanted a tool which would do this simple task for
me.

Of course, the problem was that it got WAY out of hand.. and i started
meddling with other archiving software and integrating new
functionality. It was very neat.. but I passed the stage of solving
my immediate problem.

I think this is sortof how I learn though.. I go off onto random
tangents. The most valuable thing I've done so far is to try to be
as organized as possible so that when I go off on a tangent all of
that effort is saved.. so that I can always refer back to it later if
I wanted. Then I could just be a hummingbird trying stuff out.. and
every so often I'd take another pass at some old but still
interesting thing I worked on a while back.

- writing a music-organizing program so I can say things like "Play me
some upbeat jazz and lounge, but only stuff I haven't listened to
recently, but after two hours or so, tone it down to some mellow,
instrumental lounge... with a sprinkling of Stereolab"

This one's on my list of stuff to do as well. A proper database
relating all kinds of music based on mood, theme, preference etc..
then it could be smart and play music which sounds good to my present
mood, but it could shift the music mood slowly to something else.. so
I could wind myself down very easily using music. =)

Your time saving vs fun arguments are good. A lot of people speak on
the same issues.

22

This email seems to have bounced. My apologies if this is a duplicate post.

···

---------- Forwarded message ----------
From: Sy <sy1235@gmail.com>
To: ruby-talk@ruby-lang.org (ruby-talk ML)
Date: Tue, 19 Apr 2005 22:45:22 +0900
Subject: Re: On motivating a Ruby nubie
Just to follow up on this topic, I've finally begun my quest into
Ruby[1]. Instead of doing things the way I've always thought of
learning.. I decided to have my learning experience be the original
hobbyest approach.

You all remember when you were young and in love with some hobby or
other.. and you just hacked around with it and picked things up. This
learning process is "no big deal" and wasn't about "learning a skill
in 30 days" or "adopting a new skillset" or "adapting your portable
skills" or whatever other bs buzzphrase you want. It was about trying
something new and having a lot of fun.

Well I haven't lost that child-like mindset, so I spent some time
redefining my core motivations to just hack around at Ruby and learn
as I go. No hands on the handlebars for this one.

It all began with my rewriting a simple application launcher[2]. It
accepts an input and launches a command:

I recently adapted it so it'll work on Windows. I also looked at
wrapping it up into a standalone executable with tar2rubyscript[3] and
rubyscript2exe[4].

I'm focusing my learning so that in the next few weeks I can get a
basic installer[5] put together that will replace a simple batch file.
I hope to end up converting in into a GUI installer thingy using
WxRuby[6] (recommended by Erik Veenstra of tar2rubyscript fame). I
am hesitant to use it, but RubyWebDialogs[7] was also recommended
(well.. Erik did make it).

The important thing about all of that is that it's for work. Yes, I
have an opportunity to wriggle some Ruby scripting in work. I made a
couple of "bonus disks" for our main product, which stealthily inserts
additional content that the main developer is too lazy (!) to do
himself.. and the idea has been a huge hit and is one of the driving
forces of our success.

I wrote a batch file which has grown increasingly more complex. All
it really has to do is copy a tree of files into a specific directory
and delete a few files. I'd like to expand it to allow a
user-selected or automatically-detected directory. The big push is
that soon this'll need to work on a mac. So.. although there are
probably excellent products out there which do what I need, I figure
this is simple enough that I could write an installer in Ruby!

So I think I've met my learning goals with this..

* it's a real-world thing
* it's something I'm genuinely interested in
* it's easily defined and also has existing products for me to help
define what it should do and how it should look
* it starts both small and simple and can become complex as my
abilities improve.

I'm into my second week, and my enthusiasm hasn't wavered.. so I think
that I'll do well in the long term.

[1] http://sysy.homeip.net/mw/index.php/The_Ruby_Nuby
[2] http://sysy.homeip.net/mw/index.php/TRN_-Launcher
[3] http://www.erikveen.dds.nl/tar2rubyscript/index.html
[4] http://www.erikveen.dds.nl/rubyscript2exe/index.html
[5] http://sysy.homeip.net/mw/index.php/TRN-_Installer
[6] http://trug.stok.co.uk/wiki/index.php?title=WxRuby
[7] http://trug.stok.co.uk/wiki/index.php?title=RubyWebDialogs

23

You're already high on my reading list. =)

Oh, good!

The problem is when my ideas are a
LOT bigger than I could possibly begin working on. Right now, my
problem is with taking a huge and motivating idea and breaking it
into sensible chunks..

This is *extremely* challenging. Actually, this is ending up being
the hardest part of my book (which is, you know, about learning to
program... I'm a one-trick pony, what can I say :).

On the one hand, larger projects are more motivating and fun, but are
way too hard.

On the other hand, little toy programs are easy enough to be doable,
but are not terribly motivating.

On some other third mutant hand, breaking down a large program into
smaller tasks leads to a bunch of *totally* unmotivating programs,
like "convert this array of single-element hashes into arrays of
2-element arrays" or something. Who wants to do that??

UNLESS (I am fervently hoping) you happen to know that your weird
conversion program is in fact an integral part of a webserver/blog
program you have been told you are writing. You don't know which
part, but you've been told that at some point near the end of the
book, all of the pieces will come together and *poof*! A big, cool
program.

(My currently problem: being told to write the parts is one thing.
Figuring out what parts need to be written is something else
*entirely*. How do you teach this sort of design, or is this even in
the scope of a beginner's book on programming?)

Chris

···

On 4/13/05, Sy <sy1235@gmail.com> wrote:

24

Pimki?
http://pimki.rubyforge.org/

If you're set on making your own, it may well be worth looking into the guts
of this to see how it runs and/or hacking features you want on top of it.

Cheers,
Dave

···

"Sy" <sy1235@gmail.com> wrote:

Learning to program is a matter of finding myself increasingly
frustrated at using the solutions made by others. There are things
I'd like learn to do myself.. of note, I want to make a life manager
-- a to do list, with requirements and such which also acts like a
mind mapper, a wiki, etc.

25

Dave Burt wrote:

>
> Learning to program is a matter of finding myself increasingly
> frustrated at using the solutions made by others. There are

things

> I'd like learn to do myself.. of note, I want to make a life

manager

> -- a to do list, with requirements and such which also acts like a
> mind mapper, a wiki, etc.

Pimki?
http://pimki.rubyforge.org/

If you're set on making your own, it may well be worth looking into

the guts

of this to see how it runs and/or hacking features you want on top of

it.

Plus, I have it on good authority the author is amenable to patches :wink:

If you're interested in the guts, Pimki is an Instiki-Wiki base plus
general PIM features. It's currently being updated to the new Instiki
(modern rails based), and will hopefully be released soon -- with more
features -- as Pimki2.

Maybe not the greatest source of clean software in its current state,
but I'll be happy to answer any question you may have, and add to the
features list (developed in open source time - i.e. two hours past
midnight per day :slight_smile:

Cheers,
Assaph

···

"Sy" <sy1235@gmail.com> wrote:

26

UNLESS (I am fervently hoping) you happen to know that your weird
conversion program is in fact an integral part of a webserver/blog
program you have been told you are writing. You don't know which
part, but you've been told that at some point near the end of the
book, all of the pieces will come together and *poof*! A big, cool
program.

Faith isn't so good with someone who's just starting out. Everyone
knows that eventually it'll all come together.. and yet nobody trusts
that.

The best thing to do in life is to approach big issues one step at a
time. Sure there is the occasional pecking at a topic from
different angles, and there is some charging in and tackling huge
things.. but the best overall skill to learn in my opinion is
encapsulating
problems and approaching one at a time without being overwhelmed. I'm
just not quite sure yet how I should apply this to learning ruby. =)

What popped into my mind with your description is the idea of painting
by numbers. I think this should be applied in a tutorial sense.
Painting by numbers is approaching specific problems with specific
solutions while overall keeping in mind the end-goal. Each small
problem,
each lesson, each bite-sized chunk is one perfectly coloured area in
the whole picture. The *real* trick for the person designing that
structure is to be able to communicate to the painter the whole picture.

So you would need to take your completed project, and work it
backwards.. breaking it up into pieces and arranging them in order of
complexity and relatedness and all that easily-said but
horrifically-difficult stuff. Somehow it would have to be arranged in
order of
"shade".. related colours.. so that the student is provided things in
a more-or-less linear fashion.. they are building skills on top of
skills.. or building complexity into their earlier and simpler code.

The student's perspective is that they are given one problem at a
time, they are learning one thing at a time.. and as they progress
they are
slowly beginning to realise the interrelatedness of one problem to the
next to the next. At one point a good student should be able to
predict the use of the tools they are being shown.

All throughout all of this mess, somehow the student needs to have a
greater picture reinforced. When working on a puzzle, or a
paint-by-numbers picture, the person has a kind of reference always
available, assuring them that yes they've completed a part of the
whole,
and that part goes there.. and they are now working on the next part
over here.. etc. This is the motivation necessary for a truly
engaging
tutorial.

(My currently problem: being told to write the parts is one thing.
Figuring out what parts need to be written is something else
*entirely*. How do you teach this sort of design, or is this even in
the scope of a beginner's book on programming?)

There are a few schools of thought as far as the process of learning
goes. There are more than this list, but I'll just point out some
stuff
I found obvious just now when thinking about it.

* A teacher knows all and the student should model themselves after
the teacher's abilities.
* A student should learn from the mistakes of others.
* A student should explore on their own whenever inspired to do so.

The middle ground is to get a good introduction to concepts like best
practices, common problems, simple examples and form a basic set of
tools to work with. This should be the student's first priority and
should be addressed a good intro to programming.

All of the philosophies and strangeness just does not apply to someone
who is new to programming. Telling them that there is really no such
thing as a best practice will scare the hell out of them. Still, it's
good to say things like "we're going to approach this problem with a
simple common solution.. there are always different ways to solve one
problem, but let's keep it simple"

Ok, so the good perspective is that the student should have their
goals structured and still understand the greater, or more whole value
of
the skills. They should be given specific problems to solve a
specific way but they also need to learn to be creative. So they also
need to
be provided a workbook of things to do their own way.

We've all seen this with existing tutorials. I think that the
"workbook" side of things needs to be expanded a little.. enforced
some more.
I have found more value in my experimenting with the tools I've been
shown than with any other learning resource. I think most would agree
that skill is fueled internally.. anyone who is good at anything is
that way because of a fire they stoke themselves.

···

On 4/14/05, Chris Pine <glyconis@gmail.com> wrote:

--

On 4/14/05, Paul Hanchett <paulha@aracnet.com> wrote:

Sy wrote:

Hey Syeed-- Welcome to the fray! :wink:

Dammit, I've been found out! :wink:

Find a (small) project to do on your own and begin to write the code.
Make it simple to start. I began by rewriting the coWiki text parser in
ruby.

Holy crap man.. I didn't know you were a rubyist. And on this mailing
list. And working on stuff like that. Small world.

For the audience: Paul recently took the maintainer role for coWiki, a
wiki which I have a fairly long and strong love/hate relationship
with.. which had I the skills, I would have written myself, but
"better" (using my opinions, solving my problems), and in Ruby. =)

I started by using SciTE for it's ability to easily run the code I'm
editing. But I think I'm going to spend some more effort on working
doing the same with FreeRIDE, as it has more bells and whistles. :wink:
jEdit is also a choice. I don't like how long it takes to start
FreeRIDE and jEdit, SciTE is very quick and seems to understand about
many languages-- It will run PHP scripts, if the computer is set up for it!

Thanks for jogging my memory.. I need to go through some
tools/environment-related options.

--

On 4/14/05, Osuka Adartse <rocioestradacastaneda@prodigy.net.mx> wrote:

...keep wishing, keep wanting , keep
coding, remember to congratulate yourself everytime you succed, and try
harder when not(but take a rest,get away to gain a better perspective,
heck ask for help here).

Definitely there is concensus on the spark of inspiration which a
person finds within themselves, and on working on problems close to
onesself. Starting small is another good point.

On the note of achieving.. I think also that a more public database is
an incentive for me.. because sharing is a motivator.

--

On 4/14/05, Dave Burt <dave@burt.id.au> wrote:

"Sy" <sy1235@gmail.com> wrote:
>
> of note, I want to make a life manager
> -- a to do list, with requirements and such which also acts like a
> mind mapper, a wiki, etc.

Pimki?
http://pimki.rubyforge.org/

If you're set on making your own, it may well be worth looking into the guts
of this to see how it runs and/or hacking features you want on top of it.

I saw pimki but haven't tried it yet. I'm pretty sure that I would
end up needing to make my own solution, but definitely peeking inside
the
code of other projects with end up on my list. I don't think I'll
tackle this type of project anytime soon, but the first thing I'd do
before beginning a big thing is to research other approaches (even via
other tools) to learn how other people's UIs work, and learn of the
various other opinions on things.

--

On 4/14/05, Assaph Mehr <assaph@gmail.com> wrote:

If you're interested in the guts, Pimki is an Instiki-Wiki base plus
general PIM features. It's currently being updated to the new Instiki
(modern rails based), and will hopefully be released soon -- with more
features -- as Pimki2.

Maybe not the greatest source of clean software in its current state,
but I'll be happy to answer any question you may have, and add to the
features list (developed in open source time - i.e. two hours past
midnight per day :slight_smile:

Here's what I know about myself so far:

* I have a bad memory

* I am organized (necessary due to my bad memory)

* I learn easily

* I like to experiment.

* I forget easily (if unused, my skills evapourate.. leaving ineffable
"portable skills")

* The only thing truly saving my learning and experimenting efforts is
my organization.

* I work well with others (willing to listen, wanting to learn,
appreciating opinion)

* I write "too much". I like to discuss angles, get opinions and
understand a larger picture. This makes threads go off into wild
tangents
and all kinds of fun stuff. I'm getting much better by not repeating
the same argument over and over.. heh.

* I don't colour in the lines (I go into tangents easily)

* I am strangely opinionated and desire to see my problems solved.

So this means that I am an excellent team member, but motivated
towards my own goals. I am an unherdable cat. I would desire to help
with
project but would only be motivated while the project direction meets
my needs. I would go off into tangents because my opinion would have
me work on problems of interest as opposed to team goals. I would
always be driven to do things myself, and yet I wouldn't want to
manage a
project.

So looking at someone else's code would always have me want to do it
all myself.. and patching, while a good idea, would always be
secondary
to my redoing the entire project myself. Actually.. I think I'd be
more interested in forking someone else's work and fixing it up myself
than helping fix that project. I tend to see things in terms of "tool
x works, but feature y doesn't work how I'd do it, or feature z is
missing. This is probably a bad wrinkle of a habit which I'll have to
iron out. I should prefer to patch rather than fork.