<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Disqus - Latest Comments for scarpen</title><link>http://disqus.com/by/scarpen/</link><description></description><atom:link href="http://disqus.com/scarpen/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Fri, 02 Jul 2010 08:40:22 -0000</lastBuildDate><item><title>Re: Karl Seguin's Blog</title><link>http://www.openmymind.net/2010/7/1/Installing-Nginx-with-Passenger-on-Linux#comment-60274085</link><description>&lt;p&gt;I'm pretty sure Passenger can also walk you through this for nginx if you execute "passenger-install-nginx module."  It will download the source (or ask you where it is), ask for any additional config (like modules), build, and install.&lt;/p&gt;&lt;p&gt;But becoming familiar with configure/make/install is time well spent on Linux.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sean Carpenter</dc:creator><pubDate>Fri, 02 Jul 2010 08:40:22 -0000</pubDate></item><item><title>Re: Test Naming: To Underscore or Not To Underscore</title><link>http://arcware.net/2009/01/06/test-naming-to-underscore-or-not-to-underscore/#comment-4936005</link><description>&lt;p&gt;I'm pretty much in the same camp.  I still believe underscores aren't necessary as part of an API, but they sure make test names more readable.  It took me a while to accept the fact that code written for tests doesn't have to adhere to the same set of standards as production code (it has to adhere to good coding practices, it's just that they can be different than those for production code).  Once I accepted that, I felt better about the code I was writing in tests.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sean Carpenter</dc:creator><pubDate>Tue, 06 Jan 2009 13:14:31 -0000</pubDate></item><item><title>Re: How to Suppress PowerShell Errors</title><link>http://arcware.net/2008/12/12/how-to-suppress-powershell-errors/#comment-4458933</link><description>&lt;p&gt;In the Get-ChildItem call, you can specify the "-filter" argument instead of piping the results to "where".  This causes the filter to be part of the underlying provider's call which should make it more efficient since less data is actually returned to Powershell.  You can also pipe the results of Get-ChildItem directly to Remove-Item.  Lastly, this can become a one-liner by supplying the "path" argument to Get-ChlidItem:&lt;/p&gt;&lt;p&gt;Get-ChildItem -path C:\Users\Dave\Desktop\Temp -recurse -force -filter Junk | Remove-Item -recurse -force&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sean Carpenter</dc:creator><pubDate>Wed, 17 Dec 2008 10:38:04 -0000</pubDate></item></channel></rss>