Kevin Schroeder has a nice post about the current state of PHP in the TIOBE index. And i have seen this TIOBE index pop up every now and then in blog posts. It never really interested me. I am not a big fan of trend statistics and certainly don’t care for what is the hottest language of the moment. But reading Kevin’s article got me interested. He mentions the fact that if you do manual searches on different search engine with a query like +”PHP programming” vs +”Python programming” you will get a different view then what the TIOBE index is displaying. And this is true. So let’s give that a try.

+”PHP programming”
Google : 1.460.000
Yahoo : 132,000,000
Bing : 133.000.000
Baidu : 100,000,000

Let’s do the same for Python.

+”Python programming”
Google : 952.000
Yahoo : 22,700,000
Bing : 27.200.000
Baidu : 1,860,000

But this only displays the fact that there is way more content about PHP on the web then there is about Python. It does not reflect the current request and interest in the two subjects. Plus i know some Python programmers. And i also know for a fact that the demand for Python developers has been growing slowly. More conferences are popping up. So the community is live and kicking. So how about the PHP community? There is still a steady flow of fresh content, blog posts, new and old conferences, activity in php.general (dropped a little), new versions are delivered, php.internals is busy as always and the demand for PHP developers is at an all time high. At least here it is. So this community is live and kicking as well.

So this got me reading the TIOBE Programming Community Index Definition to see if i could figure out how they calculate the final result. I am by no means a mathematics person. But the formula seems straight forward. What happens inside the hits() and hits50() function is not clear however. So matching their findings against mine is not really possible.

((hits(PL,SE1)/hits50(SE1) + … + hits(PL,SEn)/hits50(SEn))/n

So how else can we see the current state of PHP then. Let’s try Google trends. That’s what it’s there for.

Compare search requests for “PHP” vs “Python”

Interesting results. This shows that the interest for PHP has been steadily dropping since somewhere around 2004. When people started getting scared of PHP5 i assume. Python on the other hand is nearly visible but steady.

Let’s try a more precise query “PHP programming” vs “Python programming”

That will display something i did not hope for. But something i was expecting non the less. The interest for Python programming has risen over the past years.

One more comparison for the road “PHP developer” vs “Python developer”

Well that’s kind of a relieve. It shows the demand for Python developers is growing. But they have a long way to go to catch up on PHP :)

Conclusion for me is. I still have no clue what the TIOBE index does. Google trend shows a drop in PHP’s popularity and a rise in Pythons Popularity. Personally i don’t see much change in the PHP community compared to resent years. And i have no real opinion of what is going on inside the Python community. But i am happy to stick with PHP anyway.

Last week i toyed with mod_pagespeed a bit. But just couldn’t get the hang of it. So the last two days permitted me to play some more with this great Apache module. Only this time i choose to build from source and ignore the binaries for a while.

For me the main problem was. As soon as i enabled the module. It was active for all sites running on this server. And that should not be a problem. But some of these sites are WordPress monsters. That are ready to take any server down with a bit of high load.

So after a bit of trail and error. I figured out i could just disable mod_pagespeed globally by altering the main config file. After Apache reloaded mod_pagespeed was not active for the running sites.

in /etc/apache2/mods-available/pagespeed.conf make sure ModPagespeed is set to ‘off’

ModPagespeed off

So now i can simply enable settings i need on a per vhost basis. For this site end some other sites i used the following config section in my vhost.

# MOD-pagespeed

SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER
ModPagespeed on

ModPagespeedUrlPrefix “http://lenss.nl”

ModPagespeedFileCachePath “/var/mod_pagespeed/cache/”
ModPagespeedGeneratedFilePrefix “/var/mod_pagespeed/files/”

#ModPagespeedRewriteLevel CoreFilters
ModPagespeedRewriteLevel PassThrough

ModPagespeedEnableFilters add_head
ModPagespeedEnableFilters collapse_whitespace
ModPagespeedEnableFilters elide_attributes
ModPagespeedEnableFilters remove_comments
ModPagespeedEnableFilters rewrite_css
ModPagespeedEnableFilters rewrite_javascript
ModPagespeedEnableFilters move_css_to_head

First of we enable mod_pagespeed of course. And then we set the current domain for this instance. After that we set the file paths for the altered and cached files. And we use ‘PassThrough’ instead of ‘CoreFilters’. So we can decide our self’s what filters we will be using.

This had a much better result then my previous attempts. The server was still happily serving pages. And the load was OK. So let’s check the sites if mod_pagespeed is actually running.

$ wget -O /dev/null –server-response http://lenss.nl 2>&1| grep -i ‘X-Mod-Pagespeed’
X-Mod-Pagespeed: 0.9.0.0-172

Well that looks good. So now it’s time to do some testing. And this leaves me with a bit of a pickle. As i don’t have the required wget v 1.12 (i have a small patch for wget v1.11). Besides that i have some other problems running the tests

TEST: 404s are served and properly recorded.
wget -O /dev/null http://lenss.nl/mod_pagespeed/ic.a.bad.css 2>&1| grep -q ’404 Not Found’
wget -q -O – –save-headers http://localhost:80/mod_pagespeed_statistics | grep -q ‘resource_404_count: 1′
FAIL.

This fails because the statistics page requested is not available because this site uses rewrites. And i haven’t found a way to go around this yet besides disabling them in .htaccess with mod_rewrite. So shortly disabling this made it possible to run the biggest part of the test suite without problems.

resource_fetches: 2
total_page_load_ms: 0
page_load_count: 0
cache_extensions: 0
not_cacheable: 0
css_file_count_reduction: 0
css_filter_files_minified: 13
css_filter_minified_bytes_saved: 5082
css_filter_parse_failures: 0
css_elements: 0
image_inline: 0
image_rewrite_saved_bytes: 0
image_rewrites: 0
javascript_blocks_minified: 15
javascript_bytes_saved: 380
javascript_minification_failures: 0
javascript_total_blocks: 15
resource_url_domain_rejections: 0
url_trims: 0
url_trim_saved_bytes: 0
resource_404_count: 2
slurp_404_count: 0
serf_fetch_request_count: 0
serf_fetch_bytes_count: 0
serf_fetch_time_duration_ms: 0
serf_fetch_cancel_count: 0

It fails on the image compression part and that’s fine. Because i will leave that for later. So let’s run the site through the pagespeed browser extension with mod_pagespeed disabled:

load time without : 2.193
firebug/pagespeed score : 68

Now the same thing but with mod_pagespeed enabled:

Load time with : 1.284
firebug/pagespeed score : 90

That looks pretty good. And the other sites i have tested preform way better with the mod_pagespeed module enabled.

I still have some Javascript issues. Some things need further inspection because i have seen error like these coming along:

Permission denied for to call method Location.toString on .

Besides that. This morning my site was down due to Apache spitting segfaults. I disabled the ‘rewrite_javascript’ filter for now. And it seems to run a bit more stable.

[Thu Nov 11 07:38:24 2010] [notice] child pid 23608 exit signal Segmentation fault (11)

So besides it being a beta i am pretty impressed by the current state of this module. And after running it for a couple of weeks the statistics are pretty impressive.

Manuel Lemos also wrote a nice article about mod_pagespeed which is worth reading.