Home » Programming » Archive by category "PHP" (Page 2)

Choosing Zend Framework was a mistake

About 2,5 years ago at work we were still using PHP for new applications. With PHP being the language of choice I was looking at what MVC frameworks were available. At the time only Zend Framework (which was at version 1.5) seemed to be the only PHP5 framework. Aside from that it was a mature project and being developed by Zend made me decide to use it. I also reviewed the feature set at the time, of course.

Zend Framework has a steep learning curve but in my experience most OOP based MVC frameworks do. If I remember correctly I first used Zend Framework for an admin panel for a website. Aside from the time to learn the framework it sped up development. At the end I had created a nifty little admin panel for managing company profiles. Administrators were able to manage all accounts (information, pictures) and set-up permissions. A company could in turn manage its own details and pictures.

Programming with PHP became a bit more fun again. Zend Framework provided a mostly consistent API and came with pretty good documentation, although some parts lacked and still do at times.

Being convinced by Zend Framework I started working on the rewrite of a big internal application. This application was written in old procedural PHP4 code. That in itself can work, but only if there’s a decent structure. Which is what this application was missing. Basically it was plain old spaghetti code. Views and logic weren’t separated. HTML, styles, Javascript and PHP were tightly intermingled making it a pain to extend and maintain. The database scheme was a nightmare as well, but with it being a rewrite I could nicely convert it to something more sane and get it normalized. I used Perl and DBIx::Class for this by the way. I should have sticked with it…

It took about 4 or 5 months or so to fully rewrite the application. It probably could’ve been done in 3 months but as I said I found the learning curve for Zend Framework steep. I’ve even reported some bugs I found! Anyway, after several meetings with my colleagues we re-factored a lot of the application to get rid of old nasty hacks and incorrect work procedures of the old application. With the application being written in Zend Framework much of this was easy and fast to realize. Now, 2 years later we’ve added a lot more functionality. The application is still easy to maintain and to extend. And more and more plans are in the making for added functionality.

So, why is it that I think choosing Zend Framework was a mistake? Of course, it’s PHP but as I posted in earlier rants is that only recently I got the green light to use Perl instead of PHP. One problem comes from PHP though. With their latest release in the 5.2 series they suddenly announced end-of-life of PHP 5.2. Long before that it was announced that Zend Framework 2.0 would use PHP 5.3 exclusively. I knew that. But with instantly declaring PHP 5.2 dead and deprecated supporting Zend Framework 1.x after releasing 2.0 doesn’t seem to be required anymore… Why? Because after they’ll release Zend Framework 1.11 they stop doing major releases of the 1.x series. Even if I would be able to use PHP 5.3 it would be a lot of work to refactor the code to be compatible with 2.0.

Now this doesn’t directly imply that Zend Framework 1.11 will stop receiving updates in the form of minor releases. But looking at its history I fear the worst. At one point it was said that the current and the last 2 major versions would receive security updates. Out of 2 times this happened once. The second time it was supposed to happen only the current and last version were updated (I believe this was version 1.10 and 1.9. Luckily I already upgraded tot 1.9 when this happened).

Talking about upgrading, moving from Zend Framework 1.5, 1.6, 1.7, 1.8, 1.9 and 1.10 hasn’t always been painless. A couple of times sudden changes to their API have been made. At some times temporary backwards compatibility was provided, but not always. But that I can forgive, that’s why they’re major releases.

So currently I’ll probably be stuck (as in bug fixes and security updates) with Zend Framework 1.11 when it’s out. Zend Framework is a open-source project so I could always fork the project myself and customize it myself for our own purposes. Even so I’m disappointed with the course Zend Framework went (or seems to be going). The biggest problem with Zend Framework I think is that it’s more of a big collection of classes than a solid framework. Don’t mistake me here, most of the components are very solid. But if they would’ve kept the core small (that being the MVC part and related components) and had moved most classes to the ZendX namespace, such as the webservice classes, they could’ve kept the major releases to a minimum.

PHP 5.2.14 released but don’t get excited yet

Yesterday PHP 5.2.14 has been released, together with PHP 5.3.3. I used to get excited about PHP updates, but no more. This is because of a number of disappointments I’ve talked about earlier. But that’s not really the reason of why not to get excited.

So, why shouldn’t we be excited about PHP 5.2.14? The changelog contains a lot of security enhancements and bugfixes. There is nothing wrong with this, quite the opposite. It’s good! But there’s one thing that is completely unacceptable to me and that’s the sudden announcement of the end-of-life for PHP 5.2.

This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.

Yes yes I know, we can all happily migrate to PHP 5.4, what’s the big deal huh? Well, how about announcing the end-of-life of a product in advance? I don’t mind it being killed of but at least let your users know in advance. I remember PHP4 being announced to get killed off, giving users a good year afterwards to prepare for the upgrade whilst receiving (possible) security updates. Yes yes I know, they said security fixes might be published on a case by case basis. Keyword here is might.

Tell me, do bigger companies and/or enterprises etc. take this? From my experience this isn’t very much appreciated. Organizations need time to plan these kind of migrations.

For me this is again a sign of PHP failing.

How a programming language influences your mood

For over 3,5 years now I’ve been programming professionally in PHP. First in PHP4 and about half a year later we finally converted to PHP5. At first I was excited because I could use a lot of new features PHP5 offered such as proper OOP but also Zend Framework.

I started using Zend Framework from 1.5 (currently it’s at 1.10) and have very mixed feelings about it. Yes, it does have a lot of useful libraries such as MVC, basic ACL, Authorization, Input Validation & Filters, Views (with PHP as the templating language, which it essentially was designed for) and more. But ZF had a steep learning curve for me so far has been successfully used in about 5 big webapplications.

However, PHP’s inconsistent function naming, unpredictable order of expected arguments (needle and haystack anyone?), lack of closures/anonymous functions, namespacing, lexical scope and what not makes using PHP a true nightmare. Yes, PHP 5.3 finally supports closures and namespacing, but have you looked at the syntax for both? What a joke. On top of that, PEAR is even a bigger joke. Is someone using it at all?

Running into these issues day by day and knowing it can be easily solved in Perl is very, very depressing. It has totally taken away my desire to program, influencing my desire to program at all and has made my motivation disappear. I’ve truly been wondering if a programming job is really something I want.

The turnaround came when I had a talk with my boss about why we’d still use PHP for future projects. Yes, code reuse is one them but compared to Perl all the additional code I’ve written in PHP that is being reused already exists in Perl at CPAN. To my understanding the use of backslashes to define a namespace in PHP wasn’t really a design choice, but was forced upon because it was too hard to use the double colon or a dot, like many other languages do. On top of that, last time I checked, PHP6 development has been halted because they just can’t get Unicode to work.

Perl already supports Unicode, Perl doesn’t have a weird separation character for namespaces, Perl supports closures/anonymous subroutines, Perl supports lexical scoping, the core list of functions is small, easy to remember and the order of expected parameters is consistent. And it has CPAN.

I was able to convince my boss to start using Perl for future projects because of these given points for both Perl and PHP. What helped though was that he knew of Perl and we’ve also developed some applications in Perl already. One of them a Wx application, a newsletter mailer and some other small scripts. Difference now is that I can use it for webapplications as well.

Now that I’ve gotten the green light to go with Perl for future projects I’m much happier again at work. I’m more motivated to finish the current PHP projects so I can finally start doing some proper Perl work. Programming Perl makes me happy. Moving from PHP to Perl doesn’t mean we’ll be fully dropping PHP. That would be bad and ignorant. Existing stuff will still be supported, improved and extended with new features.

No matter how much you dislike one of the products you support, it’s part of the job. Having stuff you dislike is good actually, because it makes the fun stuff even more fun. For me, PHP makes Perl more fun :-).

Check your XCache settings!

So for a while now all PHP based applications at work were performing quite sloppy. Even though we’re using XCache as the opcode cache there was no difference in performance when XCache was enabled or disabled. Now, for small applications it didn’t really matter, but Zend Framework based applications were really slow. Even when all it did was route to an action and serve a page. Peak memory usage nearly topped 12 megabytes and average response time was between 600 to 950 ms. That’s a lot!

I’m sure it wasn’t the server, which has a quad-core CPU, enough free RAM and a high speed connection to the internet. Average load time is around 0.08 or so. And this is a server hosting several webshops, CRM software and CMS based websites.

Turned out that after I changed xcache.size from 16M to 64M and xcache.count from nothing to 4 (quad-core!) performance increased by almost 50%! A big Zend Framework based application went from 12 megabytes peak memory usage to only about 3.5 (depending on the type of page and actions of course). Response time went down to about 250 to 400 ms. Which is a very big increase. 400 ms Is still too much to my taste, but this is mostly for pages that fetch quite a lot of data, combine multiple views and so on. The smaller stuff (read non-ZF backed apps) how has a response time of about 80 to 180 ms, again depending on the type of page.

So remember, if you use XCache make sure you check your settings!

Update: After running for a day I found out performance degraded again. Once again it appeared that the opcode wasn’t used again. I’ve now set the xcache.ttl and xcache.gc_interval to one hour and 15 minutes respectively. Hoping this will solve the problems.

Update 2: Running multiple websites means caching a lot of files. I’ve now increased the cache size to 192, changed the gc_interval to 5 minutes and the ttl has been changed to 15 minutes. Do check though you’ve got the memory available for the increased cache size.

Change is coming

Which apparently is the slogan for launching Ubuntu 10.04. I think this is going to be a very nice LTS release. It’s too bad that they didn’t include Perl 5.12 in it, but that’s understandable as it just got released; although compiling your own is very easy. On the other hand, PHP 5.3 got in there thanks to the pressure of some fellow Dutchmen. Not that I’m a big fan of PHP, but PHP 5.3 has some nice additions such as closures.