<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for RTFB.log</title>
	<atom:link href="http://rtfblog.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://rtfblog.com</link>
	<description>Read The F/*IXME*/ Blog!</description>
	<lastBuildDate>Tue, 07 Feb 2012 09:33:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Comment on An introduction to search-based applications by An overview of the Business Intelligence world &#171; RTFB.log</title>
		<link>http://rtfblog.com/2011/04/11/introduction-sba/#comment-27</link>
		<dc:creator><![CDATA[An overview of the Business Intelligence world &#171; RTFB.log]]></dc:creator>
		<pubDate>Tue, 07 Feb 2012 09:33:35 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=68#comment-27</guid>
		<description><![CDATA[[...] is stored as unstructured data, like e-mails, and it is very difficult to analyze it. This is what SBA are trying to deal [...]]]></description>
		<content:encoded><![CDATA[<p>[...] is stored as unstructured data, like e-mails, and it is very difficult to analyze it. This is what SBA are trying to deal [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Improve your Internet upload bandwidth management by configuring your Linux router by Albin Kauffmann</title>
		<link>http://rtfblog.com/2011/03/12/improve-your-internet-upload-bandwidth-management-by-configuring-your-linux-router/#comment-26</link>
		<dc:creator><![CDATA[Albin Kauffmann]]></dc:creator>
		<pubDate>Sun, 23 Oct 2011 07:49:24 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=87#comment-26</guid>
		<description><![CDATA[Thanks. This is a wordpress theme called INove. Note that it is available for free accounts hosted on wordpress.com.]]></description>
		<content:encoded><![CDATA[<p>Thanks. This is a wordpress theme called INove. Note that it is available for free accounts hosted on wordpress.com.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Improve your Internet upload bandwidth management by configuring your Linux router by router table</title>
		<link>http://rtfblog.com/2011/03/12/improve-your-internet-upload-bandwidth-management-by-configuring-your-linux-router/#comment-25</link>
		<dc:creator><![CDATA[router table]]></dc:creator>
		<pubDate>Sun, 23 Oct 2011 07:29:56 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=87#comment-25</guid>
		<description><![CDATA[Your post is top notch.Will bookmark your page for further visits,By the way,where did you get this awesome theme for your web site?]]></description>
		<content:encoded><![CDATA[<p>Your post is top notch.Will bookmark your page for further visits,By the way,where did you get this awesome theme for your web site?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Update or insert rows in SQL by router table</title>
		<link>http://rtfblog.com/2011/09/07/update-or-insert/#comment-24</link>
		<dc:creator><![CDATA[router table]]></dc:creator>
		<pubDate>Sun, 23 Oct 2011 07:18:30 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=422#comment-24</guid>
		<description><![CDATA[Your post is top notch.Will bookmark your web page for additional visits,As an aside,where did you get this remarkable theme for your blog site?]]></description>
		<content:encoded><![CDATA[<p>Your post is top notch.Will bookmark your web page for additional visits,As an aside,where did you get this remarkable theme for your blog site?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why you should probably not bother about Ruby&#8217;s speed by Quentin Raynaud</title>
		<link>http://rtfblog.com/2011/03/21/why-you-should-probably-not-bother-about-ruby-s-speed/#comment-23</link>
		<dc:creator><![CDATA[Quentin Raynaud]]></dc:creator>
		<pubDate>Fri, 09 Sep 2011 15:35:51 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=9#comment-23</guid>
		<description><![CDATA[I read the whole article and found it interesting. I&#039;m bothered only on one point : the lack of real data about the scripting languages speed comparison. I won&#039;t deny that Ruby has made some huge improvements in speed, this is common knowledge.

But I might argue a little about the point made. Even if Ruby acquired a large community over the time, Python still has a much bigger one. Google and other companies are putting a lot of efforts in making it more and more efficient. I believe that it is still on par, if not better than Ruby. And you also forget to mention another scripting language : Javascript. It is common to put it in the &quot;interpreted language&quot; category. It would be very wrong.

You all know that browsers are fighting over Javascript performances. This allowed Javascript to make a huge comeback. And when I say huge, I really mean it. Three years ago, it was even slower than PHP, really it was poor. Now, it is not only byte compiled, it goes even further than that. It is just in time compiled when this makes sense. It uses inferences too. There is a lot of optimizations in Javascript that makes it even able to compete with C in some cases !

It might be a somewhat crude language at first look. If you go deep in Javascript, you might find it is a lot more subtle than you thought. And it is really powerfull. Probably as much as Ruby is, probably even more. And it is definitely more efficient than Python or Ruby for the time being.

So, I might suggest people to think about the huge win it represents for web development. One language for server and client side. When you write your code to check your last form, you can make it so it will validate the form both on the client before sumbitting and on the server side after that. Sure, you&#039;ll need some sort of header function to collect the data that will be different on both sides, but you get my point.

Better, there already are HTTP servers out there that allows you to write your Javascript server and client side code in a single file, allowing you to choose where your code should be processed depending on the function (server-side or clint-side) without even having to worry how the data will be sent from one to another. each of those function call will only be replaced on each side to ensure the data is sent over the network at the appropriate time and processed as it should be. you can do so using, depending on your need, both a synchronized call or asynchronized call allowing you to fine tune your performances on the client side.

Well, I&#039;m not telling you Javascript is ready to become the next answer for everything, but I&#039;m definitely telling that it&#039;s bad to forget it in such an article!]]></description>
		<content:encoded><![CDATA[<p>I read the whole article and found it interesting. I&#8217;m bothered only on one point : the lack of real data about the scripting languages speed comparison. I won&#8217;t deny that Ruby has made some huge improvements in speed, this is common knowledge.</p>
<p>But I might argue a little about the point made. Even if Ruby acquired a large community over the time, Python still has a much bigger one. Google and other companies are putting a lot of efforts in making it more and more efficient. I believe that it is still on par, if not better than Ruby. And you also forget to mention another scripting language : Javascript. It is common to put it in the &#8220;interpreted language&#8221; category. It would be very wrong.</p>
<p>You all know that browsers are fighting over Javascript performances. This allowed Javascript to make a huge comeback. And when I say huge, I really mean it. Three years ago, it was even slower than PHP, really it was poor. Now, it is not only byte compiled, it goes even further than that. It is just in time compiled when this makes sense. It uses inferences too. There is a lot of optimizations in Javascript that makes it even able to compete with C in some cases !</p>
<p>It might be a somewhat crude language at first look. If you go deep in Javascript, you might find it is a lot more subtle than you thought. And it is really powerfull. Probably as much as Ruby is, probably even more. And it is definitely more efficient than Python or Ruby for the time being.</p>
<p>So, I might suggest people to think about the huge win it represents for web development. One language for server and client side. When you write your code to check your last form, you can make it so it will validate the form both on the client before sumbitting and on the server side after that. Sure, you&#8217;ll need some sort of header function to collect the data that will be different on both sides, but you get my point.</p>
<p>Better, there already are HTTP servers out there that allows you to write your Javascript server and client side code in a single file, allowing you to choose where your code should be processed depending on the function (server-side or clint-side) without even having to worry how the data will be sent from one to another. each of those function call will only be replaced on each side to ensure the data is sent over the network at the appropriate time and processed as it should be. you can do so using, depending on your need, both a synchronized call or asynchronized call allowing you to fine tune your performances on the client side.</p>
<p>Well, I&#8217;m not telling you Javascript is ready to become the next answer for everything, but I&#8217;m definitely telling that it&#8217;s bad to forget it in such an article!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why you should probably not bother about Ruby&#8217;s speed by Xavier Noëlle</title>
		<link>http://rtfblog.com/2011/03/21/why-you-should-probably-not-bother-about-ruby-s-speed/#comment-20</link>
		<dc:creator><![CDATA[Xavier Noëlle]]></dc:creator>
		<pubDate>Mon, 27 Jun 2011 14:30:51 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=9#comment-20</guid>
		<description><![CDATA[Glad you like this article, but don&#039;t get me wrong: my point was not to state that C++ was a terrible language (I love C++ :-)), but rather to fight against the conventional wisdom by which using natively compiled language is the only way to get decent performances.

Be sure to read my forthcoming articles about distribution using Ruby, and an easy way to use C++ inside Ruby ;-)]]></description>
		<content:encoded><![CDATA[<p>Glad you like this article, but don&#8217;t get me wrong: my point was not to state that C++ was a terrible language (I love C++ <img src='http://s0.wp.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> ), but rather to fight against the conventional wisdom by which using natively compiled language is the only way to get decent performances.</p>
<p>Be sure to read my forthcoming articles about distribution using Ruby, and an easy way to use C++ inside Ruby <img src='http://s1.wp.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why you should probably not bother about Ruby&#8217;s speed by mart-e</title>
		<link>http://rtfblog.com/2011/03/21/why-you-should-probably-not-bother-about-ruby-s-speed/#comment-13</link>
		<dc:creator><![CDATA[mart-e]]></dc:creator>
		<pubDate>Mon, 06 Jun 2011 17:38:54 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=9#comment-13</guid>
		<description><![CDATA[Interesting (and certainly not wrong) way of seeing things.
I&#039;m learning C++ to improve the speed of my programs but maybe I&#039;ll change my mind and stop using this terrible language (I hate segmentation fault!)]]></description>
		<content:encoded><![CDATA[<p>Interesting (and certainly not wrong) way of seeing things.<br />
I&#8217;m learning C++ to improve the speed of my programs but maybe I&#8217;ll change my mind and stop using this terrible language (I hate segmentation fault!)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why you should probably not bother about Ruby&#8217;s speed by Taking advantage of multicore architectures with Ruby &#171; RTFB.log</title>
		<link>http://rtfblog.com/2011/03/21/why-you-should-probably-not-bother-about-ruby-s-speed/#comment-9</link>
		<dc:creator><![CDATA[Taking advantage of multicore architectures with Ruby &#171; RTFB.log]]></dc:creator>
		<pubDate>Wed, 25 May 2011 19:11:23 +0000</pubDate>
		<guid isPermaLink="false">http://rtfblog.wordpress.com/?p=9#comment-9</guid>
		<description><![CDATA[[...] explained in my previous article about Ruby&#8217;s speed, the 1.8.x and 1.9.x branches of Ruby are coexisting since 2008. One of the most important [...]]]></description>
		<content:encoded><![CDATA[<p>[...] explained in my previous article about Ruby&#8217;s speed, the 1.8.x and 1.9.x branches of Ruby are coexisting since 2008. One of the most important [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

