From: Paul M Foster on
On Fri, Apr 23, 2010 at 07:15:11AM -0400, David McGlone wrote:

> Is there a good strategy to studying PHP?
>
> For instance, is there a way to break everything down into small managable
> topics?

Obviously, a good book will help. I'd recommend O'Reilly's "Programming
PHP". Some of this also depends on whether you have a background in
programming. It's easier if you already know how to code in a different
language; then you really mostly need to know the differences between
the languages.

If you want to learn without the benefit of a book, then I'd suggest
looking over existing beginning programming books for various languages.
My observation is that they generally follow a pattern. They deal with
variable naming and types, then legal operations on those types, then
control structures, then functions, etc. (That may not be accurate; as I
said, look over the books themselves.) Most/all of this information can
be obtained from the php.net site.

Ashley's suggestion of coding a project is an outstanding idea. Coding
is a practical art, and requires practical application to be worth
anything.

Paul

--
Paul M. Foster
From: David McGlone on
On Friday 23 April 2010 10:15:46 Paul M Foster wrote:
> On Fri, Apr 23, 2010 at 07:15:11AM -0400, David McGlone wrote:
> > Is there a good strategy to studying PHP?
> >
> > For instance, is there a way to break everything down into small
> > managable topics?
>
> Obviously, a good book will help. I'd recommend O'Reilly's "Programming
> PHP". Some of this also depends on whether you have a background in
> programming. It's easier if you already know how to code in a different
> language; then you really mostly need to know the differences between
> the languages.
>
> If you want to learn without the benefit of a book, then I'd suggest
> looking over existing beginning programming books for various languages.
> My observation is that they generally follow a pattern. They deal with
> variable naming and types, then legal operations on those types, then
> control structures, then functions, etc. (That may not be accurate; as I
> said, look over the books themselves.) Most/all of this information can
> be obtained from the php.net site.
>
> Ashley's suggestion of coding a project is an outstanding idea. Coding
> is a practical art, and requires practical application to be worth
> anything.

I have coded a couple sites. One for my brother-in-law, but I hate that site
so bad, I'm ashamed to even say I did it.

He chose the layout and colors and told me exactly where he wanted everything,
and it's IMHO absolutely horrible.

There is some code that I wrote for that site that did make me feel good for
coming up with and although it works, most of the code for that site gets on
my nerves. It gives me the feeling that it's very unorganized, and poorly
written.

--
Blessings,
David M.
From: tedd on
At 3:01 PM +0100 4/24/10, Ashley Sheridan wrote:
>I look at some code I did a while back and shudder. It started off well
>enough, but then feature creep set in and now it looks like a creation
>of Frankenstein! I think it happens to all of us at some point, it just
>depends how well we deal with it. I'd rather have less then stellar code
>than have to tell a client it's going to take more time to add a feature
>and then have them go elsewhere.
>
>Thanks,
>Ash

Ash et al:

Wait until you have 40 years of code to look back at. I'm not ashamed
of any of any of my code for it was "best" that I could do I with the
equipment I had.

Of course, reviewing the web sites I did in 1995, and comparing them
with with I do today gives me pause. However, the tools that were
available then were not what they are today.

So, when you are reviewing/analyzing your past work, you really have
two things to consider: 1) What you created; 2) and the technology of
the time.

Cheers,

tedd


--
-------
http://sperling.com http://ancientstones.com http://earthstones.com