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!

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!

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).

First of all, I was able to finish off ticket #618, and integrate tasks contributed by Evan Kaufman (huge thanks and all the credits go to him). He supplied task files, which after number of slight updates, addition of unit tests, and documentation were pushed into trunk.

So, in Phing 2.4.5 we will have GitLog and GitTag tasks, which are quite handy and certainly will enable one to have more flexible build scripts.

GitLogTask is a wrapper around git-log, and here are couple of examples:

<property name="repo.dir" value="./relative/path/to/repo" />
<resolvepath propertyName="repo.dir.resolved" file="${repo.dir}" />

<!-- clone repository -->
<gitclone
    repository="git://github.com/path/to/repo/repo.git"
    targetPath="${repo.dir.resolved}" />

<gitlog
    paths="${repo.dir.resolved}"
    format="oneline"
    maxCount="2"
    stat="true"
    noMerges="false"
    since="Sun Jan 23 23:55:42 2011 +0300"
    until="Mon Jan 24 09:59:33 2011 +0300"
    outputProperty="logs"
    repository="${repo.dir.resolved}" />
<echo>${logs}<echo>
<!-- Dump logs with relative dates -->
<gitlog
    format="medium"
    date="relative"
    repository="${repo.dir.resolved}" />
<!-- Dump logs in custom format -->
<gitlog
    format="The author of %H was %an <%ae>"
    repository="${repo.dir.resolved}" />

GitTagTask is a wrapper around git-tag, and, again, here are couple of examples:

<property name="repo.dir" value="./relative/path/to/repo" />
<resolvepath propertyName="repo.dir.resolved" file="${repo.dir}" />

<!-- clone repository -->
<gitclone
    repository="git://github.com/path/to/repo/repo.git"
    targetPath="${repo.dir.resolved}" />

<!-- Create tags named "ver1.0"  out of current HEAD -->
<gittag repository="${repo.dir.resolved}" name="ver1.0" />

<!-- Force tag (re)creation even if one already exists -->
<gittag
    repository="${repo.dir.resolved}"
    name="ver1.0" force="true"/>

<!-- Create tag name "ver1.0" on a given commit  -->
<gittag repository="${tmp.dir.resolved}"
    name="ver1.0"
    commit="c573116f395d36497a1ac1dba565ecd3d3944277" />

<!-- Or in more general case: create tag name "ver1.0" on a given object -->
<gittag repository="${tmp.dir.resolved}"
    name="ver1.0"
    object="c573116f395d36497a1ac1dba565ecd3d3944277" />

<!-- Create tag with annotation and message -->
<gittag
    repository="${repo.dir.resolved}"
    name="ver1.0"
    annotate="true" message="Version 1.0 tag"/>

<!-- Delete tag -->
<gittag
    repository="${repo.dir.resolved}"
    name="ver1.0" delete="true" />

Another thing I was able to work on, is enabling separate commit creation on fast-forward merging (see fastForwardCommit option in GitMergeTask and –ff/–no-ff in official git-merge docs).

Please note that Michiel smashed lots of other bugs and created several enhancements, so stay tuned for upcoming release of Phing

That’s all for today – have a green build!

Combined with GNU Screen I have a really powerful development platform.

Unfortunately, I had a consistency problem with copy/paste text between different Vim instances (running in different iTerm2 tabs, or in separate GNU Screen windows).

When running CLI locally it is not a big deal as Vim has support for yank/paste to/from system clipboard (via * and + registers). It is not an issue if you work with MacVim either, as it has full integration with system clipboard.

My problem is that most of the time, when developing, I am connecting to different machines via ssh. There are number of solutions: for eg X11 Forwarding, using xclips.

But I wanted a more simple approach that

• will require zero configuration on my part
• will work 100% of time, disregarding from which machine I am connecting, whether I connect as ssh -x host etc

Most obvious solution is to use temp file, where selection is going to be yanked into, and (presumably from another vim instance running on the very same host) is going to be pasted from.

This trick, as many others, has been already discussed on Vim.Wikia.
All I needed to add to my Vim Bundle‘s .vimrc:

"copy the current visual selection to ~/.vbuf
vmap y :w! ~/.vbuf
"copy the current line to the buffer file if no visual selection
nmap y :.w! ~/.vbuf
"paste the contents of the buffer file
nmap p :r ~/.vbuf

Now, when working in different windows of GNU Screen (I have at least two instances of Vim – one with current code, and another with Unit Test suite), to move text between those intances, I just need to

1. visually select code
2. type ,y
3. switch to another GNU Screen window
4. type ,p

This four steps take less than a couple of seconds, mind you

See full release notes and let us know if you spot anything broken!

Happy phinging

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”

It’s been quite a lot of time from the first request by Steven Roussey to actually having GitTasks available in Phing. But finally we have them:

• GitInitTask
• GitGcTask
• GitCheckoutTask
• GitCloneTask
• GitBranchTask
• GitFetchTask
• GitMergeTask
• GitPullTask
• GitPushTask

I already planned enhancements, but these ones should get you up and running!

Although I have created those tasks from scratch, I should mention three persons without whose work this undertaking of mine wouldn’t be that interesting and rewarding: Kousuke Ebihara, Beau Simensen, and Zachary Danger.

Kousuke is the guy behind PEAR’s VersionControl_Git – which made it ridiculously easy to write git manipulating magic. Beau and Zach, beside creating custom git tasks to which I always turned for road-map and inspiration, also constantly pushed me forward, by providing feedback and asking when I will finally make GitTasks available to general public.

Thank you, guys, for your marvelous work!

I really hope that you will find those tasks helpful, and if you spot any issue you will make sure to hit me back, so that I can improve the code.

That’s all – wish you sane an non-broken builds!

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!

a) Persistent undo

Small but nevertheless very useful addition. Basically, your undo lists are dumped into undo files allowing you to undo/redo even if buffer is unloaded (or even if editor closed). Plus now you are able to undo even after buffer reload (this is separate feature actually).

To enable, add to your .vimrc:

set undofile
set undodir=/tmp

That will enable dumping undo lists into undofile, which will be located in /tmp folder.

b) Arbitrary columns

Main use for me is to highlight maximum line length. You could have similar functionality before, but now it is supported out of box:

" make sure that max lines are displayed
" (80 and 120 are from ZF Coding standards)
set colorcolumn=80,120

To update the color of the ruler use hl-ColorColumn. In our custom theme (based on wombat), I set color as:

hi ColorColumn guibg=#2d2d2d

c) Relative line numbers

Well, at first I though this kind of controversial feature, but once I tried to navigate inside document using it – I suppose I like this feature. In any case, not added to my .vimrc by default. I turn it manually:

:set rnu

and to get back to original line numbers:

:set nu

d) Conceal text

Well, this feature is mainly for syntax file writers, as it might make markup text more readable. I, honestly, haven’t enough incentive to dig into it any deeper, as I don’t really see how can I use it in my immediate work (I actually like to see all the markup).

Conclusion

Although 7.3 is a minor release, it is still the result of two-years of work, with a lot of issues fixed and several very cool additions.

Couple of notes on installation

On our 4C’s development server (running CentOS), I was able to compile 7.3 without any issues whatsoever.

While recently switching to Mac, I still program on my old Ubuntu box and updating the Vim installation didn’t work the first time I tried. I noticed that my Ubuntu installation needed xorg-dev and libgtk2.0-dev packages, once installed I was able to compile an complete the Vim’s installation.

Here is little script I use to compile and install Vim on CentOS (used it on Ubuntu as well):

#!/bin/bash
export CONF_OPT_GUI='--enable-gui=gtk2'
export CONF_OPT_PYTHON='--enable-pythoninterp'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='--with-compiledby="yourname@here.com'

make distclean
./configure $CONF_OPT_FEAT $CONF_OPT_MULTIBYTE $CONF_OPT_PYTHON $CONF_OPT_COMPBY $CONF_OPT_GUI
make
make install

Save it into extracted vim73 directory (I prefer to use name “configure-my”), then simply source:

source configure-my

Hope that saves you some time and happy Viming!!