On motivating a Ruby nubie

[Sy]

Hey all. I wanted to dive into a topic that's been on my mind for
years. I've been interested in programming for a very long time and
yet somehow I've only ever dabbled.

* I've never been forced to learn anything through school (a half-year
of turing and another half of ms access 1.0 does NOT count). Frankly,
I do not respect school for learning real programming skills and would
never pay someone money to teach me something I could learn by myself
for "free" (buying books, taking the time, searching for answers
myself).

* I've never used such skills at work (batch files don't count). I
don't think I'll ever do anything programming-related until _after_ I
learn the skills and choose to use it. Honestly, I have an
opportunity to sneak in Ruby in my (small) business.. if it does the
job. Ruby on OSX gives us extra motivation too.

* I've never had motivation to program as a hobby (batch files and
4dos scripting doesn't count, vague interest in c or asm/machine
language doesn't count). I have no problems which I see solved by
programming myself more than using someone else's tool. So instead of
developing the programming skills, I have developed effective
researching and troubleshooting skills.

And yet where I see that my problems can be solved by other people's
tools.. I feel as though I could make better tools myself. I
especially want to be able to create scripts and software solutions
for some of my stranger issues. I already know that I can be valuable
to the community being who I am and having the skills I do, but I
yearn to do more.. to solve problems MY way.

---

And so after a lot of thought I ended up looking seriously at Ruby.
Lots of time passed and I revisited the subject to learn that a
community had self-organized, that issues with documentation and such
were being solved, that entertaining tutorials were being written
(props to wtls on that one).

Fine. I like Ruby. I want to learn Ruby. How do I work on the
problem of motivation?

Hack a little every day? Read a little every day? What books, what
tutorials, what news channels? I am not overwhelmed by the amount of
choices.. but I am confused at what order to do things in and why.
The biggest challenge to a complete nubie is the number of tools Ruby
uses..

I had a hand in resurrecting my local RUG. We had our seventh meeting
this month and every time feels like a real success. I did all this
knowing that I wasn't a "real programmer" and that.. I don't know
Ruby! I look back and wonder where all the time went.

I'm a smart guy, so I am making do.. I am learning what I can but I
don't feel _effective_ or _motivated_. I don't want my hand held, I
just need a guiding light.


Has anyone thought about founding a "Ruby nubie" mailing list or
creating nubie-sized short-tutorials, quizzes and challenges? I'd be
very interested in participating.

 

[James Edward Gray II]

Fine. I like Ruby. I want to learn Ruby. How do I work on the
problem of motivation?

That's a pretty personal issue and I doubt I have any helpful advice.

When I was younger, I wanted to do all my programming projects with my
friends, who were only lightly interested. We never really completed
anything. One day, I just got tired of that and started working on
things alone (when I couldn't get help) and getting things done. I
don't know what changed; something just snapped internally. You have
to have to find the motivation for yourself and just dive in!

On the positive side, I do think it gets easier the more you do. When
I build something and see how perfect it came out (yes, I have an ego
problem), I feel like I can do anything and I want to, right now! I'm
working on as many programming projects as I can possibly juggle while
still leaving a little room for sleep and I have ideas for my next 604
projects. You just have to get the ball rolling...

Hack a little every day? Read a little every day? What books, what
tutorials, what news channels?

In my opinion, there is one true secret to learning to program. Ready?
Here comes all my ancient wisdom in one rule:

Write code.

Yes, I read a lot of books and yes they really help. However, it's my
opinion that there is simply no substitute for quality time spent
talking to a compiler. For me, that's the key.

(When you get more experienced the rule changes to "Read code.", but
that's another topic...)

Has anyone thought about founding a "Ruby nubie" mailing list or
creating nubie-sized short-tutorials, quizzes and challenges?

Not really an answer to your question, but I welcome beginner quiz
material submissions to Ruby Quiz. Next week's quiz is a nice early
project, I think. Everyone is welcome to send in more.

Good luck and I hope you find what you're looking for!

James Edward Gray II

 

[Dave Burt]

That's a pretty personal issue and I doubt I have any helpful advice.

When I was younger, ...

I wrote games. Blackjack is good, because you can fairly easily get a
computer dealer to challenge you at the game.

Write code.

I agree.

For books, I recommend Why's (Poignant) Guide to Ruby, which is a hilarious
romp through the Ruby language.

The Quiz provides a few ideas for places to start writing code, too.

Instead of games and other people's quiz suggestions, you could also rewrite
something you've already written (i.e. those batch files, or anything you've
done in C) or, perhaps even better, build something you need. If you can
identify a repetitive computer-based task you do a lot, if you can imagine
that some of the repetition could be relieved, figure out how. Ask this list
when you're stuck - we love to help with this kind of thing.

And here's something you might not hear too much around here: not everyone
is a programmer. Not everyone even ought to be a programmer. If there other
skills that are more important to you practically or however else, work on
those. Nevertheless, programming is a useful skill in a bunch of ways, and
is quite easy (IMHO) to learn to the stage where it becomes useful.

All the best,
Dave

 

[Rob .]

In my opinion, there is one true secret to learning to program. Ready?
Here comes all my ancient wisdom in one rule:

Write code.

I agree: write code

In the past to learn a new language or technology I've thought up a
personal project to work on, which gave me motivation to achieve a
certain goal.

Contributing to or starting your own open source / free software
project makes things more exciting as there is the potential others
might start using your code. This can be a great motivational aid -
careful though, it can become addictive!

Cheers,
Rob

 

[Sy]

another peice of advice : share your work. it's suprising how motivating it
is knowing others will/might be reading/using your code and it also encourages
you to abstract your problem into a more general solution which, 98% of the
time, leads to a more elegant solution as well.

I'm thinking along the lines of keeping a learning journal / snippets database.


--

Yes, I read a lot of books and yes they really help. However, it's my
opinion that there is simply no substitute for quality time spent
talking to a compiler. For me, that's the key.

Ok.. so a little bit of coding every day.. finding little snippets to
learn and log.. keeping a bit of a database of my efforts so I don't
have to revisit the wheel. Sounds good.

(When you get more experienced the rule changes to "Read code.", but
that's another topic...)

That's still very necessary.. since people who are new and
enthusiastic will commonly turn to code examples for sections to
steal. Just take a look at everyone's experimentation with
mod_rewrite.. I know the first thing I did was borrow someone's
solution to jurryrig it to my own setup. It worked too.. but of
course the real learning has to begin when I break my setup and the
rewrite doesn't work.

So in the short run, ruby code is excellent to learn stuff from.. and
to borrow.. but as soon as my inventiveness kicks in and I shuffle a
design around it'll break all my borrowed code.. forcing me to learn
enough to rewrite those parts (and to learn proper coding practices,
troubleshooting skills.. and all that good stuff).


--

I agree: write code

Contributing to or starting your own open source / free software
project makes things more exciting as there is the potential others
might start using your code. This can be a great motivational aid -
careful though, it can become addictive!

Starting a project, especially an open project, is way away from my
current inspiration. I think maybe little embarrasing personal
projects which are coded in the open air would do pretty well. I
still have a kind of learning weblog thingy in mind.


--

For books, I recommend Why's (Poignant) Guide to Ruby, which is a hilarious
romp through the Ruby language.

I noted that. I read through some of it.. I understand some of it.
While it certainly cheers me up and gives a good introduction and
such.. It's not motivating in the least. It got very horrible very
fast and I've no intention to finish it until I can make better use of
the early chapters.

What I think I'm going to do is step back and begin to write my own
tiny tutorial as my learning tool. I'll grab some code snippets and
make them do stuff.. and write notes to myself as to how things work
and why. With this, I should be able to dump in various learning
examples and such. It should work out ok. I figure I can get away
with this functionality on my existing wiki.

Maybe (one day) my "big project" should be a simple ruby weblog? It's
a fairly straightforward concept.. but with lots of curious
intricacies that could keep me very occupied.

Instead of games and other people's quiz suggestions, you could also rewrite
something you've already written (i.e. those batch files, or anything you've
done in C) or, perhaps even better, build something you need. If you can
identify a repetitive computer-based task you do a lot, if you can imagine
that some of the repetition could be relieved, figure out how. Ask this list
when you're stuck - we love to help with this kind of thing.

I'm wondering if I can rewrite some of the crap I had tinkered with in
ruby. There isn't much point.. many of those tools are too specific
to DOS.. and I don't really use any of that anymore.

Maybe the most productive thing to think is that I would like to see
Ruby as my problem-solver for my not comprehending bash and most shell
tools.

Much of it would be reinventing the wheel. But in doing so I would be
learning ruby, solving my problems and .. well doing things in ruby
for others to maybe learn from too.

Some simple ideas:

* Search through directories, looking for file 'x'

* search through files in directories, looking through their contents for 'x'

* file split/merge

* simple backup solution

* disk / directory / file reporting -- which directories have the most
files.. which take the most space.. etc.

* Appointment book / calender

* clock / scheduler

 

[Tanner Burson]

I'm thinking along the lines of keeping a learning journal / snippets database.

--



Ok.. so a little bit of coding every day.. finding little snippets to
learn and log.. keeping a bit of a database of my efforts so I don't
have to revisit the wheel. Sounds good.


That's still very necessary.. since people who are new and
enthusiastic will commonly turn to code examples for sections to
steal. Just take a look at everyone's experimentation with
mod_rewrite.. I know the first thing I did was borrow someone's
solution to jurryrig it to my own setup. It worked too.. but of
course the real learning has to begin when I break my setup and the
rewrite doesn't work.

So in the short run, ruby code is excellent to learn stuff from.. and
to borrow.. but as soon as my inventiveness kicks in and I shuffle a
design around it'll break all my borrowed code.. forcing me to learn
enough to rewrite those parts (and to learn proper coding practices,
troubleshooting skills.. and all that good stuff).

--




Starting a project, especially an open project, is way away from my
current inspiration. I think maybe little embarrasing personal
projects which are coded in the open air would do pretty well. I
still have a kind of learning weblog thingy in mind.

--



I noted that. I read through some of it.. I understand some of it.
While it certainly cheers me up and gives a good introduction and
such.. It's not motivating in the least. It got very horrible very
fast and I've no intention to finish it until I can make better use of
the early chapters.

What I think I'm going to do is step back and begin to write my own
tiny tutorial as my learning tool. I'll grab some code snippets and
make them do stuff.. and write notes to myself as to how things work
and why. With this, I should be able to dump in various learning
examples and such. It should work out ok. I figure I can get away
with this functionality on my existing wiki.

Maybe (one day) my "big project" should be a simple ruby weblog? It's
a fairly straightforward concept.. but with lots of curious
intricacies that could keep me very occupied.


I'm wondering if I can rewrite some of the crap I had tinkered with in
ruby. There isn't much point.. many of those tools are too specific
to DOS.. and I don't really use any of that anymore.

Maybe the most productive thing to think is that I would like to see
Ruby as my problem-solver for my not comprehending bash and most shell
tools.

Much of it would be reinventing the wheel. But in doing so I would be
learning ruby, solving my problems and .. well doing things in ruby
for others to maybe learn from too.

Some simple ideas:

* Search through directories, looking for file 'x'

* search through files in directories, looking through their contents for 'x'

* file split/merge

* simple backup solution

* disk / directory / file reporting -- which directories have the most
files.. which take the most space.. etc.

* Appointment book / calender

* clock / scheduler

Strangely enough, I often find that re-inventing the wheel is exactly
what helps me learn the most. I pick something I find at least useful
to me, then attempt to implement it myself, "fixing" anything I
disliked about the original. This method helps me have a clear "end
case" in mind, otherwise my projects tend to ramble on and never
really get finished.

 

[Joe Van Dyk]

Hey all. I wanted to dive into a topic that's been on my mind for
years. I've been interested in programming for a very long time and
yet somehow I've only ever dabbled.

---

And so after a lot of thought I ended up looking seriously at Ruby.
Lots of time passed and I revisited the subject to learn that a
community had self-organized, that issues with documentation and such
were being solved, that entertaining tutorials were being written
(props to wtls on that one).

Fine. I like Ruby. I want to learn Ruby. How do I work on the
problem of motivation?

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

 

[Glenn Parker]

In my opinion, there is one true secret to learning to program. Ready?
Here comes all my ancient wisdom in one rule:

Write code.

Let's not forget: Read good existing code.

Learning to write code is much like learning to write in "natural"
languages. I'm not saying software is directly analagous to literature,
but the learning processes are quite similar. You can't learn to write
without writing, but you can't learn to write *well* without reading.

As for motivation, it will not come from outside your own head. If
there is something you really want to accomplish that requires learning
to program, then you will find the necessary motivation. Find a
pragmatic goal, and the rest will follow.

 

[Sy]

Well.. I started a little project for this idea:

http://sysy.homeip.net/mw/index.php/The_Ruby_Nuby

Strangely enough, I often find that re-inventing the wheel is exactly
what helps me learn the most. I pick something I find at least useful
to me, then attempt to implement it myself, "fixing" anything I
disliked about the original. This method helps me have a clear "end
case" in mind, otherwise my projects tend to ramble on and never
really get finished.

That's exactly what I was thinking myself. There's always some piece
of me that thinks it's kindof dirty.. and possibly even insulting to
the original author. But what else can be done? I don't want to be
unhappy because of someone else's solution to a problem.

Maybe one day I can implement 4DOS scripting with Ruby.. but I'll
start with small problems and their simple tools.


--

Find a pragmatic goal, and the rest will follow.

Excellent point.

 

[Chris Pine]

Has anyone thought about founding a "Ruby nubie" mailing list or

creating nubie-sized short-tutorials, quizzes and challenges?

Well, I did create a tutorial especially for nubies (people who have
never programmed in *any* language, I mean). You might want to check
it out:

http://pine.fm/LearnToProgram/

It starts very gently, and has lots and lots of examples. Also, the
examples are all guaranteed correct: the code samples are run every
time you request the webpage! (So you can reload the random number
examples and see different outputs, for example.) In fact, the whole
tutorial is actually being generated by a Ruby program. It seemed
appropriate.

As far as motivation is concerned, I must admit that I have the
opposite problem: I'm notivated in for more directions that I have
time to work on! 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. At first, perhaps it's harder to see what
aspects of your life could be made easier by programming, but with
practice you'll start to see things all over. Right now I am:

- updating our website, all of the pages of which are generated by
Ruby (why not just write the html? because the pages are
automatically updated every time we add new pictures to our site,
which we do daily, so writing it Ruby has already saved us countless
hours of work (it generates thumbnail, too))
- writing a program to turn vaguely-logo-like instructions into a nice
truetype programmer's font (monospaced, no 0-O confusion, etc) and
it's almost done! you'll never "courier new" again!
- 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"
- writing an interpreter for a language I have been playing with...
certainly no Ruby competitor, but it's been an unparalleled learning
experience
- writing a book on Ruby

So those last two aren't really saving me any time... they are more
just for fun. I don't know what to tell you about those... hopefully,
once you learn more Ruby and use it to save yourself time, and you
have fun doing it, you might be motivated toward more "just for fun"
projects.

Best of luck, in any case,

Chris

 

[James Toomey]

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. If you just play the "what if" game and pretend that you're, say,
designing a grocery store inventory system, you'll peter out rather
quickly. You'll hit some difficult problem and say to yourself, "this
is dumb--why am I bothering with this? I don't work for a grocery store
and I find inventory rather mundane, plus there are thousands of great
programs that could do this better." Also, making something you want to
see, rather than following through tutorials, works better in my
opinion because you seek out knowledge that you know you need; with
tutorials, you're given knowledge and left to decide whether and when
that knowledge will be helpful.
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.
What I mean by #1 is to make something that you'd love to see,
something like writing your own video game or making an interactive
website. Making a website is perfect because you have a built-in
audience of the entire world. When I was learning ASP programming years
ago, I built a hiking website where you could choose the difficulty of
the hike you wanted, and the site would then query a database to
retrieve the results. Had I chosen to design a pretend-Ebay with
auction bidding, or some other fake e-commerce site like you learn in
so many tutorials, it would've taught me the same skills, but I
wouldn't have been motivated enough to struggle through the hard parts
to accomplish anything, and thus wouldn't have learned. It just
wouldn't have meant enough to me to create a bidding site because
auction-bidding doesn't interest me. However, hiking does interest me,
so I struggled through those parts and learned. 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.
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!
You can make an interactive website on any topic you love, learn a lot
of Ruby in the process, and millions of web surfers in the US, Italy,
Russia, England, Argentina, etc. can see it. How cool is that?
Now, regarding #2, I agree that many tasks can be done by existing
tools if you search for them. For example, you could write a Ruby
script to find/replace in text files, or you could find a freeware
program like "fgrep" to do the same thing, so you probably feel like,
"why should I bother writing code when I have a tool that can do
this?". In my experience, there will eventually be some annoyance or
wrinkle even with the tools that requires weird maneuverings on your
part--like a tool that requires files to always be put in a certain
folder, or doesn't search subfolders, or must be secondarily processed
by a subsequent program after the first one. A good example is photo
resizing. My 6 megapixel digital camera takes large photos which must
be sized smaller to be emailable. Adobe Photoshop does do batch
resizing, but it costs $700. There are freeware programs like
ImageMagick to do this, but you need to memorize lots of confusing
command-line switches. There are freeware GUIs built on top of the
freeware resizer, but they're frequently as confusing as using the
command-line. I faced this dilemma and finally wrote a Ruby GUI on top
of ImageMagick that just includes the parts that I need, so it's simple
to use and customized to exactly what I want. 3 weeks from now, when I
want to do more image resizing, I don't need to relearn all the
command-line switches, I can just use my nifty little program.
Designing your own Ruby tool can be frustrating if you're starting from
knowing nothing, because there are so many "gotchas" to get past and
disparate things to learn; it's one of those situations where you
"don't know what you don't know," so you're not even sure where to
start. If this is the case, try looking for some text-based task that
you do repeatedly and is somewhat cumbersome. Do you ever have a list
of names that you need to sort and remove the duplicates from? Or do
you ever have 2 lists of names and you want to find out the
intersection of the lists (that is, which names are in common)? Or a
list of numbers formatted as 3101234567 and should be formatted as
310-123-4567? These are things that can certainly be done with
Microsoft Word or Excel, but they can require an awful lot of manual
steps like sorting, replacing, sorting again, etc. These are tasks that
are great for learning Ruby because Ruby's arrays are powerful and easy
to use (far easier than VB and other languages), and only require 3 or
4 lines of code to do useful things. It can take longer the first time
because you're learning how to write the code, but once you've written
the code it will save you time everytime after that.

 

[why the lucky stiff]

I noted that. I read through some of it.. I understand some of it.
While it certainly cheers me up and gives a good introduction and
such.. It's not motivating in the least. It got very horrible very
fast and I've no intention to finish it until I can make better use of
the early chapters.

Can you spell out any of your criticisms further? I've never written a
book before and I'm sort of guessing as to what really works.
Genuinely, I thought of recommending the book here (except that it's
incomplete) since the motivation provided by my book is in the
narrative. The story motivates learning because our right brain and
left brain both become engaged.

But I can't presume to know for sure. It's an experiment that I only
hope will click.

_why

 

[Sy]

Can you spell out any of your criticisms further? I've never written a
book before and I'm sort of guessing as to what really works.
Genuinely, I thought of recommending the book here (except that it's
incomplete) since the motivation provided by my book is in the
narrative. The story motivates learning because our right brain and
left brain both become engaged.

But I can't presume to know for sure. It's an experiment that I only
hope will click.

The tone of the writing somehow changes. It's very difficult to put a
finger on. Early on there is a kind of lighthearted exploration and
comedy, but later on it really does feel like you're reaching. The
volume of insanity increased for me as I progressed.

There was a signal:noise ratio which at the beginning meant that I
could be plesantly distracted by both relevant and irrelevant things
inbetween the fairly serious bits. This was extremely valuable to me
as the entire notion of sitting down and learning a programming
language is intimidating.

Basically, a regular person -- nomatter how enthusiastic -- has an
attention problem. Their head gets full. They run up against big
ideas they can't quite process. Some people are stubborn enough to
think to themselves that they'll digest the ideas later and so they
press on.. reading even more.

In the traditional environment, that's suicide.. a person isn't
building on a good foundation. That's like skipping out of math
class.. there are concepts a person would miss out on which are
assumed to be understood later. This is even more visible when
learning programming. So the idea of introducing intentional "noise"
with both relevant and irrelevant topics, side-notes, pictures, etc..
really helps force the most enthusiastic person to pause from their
thinking about the learning and gives them just enough time to have
that all trickle in.

Your notion about left/right brains is a good one.. I found myself
thinking one way and then I was thinking another way.. while the other
side of me healed from the brutality that is learning.

Now later on in the subject matter there is an increasing amount of
complexity. You began building on the earlier-laid foundation.

The unfortunate thing is that people like me figure we're smart and
can continue to follow along without doing much ruby hacking on our
own time. This is a serious overestimation of ability. I'm actually
a complete idiot and I should have repeatedly taken additional breaks
to think about things, experiment in my own time.. my brain needs time
for the swelling to come down. =)

Now I didn't read it all in one sitting.. I did take breaks.. and I
did experiment. But I didn't quite have the set of tools I should
have had to take full advantage of those breaks. This is the gap I'm
trying to fill in here.

Ok, the subject matter got more complex. This brings many problems.
However, the lunacy-level also increased somewhat exponentially. The
signal dropped from the complexity, and the noise was raised by the
irrelevance of the distraction. I suppose my issue is that the
"quality of noise" was reduced.. it was not topical enough.

My basic problem with the complexity later on stems from my not
building a good foundation earlier on.


Frankly, that narration of yours is why I got into Ruby. Thanks.

 

[Sy]

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

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.


--

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.


---

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.

 

[Paul Hanchett]

Hey all. I wanted to dive into a topic that's been on my mind for
years. I've been interested in programming for a very long time and
yet somehow I've only ever dabbled.

Hey Syeed-- Welcome to the fray! ;-)

Fine. I like Ruby. I want to learn Ruby. How do I work on the
problem of motivation?

Hack a little every day? Read a little every day? What books, what
tutorials, what news channels? I am not overwhelmed by the amount of
choices.. but I am confused at what order to do things in and why.
The biggest challenge to a complete nubie is the number of tools Ruby
uses..

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.

It's sort of like learning any language-- Put yourself in a position
where you need it and you will learn it.

The people here are very good at answering reasonable questions. *I*
haven't gotten flamed yet! ;-)

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. ;-)
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!

Paul

 

[Chris Pine]

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

 

[Osuka Adartse]

Hey all. I wanted to dive into a topic that's been on my mind for
years. I've been interested in programming for a very long time and
yet somehow I've only ever dabbled.

* I've never been forced to learn anything through school (a half-year
of turing and another half of ms access 1.0 does NOT count). Frankly,
I do not respect school for learning real programming skills and would
never pay someone money to teach me something I could learn by myself
for "free" (buying books, taking the time, searching for answers
myself).

* I've never used such skills at work (batch files don't count). I
don't think I'll ever do anything programming-related until _after_ I
learn the skills and choose to use it. Honestly, I have an
opportunity to sneak in Ruby in my (small) business.. if it does the
job. Ruby on OSX gives us extra motivation too.

* I've never had motivation to program as a hobby (batch files and
4dos scripting doesn't count, vague interest in c or asm/machine
language doesn't count). I have no problems which I see solved by
programming myself more than using someone else's tool. So instead of
developing the programming skills, I have developed effective
researching and troubleshooting skills.

And yet where I see that my problems can be solved by other people's
tools.. I feel as though I could make better tools myself. I
especially want to be able to create scripts and software solutions
for some of my stranger issues. I already know that I can be valuable
to the community being who I am and having the skills I do, but I
yearn to do more.. to solve problems MY way.

---

And so after a lot of thought I ended up looking seriously at Ruby.
Lots of time passed and I revisited the subject to learn that a
community had self-organized, that issues with documentation and such
were being solved, that entertaining tutorials were being written
(props to wtls on that one).

Fine. I like Ruby. I want to learn Ruby. How do I work on the
problem of motivation?

Hack a little every day? Read a little every day? What books, what
tutorials, what news channels? I am not overwhelmed by the amount of
choices.. but I am confused at what order to do things in and why.
The biggest challenge to a complete nubie is the number of tools Ruby
uses..

I had a hand in resurrecting my local RUG. We had our seventh meeting
this month and every time feels like a real success. I did all this
knowing that I wasn't a "real programmer" and that.. I don't know
Ruby! I look back and wonder where all the time went.

I'm a smart guy, so I am making do.. I am learning what I can but I
don't feel _effective_ or _motivated_. I don't want my hand held, I
just need a guiding light.


Has anyone thought about founding a "Ruby nubie" mailing list or
creating nubie-sized short-tutorials, quizzes and challenges? I'd be
very interested in participating.

Just my personal 2 cents:

As a non programmer I decided to learn Ruby and in the past a bit of c
php and tried lots of langs. What has been the drive? I had a simple but
repetitive task or a desire to organize stuff or wanted a
simple-to-not-so-simple personalized app/script/utility.

Things are personal while learning on your own. Personally I like to
learn just for the sake of it,but that's me, maybe applies to You maybe
not. But one thing I can assure You; if You have a need an Ruby can
solve it, the way to go is: coding, experimenting with code ,testing
snips of code, but above all: coding!.

Find little needs that You have, even if silly(hey!! it has worked for
me). i.e. "Damn I got this lot of files containing lyrics and I would
like to ensure that the filename is *always* "Artist - The Name of the
Song.lyr", well make a lil' util, done!, mmmh now I would like that
those would get organized in a base directory c:\stuff\lyrics with
subdirs a,b,c,d,e,f...z and have subdir a containing the lyrics of
artists whose name start with 'a',done!...well what about having a local
website! or those lyrics in a db or ...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).

*start small*, You'll get more and more ambitious about your "needs" and
better at designing how the code would be.

*when feeling stuck* Every time You have doubts how to "do x" don't
overthink,plan,etc. instead type code and experiment, todays lame
experiments migth be tomorrows clever solutions.

*code and achieve* nothing motivates *me*(and maybe others) like getting
something done, the feeling of "Damn I'm good" and "whoaa I solved it
myself". Since You're solving small problems that *YOU* have, motivation
shouldn't be a problem, keep getting ambitious and You'll keep on coding
and (hopefully)getting better at it.

now back to porting that eruby app to Rails...(experimenting phase ;-))
Greetings
Adartse.

 

[Dave Burt]

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.

Cheers,
Dave

 

[Assaph Mehr]

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 ;-)

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

Cheers,
Assaph

 

[Sy]

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.


--

Sy wrote:

Hey Syeed-- Welcome to the fray! ;-)

Dammit, I've been found out!

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


--

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


--

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.


--

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

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.