[Tutor] mentor neeeeeded(log file)

[Erik Price]

On Tuesday, August 27, 2002, at 01:44  PM, Alan Trautman wrote:

> Don't forget to write down how you think the program should function. 
> Then
> compare this to the problem you are having. It will help you learn how 
> your
> thinking and what the computer does can be combined to create 
> programs. A
> quick paper flow chart of what you want to happen is a great reference 
> as
> you create the code. Eventually if you really program a lot you will 
> learn
> that good programming begins with paper, background and research not 
> at the
> keyboard (something I need to remind myself as I rewrite code 
> ...again:( ).

This is really important.  I taught myself to program from some books, 
and I wrote my first "real" application in an easy language called PHP. 
  It was really nothing more than a specialized content management 
system for a company that I was temping for.  But as I learned more and 
more about programming, I realized that I had sort of gone about it the 
wrong way -- rather than come up with a good plan of what I wanted to 
do, I sort of just went and did it.  I finally finished it after a 
couple of months (it was many thousands of lines of code), but by that 
time I knew I would have done it completely differently than I had, if 
I had known everything that I then knew when I first started.  [Sorry 
that last sentence is a mouthful.]

The reason I tell you this isn't to make you think that it's hard to 
program, but rather to emphasize that, once you get past the stage of 
experimenting with and learning the basics, you will find that 
designing the program is really a major part of the job.  This seems to 
be especially true of larger programs.

I'm still learning to program, in fact, as you can tell from my posts I 
still have a lot of questions.  I thought that it would be a worthwhile 
lesson to try using UML.  I have taken a night job as a waiter in a 
restaurant and have been using a spreadsheet to keep track of my tips 
and sales.  When I find the time, I'm going to try to model a 
tip-tracking program, perhaps using a database like MySQL to store the 
data.  But I don't want to just jump in and do it (though that is very 
tempting), I'm going to try to map out my needs first, then determine 
the various entities in the application (database, user, tips, hours 
worked, taxes, etc), and then try to see the best way to reproduce 
those real-life relationships in a program.  Only after all of this 
will I actually sit down and write the code.

For such a simple application, this might seem like overkill.  Just 
remember that it's more of an exercise than anything else!  (It can 
probably be done entirely in one line using Perl, but... ;)



Erik