Application specific Zend_Tool providers in Zend Framework

Currently the only way for Zend_Tool to pick up your custom providers is to add the provider directory to the php include path. This is especially problematic if you have multiple applications in one server.

One workaround I use is to create a script wrapping in [APP_ROOT]/script:


ZF_CONFIG_FILE = $(pwd)’/application/configs/zf.ini’




`which zf` $@

If you have integrated the Zend library in your application, you can add the zf scripts in the same folder as the script. The last line then becomes:

$(pwd)/script/ $@

Now you can use script/zfc instead of zf and all of your custom providers should get loaded correctly.

India soon to be the biggest source of PHP developers?

From Manuel Lemos of PHPClasses:

The number of Indian PHP developers has been growing at a large pace in the last few years, when compared to other countries. A few years ago, India was just one of the top ten countries with more PHP developers. Now India is number 2 and is almost surpassing United States, which is still number 1.

While it is difficult to take such broad conclusions seriously based on member statistics of a single community, PHPClasses does have a large user base and can arguably be considered representative. Any article tagged India and software these days attract the usual crap about how Indian developers are the worst and how everybody who outsources to India never does it again. So I was surprised when some of the usually ‘silent’ majority of the client base who continue outsourcing development to India came out to defend their decision.

I did come away with a very interesting statistic; Indian developers have won most awards this year for their contribution against sizable competition. Most Indian developers I meet have difficulty understanding the concept of giving back to the community, so it’s always refreshing to see a number of people doing exactly that.

MySQL sale: Implications for LAMP

Very few would relate the Sun MySQL deal with the recent final release of PHP4. With the ‘M’ of LAMP under the control of a traditional rival and death of the technology that almost single handedly popularized the LAMP stack, what does the future of the PHP and LAMP in general look like?

PHP is different now from the time when I started working with it. It was almost impossible to sell PHP to the so called ‘enterprise’. In sharp contrast, recently I was in a meeting with a major software services company who has big teams for Java and .Net but was desperate for a partner who would help them build PHP capabilities.

Companies like Zend deserve major credit for this shift. Over the last few years they have been trying to be more acceptable to the enterprise market. The results are apparent; Windows/IIS is trying to play nice with PHP, IBM/Oracle has made significant contributions to improve PHP’s integration with their products. No wonder, Zend increasingly looks like another prime candidate for acquisition by one of the big boys.

Perhaps this move was necessary to ensure the long term survival of PHP. The ‘P’ of LAMP no longer means only PHP; it has grown to encompass technologies like Python and Ruby. Frameworks like Rails have a low enough entry barrier for the bulk of PHP developers to consider them as alternatives. PHP benefited a lot from its early adoption by shared hosting providers. Now, hosts offer other technologies as well and VPS hosting has become affordable enough to be an alternative.

What about MySQL and Sun? For MySQL this deal is hard to top, they finally got the global sales, support and delivery potential to compete with the likes of Oracle and SQL Server. For Sun, this is great for multiple reasons. It has been steadily losing new developers and mindshare to LAMP technologies. This acquisition, among other developments allows them to fuzzy the distinction a bit … sounds similar to what Microsoft is trying to do with Linux, isn’t it? It does not hurt that they finally have a strong database offering. I suspect Sun will shortly develop an alternative to InnoDB as well.

Perhaps technologies like JRuby and Groovy point towards the future, where scripting languages and frameworks exist inside the Java ecosystem rather than with an alternative stack. How much these developments would affect an internet increasingly accessed via devices and rich internet applications, remains to be seen.