July 17th, 2010 by Jérôme
1 comment »
Dear Mr Arrington,
I just read the following blog post on Techcrunch : Breaking: French Government Still Can’t Get France.fr live
Even though you have a point about france.fr being down for days right after its launch, you did not need a blog post on Techcrunch for that, there is a simple word to explain this failure : incompetence.
What is absolutely pointless in your article is this :
If the country’s experience with building aircraft carriers
is any indication of their ability to build websites, we should see it limping along sometime in 2013.
Let’s skip the aircraft carriers thingy because it is absolutely out of topic here.
French people not able to do websites ? Do people behind Dailymotion, Netvibes, Skyblog, Seesmic, Deezer come from Mars ? You can love or hate the service but you can not say that french people can not make websites.
By the way, showing the list of wars France lost is also useless, unless you want to talk about Vietnam and Irak 
If ever someone read this blog post and uses the WW2 argument, I would recommend this person to read a history book first so he can understand why the USA entered into the conflict. Reading a bit on Lafayette is recommended as well.
So please Mr Arrington, do what you do well i.e publishing news about tech and the Internet in general and stop the rest.
Best Regards,
PS : if ever this website goes down after a while due to the incoming traffic this is because it is hosted on a cheap shored host I do not quite care about not because it is French.
July 15th, 2010 by Jérôme
4 comments »
If you use collectd and would like to monitor your Varnish instance(s), this blog post is for you. The new Varnish plugin for collectd is ready, however we would love to get feedback from you. The plugin has already been pushed on production on Camp To Camp and the feedback is really positive so far. However it is always good to get more feedback from different people using collectd and Varnish in different contexts.
How can you help ? Simply run the Varnish plugin on one of your production (or test) server(s) and provide feedback, and ideally some graphs 
Installing the Varnish plugin for Collectd is really trivial :
1. run git clone http://github.com/octo/collectd.git
2. compile collectd as you would normally do, do not forget the –enable-varnish flag
3. configure the Varnish plugin in collectd.conf, as explained in the configuration synopsis
4. start collectd
For more information, feel free to read and/or comment the dedicated wiki page .
Feedback can be provided as you wish, either by sending an email to the mailing-list or directly to me <jerome.renard @ gmail.com>
Thanks in advance for your feedback.
June 29th, 2010 by Jérôme
1 comment »
After I easily switched from Mercurial to Git, I needed to update the committer’s name and email adress. I found that using git filter-branch could help me.
Here is what I did :
git filter-branch --env-filter \
'export GIT_AUTHOR_NAME="Foo" ; GIT_AUTHOR_EMAIL="foo.bar@example.com"'
And git updated the author’s name and author’s email for every commit.
‘Hope that helps
June 29th, 2010 by Jérôme
2 comments »
For a project I am currently working I needed to switch from Mercurial to Git.
I used the method described below, that is really trivial and it works just fine.
Download fast-export and extract it wherever you want.
Run the following commands :
mkdir git.migration && cd !$ && git init
/path/to/fast-export/hg-fast-export.sh -r /path/to/your/mercurial/repository
And wait for a few minutes/seconds, depending on the size of your repository. In the end of the process you should get a result like :
git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 10000
Total objects: 5426 ( 566 duplicates )
blobs : 1990 ( 453 duplicates 1454 deltas)
trees : 3027 ( 113 duplicates 1762 deltas)
commits: 409 ( 0 duplicates 0 deltas)
tags : 0 ( 0 duplicates 0 deltas)
Total branches: 1 ( 1 loads )
marks: 1024 ( 409 unique )
atoms: 1030
Memory total: 2540 KiB
pools: 2149 KiB
objects: 390 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 33554432
pack_report: core.packedGitLimit = 268435456
pack_report: pack_used_ctr = 1
pack_report: pack_mmap_calls = 1
pack_report: pack_open_windows = 1 / 1
pack_report: pack_mapped = 7542871 / 7542871
---------------------------------------------------------------------
Now run :
git checkout
Done.
‘Hope that helps
June 14th, 2010 by Jérôme
No comments »
What is pv ?
It is a tool that monitors the progress of data through a pipe.
How to install it ?
Well, that is quite simple, the package name is the same for all platforms : pv so you can use
sudo port|yum|apt-get install pv
How to use it ?
Let’s take an example, you want to compress a big text file, you would normally run something like gzip <filename> and wait for the process to be finished without knowing exactly when.
With pv you can know exactly what the status of the process is and when it is finished.
Let’s reuse the gzip example above and try the following (I tried on a 1.6GB text file) :
17:08 jerome@gimli/private/tmp% gzip dummy.txt
#and just wait for gzip to finish
Now let’s try with pv:
17:10 jerome@gimli/private/tmp% pv dummy.txt | gzip > dummy.txt.gz
1.16GB 0:00:14 [81.9MB/s] [==============[...]===================>] 100%
Let’s extract the file by using pv as well :
17:11 jerome@gimli/private/tmp% pv dummy.txt.gz | gunzip > dummy.txt.gunzip
3.45MB 0:00:22 [ 158kB/s] [==============[...]===================>] 100%
Cool isn’t it ?
Now we know exactly when the process is finished, this is really useful.
For more information about pv, you can read the manual page
‘Hope that helps
June 9th, 2010 by Jérôme
1 comment »
If you want to build PHP from the SVN repository, you have to run buildconf [--force].
But depending on the version of autoconf you have on your machine you can get the very annoying warning message :
[...]
buildconf: Your version of autoconf likely contains buggy cache code.
Running vcsclean for you.
To avoid this, install autoconf-2.13.
[...]
If you do not have autoconf 2.13 installed, then you have to install it first.
On RedHat running sudo yum install autoconf213 should work. On Debian, the autoconf2.13 package is available.
Once autoconf2.13 install, you can instruct buildconf to use this new version of autoconf by runing :
export PHP_AUTOCONF=`which autoconf-2.13`
You can check the value is correct by running :
echo $PHP_AUTOCONF
Which should give you something like (depending on your system)
/usr/bin/autoconf-2.13
Now retry to run ./buildconf –force. The annoying message is gone, joy
‘Hope that helps.
May 27th, 2010 by Jérôme
2 comments »
I was searching something in the Varnish source code when I found a non documented (at least there is nothing in man varnishstat, for Varnish 2.1.2) feature.
Varnishstat can return statistics in XML. How to get this format ? That’s pretty simple, just add the -x argument to varnishstat, for example using :
varnishstat -x
will return something like :
<?xml version="1.0"?>
<varnishstat timestamp="2010-05-27T17:03:26">
<stat>
<name>client_conn</name>
<value>33036</value>
<description>Client connections accepted</description>
</stat>
<stat>
<name>client_drop</name>
<value>0</value>
<description>Connection dropped, no sess/wrk</description>
</stat>
<stat>
<name>client_req</name>
<value>34740</value>
<description>Client requests received</description>
</stat>
<stat>
<name>cache_hit</name>
<value>33580</value>
<description>Cache hits</description>
</stat>
[....]
</varnishstat>
So now, if you only want to get cache hits and cache_misses in XML so you can parse them easily on you can do :
varnishstat -f cache_hit,cache_miss -x
And you get something like
<?xml version="1.0"?>
<varnishstat timestamp="2010-05-27T17:05:41">
<stat>
<name>cache_hit</name>
<value>33580</value>
<description>Cache hits</description>
</stat>
<stat>
<name>cache_miss</name>
<value>1160</value>
<description>Cache misses</description>
</stat>
</varnishstat>
If you want to know more about that, have a look at the do_xml function in varnishstat.c
‘Hope that helps
April 26th, 2010 by Jérôme
4 comments »
I just released ezenhanceddebug 1.2, here are the new things I added :
Compatible with eZ Publish 4.3
If you read the changelog in the eZ Publish 4.3 release, you will notice :
- Implemented enhancement #16216: Deprecate templateInit()
Which is documented by
- kernel/common/template.php: templateInit()
Function will be removed in a future version, use eZTemplate::factory() instead.
This change has been implemented.
KCacheGrind support
There is two new configuration directives in ezenhanceddebug.ini.append.php :
[ProfilerSettings]
Profiler=enabled
ProfilerOutputDir=/tmp/ezenhanceddebug
If [ProfilerSettings]/Profiler is set to enabled, then anytime you generate a page you will get a KCacheGrind compatible file in [ProfilerSettings]/ProfilerOutputDir/url_alias_of_the_page.out
Here is how it looks like :
Each function follows the pattern : <template_name>::<template_function_or_operator>
There is no callgraph available, this is currently not implemented. Due to the anarchic way of calling templates from eZTemplate, it is very difficult to deduct a valid callgraph, maybe I will add this in the future if I find exactly what I am looking for in the template engine.
The full eZEnhancedDebug extension is now hosted at GitHub .
April 12th, 2010 by Jérôme
2 comments »
I wanted to share a bit of informations about the tools I use every day and which I could not work well without. Let’s go.
Vim:
I spend most of my time editing text (writing code, sending emails etc, etc) so having an efficient text editor is really important, I started to work with vim a few years ago and feel really cumfortable with it, furthermore I can learn one new feature / keyboard shortcut every day to make my life even easier.
Hudson:
Every time I start working on something new I define a new job in hudson so all my projects are build and unit tested automatically on a regular basis. Coupling hudson and Ant is a piece of cake. I appreciate the feeling of being backed up by a tool that will ring the alarm bell when something is wrong (of course it can do much more ).
OpenGrok:
I discovered that only a few weeks ago and can not live without since then, this “wicked fast” source code browser is awesome. Basically you take Lucene + Excuberant Ctags + a fair amounf of java code and then you have it. Installing it on OpenSolaris is a piece of cake and takes around 5 minutes to get a working instance If you plan to use it on Mac Os X, get ready to fight a bit, first for installing Tomcat and then you’ll have to patch OpenGrok in order to make it work, but after that, it works just fine. I really appreciate the way of browsing different code repositories using different SCM and different programming languages (like shown below) and to be able to search into one of them easily. Even if you are a grep wizard or an ack addict, using OpenGrok is really an interesting complement.
And you, what are the tools you can not work without ?
March 25th, 2010 by Jérôme
3 comments »
I needed a way to unit test some code that sends HTTP headers via the header function.
However when doing this from the command line :
php -r "header('Foo : Bar'); print_r(headers_list());"
The only result you get is an empty array, which makes sense of course but for unit testing from the command line that is annoying.
XDebug saves the day again by providing the xdebug_get_headers function.
Let’s try the same code, but with XDebug this time :
php -r "header('Foo:Bar'); print_r(xdebug_get_headers());"
Returns
Array
(
[0] => Foo:Bar
)
Joy
