<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Sat, 25 May 2013 22:25:55 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[DZone.com: All debugging and no testing makes the PHP programmer a dull boy ]]></title>
      <guid>http://www.phpdeveloper.org/news/18210</guid>
      <link>http://www.phpdeveloper.org/news/18210</link>
      <description><![CDATA[<p>
In <a href="http://css.dzone.com/articles/all-debugging-and-no-testing">this new post</a> on DZone.com, <i>Giorgio Sironi</i> suggests that "all debugging and no testing" in your development practices can be more difficult in the long run.
</p>
<blockquote>
By now you have already understood that I would always proposed automated end-to-end and unit tests as a way to substitute much of debugging. End-to-end tests can serve only to discover that a bug exists, while a unit test's job is instead to tell you exactly where the problem is.
</blockquote>
<p>
He advocates testing because it fits two needs - it's repeatable (a consistent, "third party" structure) and it allows you to find the pieces of code causing the issue more quickly rather than having to guess where the problem is an insert checks. He doesn't suggest completely getting rid of things like Xdebug, though. They have their place and he even suggests some configuration changes that can help make it even more effective.
</p>]]></description>
      <pubDate>Tue, 10 Jul 2012 13:06:02 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Working Software Blog: Parsing the output of PHPs print_r function]]></title>
      <guid>http://www.phpdeveloper.org/news/15744</guid>
      <link>http://www.phpdeveloper.org/news/15744</link>
      <description><![CDATA[<p>
On the Working Software blog there's <a href="http://workingsoftware.com.au/page/Parsing_the_output_of_PHPs_printr_function">a recent post</a> looking at correcting a mistake that the developer made when choosing the logging method of his application - pushing the output of <a href="http://php.net/print_r">print_r</a> into a file.
</p>
<blockquote>
 recently deployed a job on which the timeline was so tight that my ability to type quickly was what made the difference between delivering on time or not. Everything was rushed, the budget was tight, it was one of those real seat of the pants deals and there was far too little testing done. [...] The only problem is that, in the 5 minutes before the site was supposed to go live, I didn't really have much time to thoughtfully prepare a logging system to record all this stuff and, in my haste, I settled for [a file_put_contents of the print_r of $_GET and $_POST].
</blockquote>
<p>
Obviously, this solution is useful for casual browsing of the information, but if you need any real data from it, it's a real chore. To help you with the task, they've put together a snippet of code that can work through your print_r output and return it in a much more handy line-by-line result. Full code is copy-and-paste ready in <a href="http://workingsoftware.com.au/page/Parsing_the_output_of_PHPs_printr_function">the post</a>.
</p>]]></description>
      <pubDate>Fri, 14 Jan 2011 12:19:00 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Brandon Savage's Blog: Bug-Free: Your Bug-Fixing Toolkit (Part 1 of N)]]></title>
      <guid>http://www.phpdeveloper.org/news/11225</guid>
      <link>http://www.phpdeveloper.org/news/11225</link>
      <description><![CDATA[<p>
<i>Brandon Savage</i> has the <a href="http://www.brandonsavage.net/entry/bugfree-your-bugfixing-toolkit-part-1-of-n.html">first part</a> of a series posted (with N parts) showing off some of the tools that PHP already has built in to make your debugging life easier.
</p>
<blockquote>
PHP has a large number of tools for fixing bugs and resolving underlying issues. But many people don't know what they are, and some of them are extensions requiring installation in order to work. In this series, we'll explore some features for debugging PHP scripts, from the most basic to more advanced.
</blockquote>
<p>
He <a href="http://www.brandonsavage.net/entry/bugfree-your-bugfixing-toolkit-part-1-of-n.html">looks at</a> three of the most basic ones (and ones that most developers I know out there use every day) - <a href="http://php.net/var_dump">var_dump</a>, <a href="http://php.net/print_r">print_r</a> and <a href="http://php.net/var_export">var_export</a>. Examples of each in use are included...
</p>]]></description>
      <pubDate>Thu, 16 Oct 2008 10:29:57 -0500</pubDate>
    </item>
  </channel>
</rss>
