NYCPHP Meetup

[Froilan Cajayon Mendoza]

Gary,

I think the key to programming the right away is to understand the logic
and structure of solving the problem the right way.  This is where
algorithms and data/programming structures come into play.

My first-time-in-programming students sometimes get frustrated because the
first few sessions of my programming class we talk about seemingly mundane
non-programming problems (like describe the detailed steps you'd take to
get from one subway stop to another and note possible errors).  But by
training them how to think and solve the problem logically, it is easier
(relatively) for them to grasp the need for, let's say, a loop or a class,
regardless of programming language.  The next step is then to build on
specific syntax (or lack thereof in PHP :)) and nuisances of the language
you're teaching (enjoy your Hello World program), and then you can talk
about the tools mentioned in your post.

I think learning specific tools (Git, SVN, unit testing) before
understanding logic, algorithm and data structures is problematic.
 Checking in a badly-coded program doesn't make it 'right' -- it's still
bad code, only other people can access it easily (which makes it worse :)).
 If you're solid 'programmatically', those tools can be easily (again,
relatively) learnt.

Froilan



On Mon, Jan 23, 2012 at 2:02 PM, <talk-request at lists.nyphp.org> wrote:

>
>
> Message: 1
> Date: Mon, 23 Jan 2012 13:54:11 -0500
> From: Justin Dearing <zippy1981 at gmail.com>
> To: NYPHP Talk <talk at lists.nyphp.org>
> Subject: Re: [nycphp-talk] Learning to program the right way
> Message-ID:
>        <CABsCM1MFKDafi6PPksh1Gr=KcV7MP=DTK2w2xFQykXAnMfWy3g at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Gary,
>
> Version control, unit tests, etc are not learning to program. They are
> learning software engineering. Quite frankly, if you started "Software
> engineering 101" like this, it would probably add another course between
> this course and a data structures and algorithms course at a university.
> Also, you would bore some of your students to death due to the extended
> time before they get to the good part.
>
> On the other hand, maybe those students need to be bored, scared or
> otherwise culled out of CS. Also, its not like freshmen organic chemistry
> students are turning coal into methane. Also, I don't see why you can't
> teach a data structures and algorithms class by having students step
> through algorithm implementations with a debugger and examining query
> plans. Yes make them implement one or two classic algorithms from scratch,
> but most developers should never do this in practice because their
> languages have standard libraries.
>
> Maybe it is time to offer software engineering degrees distinct from
> computer science.
>
> Justin
>
> On Mon, Jan 23, 2012 at 1:31 PM, leam hall <leamhall at gmail.com> wrote:
>
> > Gary,
> >
> > Part of me thinks this is a great idea. Another part of me thinks
> > you're thinking inside the box. Why not have a "How to really program"
> > class where you introduce these topics, functional and OOP, MVC, go
> > over the basics of a few languages, and stuff like that?
> >
> > I would have loved something like that. Heck, I still would! Have you
> > read Zed Shaw's "How to program python the hard way"?
> >
> > Leam
> >
> > On 1/23/12, Gary Mort <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
> > >
> >
> >
> > --
> > Mind on a Mission <http://leamhall.blogspot.com/>
> > _______________________________________________
> > 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/e1b047d1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 23 Jan 2012 14:02:29 -0500
> From: Philip Camilleri <philip.camilleri at gmail.com>
> To: NYPHP Talk <talk at lists.nyphp.org>
> Subject: Re: [nycphp-talk] Learning to program the right way
> Message-ID:
>        <CAAUg13MOWvQNJ+_svm-OemohZgC1YWq_HeP+-J3K5g6=RDqYXw at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Once again, though, Gary, I think you're mixing two separate issues.
> Details about escaping & sql-injection have no place in sample-code, except
> in that chapter that has to do with these issues.
>
> That said, if you want to write a book about PHP that goes through the
> lengths of outlining source-control, unit-testing, etc, all the best to
> you. Honestly.
>
> But then again, what about data-structures, standard algos, etc? How many
> times have you seen "good" programmers fail to use appropriate search or
> sort algorithms, or have no idea on how to use indices or hashing tables? A
> *really* good programmer should know all of these things, and MUCH more.
>
> P.
>
>
>
>
>
> On Mon, Jan 23, 2012 at 1:53 PM, Gary Mort <garyamort at gmail.com> wrote:
>
> >  I personally think that when instructing someone in how to program for a
> > language, one should include good practices - including choosing good
> data
> > structures for the example code and explaining why they are chosen.  That
> > is another issue I have with programming books, they often include some
> > truly atrocious code.  For example, most of the mysql sample code does
> not
> > include escaping the data to avoid injection.  Data inputs generally do
> not
> > include sanitizing the data.
> >
> > Since a lot of people will go directly from the example code to using
> that
> > code with slight modifications on their own personal website, the
> examples
> > should be secure.  About the only thing I'm not gung ho on is Git.  Any
> > version control system[even CVS] is fine.  However, since the commands
> that
> > will be gone over are primarily clone, add, commit, and maybe push - they
> > are simply commands with equivalents in all the version control systems.
> > Git simply has the benefit of github, so part of the instructional code
> can
> > be a github repo.
> >
> > Also when your learning to code, your adopting habits.  If your habits
> are
> > jumping straight to the code and not committing changes and testing, then
> > it is just that much harder to learn about it later.
> >
> > Though I do admit calling "the right way" is controversial - I simply
> > can't think of any other wording that would be short AND summarize the
> goal
> > of the course....maybe "Learning to Program PHP Professionally"....though
> > I'm sure lots of professionals would then object that their being dissed.
> > :-)
> >
> >
> > On 1/23/2012 1:42 PM, Rukbat wrote:
> >
> > 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> 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 Listhttp://
> lists.nyphp.org/mailman/listinfo/talk
> > http://www.nyphp.org/show-participation
> >
> >
> >
> >
> > _______________________________________________
> > New York PHP User Group Community Talk Mailing Listhttp://
> 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/b7a706e6/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>
> End of talk Digest, Vol 63, Issue 7
> ***********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20120123/3c81917c/attachment.html>