<?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 for Dragons in the Algorithm</title>
	<atom:link href="http://mcherm.com/comments/feed" rel="self" type="application/rss+xml" />
	<link>http://mcherm.com</link>
	<description>Adventures in Programming</description>
	<lastBuildDate>Fri, 02 Apr 2010 16:07:43 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on ToDo by Rob Roath</title>
		<link>http://mcherm.com/todo/comment-page-1#comment-38477</link>
		<dc:creator>Rob Roath</dc:creator>
		<pubDate>Fri, 02 Apr 2010 16:07:43 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/blog/todo#comment-38477</guid>
		<description>Hi,

I was sucked into the vortex of social networking today and I ended up here.  You look like a very talented guy.  I specialize in placing IT pros in the Phila metro area.  Please ping me if you ever want to look for a new technical position.  The market is realy heating up.  All the best, Rob  215.568.1513, robert.roath@rht.com</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I was sucked into the vortex of social networking today and I ended up here.  You look like a very talented guy.  I specialize in placing IT pros in the Phila metro area.  Please ping me if you ever want to look for a new technical position.  The market is realy heating up.  All the best, Rob  215.568.1513, <a href="mailto:robert.roath@rht.com">robert.roath@rht.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Logging APIs &#8211; Feature List by David Horvath</title>
		<link>http://mcherm.com/permalinks/1/logging-apis-feature-list/comment-page-1#comment-35408</link>
		<dc:creator>David Horvath</dc:creator>
		<pubDate>Tue, 09 Feb 2010 13:21:12 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=388#comment-35408</guid>
		<description>The JVM may prevent #2 but that doesn&#039;t help for O/S faults, or, as you mention, other languages. In the &quot;old C days&quot; the saying was &quot;The world is not a VAX&quot; (because the VAX would let you get away with things that would upset other systems – like dereferencing the NULL pointer). So you have to remember, &quot;The world is not just Java&quot; :-)</description>
		<content:encoded><![CDATA[<p>The JVM may prevent #2 but that doesn&#8217;t help for O/S faults, or, as you mention, other languages. In the &#8220;old C days&#8221; the saying was &#8220;The world is not a VAX&#8221; (because the VAX would let you get away with things that would upset other systems – like dereferencing the NULL pointer). So you have to remember, &#8220;The world is not just Java&#8221; :-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Logging APIs &#8211; Feature List by mcherm</title>
		<link>http://mcherm.com/permalinks/1/logging-apis-feature-list/comment-page-1#comment-35407</link>
		<dc:creator>mcherm</dc:creator>
		<pubDate>Tue, 09 Feb 2010 13:20:24 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=388#comment-35407</guid>
		<description>Oh, I particularly like your #1 &quot;Uniqueness of Message&quot;. A useful feature that I&#039;ve seen is to automatically mark each log message with the line and file from which it was generated. This should be one of the criteria.

 

#2 I&#039;m not so sure about. In the Java world, files flush when they are closed suddenly, unless the JVM itself crashes -- and that is VERY rare these days; it essentially never happens with our files. Of course, this isn&#039;t supposed to be a java-specific list, so given that I should probably list that one too.</description>
		<content:encoded><![CDATA[<p>Oh, I particularly like your #1 &#8220;Uniqueness of Message&#8221;. A useful feature that I&#8217;ve seen is to automatically mark each log message with the line and file from which it was generated. This should be one of the criteria.</p>
<p>#2 I&#8217;m not so sure about. In the Java world, files flush when they are closed suddenly, unless the JVM itself crashes &#8212; and that is VERY rare these days; it essentially never happens with our files. Of course, this isn&#8217;t supposed to be a java-specific list, so given that I should probably list that one too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Logging APIs &#8211; Feature List by David Horvath</title>
		<link>http://mcherm.com/permalinks/1/logging-apis-feature-list/comment-page-1#comment-35406</link>
		<dc:creator>David Horvath</dc:creator>
		<pubDate>Tue, 09 Feb 2010 13:19:26 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=388#comment-35406</guid>
		<description>Two issues largely missed in logging

Uniqueness of message – &quot;we had an error&quot; that appears in multiple places… Which specific chunk of code with that message was the one that created it?  I&#039;ve seen function name and/or unique error number be most effective. But if you’ve got multiple functions with the same name (object overloading) then it can become complex. And tracking unique error numbers, especially with shared code/object libraries can become complex. 
Message buffering. This one only really matters if the application crashes rather than being able to exit gracefully when an error is detected/handled. I&#039;m a strong proponent of the C fflush(); it could be handled as part of the error logging code/objects (your logger.X example) with a frequency count (every N messages) or semi-explicitly (after a type of invocation), or even manually. 
 

Granted, frequent fflushes slows processing (forcing physical I/O rather than buffered into larger writes), but provides more information on failure.

 

Your last &quot;Delayed String Construction&quot; example reminds me a lot of the C printf statement… Except you used {} instead of %s%s%s%s%s.</description>
		<content:encoded><![CDATA[<p>Two issues largely missed in logging</p>
<p>Uniqueness of message – &#8220;we had an error&#8221; that appears in multiple places… Which specific chunk of code with that message was the one that created it?  I&#8217;ve seen function name and/or unique error number be most effective. But if you’ve got multiple functions with the same name (object overloading) then it can become complex. And tracking unique error numbers, especially with shared code/object libraries can become complex.<br />
Message buffering. This one only really matters if the application crashes rather than being able to exit gracefully when an error is detected/handled. I&#8217;m a strong proponent of the C fflush(); it could be handled as part of the error logging code/objects (your logger.X example) with a frequency count (every N messages) or semi-explicitly (after a type of invocation), or even manually. </p>
<p>Granted, frequent fflushes slows processing (forcing physical I/O rather than buffered into larger writes), but provides more information on failure.</p>
<p>Your last &#8220;Delayed String Construction&#8221; example reminds me a lot of the C printf statement… Except you used {} instead of %s%s%s%s%s.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Raising the limit on IDs processed by Shawn Poulson</title>
		<link>http://mcherm.com/permalinks/1/raising-the-limit/comment-page-1#comment-31311</link>
		<dc:creator>Shawn Poulson</dc:creator>
		<pubDate>Fri, 13 Nov 2009 14:07:26 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=324#comment-31311</guid>
		<description>Start with a cage containing five monkeys. Inside the cage, hang a banana on a string and place a set of stairs under it.

Before long, one of the monkeys will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, all of the monkeys are sprayed with cold water. After a while, another monkey makes an attempt with the same result; all the monkeys are sprayed with cold water.

Pretty soon, none of the monkeys will try to climb the stairs.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack &amp; restrain him. After another attempt and attack, he knows that if he tries to climb the stairs, then he will be assaulted.

Next, remove one of the original four monkeys and replace it with a new one. The newcomer goes to the stairs and is restrained by the group. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth.

Every time the newest monkey takes to the stairs, he is punished by the group.

Now, all of the monkeys, which are restraining each other, have no idea why they were not permitted to climb the stairs or why they are participating in the restraint of the newest monkey. After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water.

Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that&#039;s the way it&#039;s always been done around here. 

-Author Unknown</description>
		<content:encoded><![CDATA[<p>Start with a cage containing five monkeys. Inside the cage, hang a banana on a string and place a set of stairs under it.</p>
<p>Before long, one of the monkeys will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, all of the monkeys are sprayed with cold water. After a while, another monkey makes an attempt with the same result; all the monkeys are sprayed with cold water.</p>
<p>Pretty soon, none of the monkeys will try to climb the stairs.</p>
<p>Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack &amp; restrain him. After another attempt and attack, he knows that if he tries to climb the stairs, then he will be assaulted.</p>
<p>Next, remove one of the original four monkeys and replace it with a new one. The newcomer goes to the stairs and is restrained by the group. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth.</p>
<p>Every time the newest monkey takes to the stairs, he is punished by the group.</p>
<p>Now, all of the monkeys, which are restraining each other, have no idea why they were not permitted to climb the stairs or why they are participating in the restraint of the newest monkey. After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water.</p>
<p>Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that&#8217;s the way it&#8217;s always been done around here. </p>
<p>-Author Unknown</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Upgrading GWT/AppEngine to v1.6+ by mcherm</title>
		<link>http://mcherm.com/permalinks/1/upgrading-gwtappengine-to-v1-6/comment-page-1#comment-31097</link>
		<dc:creator>mcherm</dc:creator>
		<pubDate>Mon, 09 Nov 2009 15:49:19 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=314#comment-31097</guid>
		<description>Yeah... sorry for the long absence. There&#039;s an essay in there about extrinsic vs intrinsic motivation.</description>
		<content:encoded><![CDATA[<p>Yeah&#8230; sorry for the long absence. There&#8217;s an essay in there about extrinsic vs intrinsic motivation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Upgrading GWT/AppEngine to v1.6+ by Shawn Poulson</title>
		<link>http://mcherm.com/permalinks/1/upgrading-gwtappengine-to-v1-6/comment-page-1#comment-31090</link>
		<dc:creator>Shawn Poulson</dc:creator>
		<pubDate>Mon, 09 Nov 2009 12:51:57 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=314#comment-31090</guid>
		<description>Yay!  You&#039;re back!</description>
		<content:encoded><![CDATA[<p>Yay!  You&#8217;re back!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How Long is an Email Address? by mcherm</title>
		<link>http://mcherm.com/permalinks/1/how-long-is-an-email-address/comment-page-1#comment-22054</link>
		<dc:creator>mcherm</dc:creator>
		<pubDate>Wed, 24 Jun 2009 16:20:12 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=227#comment-22054</guid>
		<description>Porges: Thanks. And a recently-published writeup of the issue can be found here: http://www.eph.co.uk/resources/email-address-length-faq/</description>
		<content:encoded><![CDATA[<p>Porges: Thanks. And a recently-published writeup of the issue can be found here: <a href="http://www.eph.co.uk/resources/email-address-length-faq/" rel="nofollow">http://www.eph.co.uk/resources/email-address-length-faq/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on How Long is an Email Address? by Porges</title>
		<link>http://mcherm.com/permalinks/1/how-long-is-an-email-address/comment-page-1#comment-22045</link>
		<dc:creator>Porges</dc:creator>
		<pubDate>Wed, 24 Jun 2009 13:55:04 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=227#comment-22045</guid>
		<description>If you look at 5321, you&#039;ll find that SMTP gives a much shorter maximum length: 254 octets.</description>
		<content:encoded><![CDATA[<p>If you look at 5321, you&#8217;ll find that SMTP gives a much shorter maximum length: 254 octets.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Estimate Units by Doug L.</title>
		<link>http://mcherm.com/permalinks/1/estimate-units/comment-page-1#comment-21537</link>
		<dc:creator>Doug L.</dc:creator>
		<pubDate>Wed, 17 Jun 2009 23:00:31 +0000</pubDate>
		<guid isPermaLink="false">http://mcherm.com/?p=268#comment-21537</guid>
		<description>Neither hours nor days.  Use &quot;ideal estimation units&quot;.  Then, keep track.  Measure your first few iterations, and you end up with a rough approximation of how many IEUs you or your team can accomplish in, say, a week.</description>
		<content:encoded><![CDATA[<p>Neither hours nor days.  Use &#8220;ideal estimation units&#8221;.  Then, keep track.  Measure your first few iterations, and you end up with a rough approximation of how many IEUs you or your team can accomplish in, say, a week.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

