<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: PHP Developer Best Practices</title>
	<atom:link href="http://mikenaberezny.com/2008/09/16/php-developer-best-practices/feed/" rel="self" type="application/rss+xml" />
	<link>http://mikenaberezny.com/2008/09/16/php-developer-best-practices/</link>
	<description></description>
	<lastBuildDate>Fri, 01 Jul 2011 12:51:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: Hodicska Gergely</title>
		<link>http://mikenaberezny.com/2008/09/16/php-developer-best-practices/comment-page-1/#comment-116940</link>
		<dc:creator>Hodicska Gergely</dc:creator>
		<pubDate>Sat, 20 Sep 2008 10:50:53 +0000</pubDate>
		<guid isPermaLink="false">http://mikenaberezny.com/?p=426#comment-116940</guid>
		<description>THX for sharing the slides: great work. A few comments:
- I prefer TAB over space with a little rule: use TAB in the beginning of the lines, and use space after. This way every developer can use his own indentation width and the look of the code is consistent. Of course this needs a little more discipline from the developer.
- I missed a little mentioning creating convention related to the database too. There could be a lot mess on this level too. (table name: plural or not, PK: id or user_id, index/trigger naming convention, &quot;design patterns&quot;: using the same data types in the same situations, field naming convention: is_ for bool etc., query formating and a lot more).
- &quot;Learn to design for testability&quot;: a very important point and unfortunately this one is not really covered by PHP books.</description>
		<content:encoded><![CDATA[<p>THX for sharing the slides: great work. A few comments:<br />
- I prefer TAB over space with a little rule: use TAB in the beginning of the lines, and use space after. This way every developer can use his own indentation width and the look of the code is consistent. Of course this needs a little more discipline from the developer.<br />
- I missed a little mentioning creating convention related to the database too. There could be a lot mess on this level too. (table name: plural or not, PK: id or user_id, index/trigger naming convention, &#8220;design patterns&#8221;: using the same data types in the same situations, field naming convention: is_ for bool etc., query formating and a lot more).<br />
- &#8220;Learn to design for testability&#8221;: a very important point and unfortunately this one is not really covered by PHP books.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Day</title>
		<link>http://mikenaberezny.com/2008/09/16/php-developer-best-practices/comment-page-1/#comment-116708</link>
		<dc:creator>Kevin Day</dc:creator>
		<pubDate>Fri, 19 Sep 2008 13:09:05 +0000</pubDate>
		<guid isPermaLink="false">http://mikenaberezny.com/?p=426#comment-116708</guid>
		<description>Great slides. It finally convinced me to integrate testing into my development procedure.  Thanks!</description>
		<content:encoded><![CDATA[<p>Great slides. It finally convinced me to integrate testing into my development procedure.  Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas</title>
		<link>http://mikenaberezny.com/2008/09/16/php-developer-best-practices/comment-page-1/#comment-116268</link>
		<dc:creator>Thomas</dc:creator>
		<pubDate>Tue, 16 Sep 2008 22:54:07 +0000</pubDate>
		<guid isPermaLink="false">http://mikenaberezny.com/?p=426#comment-116268</guid>
		<description>Distributed VCS without a mention of Mercurial? That was surprising. Great presentation, although I was also surprised that you left off the Drupal project&#039;s coding standards which are prominent. I think I finally get TDD now, and I&#039;m going to see how I can use in (SimpleTest) in my business&#039; CakePHP app.</description>
		<content:encoded><![CDATA[<p>Distributed VCS without a mention of Mercurial? That was surprising. Great presentation, although I was also surprised that you left off the Drupal project&#8217;s coding standards which are prominent. I think I finally get TDD now, and I&#8217;m going to see how I can use in (SimpleTest) in my business&#8217; CakePHP app.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Naberezny</title>
		<link>http://mikenaberezny.com/2008/09/16/php-developer-best-practices/comment-page-1/#comment-116262</link>
		<dc:creator>Mike Naberezny</dc:creator>
		<pubDate>Tue, 16 Sep 2008 22:21:40 +0000</pubDate>
		<guid isPermaLink="false">http://mikenaberezny.com/?p=426#comment-116262</guid>
		<description>Yes.  Most users treat a tag in Subversion as a snapshot in time.  Once created, the tag is not modified.  A new deployment milestone will be a new tag.  

Using the &lt;code&gt;export&lt;/code&gt; command instead of &lt;code&gt;checkout&lt;/code&gt; prevents the repository information (&lt;code&gt;.svn&lt;/code&gt; directories) from being created.</description>
		<content:encoded><![CDATA[<p>Yes.  Most users treat a tag in Subversion as a snapshot in time.  Once created, the tag is not modified.  A new deployment milestone will be a new tag.  </p>
<p>Using the <code>export</code> command instead of <code>checkout</code> prevents the repository information (<code>.svn</code> directories) from being created.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vid Luther</title>
		<link>http://mikenaberezny.com/2008/09/16/php-developer-best-practices/comment-page-1/#comment-116257</link>
		<dc:creator>Vid Luther</dc:creator>
		<pubDate>Tue, 16 Sep 2008 21:48:14 +0000</pubDate>
		<guid isPermaLink="false">http://mikenaberezny.com/?p=426#comment-116257</guid>
		<description>Great presentation/Slides Mike and Matthew, too bad I couldn&#039;t make it to actually see it in person.  I had one question. 

Why do an export from the SVN tag?, why not a CO of the tag? Is it because ideally once something is tagged, any maintenance fixes etc, will be done to a different branch, and hence a new tag will be created?</description>
		<content:encoded><![CDATA[<p>Great presentation/Slides Mike and Matthew, too bad I couldn&#8217;t make it to actually see it in person.  I had one question. </p>
<p>Why do an export from the SVN tag?, why not a CO of the tag? Is it because ideally once something is tagged, any maintenance fixes etc, will be done to a different branch, and hence a new tag will be created?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

