Comments for RTFB.log // Read The F/*IXME*/ Blog! Tue, 22 Jul 2014 19:59:41 +0000 hourly 1 Comment on Improve your Internet upload bandwidth management by configuring your Linux router by Simone // Tue, 22 Jul 2014 19:59:41 +0000 Great guide!!! I’ve found I can use tc by telnet on my modem router :)

Comment on Fix Gallery3 to extract IPTC headlines and captions by Albin Kauffmann // Thu, 01 Nov 2012 15:31:58 +0000 Oh, and note that the patch style works with the last version of gallery (3.0.4).

Comment on Fix Gallery3 to extract IPTC headlines and captions by Albin Kauffmann // Thu, 01 Nov 2012 15:29:47 +0000 Hey!
I’m still far from being an expert with Gallery, but I think you should be able to extract your IPTC contacts but using the same principle. Just set the correction filed in the structure pointed to by $item.

This patch is applied with the following command :
$ cd /path/to/your/gallery3
$ patch -p1 < /path/to/gallery-3.0.2-exif.patch

I hope this helps :)

Comment on Fix Gallery3 to extract IPTC headlines and captions by Peter // Thu, 25 Oct 2012 17:14:59 +0000 I am sure this is exactly what I need. My IPTC fields are jumbled (thanks to iView Media Pro!) and need to extract IPTC Contact so its also searchable from inside G3 along with IPTC Keyword.

Does this code (with the obvious edit to address Contact field) make this happen?
If so, how to install the .patch? (Sorry – I am new!)

Any other help you can suggest for a fairly new user?

Thanks anyway for proving that I am not the only one with such a challenge!

Comment on An introduction to search-based applications by An overview of the Business Intelligence world « RTFB.log // Tue, 07 Feb 2012 09:33:35 +0000 [...] is stored as unstructured data, like e-mails, and it is very difficult to analyze it. This is what SBA are trying to deal [...]

Comment on Why you should probably not bother about Ruby’s speed by Quentin Raynaud // Fri, 09 Sep 2011 15:35:51 +0000 I read the whole article and found it interesting. I’m bothered only on one point : the lack of real data about the scripting languages speed comparison. I won’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 “interpreted language” 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’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’m not telling you Javascript is ready to become the next answer for everything, but I’m definitely telling that it’s bad to forget it in such an article!

Comment on Why you should probably not bother about Ruby’s speed by Xavier Noëlle // Mon, 27 Jun 2011 14:30:51 +0000 Glad you like this article, but don’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 ;-)

Comment on Why you should probably not bother about Ruby’s speed by mart-e // Mon, 06 Jun 2011 17:38:54 +0000 Interesting (and certainly not wrong) way of seeing things.
I’m learning C++ to improve the speed of my programs but maybe I’ll change my mind and stop using this terrible language (I hate segmentation fault!)

Comment on Why you should probably not bother about Ruby’s speed by Taking advantage of multicore architectures with Ruby « RTFB.log // Wed, 25 May 2011 19:11:23 +0000 [...] explained in my previous article about Ruby’s speed, the 1.8.x and 1.9.x branches of Ruby are coexisting since 2008. One of the most important [...]