From: Sy Date: 2005-04-14T15:46:54+09:00 Subject: Re: On motivating a Ruby nubie On 4/14/05, Chris Pine wrote: > > 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, Paul Hanchett wrote: > 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. -- On 4/14/05, Osuka Adartse 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 wrote: > "Sy" 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 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 :) 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.