Premature Optimization

Ever tried looking up your name in Wikipedia? Check this out.
I knew it - and the title says it all.

YAML has become quite a buzz word in the last few months. For those of you who don’t know yet (perhaps because you read my blog, and only my blog!?), YAML is:

YAML(tm) (rhymes with “camel”) is a straightforward machine parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and Python. YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering.

YAML is becoming popular for a good reason: It’s easy to work with, and lots of fun! If you’ve tried Symfony, you know it heavily uses YAML for it’s configuration files - a task which YAML fits like a charm for.

Being the buzz-word worshipers that we are, several voices have been heard in the the Zend Framework community for a YAML parser class, and most notably, for a Zend_Config implementation based on YAML. Pádraic Brady already proposed an implementation for Zend_Yaml, but for those of you who are impatient (like me!) and want to use YAML as configuration files in your projects today, here’s a simple and elegant solution:
[more...]

In the last few weeks I’ve been thinking about models allot. Models, as in Model-View-Controller modules, are the most abstract and hard to frame-out part of this holy trinity (one might say Models are the “Holy Spirit” of MVC). So what’s the best practice here, if there is even one?

Models represent data and provide the means to preform data-specific actions. In a sense this is exactly what objects are (as in OOP objects) - so one might say that simple container objects are in a sense what the model should be. But in the real world, you almost always need data persistence, which means having some kind of storage mechanism to read from or write to. In the PHP world that’s almost always a database (and almost always MySQL) but it doesn’t have to be: Models could be based on RSS feeds, XML or other serialized data formats, web services, and more. In fact, $_SESSION could (and should?) be a part of your model. So data-layer abstraction could be a nice thing!

It gets even further - think about a model class which uses several data layers, mixing RSS feeds with locally stored meta-data for example; Or a Transaction class, that when saved, will both save local information in the DB and send an API call to PayPal, executing the transaction or fetching information from PayPal’s logs.

Well - getting back to my point, I was thinking about the best way to “frame-out” models and I have to say I didn’t come up with a good, practical solution. One of the conclusions I did made however, is that we are thinking completely wrong when designing our models. We (or at least I) have a tendency to design the model layer by starting from the storage and data access layers (the DB schema usually) and then going to the application layer. If you ever used Propel, it does exactly the same (as all ORM attempts probably do) - you design a database schema, and then build your model classes around it. Then, whenever your application requires some complex relations or data access, it becomes hell and you need to hack things together to make it work (try things like efficient batch updates, or efficient JOINs).

This is obviously wrong. We should be building or at least designing our application first - designing the logic, planning what sort data and what data related actions each action will need to perform, and then design model classes accordingly. These classes in turn will be used to design the data storage layer. The end result will probably be a set of classes for each DB table (or pseudo JOINed tables for that matter) but in run time, will be much more efficient and easy to use.

I am not sure how this can be done and even if this is possible - consider it to be a theoretical idea. But think of the possibilities when you start from the application layer and go down - instead of being limited by your data access layer.

You’re more than welcome to share any thoughts (or objections).

In the last couple of days the PHP world is boiling with excitement, with discussions about namespaces implementation in PHP 6.0. In my non-internals eyes, Dimitry’s proposal looks both simple and elegant.

I have very little to say beyond what was already said by others - but there is one thing I feel needs to be said: A feature like namespaces is important and expected enough, and should be implemented even if it means postponing the release of PHP 6.0. Most PHP users didn’t migrate to PHP 5.x yet - so while they do that, both the planned Unicode support and the emerging namespaces suggestion can be implemented into PHP 6.0 - even if this means the release will be delayed.

In other news, it looks like I’ve just been accepted to speak at the Zend Conference in October 07. Some people might thing this is no big deal if you work for Zend, but looking at the other speakers, and at the number of people who proposed topics, this is quite an honor for me just to be considered.

Right now I plan to deliver two talks: One which I already gave and IPC07, about Zend_Search_Lucene. The second, which will be more manager / team-leader oriented, will be about building scalable development environments - and in scalable the I mean procedure, infrastructure and people wise, and not performance / technology wise. So it’s going to be an interesting talk I hope - and not the regular technical mumbo-jumbo I usually get to talk about.

In any case the conference itself is probably going to be loads of fun and I’m really looking forward to it.

Happy times and great success! 1.0 is finally out, and I’m sure it will (already has?) got quite allot of coverage in the PHP blogsphere - and even got into the main page of Digg - so I’m not going to write about the framework too much - however I do feel a personal retrospection is in place…

I joined the ZF community back in May 2006 (at least this is the earliest SVN commit I could find) - I made some complaints about the HTTP client, and Andi suggested I take charge of it. One thing led to another, and I ended up rewriting the whole Zend_Http classes. Things were not always done the “framework” way (there were no proposals or specs up until later in the development process for example), but I think the result is decent and useful.

There is already lots of talk about the next stages - we’ve been in a feature freeze for quite some time, and I have plans for several requested changes and new components: It seems that in the last couple of weeks the growing interest got people to report bugs and ask for interface changes - ironically at the stage when it was to late to make any changes. So there is already a list of proposed improvements to Zend_Http classes - I plan on doing some work on Zend_Http_Cookie and Zend_Http_CookieJar - and perhaps one day also improve Zend_Http_Client doing things like creating a Zend_Http_Request class that will be inter-operable with Zend_Controller_Request_Http. Also, there is the much needed support for CONNECT requests for HTTPS proxying - and more.

Additionally, I put up (and am still updating) a proposal for Zend_Service_PayPal - a PayPal web services component. Hopefully this proposal will be accepted soon, and the pieces of code I already have can be moved from the laboratory to the incubator, and from there to the main library.

So the future of Zend Framework begins today, and 1.0 is definitely not the end - in fact, I have a feeling this might just be the beginning of, well urm.. a beautiful friendship