Wednesday, October 26, 2005

Zend, Eclipse and DLTK

Why abandon PHP cause? I am a little bit concerned about Zend future and direction PHP takes from. I would like to see development of PHP itself more vibrant in terms of community support. Quality assurance technologies, new development instrumentation to overcome political PHP problems when new released versions are not compatible with the old ones - when API and quirks notices are growing bigger and bigger without any hope of refactoring. Majority of the tools available from PHP.NET site are outdated and even if considered minimally useful they definitely could be better. If only Zend could support full-time developers to support PHP.NET and community services like IBM does for Eclipse.

Zend is missing opportunities drowned in self-promotions in enterprise market. Should be good for them, but it needs to pay more attention to developers and PHP community. Zend seems to be a bunch of good folks, but also the ones who either very cautious, or do not have trust or resources to invest in communiy projects, or lack some essential management, market analysis skills used to keep in touch with the rest of the world to forecast and interpret the vision of PHP from outside.

Take a look at this initiatives that are quite dead and seem to be promoted only as a plug for community demands.

I could only hope that Zend could crawl out from this crisis and receive good support from developers and financial companies to promote and bring joy of easy and fast application development to many of us. It is hard for a company who survives by selling products which ease the development, but another models of evolution are still possible.

I hope that the example of Eclipse success will make Zend think about elaboration on a global scale to reach common goals. Like support in the following project.

As for PHP freelancer and enthusiast if I'd be asked "Who is Zend?" I would tell "Zend's dead, baby. Zend's dead."

Tuesday, October 18, 2005

PHP PEAR File SearchReplace

If you're not a PHP programmer the following info is a complete waste of time. You've been warned.

To tell the truth I've almost finished writing another "Why I dislike PEAR?" article, but under a fit of creativity I've completely forgot what I want to tell in the first place. So I stripped all spicy stuff and left only fruits.

Let me introduce my tool written by Richard Heyes ( ). Very useful PHP library for filtering files, bunch of .html or sources all at once. It is a low-level analog of numerous "Search and Replace" utilities. Well written articles about how to use it are here:;1186595404;pp;2;fp;2;fpid;76768

The main flaw in this library that it doesn't support Search without Replace. By calling doSearch() you immediately start write modifications. No preview, no read-only grep. This may become quite dangerous and was meant to be changed in version 2 or even in another new package that was proposed , but the proposal has been rejected. That's why I disliked PEAR. There is no way to change API even though this API is a bug in the first place. It was also not possible to release new refactored version with new API without the approval. You have to be nice and polite and even then nobody guarantees that your arguments are acceptable. The method for search without replace could be easily added if not this PEAR bureaucracy and backwards compatibility talks.

Since a lot of time has passed and I still can't release a package, it will be good to say something about planned modifications and let people use proper API to avoid possible conflicts in the future. I am not able to support PEAR packages anymore, because I've switched to SVN and Python (sorry), moreover and I do not know any convenient CVS tools that work through the proxy, but just in case somebody will get the courage to take over development my last advice to those who still use this library.

If you intend to use this package in future - use doReplace() method instead of doSearch(). doReplace() method is not documented, because 1.0.1 doesn't have it, but it more accurately describes what SearchReplace() do. It may happen that in futer doSearch() will be used just for search and statistics collection. Now that you've been warned you may edit your scripts with the goal for better future compatibility in mind (sorry, couldn't resist to include usual marketing crap).