NYCPHP Meetup

[Gary Mort]

One thing that has annoyed me more and more over time is the way books 
and classes go about teaching /how/ to program in a language.

They all start off with "Hello World" and then progress slowly form 
there to more and more complicated things.  I've noticed that even Ruby 
books, the poster child for unit testing, proceed in this manner.

In short, they wait until /after/ someone has developed bad habits and 
then introduce version control and unit testing as an afterthought.

It seems to me that the /correct/ way to teach programming is to start 
with a little version control, then do a little unit testing, and then 
proceed to the coding.  Especially useful is to structure the course so 
that the users experience just /why/ version control and unit tests are 
a good thing.

As such, I'm going to try to put together a course on learning to 
program PHP the right way.

It starts off with learning a minimal number of git commands[you don't 
need to know them all, and there is no reason to confuse yourself at 
this point!  All you need are "git clone...", "git commit...", and "git 
push..." while not necessary is a nice to have.  This unit will include 
cloning an existing code repository on github, making a change, and 
commiting your change.

The code should include a class or two /and/ some incomplete unit tests 
for said class.

The next step is learning some basic unit test commands, run the unit 
tests on the code to see them working, demonstration of how to run the 
checks so you can see what methods are not currently covered by unit tests.

Unit tests are fairly trivial bits of code, so the first introduction to 
coding will be to add the missing unit tests.  Verify the addition.  
Commit the changes.

After that, we can do the traditional "hello world" app....the RIGHT 
way, ie make a unit test for it, then implement it.  Verify the new 
code.  Commit the changes.

Next up will be making some major functional changes to the code, 
extending it, expanding it, etc.  At this point, we should be doing some 
fairly radical, but simple, changes to the code where we will be 
deleting entire sets of logic and replacing them with new sets - 
including changing the unit tests first!  Verify the new code.  Commit 
the changes.

Following all these changes, we will now have to undo some of the 
modifications and use the original code....  so a quick review now of 
how to use git to browse through previous commits, review differences in 
code, etc.  And of course, as always start with unit tests, verify the 
changes, commit the changes.


As you can see from the above, this also explains /why/ programming 
books suck so much.  It's a lot of extra verbage to go step by step 
through the testing/commit process - and programmers are by nature 
lazy!  So they skip it.

I'm curious if there are any other items people think should be 
incorporated into this tutorial.