<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for jsorensen</title><link xmlns="http://www.w3.org/2005/Atom" rel="http://api.friendfeed.com/2008/03#sup" href="http://disqus.com/sup/all.sup#usercomments-e16078fc" type="application/json"/><link>http://disqus.com/people/jsorensen/</link><description></description><language>en</language><lastBuildDate>Tue, 05 May 2009 05:04:26 -0000</lastBuildDate><item><title>Re: Fix a bug in Ruby&amp;#8217;s configure.in and get a ~30% performance boost.</title><link>http://timetobleed.com/fix-a-bug-in-rubys-configurein-and-get-a-30-performance-boost/#comment-9007139</link><description>Good stuff, keep it coming!&lt;br&gt;&lt;br&gt;With the risk of being "that guy", are you submitting this upstream?&lt;br&gt;&lt;br&gt;Does it ever make sense to use the old behaviour of --enable-pthread (eg. why the extra flag)?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jsorensen</dc:creator><pubDate>Tue, 05 May 2009 05:04:26 -0000</pubDate></item><item><title>Re: The Exciter - Why You Should Deploy Your Next Application on Ruby 1.9 and a Rant in General</title><link>http://theexciter.com/articles/why-you-should-deploy-your-next-application-on-ruby-1.html#comment-6700160</link><description>Oh yeah, repository sharing sites, as well as git it self is just the enabling medium here.&lt;br&gt;&lt;br&gt;The real problem in all this is of course the fact that maintainers sometimes stop maintaining, for various reasons (and that's fine). Maybe something is needed that takes advantages of the social distributed aspect, but isn't geared towards who has the longest HEAD (no pun), but rather how many are actually using a gem. And not decided by vote, but actual usage and gem downloads.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jsorensen</dc:creator><pubDate>Fri, 27 Feb 2009 09:37:06 -0000</pubDate></item><item><title>Re: The Exciter - Getting Webby With It</title><link>http://theexciter.com/articles/getting-webby-with-it.html#comment-4726970</link><description>I did originally :) Except it confuses webby when it's in a post (thinks its part of the yaml header)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jsorensen</dc:creator><pubDate>Mon, 29 Dec 2008 11:53:49 -0000</pubDate></item><item><title>Re: Verbose logging will disturb your sleep</title><link>http://brodwall.com/johannes/blog/2008/10/28/verbose-logging-will-disturb-your-sleep/#comment-3351968</link><description>:)&lt;br&gt;&lt;br&gt;And my point is that actually sitting there watching those logs feels like an anti-pattern in the first place (information overload is just the symptom/consequence of that), when you really should be collecting and filtering that data from a bigger perspective in order to find correlations and causes, just like you would with any other system related data (performance graphs over time being a good example).</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jsorensen</dc:creator><pubDate>Tue, 28 Oct 2008 18:13:45 -0000</pubDate></item><item><title>Re: Verbose logging will disturb your sleep</title><link>http://brodwall.com/johannes/blog/2008/10/28/verbose-logging-will-disturb-your-sleep/#comment-3351618</link><description>Doesn't matter if it's rails, postgres, tomcat or apache, it's the idea of actually doing the mundane task of sitting there, watching all those little things scroll by, while possibly missing the bigger picture; the overall system components interacting.&lt;br&gt;&lt;br&gt;But sure, it all depends on what exactly you're looking for in those logs...</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jsorensen</dc:creator><pubDate>Tue, 28 Oct 2008 17:50:37 -0000</pubDate></item><item><title>Re: Verbose logging will disturb your sleep</title><link>http://brodwall.com/johannes/blog/2008/10/28/verbose-logging-will-disturb-your-sleep/#comment-3350353</link><description>The other side of the issue may very well be that your actual approach to viewing the log is flawed. I definitely see your point, but I want to raise it with a "don't tail -f logfiles".&lt;br&gt;&lt;br&gt;The problem with tailing logfiles is that your context is wrong, you're spend braintime trying to find that particular logging statement (at least if you're trying to figure out the symptoms of an issue), instead of trying to figure out what actually is wrong when all the cogs run together.&lt;br&gt;Logging to a system that allows you to filter and match timestamps against other systems' logs seems like a much nicer way of spending "braintime". I keep hearing &lt;a href="http://splunk.com" rel="nofollow"&gt;splunk.com&lt;/a&gt; is good, and there's a few other solutions whose names escape me right now.&lt;br&gt;&lt;br&gt;Granted, I haven't used such an approach too much, but frankly I'm just tired of shifting and grepping through all those log files. I'd much rather be in a situation where I could log more and filter more afterwards/meanwhile, than sacrificing (useful) log output in order to ease my what-feels-like-stone-age approach to logging (tail + grep/sed).</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jsorensen</dc:creator><pubDate>Tue, 28 Oct 2008 16:38:45 -0000</pubDate></item></channel></rss>