NYCPHP Meetup

[Rukbat]

I have to strongly second this.  Learning programming means learning 
algorithms and data structures.  Learning the job a programmer does 
includes version control, unit testing and many other things.  Learning 
a language or ten is one of those other things, but it's not part of 
learning programming, it's learning syntax.

Being a competent professional programmer means learning all of them, 
but version control doesn't include syntax and programming doesn't 
include PHP.  A book on PHP shouldn't include data structures OR version 
control - those are separate subjects.

My not-even-two-cents.

On 1/23/2012 1:27 PM, Philip Camilleri wrote:
> hi Gary, to be honest I would argue that such things as Version 
> Control and Unit Testing do not really belong in a language-specific 
> text-book or tutorial. After all, one does not try to teach program 
> control, binary logic, control and data structures, and the like in a 
> language-specific text-book either, right?
>
> I definitely *strongly* agree that programmers (the ones I come 
> across, at least) seem to learn a language (PHP, Ruby, etc), but don't 
> seem to understand much about the underlying or adjacent issues 
> (version control, unit testing are among those; but also such 
> fundamental things as the important differences between data-types, 
> appropriate use of different data-structures, performance 
> optimization, etc)
>
> However, all of these should be taught to programmers. One can know a 
> language inside-out, but without "real technical knowledge", a 
> programmer can only go so far...
>
> just my two cents...
>
> P.
>
>
>
> On Mon, Jan 23, 2012 at 1:17 PM, Gary Mort <garyamort at gmail.com 
> <mailto:garyamort at gmail.com>> wrote:
>
>     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.
>     _______________________________________________
>     New York PHP User Group Community Talk Mailing List
>     http://lists.nyphp.org/mailman/listinfo/talk
>
>     http://www.nyphp.org/show-participation
>
>
>
>
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show-participation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20120123/7eedd341/attachment.html>