Victor Farazdagi

After reading the amazing post by Manuel Lemos Top 10 Wrong Ideas About PHP, I felt I really need to go over those Wrong Ideas once more (just in case somebody missed the original message).

Disclaimer: Manuel Lemos is a well-regarded developer, with lots of contributions, and if you ever used PHPClasses you most probably know who he is. So, I was really prepared to enjoy his new article, provocatively called “Top 10 Wrong Ideas About PHP”. I read the article and then re-read, and then once again – now I am ready to shed some light on my perception of that Top 10.

Take the article below with a lot of humor, as otherwise it loses most of its merits.

If you don’t have much time, here is an abridged version: PHP is a nice language!

1. PHP is not a compiled language (it is interpreted)

• When it comes to speed PHP is reasonably performant, most probably you’ll hit DB bottleneck before you will decide that you need to invent your HipHop.
• So, who the heck worries about such things – I belive, it is quite good enough to know that I do not compile source code before execution, and when it comes to execution PHP does quite well.
• I don’t understand why when talking about PHP, some other languages need to be brought into discussion – I mean languages with completely different philosophy behind them. While it sounds sexy that PHP optcode is very similar to Java’s bytecode, the suggestion that seems to be outcome of such comparison – that PHP as platform is on par with Java – is totally misleading. So, telling that PHP is compiled language just like Java, C# and others (what are they, btw) – is stretching too far.

2. PHP cannot do X (access memory, control hardware devices etc)

• The main idea Manuel is pressing here is the fact that you can write your own extension if you need it. That’s cool but do I have to mention that ability to create extension in C is not actually an exclusive feature of PHP.
• Plus, although definitely improving – decent documentation on how to author PHP extensions is still scarce.
• I love the passage “if you are not capable of developing C or C++ code, you can always hire another developer to do it for you” – I guess yet another exclusive recipe to live happily after in PHP world.
• PHP has crazy amount of ready to use extensions indeed. So, while all arguments about authoring an extension are a bit naive – the truth is you rarely have some area uncovered.

3. PHP cannot do sth that can be done in language X

• There are actually many things that PHP cannot do, which already available in other languages. Anyone who thinks that PHP is feature complete, should code PHP4 till the end of his days. PHP is constantly evolving to include those features – PHP is not an ideal language, so it is improving constantly. I just don’t see why I, as PHP developer, need to be shy that some feature is unsupported yet.
• PHP (to date) has oversimplified object model. Not a different programming style or methodology or anything – it is a mere fact: dominant paradigm in modern PHP development is OO, and currently implemented OO model is very simple. Comparing in this sense PHP to Java, or Python, or Ruby (or even JavaScript) – is missing the whole point. PHP’s simplified object model is actually an asset in most situations, it is simple and (dare I say) elegant. But it has its problems – as any architectural design would have.
• Then as a different solution Manuel declares the ability to execute code in other languages – well, you either didn’t try to use it in production environment or have a very low standards for what is called an integration. Most of extensions to execute other languages are dated, lack documentation and support. So, not an option really.
• I loved the perverted logic of executing Ruby code: convert Ruby into Java using JRuby (hallelujah!!) and then try to execute it from with PHP using some extension. Lots of fun!

4. PHP is only for Web development

• You can have CLI scripts indeed, as you can have in myriads of other languages too. Is PHP very suitable for shell scripting – pretty much so! But I guess anyone who has done shell scripting is smart enough to understand that he can use PHP scripting language, for ..well, shell scripting.
• When somebody starts talking about PHP-GTK seriously it means he didn’t try to do it full scale (hey, anybody did it as a full-time job?). PHP-GTK is a nice experiment – but there are really better tools to do desktop development. You know, if I can hit you with a hammer it doesn’t necessarily mean I should to, so while you can amaze your Java/Ruby/Python/.NET friends that PHP *can* cope with desktop development – do NOT try to actually do it.
• So, you can use PHP for CLI scripting (quite cool by the way!), for desktop development (if you are feeling lonely and masochistic all at the same time), but where PHP really shines is ..um, well..web development. Is it bad? Absolutely not!

5. PHP is controlled by Zend

• If anyone has such a “wrong idea” in his or her head – do not bother, most probably it is terminal
• So, while refuting such a claim is really nice – if we go on like this we should also state that PHP is not controlled by aliens as well (just in case some UFO-frightened prospect PHP developer feels safe about his time investment).

6. PHP documentation is bad or insufficient

• Who ever told this? I look at my local bookstore shelves: lots of PHP books. Amazon? City library? In different human languages? Lots of various level PHP books. Honestly, I won’t be surprised to look into microwave to find out PHP book even there.
• Then of course we have manual, and comments in it. The great thing.
• I guess the whole point of Manuel mentioning a non-existent wrong idea of PHP having not enough documentation is to refute it (done easily).

7. PHP projects are not reusable because they are not Object Oriented

• Leaving apart the fact that in order to re-use code it doesn’t have to be object oriented at all let’s see what bothers that lunatic to-be PHP programmer, who is worried that universe over there will not be able to re-use his projects.
• Tweaking WordPress is not actually re-using, or does Manuel suggests that judging by the quality of WordPress code base you definitely get a perception that it has already been used (and probably not once!), and you just merely re-using?
• When Manuel started to explain that instead of packages/modules/namespaces to distinguish between two otherwise colliding “print” functions all you need is to use “mysql_” prefix I, honestly, scrolled up and looked when article was published: 18 Aug, 2011 – the very day PHP 5.3.7 release was announced (with a notice that PHP 5.2 is not supported anymore, btw). Facepalm!
• If that brilliant prospect PHP user would approach me and say that he can’t rely on PHP because he can’t have two print() functions, well I will enlighten him (by hitting with the printed version of PHP manual – all extensions included) that there are means (in other languages, and the idea has already been ported and widely used), besides prefixing with “mysql_”.

8. PHP is worse than RoR, Django, X language framework

• Again, not sure why Top 10 Wrong Ideas are not called “Top 10 Wrong Ideas Of Mentally Disabled, and Blind, and Ignorant Social Sci. Students Who Failed Their Mid-Terms”? Comparing apples to bananas? For what?
• Why didn’t the lunatic having this wrong idea compare PHP to *the language X* (be it anything). Additionally clarifying the task at hands? In order to have a qualitative claims lots of parameters should be defined, otherwise comparison is pointless: I doubt you will be able to produce, say, RESTrul web-service any quicker in Ruby, or Python than I will be able to do in PHP. But I wouldn’t even think to compete on meta-programming, DSL authoring – because I am at disadvantage there. Why not to jump into another platform if DSL is absolutely necessary for solving problem efficiently?

9. PHP is not good for high performance scalable web sites or applications.

• Yet another weak/artificial claim/idea, just waiting to be refuted. I love to refer anyone who wonders about scalability of a framework, or language to this answer: Languages, libraries and frameworks don’t scale. Architectures do.
• I wish people stop telling that because of Facebook, we are covered as far as PHP scalability is concerned. FB went as far as creating whole HipHop thing (and no it doesn’t prove the opposite either). FB is quite special – I really doubt that many of us will need scalability at the FB’s extent, so decisions (even decision to create compiler) are quite special case too.
• After elaborating in dozens of paragraphs, Manuel concludes: “most of those techniques are not language specific”. So, now I guess we can draw an obvious conclusion ourselves: PHP is better than others yet again!

10. PHP developers are cheaper because they are not qualified

• Why not admit that because PHP is a simple and nice language, there are more people tackling it (to a different level of success), so there are more not-so-qualified developers. When we have high learning curve, we have most of not so fanatic developers sorted out, and this is exactly what happens to starship pilots too (I wanted to be a pilot on a battle starship – but instead slaving in Vim!)
• Whenever someone brings the price tag to discussion, it becomes pointless. The fact is that qualified, PHP or not, developers are not cheap. And there’s nothing in the language that will decrease your rate if you are high profile PHP developer. Period.

Final thoughts:

It is funny that in 2011 (when all decent PHP developers know both weak and strong sides of the language) very prominent community figures (and I am talking about Manuel here) feel the pressure to refute chimeric claims that PHP is any worse/better/suitable than X? Throughout the article, Manuel stresses: PHP is a nice language. Well, it is the fact – you only need to clarify for what problem domain it is nice, whether there are alternatives etc etc

And that applies to any language. So, if you feel guilty of using PHP, don’t. Instead, just go learn some *additional* language – it will enrich your horizons and even make you a better *PHP* programmer!

Take care!

After couple of months of hacking, I finally released Phrozn version 0.2. I had to cut down the feature list as there are quite a lot of things I want to do and not that much time I can dedicate at the moment. Still, I think the release enhances Phrozn project in several ways, so let me tell you what’s new in.. well, new version of Phrozn:

Content Providers

When working on yet another side-project of mine – ZFCasts (podcast show in Russian where me and my friends speculate on Zend Framework) – I was immediately stuck, as there was no way I can inject (programmatically) my own content into the pages. Basically, I had an RSS feed with all the contents of the show, and what I needed was some means to integrate that RSS’s contents into my templates.

That’s when Content Providers were created. If you are used to some other static site generators (in Ruby and Python) you might know those beasts under the “Generators” name. Why on earth I named them “Content Providers” is something I don’t have answer for, so let’s just stick with the term.

Right now you can have better control on the variables used within your templates. Basically, you can inject anything – RSS, hard-coded data, result of the call to some external web-service. Coupled with the fact that you can put your phr up job into cron, you have quite good mechanism of keeping your site updated.

For full info, please, check the official documentation.

Phrozn Bundles

My original aim and one of the top priorities (if not the most important one) is to make contribution not only possible but an easy and fun process. If someone is cool enough to contribute some text processor – that must be possible without diving into the Phrozn internals.

On par with that goal, I introduced so-called bundles. Bundles are basically some directories in standardized format, that you can archive (into .tgz format) and start distributing to other Phrozn users. I wanted as simple and transparent mechanism of 3rd party code contribution as possible.

Therefore, I launched the Phrozn Bundles repository on GitHub, so that you can fork it, write your bundle, and send me a pull request (I will take care of archiving and registering it with core Phrozn program). Once done, any Phrozn user will be able to install your bundle as easy as typing:

        phr bundle apply your-bundle-name

By the way, bundles can be very useful even if you can’t contribute them back – they give you very simple way to transfer styles, themes, plugins between several phr installations.

For more info, please, see

• phr bundle CLI reference
• How to create custom Phrozn bundle

I did number of other changes and bug fixes (changelog), but Bundles and Content Providers are by far the most important additions to the stack.

Finally..

Should you find any issue, please let me know. If you don’t find issue but think Phrozn is useful, let me know too )

One last thing for today’s post. Huge thanks to Phrozn’s early contributors that helped me nailing down the bugs:

• Osman Üngür
• Kazusuke Sasezaki
• Jonathan Van Belle

Thank you guys, and looking forward to seeing even more contributors in upcoming releases!

I am really happy to announce new little project of mine – Phrozn.

For quite some time I have been using static site generators written in Ruby an Python. In many cases, static site is exactly what you want. Consider blogs, manuals/books, info pages.

Given the scale of how client-side technologies (such as JavaScript) evolved, most of dynamic functionality can be implemented using client-side scripts + remote web-services (e.g. Disqus for comments). More than often we a going down that road even on our completely dynamic sites – it makes things more simple.

I am not saying that platforms such as WordPress are going down. I don’t think so. But I think there are many people, just like me, that do not use more than 1% of WordPress functionality, and as such I simply do not need the whole WP for publishing in my blog.

All I need is to write some article in my favorite editor (Vim), run some tool which will wrap entry into layout, add styles and whistles, and publish the entry. Right now, on this very blog, I don’t see any feature I can not have with

        static site generator + JavaScript + some well-known service

And the clear benefit for me is relying on my favorite editor (I HATE text-area editors). Coupled with format independence (I can write my entry in HTML, or Twig, or Textile, or Markdown or any other esoteric beast), I get an ideal solution for my simple needs.

Other thing to consider is resources. Running WordPress is certainly way more resource-expensive (both CPU and RAM) than having static web site. For me this means I can have all my projects on medium server with more simple maintenance and caching strategies.

All this is good, but I couldn’t find any static site generators in PHP. Given the amount of generators in other languages I was surprised. So, I decided to create one myself, that’s how Phrozn project was born

It is in early stages of development, but is already quite usable. Please check out documentation and let me know if you have any questions.

P.S. I will move this blog into Phrozn pretty soon, so that you have yet another example of “phrozn site” (source code of phrozn.info site is available on GitHub).

Today, ZFConf Ukraine was announced on several major platforms (including habrahabr.ru and zendframework.ru).

The conference will take place in Kyiv, on 27 Nov. 2010 and I have a great luck and privilege^* speaking there! Conference language is Russian and in addition to Zend Framework talks, you can also listen to Magento people there!

Attending is simple (remember to register though) and I really hope to see you there: it will be interesting, it is an opportunity to meet real people, and it is free.

My talk is about ZF2 evolution as seen through design patterns application on both existing and upcoming architecture. NB: It is waaaay more funny than it sounds

^* Like in “GRANT SPEAK ON zfconfs.zfconfua”

As anyone doing serious programming using PHP, you certainly know that Sebastian Bergmann released version 3.5 of his exceptional PHPUnit package. He announced the release later on in his blog.

Version 3.5 is actually the version you get when using

pear install phpunit/phpunit

and it means that within short period of time everybody will be running it.

And it so happened that when preparing the new Phing release (2.4.3) we weren’t aware of what was comming with PHPUnit 3.5 – that’s some backward incompatible changes due to package refactoring done on that branch. So, once 3.5 was out we started getting reports that PHPUnitTask for Phing doesn’t work. And it actually didn’t

Since PHPUnit is crucial for PHP development, we had to push one extra release before we proceed with Phing 2.4.3 – so here you are: Phing 2.4.2.1 release with (hopefully) PHPUnit 3.5 support.

In order to upgrade:

pear upgrade phing/phing

Let us know if you happen to spot any issues.

Just throwing message with #phing hashtag on twitter is enough, if you have any further questions you can always contact me or Michiel (or shout something in @PhingOfficial).

Thanks for running your builds on Phing, and stay tuned for new release!

Couple of days ago, Vim team released new version of their great text editor. Once I had a little time, that’s today, I upgraded all my boxes. There couple of new features that are particularly interesting:

Read the rest of this entry

Recently, I become involved in Zend Framework even more – this time not only developing using it (which I am doing for some 3 years now), but actually contributing back whenever I can. And I plan to dedicate even more hrs/week to work on this undoubtedly nice, yet complex piece of software.

So, lyrics aside – today I had to learn new Subversion trick (the hard way), so I am writing it down here, in hope that it saves some other hacker time to play PacMan.

Problem:
I needed to checkout into single working copy all relevant (to me) parts of ZF repository. Not doing separate checkouts for the trunk, then branches, then incubator, but having single checkout of repo which I can keep up to date by simple

svn up

directly from the root of working copy.

Now the problematic part: you never ever want to checkout whole ZF repository – need I mention that it is HUGE? So, what I actually wanted is to checkout the whole repo excluding some paths – such as lots of previous releases in tags/branches folders.

Read the rest of this entry

Usage of Zend_Http_Client is pretty straight-forward:

$client = new Zend_Http_Client($uri);
$client->request(Zend_Http_Client::HEAD); // HTTP HEAD request

However, today, on my Ubuntu box I had real problems as HTTP client constantly ended in segmentation fault (SIGTERM in apache logs). When debugging, I noticed that it does so only if $uri contains so called “unwise” characters, such as spaces, “{“, “}”, “^” etc.

Going deeper, I reviewed the source code of Zend_Http_Client::setUri($uri) method, only to discover that it relies on Zend_Uri::factory($uri), to initialize the URLs. From there it was pretty simple. Zend_Uri is aware of “unwise” chars problem and disallows them by default (why exception thrown by Zend_Uri ended in SIGTERM is yet to discover, however). In order to allow such a characters:

Zend_Uri::setConfig(array('allow_unwise' => true));
$client = new Zend_Http_Client($uri); // $uri may contain unwise chars now

After issuing above instruction Zend_Uri accepts those unwisely formed URIs. Plus, you have to URL-encode white-spaces (i.e. make sure that white-spaces in query string, or actually in URI part after the host name are replaced with “%20″ char) to make them acceptable.

Further info available in offical documentation.

Please note, that I still think that having unreliable chars in URI is really bad practice. If you work with some system that already gone far on this path, it’s nice to have a method to actually consume such a wildly formed URIs. Kudos to Zend_Uri maintainers!

I have used ZF in several projects, and think is is quite safe to use svn:externals to attach Zend and ZendX as external dependency. It might not be the good idea for other projects, but when it comes to ZF – what is in trunk is pretty stable.

So, go into folder which stores ZF, and safely remove the library. Then just add ZF as external dependency (which would be updated every time you update the working copy):

svn pe svn:externals .

in and editor opened, enter the dependencies:

Zend http://framework.zend.com/svn/framework/standard/trunk/library/Zend
ZendX http://framework.zend.com/svn/framework/extras/trunk/library/ZendX

finally commit everything and obtain.

svn ci -m 'ZF set as external dep'
svn up

The beauty of this approach – you always have up to date version of ZF.
The danger of this approach – you always have up to date version of ZF!

Word of caution:
Sometimes this may break things (when backward-compatibility is broken in ZF trunk), but actually if you have unit tests which check your build before deploying, you are pretty safe – you spot the problem, you resolve it.

NB: This approach supposes that you tag your releases, so that when new release is coming out, you create a tag, export everything into newly created tag (thus freezing the code), and checkout from tag on production server.

I have finally completed proposal for Authorize.net CIM API. Hopefully, this API gets included into ZF (in one form or another), as ANet is one of the best services to work with user payment profiles, let alone CC processing. On proposal page you can review use cases, and if you are interested in internals feel free to download fully-working component’s prototype (it is still a prototype as most probably it would be updated in accordance with peer review on ZF wiki).

Let me know your suggestions on how the component can be improved.