From zaunere at gmail.com Sat Jan 7 17:56:15 2012 From: zaunere at gmail.com (Hans Z) Date: Sat, 7 Jan 2012 17:56:15 -0500 Subject: [nycphp-talk] Happy New Year! ...and New Mailman Server Message-ID: Hello everyone, This is basically a test of a new mailman server and can be safely ignored. Though, happy new year to everyone :) I'll be putting up events for Jan. and Feb. - just finishing up moving everything to a new server. Best, Hans From Margaret.Waldman at bbdo.com Sat Jan 7 18:40:05 2012 From: Margaret.Waldman at bbdo.com (Waldman, Margaret) Date: Sat, 7 Jan 2012 18:40:05 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: References: Message-ID: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Did strcmp change is 5.3? trying to fix 5.2.5 to 5.3.8 issues strcmp seems to be at the source. I'm writing to a file, but \n and \r are not causing carriage returns ... very busy ... thank you in advanced Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. From appel at alsjeblaft.nl Sat Jan 7 19:01:57 2012 From: appel at alsjeblaft.nl (Ap | Alsjeblaft!) Date: Sat, 7 Jan 2012 19:01:57 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Message-ID: Hi Margaret, According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at http://www.php.net/manual/en/migration53.incompatible.php there were no backward incompatible changes made to strcmp(). Are you sure strcmp() is the culprit? Regards, Mark -- *Alsjeblaft!* webdevelopment Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, dazzledkid.com , arthurjussen.nl, schradinova.nl, roomeleven.nl & studiopino.nl appel at alsjeblaft.nl http://www.alsjeblaft.nl/ On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret wrote: > strcmp -------------- next part -------------- An HTML attachment was scrubbed... URL: From zippy1981 at gmail.com Sat Jan 7 19:16:35 2012 From: zippy1981 at gmail.com (Justin Dearing) Date: Sat, 7 Jan 2012 19:16:35 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Message-ID: Margaret, Just guessing, but maybe its a PHP.ini, change? Do you have access to the old and new PHP.ini? Maybe just run diff against them (or the output of php -i if there really different Do you have a sample code snippet and the expected we can try? Justin On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret wrote: > Did strcmp change is 5.3? trying to fix 5.2.5 to 5.3.8 issues strcmp > seems to be at the source. > > I'm writing to a file, but \n and \r are not causing carriage returns ... > very busy ... thank you in advanced > > Please consider the environment before printing this e-mail. > > This message and any attachments contain information, which may be > confidential or privileged. If you are not the intended recipient, please > refrain from any disclosure, copying, distribution or use of this > information. Please be aware that such actions are prohibited. If you have > received this transmission in error, kindly notify us by e-mail to > helpdesk at bbdo.com. We appreciate your cooperation. > _______________________________________________ > New York PHP Users 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: From zippy1981 at gmail.com Sat Jan 7 19:38:50 2012 From: zippy1981 at gmail.com (Justin Dearing) Date: Sat, 7 Jan 2012 19:38:50 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Message-ID: On Sat, Jan 7, 2012 at 7:01 PM, Ap | Alsjeblaft! wrote: > Hi Margaret, > > According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at > http://www.php.net/manual/en/migration53.incompatible.php there were no > backward incompatible changes made to strcmp(). Are you sure strcmp() is > the culprit? > > Lies, damn lies, and documentation. There is at least one change apparently, although, you shouldn't be using strcmp on an array http://www.php.net/manual/en/function.strcmp.php#102677 However, a snippet would be useful for diagnosing this. > Regards, > Mark > > -- > *Alsjeblaft!* > webdevelopment > > Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, > dazzledkid.com, arthurjussen.nl, schradinova.nl, roomeleven.nl & > studiopino.nl > > appel at alsjeblaft.nl > http://www.alsjeblaft.nl/ > > > > On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret < > Margaret.Waldman at bbdo.com> wrote: > >> strcmp > > > > _______________________________________________ > New York PHP Users 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: From appel at alsjeblaft.nl Sat Jan 7 19:52:17 2012 From: appel at alsjeblaft.nl (Ap | Alsjeblaft!) Date: Sat, 7 Jan 2012 19:52:17 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Message-ID: Ouch, you're absolutely right, Justin. Thanks for the correction! -- *Alsjeblaft!* webdevelopment Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, dazzledkid.com , arthurjussen.nl, schradinova.nl, roomeleven.nl & studiopino.nl appel at alsjeblaft.nl http://www.alsjeblaft.nl/ On Sat, Jan 7, 2012 at 7:38 PM, Justin Dearing wrote: > On Sat, Jan 7, 2012 at 7:01 PM, Ap | Alsjeblaft! wrote: > >> Hi Margaret, >> >> According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at >> http://www.php.net/manual/en/migration53.incompatible.php there were no >> backward incompatible changes made to strcmp(). Are you sure strcmp() is >> the culprit? >> >> > Lies, damn lies, and documentation. There is at least one change > apparently, although, you shouldn't be using strcmp on an array > http://www.php.net/manual/en/function.strcmp.php#102677 > > However, a snippet would be useful for diagnosing this. > > > >> Regards, >> Mark >> >> -- >> *Alsjeblaft!* >> webdevelopment >> >> Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, >> dazzledkid.com, arthurjussen.nl, schradinova.nl, roomeleven.nl & >> studiopino.nl >> >> appel at alsjeblaft.nl >> http://www.alsjeblaft.nl/ >> >> >> >> On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret < >> Margaret.Waldman at bbdo.com> wrote: >> >>> strcmp >> >> >> >> _______________________________________________ >> New York PHP Users Group Community Talk Mailing List >> http://lists.nyphp.org/mailman/listinfo/talk >> >> http://www.nyphp.org/Show-Participation >> > > > _______________________________________________ > New York PHP Users 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: From rukbatsramblings at gmail.com Mon Jan 9 10:06:56 2012 From: rukbatsramblings at gmail.com (Rukbat) Date: Mon, 09 Jan 2012 10:06:56 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Message-ID: <4F0B0290.80804@gmail.com> On 1/7/2012 6:40 PM, Waldman, Margaret wrote: Are you by any chance writing in one OS and reading in another? That would cause the problem you're describing. > Did strcmp change is 5.3? trying to fix 5.2.5 to 5.3.8 issues strcmp seems to be at the source. > > I'm writing to a file, but \n and \r are not causing carriage returns ... very busy ... thank you in advanced > > Please consider the environment before printing this e-mail. > > This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. > _______________________________________________ > New York PHP Users Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/Show-Participation From Margaret.Waldman at bbdo.com Mon Jan 9 11:47:18 2012 From: Margaret.Waldman at bbdo.com (Waldman, Margaret) Date: Mon, 9 Jan 2012 11:47:18 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Message-ID: <0AA505314F90694189E15374C1A64D9F23A15ED6DE@EX14WNY.addomain.org> I was using (strcmp($single_keys[$i], $key_prefixes[$j]) !== false) before. Had to change it to -1. Looks to be. From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Ap | Alsjeblaft! Sent: Saturday, January 07, 2012 7:02 PM To: NYPHP Talk Subject: Re: [nycphp-talk] strcmp Hi Margaret, According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at http://www.php.net/manual/en/migration53.incompatible.php there were no backward incompatible changes made to strcmp(). Are you sure strcmp() is the culprit? Regards, Mark -- Alsjeblaft! webdevelopment Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, dazzledkid.com, arthurjussen.nl, schradinova.nl, roomeleven.nl & studiopino.nl appel at alsjeblaft.nl http://www.alsjeblaft.nl/ On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret > wrote: strcmp Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Margaret.Waldman at bbdo.com Mon Jan 9 11:55:41 2012 From: Margaret.Waldman at bbdo.com (Waldman, Margaret) Date: Mon, 9 Jan 2012 11:55:41 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: <0AA505314F90694189E15374C1A64D9F23A15ED6DE@EX14WNY.addomain.org> References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> <0AA505314F90694189E15374C1A64D9F23A15ED6DE@EX14WNY.addomain.org> Message-ID: <0AA505314F90694189E15374C1A64D9F23A15ED6DF@EX14WNY.addomain.org> Looks like == strlen($key_prefixes[$i]) is a better comparison (not not comments about my loop taking almost ixj please) From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Waldman, Margaret Sent: Monday, January 09, 2012 11:47 AM To: 'NYPHP Talk' Subject: Re: [nycphp-talk] strcmp I was using (strcmp($single_keys[$i], $key_prefixes[$j]) !== false) before. Had to change it to -1. Looks to be. From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Ap | Alsjeblaft! Sent: Saturday, January 07, 2012 7:02 PM To: NYPHP Talk Subject: Re: [nycphp-talk] strcmp Hi Margaret, According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at http://www.php.net/manual/en/migration53.incompatible.php there were no backward incompatible changes made to strcmp(). Are you sure strcmp() is the culprit? Regards, Mark -- Alsjeblaft! webdevelopment Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, dazzledkid.com, arthurjussen.nl, schradinova.nl, roomeleven.nl & studiopino.nl appel at alsjeblaft.nl http://www.alsjeblaft.nl/ On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret > wrote: strcmp Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakics at gmail.com Mon Jan 9 11:55:26 2012 From: rakics at gmail.com (Sasa Rakic - Gmail) Date: Mon, 9 Jan 2012 17:55:26 +0100 Subject: [nycphp-talk] strcmp In-Reply-To: <0AA505314F90694189E15374C1A64D9F23A15ED6DE@EX14WNY.addomain.org> References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> <0AA505314F90694189E15374C1A64D9F23A15ED6DE@EX14WNY.addomain.org> Message-ID: <01cb01ccceef$7cf6dac0$76e49040$@gmail.com> Hi Margaret, I have used mostly strncmp: Best regards, Sasa From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Waldman, Margaret Sent: Monday, January 09, 2012 5:47 PM To: 'NYPHP Talk' Subject: Re: [nycphp-talk] strcmp I was using (strcmp($single_keys[$i], $key_prefixes[$j]) !== false) before. Had to change it to -1. Looks to be. From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Ap | Alsjeblaft! Sent: Saturday, January 07, 2012 7:02 PM To: NYPHP Talk Subject: Re: [nycphp-talk] strcmp Hi Margaret, According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at http://www.php.net/manual/en/migration53.incompatible.php there were no backward incompatible changes made to strcmp(). Are you sure strcmp() is the culprit? Regards, Mark -- Alsjeblaft! webdevelopment Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, dazzledkid.com, arthurjussen.nl, schradinova.nl, roomeleven.nl & studiopino.nl appel at alsjeblaft.nl http://www.alsjeblaft.nl/ On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret wrote: strcmp Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Margaret.Waldman at bbdo.com Mon Jan 9 13:21:25 2012 From: Margaret.Waldman at bbdo.com (Waldman, Margaret) Date: Mon, 9 Jan 2012 13:21:25 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: <01cb01ccceef$7cf6dac0$76e49040$@gmail.com> References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> <0AA505314F90694189E15374C1A64D9F23A15ED6DE@EX14WNY.addomain.org> <01cb01ccceef$7cf6dac0$76e49040$@gmail.com> Message-ID: <0AA505314F90694189E15374C1A64D9F23A15ED6E1@EX14WNY.addomain.org> Thanks. My start with method returns return (!strncmp($val, $sub, strlen($sub)); now it was !strcmp(substr($val, 0, strlen($sub), $sub) From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Sasa Rakic - Gmail Sent: Monday, January 09, 2012 11:55 AM To: 'NYPHP Talk' Subject: Re: [nycphp-talk] strcmp Hi Margaret, I have used mostly strncmp: Best regards, Sasa From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Waldman, Margaret Sent: Monday, January 09, 2012 5:47 PM To: 'NYPHP Talk' Subject: Re: [nycphp-talk] strcmp I was using (strcmp($single_keys[$i], $key_prefixes[$j]) !== false) before. Had to change it to -1. Looks to be. From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Ap | Alsjeblaft! Sent: Saturday, January 07, 2012 7:02 PM To: NYPHP Talk Subject: Re: [nycphp-talk] strcmp Hi Margaret, According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at http://www.php.net/manual/en/migration53.incompatible.php there were no backward incompatible changes made to strcmp(). Are you sure strcmp() is the culprit? Regards, Mark -- Alsjeblaft! webdevelopment Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, dazzledkid.com, arthurjussen.nl, schradinova.nl, roomeleven.nl & studiopino.nl appel at alsjeblaft.nl http://www.alsjeblaft.nl/ On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret > wrote: strcmp Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Margaret.Waldman at bbdo.com Mon Jan 9 13:23:45 2012 From: Margaret.Waldman at bbdo.com (Waldman, Margaret) Date: Mon, 9 Jan 2012 13:23:45 -0500 Subject: [nycphp-talk] strcmp In-Reply-To: References: <0AA505314F90694189E15374C1A64D9F23A15ED6D9@EX14WNY.addomain.org> Message-ID: <0AA505314F90694189E15374C1A64D9F23A15ED6E2@EX14WNY.addomain.org> Nope. Problem lays in some dup data I received and not calling my starts_with method. From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Ap | Alsjeblaft! Sent: Saturday, January 07, 2012 7:02 PM To: NYPHP Talk Subject: Re: [nycphp-talk] strcmp Hi Margaret, According to the page 'Migrating from PHP 5.2.x to PHP 5.3.x' at http://www.php.net/manual/en/migration53.incompatible.php there were no backward incompatible changes made to strcmp(). Are you sure strcmp() is the culprit? Regards, Mark -- Alsjeblaft! webdevelopment Stuff I've built: wende.nu, sizzer.nl, happycampermusic.com, dazzledkid.com, arthurjussen.nl, schradinova.nl, roomeleven.nl & studiopino.nl appel at alsjeblaft.nl http://www.alsjeblaft.nl/ On Sat, Jan 7, 2012 at 6:40 PM, Waldman, Margaret > wrote: strcmp Please consider the environment before printing this e-mail. This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by e-mail to helpdesk at bbdo.com. We appreciate your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorge at refinery29.com Mon Jan 23 13:01:23 2012 From: jorge at refinery29.com (Jorge Lopez) Date: Mon, 23 Jan 2012 13:01:23 -0500 Subject: [nycphp-talk] Tech Event / Refinery29 Message-ID: Hello, Just wanted to give people a heads up about an event we're hosting at Refinery29! http://msw-fe.eventbrite.com/ The lineup is pretty amazing: - Damian Galarza - Thrillist - Benjamin Wilson - Refinery29 - Pau Santesmasses - Tumblr - Mike Singleton - Foursquare - Ahmed Hashim - Etsy Hope to see some of you guys there. -- * Jorge Lopez ** I ** ** VP of Engineering * * * * REFINERY29 30 Cooper Square, Floor 4, New York, NY 10003 Office: 646-480-4151 I Mobile: 917-267-9130 Refinery29.com I Twitter I Facebook * -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyamort at gmail.com Mon Jan 23 13:17:06 2012 From: garyamort at gmail.com (Gary Mort) Date: Mon, 23 Jan 2012 13:17:06 -0500 Subject: [nycphp-talk] Learning to program the right way Message-ID: <4F1DA422.5040308@gmail.com> 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. From philip.camilleri at gmail.com Mon Jan 23 13:27:01 2012 From: philip.camilleri at gmail.com (Philip Camilleri) Date: Mon, 23 Jan 2012 13:27:01 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1DA422.5040308@gmail.com> References: <4F1DA422.5040308@gmail.com> Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Mon Jan 23 13:31:57 2012 From: leamhall at gmail.com (leam hall) Date: Mon, 23 Jan 2012 13:31:57 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1DA422.5040308@gmail.com> References: <4F1DA422.5040308@gmail.com> Message-ID: 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 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 From rukbatsramblings at gmail.com Mon Jan 23 13:42:11 2012 From: rukbatsramblings at gmail.com (Rukbat) Date: Mon, 23 Jan 2012 13:42:11 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1DA422.5040308@gmail.com> Message-ID: <4F1DAA03.3020802@gmail.com> 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 > 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: From rainelemental at gmail.com Mon Jan 23 13:50:21 2012 From: rainelemental at gmail.com (Federico Ulfo) Date: Mon, 23 Jan 2012 13:50:21 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1DA422.5040308@gmail.com> Message-ID: Everybody wants to see fast results, and starting with Hello World is always the best way. Also starting from the basics is good because once you master the logic of OOP and procedural programming you can move from one language to another. About Git and Unit, I agree partially, if you decide to go into the PHP world is good to know them from the beginning, may be soon after Hello World! On Mon, Jan 23, 2012 at 1:31 PM, leam hall 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 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 > _______________________________________________ > 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: From garyamort at gmail.com Mon Jan 23 13:53:24 2012 From: garyamort at gmail.com (Gary Mort) Date: Mon, 23 Jan 2012 13:53:24 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1DAA03.3020802@gmail.com> References: <4F1DA422.5040308@gmail.com> <4F1DAA03.3020802@gmail.com> Message-ID: <4F1DACA4.4040207@gmail.com> 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 > > 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 > > > > _______________________________________________ > 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: From zippy1981 at gmail.com Mon Jan 23 13:54:11 2012 From: zippy1981 at gmail.com (Justin Dearing) Date: Mon, 23 Jan 2012 13:54:11 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1DA422.5040308@gmail.com> Message-ID: 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 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 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 > _______________________________________________ > 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: From philip.camilleri at gmail.com Mon Jan 23 14:02:29 2012 From: philip.camilleri at gmail.com (Philip Camilleri) Date: Mon, 23 Jan 2012 14:02:29 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1DACA4.4040207@gmail.com> References: <4F1DA422.5040308@gmail.com> <4F1DAA03.3020802@gmail.com> <4F1DACA4.4040207@gmail.com> Message-ID: 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 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 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: From lists at enobrev.com Mon Jan 23 15:41:45 2012 From: lists at enobrev.com (Mark Armendariz) Date: Mon, 23 Jan 2012 15:41:45 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1DA422.5040308@gmail.com> References: <4F1DA422.5040308@gmail.com> Message-ID: <4F1DC609.5010807@enobrev.com> It seems this might be an unpopular opinion around here, but I think it's a great idea to include all of the above. It teaches that while these things may be optional, the option is to remove them from your process, not to add them. It's important that these ideas are introduced early so that when one tries to continue research on their own, they at least have some idea of what the hell people are talking about. More importantly, I think it's a big deal to understand how all these things fit together. I would otherwise recommend some sort of agnosticism towards your outside tools. Show git, but mention and offer links to bzr, hg, svn. Show phpunit but mention and offer links to simpletest. PHP and MySQL are tied at the hip because every blog title and book had the two welded together for years, which in many cases makes one think that other databases (or languages) would be incorrect without the other. I agree with most responses here that it's the code is top priority and should remain the focal point. But including these other subjects will help the reader get a broader view of what programming is all about. On 01/23/2012 01:17 PM, Gary Mort 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 From greg at freephile.com Mon Jan 23 17:25:21 2012 From: greg at freephile.com (Greg Rundlett (freephile)) Date: Mon, 23 Jan 2012 17:25:21 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1DA422.5040308@gmail.com> References: <4F1DA422.5040308@gmail.com> Message-ID: > > > I'm curious if there are any other items people think should be > incorporated into this tutorial. > I think that there have been books like this (For example, a book from 2004 written by George Schlosshnagle: http://www.amazon.com/Advanced-PHP-Programming-George-Schlossnagle/dp/0672325616) and I agree that there should be more books or tutorials that combine the language particulars with the complete set of best practices that make up software development. Greg Rundlett my public PGP key -------------- next part -------------- An HTML attachment was scrubbed... URL: From codebowl at gmail.com Mon Jan 23 18:03:35 2012 From: codebowl at gmail.com (Joseph Crawford) Date: Mon, 23 Jan 2012 18:03:35 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1DA422.5040308@gmail.com> Message-ID: <166228E9-5A78-4815-A77B-3D579CE53E6B@gmail.com> Taken from Zend Framework A Beginners Guide which is the most up to date book about Zend Framework which targets ZF 1.10 mysql> CREATE TABLE IF NOT EXISTS user ( -> RecordID INT(4) NOT NULL AUTO_INCREMENT, -> Username VARCHAR(10) NOT NULL, -> Password TEXT NOT NULL, -> PRIMARY KEY (RecordID) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Why would you ever use TEXT for a password field? Not to mention all the other types etc. mysql> CREATE TABLE IF NOT EXISTS type ( -> TypeID INT(11) NOT NULL AUTO_INCREMENT, -> TypeName VARCHAR(255) NOT NULL, -> PRIMARY KEY (TypeID) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Query OK, 0 rows affected (0.09 sec) mysql> CREATE TABLE IF NOT EXISTS item ( -> RecordID INT(11) NOT NULL AUTO_INCREMENT, -> RecordDate DATE NOT NULL, -> SellerName VARCHAR(255) NOT NULL, -> SellerEmail VARCHAR(255) NOT NULL, -> SellerTel VARCHAR(50) DEFAULT NULL, -> SellerAddress TEXT, -> Title VARCHAR(255) NOT NULL, -> `Year` INT(4) NOT NULL, -> CountryID INT(4) NOT NULL, -> Denomination FLOAT NOT NULL, -> TypeID INT(4) NOT NULL, -> GradeID INT(4) NOT NULL, -> SalePriceMin FLOAT NOT NULL, -> SalePriceMax FLOAT NOT NULL, -> Description TEXT NOT NULL, -> DisplayStatus TINYINT(1) NOT NULL, -> DisplayUntil DATE DEFAULT NULL, -> PRIMARY KEY (RecordID) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Query OK, 0 rows affected (0.09 sec) mysql> CREATE TABLE IF NOT EXISTS user ( -> RecordID INT(4) NOT NULL AUTO_INCREMENT, -> Username VARCHAR(10) NOT NULL, -> Password TEXT NOT NULL, -> PRIMARY KEY (RecordID) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; Query OK, 0 rows affected (0.09 sec) mysql> CREATE TABLE IF NOT EXISTS log ( -> RecordID int(11) NOT NULL AUTO_INCREMENT, -> LogMessage text NOT NULL, -> LogLevel varchar(30) NOT NULL, -> LogTime varchar(30) NOT NULL, -> Stack text, -> Request text, -> PRIMARY KEY (RecordID) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8; On Jan 23, 2012, at 5:25 PM, Greg Rundlett (freephile) wrote: > > I'm curious if there are any other items people think should be incorporated into this tutorial. > > I think that there have been books like this (For example, a book from 2004 written by George Schlosshnagle: http://www.amazon.com/Advanced-PHP-Programming-George-Schlossnagle/dp/0672325616) and I agree that there should be more books or tutorials that combine the language particulars with the complete set of best practices that make up software development. > > > Greg Rundlett > my public PGP key > _______________________________________________ > New York PHP User Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/show-participation From froilan at nyu.edu Mon Jan 23 22:52:06 2012 From: froilan at nyu.edu (Froilan Cajayon Mendoza) Date: Mon, 23 Jan 2012 22:52:06 -0500 Subject: [nycphp-talk] Learning to program the right way Message-ID: 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, wrote: > > > Message: 1 > Date: Mon, 23 Jan 2012 13:54:11 -0500 > From: Justin Dearing > To: NYPHP Talk > Subject: Re: [nycphp-talk] Learning to program the right way > Message-ID: > > > 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 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 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 > > _______________________________________________ > > 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 > To: NYPHP Talk > Subject: Re: [nycphp-talk] Learning to program the right way > Message-ID: > > > 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 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 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: From garyamort at gmail.com Tue Jan 24 11:11:42 2012 From: garyamort at gmail.com (Gary Mort) Date: Tue, 24 Jan 2012 11:11:42 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: Message-ID: <4F1ED83E.3080008@gmail.com> On 1/23/2012 10:52 PM, Froilan Cajayon Mendoza wrote: > 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. Personally, I don't think PHP is a good "first" language, so I expect people picking up PHP to already have covered "basics". :-) While PHP can be run from the command line, it's biggest usage is in web design. So learning PHP involves using MySQL, Javascript, HTML, and CSS. Since all of that needs to be covered as well, you might as well do it all right. Also, "checking bad code" into version control is productive. When someone is first learning code, they may well 6 or 7 different ways of doing something. By the time they get to number 7, they may decide that the third solution was the best. Without version control, it means they will be making bad filename choices[attempt1.php, attempt2.php, attempt3.php] or relying heavily on their editors undo function. Wheras if they were using version control from the start, then they can revert to the version they saved on the third attempt, and by the time their done with the course they will have the habit of trying lots of things and reverting code when needed. From zippy1981 at gmail.com Tue Jan 24 11:46:03 2012 From: zippy1981 at gmail.com (Justin Dearing) Date: Tue, 24 Jan 2012 11:46:03 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1ED83E.3080008@gmail.com> References: <4F1ED83E.3080008@gmail.com> Message-ID: On Tue, Jan 24, 2012 at 11:11 AM, Gary Mort wrote: > On 1/23/2012 10:52 PM, Froilan Cajayon Mendoza wrote: > >> 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. >> > Personally, I think that at some point in college the following should be taught to CompSci, MIS/IT, Engineering and Finance majors: * How to code * How to use source control (presented to IT in a way that covers devops, storing config files, and how sharepoint and wiki's work) I do think they need to be taught in isolation. I do think that CompSci majors should understand unit testing, and that unit testing frameworks are good for engineering and finance. If you've ever seen anyone use a unit testing framework to show their code demo's, you'd see what I mean. I think its a problem that we don't teach revision control in school. I think that it should be taught early enough in the curriculum that you'd learn it even if you just go for an associates degree. I don't think it should happen in the same class as when you learn what a for loop is. Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmerlo at ncc.edu Tue Jan 24 12:23:21 2012 From: cmerlo at ncc.edu (Christopher R. Merlo) Date: Tue, 24 Jan 2012 12:23:21 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> Message-ID: On Tue, Jan 24, 2012 at 11:46 AM, Justin Dearing wrote: Personally, I think that at some point in college the following should be > taught to CompSci, MIS/IT, Engineering and Finance majors: > * How to code > * How to use source control (presented to IT in a way that covers devops, > storing config files, and how sharepoint and wiki's work) > > I do think they need to be taught in isolation. I do think that CompSci > majors should understand unit testing, and that unit testing frameworks are > good for engineering and finance. If you've ever seen anyone use a unit > testing framework to show their code demo's, you'd see what I mean. > > I think its a problem that we don't teach revision control in school. I > think that it should be taught early enough in the curriculum that you'd > learn it even if you just go for an associates degree. I don't think it > should happen in the same class as when you learn what a for loop is. > Justin is, as usual, correct about all of this. But as someone who's been involved in CS curriculum design at the associates level for going on 12 years now, the problem -- at least for us at the community college level -- is that we can only make our students take 66 credits, of physics and music and English and all the other stuff, along with CS and math. I would love to offer our CS students a course on these software engineering topics, like source control and unit tests and how to do a code review, but not at the expense of assembly or linear algebra, and SUNY won't let us do it at the expense of sociology or art. (That's not a complaint; I think the curriculum *should* be well-rounded. We just don't have space.) -c -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Tue Jan 24 12:47:05 2012 From: leamhall at gmail.com (Leam Hall) Date: Tue, 24 Jan 2012 12:47:05 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> Message-ID: <4F1EEE99.80907@gmail.com> On 01/24/2012 12:23 PM, Christopher R. Merlo wrote: > Justin is, as usual, correct about all of this. But as someone who's been > involved in CS curriculum design at the associates level for going on 12 > years now, the problem -- at least for us at the community college level -- > is that we can only make our students take 66 credits, of physics and music > and English and all the other stuff, along with CS and math. I would love > to offer our CS students a course on these software engineering topics, > like source control and unit tests and how to do a code review, but not at > the expense of assembly or linear algebra, and SUNY won't let us do it at > the expense of sociology or art. (That's not a complaint; I think the > curriculum *should* be well-rounded. We just don't have space.) > -c I won't argue, and I have a SUNY-Regent's College degree. However, I think this more points out that we need to move out of traditional "college" education and forward to something new or backward to apprenticeships or something else. The cost of college no longer meets the "increased income" myth, if it ever did. In hiring discussions my degrees have meant much less than respected certifications and experience. So Gary, I suggest you proceed with your book and dedicate a forum or other interactive website. Maybe use Moodle? Develop your plan, test it with others, and then charge a hundred or so bucks for the learning and access to the member's forum. I'd probably join. Leam From philip.camilleri at gmail.com Tue Jan 24 12:58:05 2012 From: philip.camilleri at gmail.com (Philip Camilleri) Date: Tue, 24 Jan 2012 12:58:05 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1EEE99.80907@gmail.com> References: <4F1ED83E.3080008@gmail.com> <4F1EEE99.80907@gmail.com> Message-ID: i don't wish to start a separate discussion here, but maybe the problem lies with the University/College education system here in the US. I went to school in Europe (a few years back, nonetheless, when the system was somewhat different to what it is today). But the philosophy back then was to get a "rounded" education before getting to University -- which meant you did all your advanced math, language, literature, history, geography, economics, social sciences, and so on, up until you were 18. In fact, our system was such that you specialized as you progress (i.e. 8 core subjects at 13, then 4 core subjects at 16, and finally 1 (or 2) core subject(s) at Uni, at 18). If one wanted to learn more about art, history or economics one simply picked up the books or followed extra-curricular courses. Granted, I know this is all wishful thinking, but to hear someone say that they have a Degree in CS, but do not know such things as source-control, or unit-testing paradigms (or even how to log into a Unix box -- and believe me, I have heard this one on *several* occasions while interviewing candidates both here in the US and in the UK) is absolutely demoralizing! Anyway, as Leam said, best of luck with your book -- it may yet become "required reading" for developers!! On Tue, Jan 24, 2012 at 12:47 PM, Leam Hall wrote: > On 01/24/2012 12:23 PM, Christopher R. Merlo wrote: > > Justin is, as usual, correct about all of this. But as someone who's been >> involved in CS curriculum design at the associates level for going on 12 >> years now, the problem -- at least for us at the community college level >> -- >> is that we can only make our students take 66 credits, of physics and >> music >> and English and all the other stuff, along with CS and math. I would love >> to offer our CS students a course on these software engineering topics, >> like source control and unit tests and how to do a code review, but not at >> the expense of assembly or linear algebra, and SUNY won't let us do it at >> the expense of sociology or art. (That's not a complaint; I think the >> curriculum *should* be well-rounded. We just don't have space.) >> -c >> > > I won't argue, and I have a SUNY-Regent's College degree. However, I think > this more points out that we need to move out of traditional "college" > education and forward to something new or backward to apprenticeships or > something else. > > The cost of college no longer meets the "increased income" myth, if it > ever did. In hiring discussions my degrees have meant much less than > respected certifications and experience. > > So Gary, I suggest you proceed with your book and dedicate a forum or > other interactive website. Maybe use Moodle? Develop your plan, test it > with others, and then charge a hundred or so bucks for the learning and > access to the member's forum. I'd probably join. > > Leam > > > ______________________________**_________________ > 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: From ramons at gmx.net Tue Jan 24 13:42:50 2012 From: ramons at gmx.net (David Krings) Date: Tue, 24 Jan 2012 13:42:50 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1DA422.5040308@gmail.com> References: <4F1DA422.5040308@gmail.com> Message-ID: <4F1EFBAA.6040303@gmx.net> On 1/23/2012 1:17 PM, Gary Mort 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. [...] as well as other posts... Hi! Here are my 2 cents on this, from the perspective of a QA analyst who writes code as hobby and to know just enough about it to disable the 'cannot be done in programming language XYZ' argument of developers. First of all, congratulations that you want to write a course. It will be a lot of work, thrice as much as you think it will be. I've been there and in the end it will be worth the effort. Yes, please, focus on all these things that are not about learning more code words. There are already excellent books for that (and many crappy ones), but I haven't seen one that explains the mindset of a good developer. I do assume you target that at people who are learning how to code, or better to say who want to learn how to run a successful software project. If that is true, then no bit of code is trivial. Even Hello World is not trivial. In short, for anyone new to this, nothing is trivial. So if you want this to be a well liked course don't use words like "trivial". You may find it trivial, but for others it is a tremendously tricky problem to wrap their mind around. If you write for experienced software architects, then fine, mock the n00bs, but even then it is unnecessary. Don't even think that any of this is trivial. - unit testing Very important and that unit should consist of two parts: why do it and how to do it/what does a test need to cover. The why part should be easy for you as you are already fully convinced. Imagine you need to consume code from someone who does not write a single unit test and claims he does not have to, because he is a programmer for 40 years. Argue against a case like that. What it needs to cover should be about testing edge conditions, proper error handling, short anything that it is not normal. At that point it may be helpful to see some code examples on how it is done right (please, don't include incorrect code or bad examples, reserve that for exercises if you want to add some). - source control In that section I wouldn't focus solely on git. In the next place subversion is used and others may use CVS or TFS or Vault or whatever. Focus on the benefits of source and version control for anything about the project (which includes help, documentation, etc - yes, the help and doc sources are sources and belong in source control) versus simply copying files to a floppy as backup. Still, should mention that making simple file backups is important as well, same as backing up the entire repository. If you want to include specific commands, add a table at the end that lists the basic commands for the most popular open source and proprietary source control systems. - algorithms / objects / classes Wow! Big words, big enough to scare anyone. I've come across plenty of code that was presented as awesome because it is "fully object oriented". I couldn't tell if it was or not, because it didn't work at all. The only time I ever used an object so far is to handle a ZIP archive, because the PHP module doesn't work any different. You can do plenty of stuff without creating a single object. I use arrays to store data and then write code around it. And that may just be the lead-in to show that packaging that all into an object is the way to go: one part are the data structures, the other part is the code around it. Introduce it in that manner, that way even a novice PHP coder like me can follow that path. Explain it without ever using the word "object", focus solely on the benefits and mention the disadvantages. Tell people that all that is called "object" in the last sentence of the section. Same applies for algorithms. Even when you start off with a definition of the word it will not mean much. Talk about how to sort stuff quickly, how to find stuff quickly, how to arrange stuff based on a pattern. Using key words like that make it much easier to grasp what it is about. And again, the last sentence can explain that all this is known as algorithms. And same applies for classes - documentation Your course needs to cover that. Fact is that we do not communicate with it each other in PHP (or C or Java or whatever). So something like "self-explaining code" is total bupkis. No matter how well structured the code is, I still have no clue what it does when looking at it. Documentation is utterly important unless you write some one time use glue code or engage in gogglelistic projects with a life span of less than six months. It not only matters which docs to write, but also when to write them. Here is how I see it: - scope doc of project: what is it supposed to be (address label creator or a bird bath?) - functional requirements: detailed list of individual features and functions explaining the expectations of the stakeholders (users, QA, devs, etc.) - technical spec I: flow charts, description of approach => now write code, unit tests, and so on - technical spec II: amend the first version and add a description of what was done, no code is to be found in here The scope doc can be skipped if not needed and rolled into the functional requirements. All these docs do not need to be novels. Defining the scope in one or two sentences is fine, requirements can be a collection of lists with key words (name of a text field, max length, any chars that need to be rejected) plus a mockup of the UI if there is one. If there is none, a list of the commands expected. Tech spec needs to include the database table design unless there is another way to easily get to that. The first part is purely about stating what the plan is and how the developer understands the program needs to work. - quality The past decade I spent on learning about software QA and went through endless discussions about what is a bug. Of course, I forgot where I got that quote from (I'll find the source when you want to), but the best definition of "bug" I ever came across is this one: "A bug is anything that negatively impacts the user experience." So quality is a matter of user perception, or even shorter: quality is a matter of the user. So if a developer wants to write quality code then never ever forget about the user. If a developer never met a user or talked to one, how can she or he know how the software gets used? I think any developer in any company should do at least a few days per month phone support. This isn't a problem for the one man shops, because it becomes more obvious in that constellation. Developers create software for others to use, not to get all jiggy about how awesome their new code is. If you think about users you get something like Firefox 3.6. If you only focus on having a good ol' time as developer then you get Firefox 9...and declining market share. Make the users happy, which is a task that goes far beyond the app compiling and not crashing. Even a crash is OK if there is a useful error message. - error handling We all know the "Access violation at address 00000000" errors. They are totally useless. As are the 50k lines of error output from ASP.NET web apps. Any error, foreseen or not, needs to be properly handled producing humanly intelligible output that states at least what went wrong (and no, nobody aside a developer knows what access violation means), what was expected as input, what was received as input, and what a possible remedy could be. Also, include the name of the module or file in which the error occurred. That should be easier when distributing the code across multiple files rather than stuffing everything into one big file. - adherence to UX guidelines There are several UX guidelines published by various companies. I know that Apple, Microsoft and IBM published theirs. Also, the "The essential guide to user interface design" by W. O. Galitz is an excellent resource. Each company may have their own design and style guides, and if not, it is long overdue to craft them. So much for now, come to think, you could write the entire course without any code samples and still have a very valuable product. David From ramons at gmx.net Tue Jan 24 13:52:23 2012 From: ramons at gmx.net (David Krings) Date: Tue, 24 Jan 2012 13:52:23 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> Message-ID: <4F1EFDE7.6070100@gmx.net> On 1/24/2012 12:23 PM, Christopher R. Merlo wrote: > Justin is, as usual, correct about all of this. But as someone who's been > involved in CS curriculum design at the associates level for going on 12 years > now, the problem -- at least for us at the community college level -- is that > we can only make our students take 66 credits, of physics and music and > English and all the other stuff, along with CS and math. I would love to > offer our CS students a course on these software engineering topics, like > source control and unit tests and how to do a code review, but not at the > expense of assembly or linear algebra, and SUNY won't let us do it at the > expense of sociology or art. (That's not a complaint; I think the curriculum > *should* be well-rounded. We just don't have space.) > -c Hi! Having received my BS degree not at a US university I never understood why students at a college or university have to take music and English classes when they are going for a CS degree. I can see math and to some extent physics as in learning about the effects in semiconductors and nanotechnology, but debating Debussy and reading "The Great Gatsby" for the nth time...why? The well-rounded part is something students should get (should have gotten) in high school. That is exactly the reason why companies rather ship in folks from overseas. Sorry, this is digressing from the original topic... David From gatzby3jr at gmail.com Tue Jan 24 14:20:14 2012 From: gatzby3jr at gmail.com (Brian O'Connor) Date: Tue, 24 Jan 2012 14:20:14 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> <4F1EEE99.80907@gmail.com> Message-ID: I can't speak for anyone else's experience other than my own, but when I went to get my degree in CS I was exposed to version control, unit testing, code reviews without sacrificing any other of the core topics associated with the degree. Most of those "non-core" cs tools we're taught in the first 3 classes, and then we were expected to learn the rest on our own. As far as I'm concerned, school isn't the end all be all to learn everything there is to be a competent programmer. It's a starting point to teach you how to learn. On Jan 24, 2012 12:58 PM, "Philip Camilleri" wrote: > i don't wish to start a separate discussion here, but maybe the problem > lies with the University/College education system here in the US. > > I went to school in Europe (a few years back, nonetheless, when the system > was somewhat different to what it is today). But the philosophy back then > was to get a "rounded" education before getting to University -- which > meant you did all your advanced math, language, literature, history, > geography, economics, social sciences, and so on, up until you were 18. In > fact, our system was such that you specialized as you progress (i.e. 8 core > subjects at 13, then 4 core subjects at 16, and finally 1 (or 2) core > subject(s) at Uni, at 18). If one wanted to learn more about art, history > or economics one simply picked up the books or followed extra-curricular > courses. > > Granted, I know this is all wishful thinking, but to hear someone say that > they have a Degree in CS, but do not know such things as source-control, or > unit-testing paradigms (or even how to log into a Unix box -- and believe > me, I have heard this one on *several* occasions while interviewing > candidates both here in the US and in the UK) is absolutely demoralizing! > > Anyway, as Leam said, best of luck with your book -- it may yet become > "required reading" for developers!! > > > > > > On Tue, Jan 24, 2012 at 12:47 PM, Leam Hall wrote: > >> On 01/24/2012 12:23 PM, Christopher R. Merlo wrote: >> >> Justin is, as usual, correct about all of this. But as someone who's >>> been >>> involved in CS curriculum design at the associates level for going on 12 >>> years now, the problem -- at least for us at the community college level >>> -- >>> is that we can only make our students take 66 credits, of physics and >>> music >>> and English and all the other stuff, along with CS and math. I would >>> love >>> to offer our CS students a course on these software engineering topics, >>> like source control and unit tests and how to do a code review, but not >>> at >>> the expense of assembly or linear algebra, and SUNY won't let us do it at >>> the expense of sociology or art. (That's not a complaint; I think the >>> curriculum *should* be well-rounded. We just don't have space.) >>> -c >>> >> >> I won't argue, and I have a SUNY-Regent's College degree. However, I >> think this more points out that we need to move out of traditional >> "college" education and forward to something new or backward to >> apprenticeships or something else. >> >> The cost of college no longer meets the "increased income" myth, if it >> ever did. In hiring discussions my degrees have meant much less than >> respected certifications and experience. >> >> So Gary, I suggest you proceed with your book and dedicate a forum or >> other interactive website. Maybe use Moodle? Develop your plan, test it >> with others, and then charge a hundred or so bucks for the learning and >> access to the member's forum. I'd probably join. >> >> Leam >> >> >> ______________________________**_________________ >> 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: From zippy1981 at gmail.com Tue Jan 24 14:52:58 2012 From: zippy1981 at gmail.com (Justin Dearing) Date: Tue, 24 Jan 2012 14:52:58 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> Message-ID: On Tue, Jan 24, 2012 at 12:23 PM, Christopher R. Merlo wrote: > Justin is, as usual, correct about all of this. But as someone who's been > involved in CS curriculum design at the associates level for going on 12 > years now, the problem -- at least for us at the community college level -- > is that we can only make our students take 66 credits, of physics and music > and English and all the other stuff, along with CS and math. I would love > to offer our CS students a course on these software engineering topics, > like source control and unit tests and how to do a code review, but not at > the expense of assembly or linear algebra, and SUNY won't let us do it at > the expense of sociology or art. (That's not a complaint; I think the > curriculum *should* be well-rounded. We just don't have space.) > -c > Chris, This borders on academic heresy, but maybe a community colleges should offer AOS (Associate in Occupational Studies) degrees in *addition* to Associates in arts and Sciences. Briarcliffe, and probably may other for profit universities did that, but if it was offered at a school that also has Associates in Arts and Sciences as opposed to AOSes and "diplomas," there would be some more vigor and quality in the program, and the one or two electives taken would be better taught. Obviously, the AOS should only be marketed to non-traditional (25+) students and those absolutely sure they don't want a bachelors. I was going to make an argument that assembly might not be needed at the associates level, but writing this has made me question that myself. However, I think its more important to be able to read assembly than write assembly, so maybe it should be taught that way. One or two lessons where you write some stuff to appreciate the syntax, and the rest would be "compile this code, step through the assembly" Seeing different calling conventions in action will probably teach students a lot, and honestly I'd probably audit a course taught that way. Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Tue Jan 24 15:08:08 2012 From: leamhall at gmail.com (Leam Hall) Date: Tue, 24 Jan 2012 15:08:08 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> Message-ID: <4F1F0FA8.3070108@gmail.com> On 01/24/2012 02:52 PM, Justin Dearing wrote: > I was going to make an argument that assembly might not be needed at the > associates level, but writing this has made me question that myself. > However, I think its more important to be able to read assembly than write > assembly, so maybe it should be taught that way. One or two lessons where > you write some stuff to appreciate the syntax, and the rest would be > "compile this code, step through the assembly" Seeing different calling > conventions in action will probably teach students a lot, and honestly I'd > probably audit a course taught that way. > > Justin Randall Hyde of "The Art of Assembly" book fame posits that programmers who learn the machines and how things work, through Assembly programming, are more able to write performant code. I don't know enough to confirm or deny that theory, but it stuck with me. Leam From jslozier at gmail.com Tue Jan 24 23:24:18 2012 From: jslozier at gmail.com (Jay Lozier) Date: Tue, 24 Jan 2012 23:24:18 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1F0FA8.3070108@gmail.com> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> Message-ID: <4F1F83F2.90905@gmail.com> On 01/24/2012 03:08 PM, Leam Hall wrote: > On 01/24/2012 02:52 PM, Justin Dearing wrote: > >> I was going to make an argument that assembly might not be needed at >> the >> associates level, but writing this has made me question that myself. >> However, I think its more important to be able to read assembly than >> write >> assembly, so maybe it should be taught that way. One or two lessons >> where >> you write some stuff to appreciate the syntax, and the rest would be >> "compile this code, step through the assembly" Seeing different calling >> conventions in action will probably teach students a lot, and >> honestly I'd >> probably audit a course taught that way. >> >> Justin > > Randall Hyde of "The Art of Assembly" book fame posits that > programmers who learn the machines and how things work, through > Assembly programming, are more able to write performant code. > > I don't know enough to confirm or deny that theory, but it stuck with me. Neither do I, but what little I know of assembly programming is one you are programming closer to machine language and two your actually implementing for example a for loop in much gorier detail. Both require one to pay more attention to the details of what and how one codes. Also, many claim assembly code can be optimized for performance. How important is this today for most applications may be debatable. > > Leam > > _______________________________________________ > New York PHP User Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/show-participation > -- Jay Lozier jslozier at gmail.com From rukbatsramblings at gmail.com Thu Jan 26 11:03:02 2012 From: rukbatsramblings at gmail.com (Rukbat) Date: Thu, 26 Jan 2012 11:03:02 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1F0FA8.3070108@gmail.com> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> Message-ID: <4F217936.5090405@gmail.com> As someone who started by writing machine code (not assembly, bits - and in octal, which was the big thing back when we wrote code on stone with wooden chisels), I can say that's very true. I've sen some C code that, when it was compiled to assembly, was absolutely terrible. (And don't get me started on the massive bug in version 2 of Microsoft's C compiler.) But with PHP, you're writing data, not code. Yes, it looks like code, but it's just data to the PHP interpreter which is running it. The efficiency at the assembly level really comes from writing an efficient PHP interpreter. If that's inefficient, the best PHP code isn't going to execute fast. The other, and I think more important, considerations are SQL and Javascript They'll impact the user's experience a lot more than the PHP code will. If you do a search on a huge table using LIKE or not using a proper index, it may be done when you get back from lunch - in Paris. That has nothing to do with PHP. Neither did the fact that some JS ran 50 times slower in IE5 than it did in FF1. You have to write efficient JS and efficient SQL. Inefficient PHP isn't elegant, but it won't impact the user nearly as much as a SQL join that forces a linear search on a table with 10 million records. And that's not stuff you teach in a CS course - that's the difference between an entry level programmer and someone with bloody fingers. But yes, if you're writing on the metal, assembly can be a lot more efficient at runtime than a 3GL. (Not at writing time, though - printf is a lot more efficient to write than poking bytes to the screen memory by hand, or even sending a string to an API.) On 1/24/2012 3:08 PM, Leam Hall wrote: > On 01/24/2012 02:52 PM, Justin Dearing wrote: > >> I was going to make an argument that assembly might not be needed at >> the >> associates level, but writing this has made me question that myself. >> However, I think its more important to be able to read assembly than >> write >> assembly, so maybe it should be taught that way. One or two lessons >> where >> you write some stuff to appreciate the syntax, and the rest would be >> "compile this code, step through the assembly" Seeing different calling >> conventions in action will probably teach students a lot, and >> honestly I'd >> probably audit a course taught that way. >> >> Justin > > Randall Hyde of "The Art of Assembly" book fame posits that > programmers who learn the machines and how things work, through > Assembly programming, are more able to write performant code. > > I don't know enough to confirm or deny that theory, but it stuck with me. > > Leam > > _______________________________________________ > New York PHP User Group Community Talk Mailing List > http://lists.nyphp.org/mailman/listinfo/talk > > http://www.nyphp.org/show-participation From ajai at bitblit.net Thu Jan 26 11:34:41 2012 From: ajai at bitblit.net (Ajai Khattri) Date: Thu, 26 Jan 2012 11:34:41 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F217936.5090405@gmail.com> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> Message-ID: <4F2180A1.2020709@bitblit.net> On 1/26/12 11:03 AM, Rukbat wrote: > As someone who started by writing machine code (not assembly, bits - > and in octal, which was the big thing back when we wrote code on stone > with wooden chisels), I can say that's very true. As someone who also cut his teeth writing code on 6502 and 68000 processors, I personally believe all programmers should have some experience writing machine code. Not for machismo or bragging rights, but simply because it gives you a different perspective on languages and runtimes in general. You understand a lot more how languages operate at a lower level and that makes you a better programmer when using high level languages. -- A From garyamort at gmail.com Thu Jan 26 12:08:09 2012 From: garyamort at gmail.com (Gary Mort) Date: Thu, 26 Jan 2012 12:08:09 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F1EFBAA.6040303@gmx.net> References: <4F1DA422.5040308@gmail.com> <4F1EFBAA.6040303@gmx.net> Message-ID: <4F218879.1020006@gmail.com> Hi David, thanks for the excellent suggestions! In all honesty, I think some people are viewing my goals as loftier than they are. I don't plan on writing a book or designing a curriculum. Instead, I want to go through one of my old "Learn to program Object Oriented PHP" and rejuggle the lessons so that as much as possible, good practices are used throughout the chapters. My plan would be to publish it on my website, maybe setup an email list to send out notifications when each new lesson is available - and definitely to have a forum for people to discuss with each other as well as provide me with feedback. Also, just to clarify, I am shamefully at the middle of the process to unit test, comment, and use version control. As such, one of my goals with this process is to actually learn - as I find trying to write instructions for others helps me develop it in my own head. So I expect the initial "lessons" to be rough and need fine tuning - but one of the things I've really learned is that even bad version control is better than no version control. Many people get so hung up on which system to use - wheras it doesn't matter nearly as much as using SOMETHING. If at the end of the whole process I have something solid, then I can consider the daunting task of "writing a book".. :-) On 1/24/2012 1:42 PM, David Krings wrote: > > - algorithms / objects / classes > > - documentation > - scope doc of project: what is it supposed to be (address label > creator or a bird bath?) > - functional requirements: detailed list of individual features and > functions explaining the expectations of the stakeholders (users, QA, > devs, etc.) > - technical spec I: flow charts, description of approach > => now write code, unit tests, and so on > - technical spec II: amend the first version and add a description of > what was done, no code is to be found in here > > - error handling > - adherence to UX guidelines From tedd.sperling at gmail.com Thu Jan 26 12:22:18 2012 From: tedd.sperling at gmail.com (Tedd Sperling) Date: Thu, 26 Jan 2012 12:22:18 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F2180A1.2020709@bitblit.net> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> Message-ID: <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> On Jan 26, 2012, at 11:34 AM, Ajai Khattri wrote: > On 1/26/12 11:03 AM, Rukbat wrote: >> As someone who started by writing machine code (not assembly, bits - and in octal, which was the big thing back when we wrote code on stone with wooden chisels), I can say that's very true. > > As someone who also cut his teeth writing code on 6502 and 68000 processors, I personally believe all programmers should have some experience writing machine code. Not for machismo or bragging rights, but simply because it gives you a different perspective on languages and runtimes in general. You understand a lot more how languages operate at a lower level and that makes you a better programmer when using high level languages. Oh, you had it easy. I cut my teeth on pre-6502 processors, namely a home built variety (dual logic analyzers), where we programmed with dip switches and saved our programs to paper punch tape. Later we hard-wired our first assembly language. Of course, most of us came from the "programming with rocks" community where an absence of a rock (i.e., a zero) was a new concept. Before that all our big programs resembled pyramids. It's always nice to realize the value of 001. Cheers, tedd _____________________ tedd at sperling.com http://sperling.com From rukbatsramblings at gmail.com Thu Jan 26 16:53:52 2012 From: rukbatsramblings at gmail.com (Rukbat) Date: Thu, 26 Jan 2012 16:53:52 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> Message-ID: <4F21CB70.3030804@gmail.com> On 1/26/2012 12:22 PM, Tedd Sperling wrote: > On Jan 26, 2012, at 11:34 AM, Ajai Khattri wrote: > >> On 1/26/12 11:03 AM, Rukbat wrote: >>> As someone who started by writing machine code (not assembly, bits - and in octal, which was the big thing back when we wrote code on stone with wooden chisels), I can say that's very true. >> As someone who also cut his teeth writing code on 6502 and 68000 processors, I personally believe all programmers should have some experience writing machine code. Not for machismo or bragging rights, but simply because it gives you a different perspective on languages and runtimes in general. You understand a lot more how languages operate at a lower level and that makes you a better programmer when using high level languages. > Oh, you had it easy. I cut my teeth on pre-6502 processors, namely a home built variety (dual logic analyzers), where we programmed with dip switches and saved our programs to paper punch tape. Later we hard-wired our first assembly language. Punched tape? My first assembler was a legal pad and a pencil with a good eraser. Did a lot of 2-pass assembling that way. (Okay, so I still have a [probably] working model 19 in my basement, but that came later.). 8080 wire-wrapped with 1k of 2102 RAM. (I don't consider the 8008 board I made a "computer".) Remember the 2708? No more toggle switches to get it running by that point. From david at davidmintz.org Fri Jan 27 09:34:03 2012 From: david at davidmintz.org (David Mintz) Date: Fri, 27 Jan 2012 09:34:03 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F21CB70.3030804@gmail.com> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> Message-ID: Debugging has scarcely been mentioned in this thread. Perhaps the proposed "Right Way" syllabus should include how to debug right along with unit testing and version control, since these three are related tools/skills. There might be a sort of middle way where you introduce coding first, and then as soon as the project becomes even moderately complex, get into how to fix the bug you just introduced; how you might have avoided it in the first place, with unit testing; and how you could have rolled back, with version control. As a perpetual wannabe (day job that is formally not IT-related, but self-appointed self-taught coder and general-purpose geek for our federal court interpreters' office), I have stumbled and fumbled and learned the hard way for years. One thing I still haven't taken the time to master is proper use of a debugger, so I still rely too heavily on friends like echo and print_r(). I could use a good tutorial or online course in that. -- David Mintz http://davidmintz.org/ It ain't over: http://www.healthcare-now.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rukbatsramblings at gmail.com Fri Jan 27 10:11:52 2012 From: rukbatsramblings at gmail.com (Rukbat) Date: Fri, 27 Jan 2012 10:11:52 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> Message-ID: <4F22BEB8.6090803@gmail.com> On 1/27/2012 9:34 AM, David Mintz wrote: > Debugging has scarcely been mentioned in this thread. Perhaps the > proposed "Right Way" syllabus should include how to debug right along > with unit testing and version control, since these three are related > tools/skills. > > There might be a sort of middle way where you introduce coding first, > and then as soon as the project becomes even moderately complex, get > into how to fix the bug you just introduced; how you might have > avoided it in the first place, with unit testing; and how you could > have rolled back, with version control. > > As a perpetual wannabe (day job that is formally not IT-related, but > self-appointed self-taught coder and general-purpose geek for our > federal court interpreters' office), I have stumbled and fumbled and > learned the hard way for years. One thing I still haven't taken the > time to master is proper use of a debugger, so I still rely too > heavily on friends like echo and print_r(). I could use a good > tutorial or online course in that. > Agreed - and if you don't run Firebug and FirePHP you should install them and learn how to use them. FirePHP is an easy to learn and very powerful debugging tool. And it could use a good tutorial - the site seems to be aimed at the experienced professional. From david at davidmintz.org Fri Jan 27 10:14:29 2012 From: david at davidmintz.org (David Mintz) Date: Fri, 27 Jan 2012 10:14:29 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F22BEB8.6090803@gmail.com> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> <4F22BEB8.6090803@gmail.com> Message-ID: On Fri, Jan 27, 2012 at 10:11 AM, Rukbat wrote: > On 1/27/2012 9:34 AM, David Mintz wrote: > >> [...] >> >> As a perpetual wannabe (day job that is formally not IT-related, but >> self-appointed self-taught coder and general-purpose geek for our federal >> court interpreters' office), I have stumbled and fumbled and learned the >> hard way for years. One thing I still haven't taken the time to master is >> proper use of a debugger, so I still rely too heavily on friends like echo >> and print_r(). I could use a good tutorial or online course in that. >> >> > Agreed - and if you don't run Firebug and FirePHP you should install them > and learn how to use them. FirePHP is an easy to learn and very powerful > debugging tool. And it could use a good tutorial - the site seems to be > aimed at the experienced professional. I could not possibly imagine living without Firebug and FirePHP. I am thinking more along the lines of XDebug. -- David Mintz http://davidmintz.org/ It ain't over: http://www.healthcare-now.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From garyamort at gmail.com Fri Jan 27 11:14:07 2012 From: garyamort at gmail.com (Gary Mort) Date: Fri, 27 Jan 2012 11:14:07 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> Message-ID: <4F22CD4F.70506@gmail.com> On 1/27/2012 9:34 AM, David Mintz wrote: > Debugging has scarcely been mentioned in this thread. Perhaps the > proposed "Right Way" syllabus should include how to debug right along > with unit testing and version control, since these three are related > tools/skills. I am especially weak on debugging - as such I'd tend to make that a later chapter where I can cover the different ways to debug and pluses and minuses. I still tend towards "echo...." to debug because it's fast and easy. A level up from that is still using manually inserted print statements, but sending them to a firebug console instead[so it doesn't mess up the page]. Then there is using debug_backtrace to actually grab some detailed line info. And of xdebug which I have setup and used, but it always seems lengthier than echo to use..probably due to not practicing with it[which right there indicates that I SHOULD include a full lesson on xdebug because having to write it will help me to clarify it...and then after I publish it for all the world to see, I'm sure the kind folks from NYPHP will tell me all the things I'm doing wrong. :-)] From ramons at gmx.net Fri Jan 27 13:14:15 2012 From: ramons at gmx.net (David Krings) Date: Fri, 27 Jan 2012 13:14:15 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> <4F22BEB8.6090803@gmail.com> Message-ID: <4F22E977.7080303@gmx.net> On 1/27/2012 10:14 AM, David Mintz wrote: > I could not possibly imagine living without Firebug and FirePHP. I am thinking > more along the lines of XDebug. Never used Firebug and FirePHP, but I will take it for a spin...when I ever get around to do some PHP coding again. Years back I looked around for good implementations of a PHP debugger and ended up going back to the 'source' of one using PhpED from Nusphere: the DBG debugger. In a nutshell, whatever you want to echo you can do with a debugger, and even more as you can do that before output is supposed to start or when there is no output at all. I tend to create separate script files depending on functional area (input/processing/output) and the processing files never generate any output. Throwing an echo in there would only add code that I have to take out later...and potentially forget about. Debuggers also show you the content of all variables and arrays and system values at a breakpoint, which is another benefit, because with break points you can continue on, which an echo it is not that easy, especially when the actual output with proper html header is yet to follow (and will fail). There are a few implementations of DBG in other editors that do not work across separate scripts, which is just useless. But no matter which debugger you have available, learning the basics of how to use it is time well spent. Other tools worthwhile to learn how to use are a profiler and phpdocumentor....unless you don't care about creating docs and flowcharts and stuff like that for others. David From jeff at jeffslutz.com Fri Jan 27 13:22:15 2012 From: jeff at jeffslutz.com (Jeff Slutz) Date: Fri, 27 Jan 2012 13:22:15 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: <4F22E977.7080303@gmx.net> References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> <4F22BEB8.6090803@gmail.com> <4F22E977.7080303@gmx.net> Message-ID: For more invisible/seamless debugging server-side I've found error_log() to be extremely handy as it doesn't change the display output at all. JS -- Jeff Slutz JSLEUTH LLC 3242 44th ST APT 3F Astoria, NY 11103 c. 970.443.9390 jeff at jeffslutz.com On Fri, Jan 27, 2012 at 1:14 PM, David Krings wrote: > On 1/27/2012 10:14 AM, David Mintz wrote: > >> I could not possibly imagine living without Firebug and FirePHP. I am >> thinking >> more along the lines of XDebug. >> > > Never used Firebug and FirePHP, but I will take it for a spin...when I > ever get around to do some PHP coding again. Years back I looked around for > good implementations of a PHP debugger and ended up going back to the > 'source' of one using PhpED from Nusphere: the DBG debugger. In a nutshell, > whatever you want to echo you can do with a debugger, and even more as you > can do that before output is supposed to start or when there is no output > at all. I tend to create separate script files depending on functional area > (input/processing/output) and the processing files never generate any > output. Throwing an echo in there would only add code that I have to take > out later...and potentially forget about. > Debuggers also show you the content of all variables and arrays and system > values at a breakpoint, which is another benefit, because with break points > you can continue on, which an echo it is not that easy, especially when the > actual output with proper html header is yet to follow (and will fail). > There are a few implementations of DBG in other editors that do not work > across separate scripts, which is just useless. But no matter which > debugger you have available, learning the basics of how to use it is time > well spent. > Other tools worthwhile to learn how to use are a profiler and > phpdocumentor....unless you don't care about creating docs and flowcharts > and stuff like that for others. > > > David > ______________________________**_________________ > 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: From rainelemental at gmail.com Fri Jan 27 13:37:35 2012 From: rainelemental at gmail.com (Federico Ulfo) Date: Fri, 27 Jan 2012 13:37:35 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> <4F22BEB8.6090803@gmail.com> <4F22E977.7080303@gmx.net> Message-ID: I don't know how we arrived to the debugging discussion but I'd like to share with you guys the script I use to debug my apps https://github.com/rainphp/rainframework/blob/master/system/library/error.functions.php is very handy, just include it in your project and it will display infos and backtrace of your errors Federico On Fri, Jan 27, 2012 at 1:22 PM, Jeff Slutz wrote: > For more invisible/seamless debugging server-side I've found error_log() > to be extremely handy as it doesn't change the display output at all. > > JS > -- > Jeff Slutz > JSLEUTH LLC > 3242 44th ST APT 3F > Astoria, NY 11103 > c. 970.443.9390 > jeff at jeffslutz.com > > > > On Fri, Jan 27, 2012 at 1:14 PM, David Krings wrote: > >> On 1/27/2012 10:14 AM, David Mintz wrote: >> >>> I could not possibly imagine living without Firebug and FirePHP. I am >>> thinking >>> more along the lines of XDebug. >>> >> >> Never used Firebug and FirePHP, but I will take it for a spin...when I >> ever get around to do some PHP coding again. Years back I looked around for >> good implementations of a PHP debugger and ended up going back to the >> 'source' of one using PhpED from Nusphere: the DBG debugger. In a nutshell, >> whatever you want to echo you can do with a debugger, and even more as you >> can do that before output is supposed to start or when there is no output >> at all. I tend to create separate script files depending on functional area >> (input/processing/output) and the processing files never generate any >> output. Throwing an echo in there would only add code that I have to take >> out later...and potentially forget about. >> Debuggers also show you the content of all variables and arrays and >> system values at a breakpoint, which is another benefit, because with break >> points you can continue on, which an echo it is not that easy, especially >> when the actual output with proper html header is yet to follow (and will >> fail). >> There are a few implementations of DBG in other editors that do not work >> across separate scripts, which is just useless. But no matter which >> debugger you have available, learning the basics of how to use it is time >> well spent. >> Other tools worthwhile to learn how to use are a profiler and >> phpdocumentor....unless you don't care about creating docs and flowcharts >> and stuff like that for others. >> >> >> David >> ______________________________**_________________ >> 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: From ajai at bitblit.net Fri Jan 27 14:33:38 2012 From: ajai at bitblit.net (Ajai Khattri) Date: Fri, 27 Jan 2012 14:33:38 -0500 Subject: [nycphp-talk] Learning to program the right way In-Reply-To: References: <4F1ED83E.3080008@gmail.com> <4F1F0FA8.3070108@gmail.com> <4F217936.5090405@gmail.com> <4F2180A1.2020709@bitblit.net> <626C65E4-59D9-45B8-8366-C4BB5FF4CD23@gmail.com> <4F21CB70.3030804@gmail.com> <4F22BEB8.6090803@gmail.com> <4F22E977.7080303@gmx.net> Message-ID: <4F22FC12.8050605@bitblit.net> On 1/27/12 1:37 PM, Federico Ulfo wrote: > I don't know how we arrived to the debugging discussion but I'd like > to share with you guys the script I use to debug my apps > https://github.com/rainphp/rainframework/blob/master/system/library/error.functions.php > is very handy, just include it in your project and it will display > infos and backtrace of your errors > If you're using a full framework, most already include debug toolbars and backtraces... -- A