Fluent Interfaces

I'd like to add to Paul's and Mike's posts regarding fluent interfaces.

I very much agree with them that this kind of method chaining allows to create very readable and intuitive interfaces. The million dollar question is when to actually use this kind of programming style.

Of course there are no definitive answers but I suggest to consider the following points:
a) Use your intuition. If you don't feel this will address the 95% of common use-case for using your interface, then it's probably not the right solution for what you're trying to accomplish.
b) As Paul noted, if in the common use-case you don't have all the necessary data available to complete the task in one go, you should think twice about doing it.
c) Probably the most important point: It really has to read well in your language (e.g. English), preferably as a complete sentence. If you can't read the code out aloud then it's probably not what you want. This is a good example of what I think reads well:

$sms->to("1650939202")
->from("14082924021")
->message("Will meet you at 8pm")
->send();

d) You will usually want some form of error handling for your code. This kind of syntax pretty much forces you to use exception based error handling. Make sure that this suits your needs and application architecture.

Do you have any other suggestions for guidelines? I'd be happy to hear them.

MAC OS X - Update

Quick update for those who were interested in a Windows clone of MAC OS X Expose .
Although I mentioned Winplosion in my previous blog entry, I found there are lots of different solutions out there. I ended up purchasing http://www.entbloess.com which isn't perfect, but it seemed to be the best and most stable of the bunch. It's only $8 so worth buying if you find it usefull.

MAC OS X - Am I ready to make the move?

I've pretty much always been using Windows (on the desktop), and never found a compelling reason to move to another operating system.
That said, over the past few years I have noticed an increasing number of MAC OS X notebooks present at PHP conferences, which intrigued me and has kept me interested in where the MACs are heading.
No doubt that there are some compelling reasons to move to a MAC.
For me as a developer, one of the biggest reasons would be having a UNIX development environment natively side-by-side to the desktop environment. Although VMWare is an amazing tool, and I'm a big fan of it, booting and running it, is not always natural, and half the time I actually prefer to SSH into a remote server on the Internet as opposed to powering up VMWare.
Another compelling reason for the MAC is the slick GUI. I have always been especially jelous of the cool F9 Expose feature. Yeah you could say it's a minor detail, but when you have lots of apps running, alt-tab is a real headache, especially when some of those apps are the same (like many firefox instances). I finally found a cure for that called WinPlosion (http://www.winplosion.com/). Although it's not quite as sexy as the MAC solution, it's pretty cool, very lightweight and slick. If you're a Windows user, give it a try.
So where does that leave me? I guess for me personally, the achilles heel of the MACT is that there's no chance in the world that I'll ever get used to a TouchPad. I just can't deal with it. The Thinkpad TrackPoint (a.k.a nipple) is probably the main reason why I'll continue using Thinkpad's. If/when Apple ever adopts it, then I believe I'll be ready to make the move. And as at that time, MACs will be running on x86, I believe there'll be even more of a reason to make the move.

Zend Framework (post is too long so make sure to grab coffee)

I've been happy to see that there has been so much positive feedback regarding the Zend Framework. I'd like to thank everyone who have shared their thoughts and suggestions with me either via email or blog postings.

I'm aware that things are a bit fuzzy at this point (vapourware?), although Wez's recent blog posting has definitely made things a bit more real for many.

My intention is to share some of the work as early as possible so that people can start to play around with it. Main reason why we're holding back right now, is because at this point I don't believe we have enough implemented to make a good first impression. We have made some good progress when it comes to modules such as implementations for application-level search (ala Lucene), database access (active record), input filtering and logging but we definitely need to remain focused on the development in order to get it together.

As some know, our ultimate goal for the framework is what we call "Extreme Simplicity". Some might have heard me use that term in some of the talks regarding PHP, and I'd like to bring this concept over to the framework. I believe this is what the PHP spirit is all about and the idea behind it is that it's possible to create very simple & easy-to-use languages&frameworks which still remain powerful and flexible, e.g. PHP, SimpleXML or ext/soap. Sure it's tough, because you have to choose the 80% feature set that you want to implement and not the 100%, and giving up functionality isn't always easy, but by creating what I call a use-at-will architecture you can do that but still let people use other mechanism if they need to (for example, power users of PHP write C extensions, e.g. Yahoo!). Another example of use-at-will is DB access. I believe a large amount of framework users would prefer to use PDO or native DB access, and not ActiveRecord. But people who are looking at creating rapid applications and don't need to go down to the native driver level, would have a much easier time. Both would work which I think is also what people expect.

In any case, the progress we've made is still short from being called a framework. We are currently working on some of the key MVC glue which would really define the framework for what it is. We have gotten some great ideas, especially from 100days who are working with us on the framework. The main challenge is to create a model-controller that is both simple to use and powerful. I definitely wouldn't want to go into what I consider a complicated route such as Java struts. Striking the right balance is hard and it often means implementing just the features, which make it "good enough". In fact, that's harder than doing something which does everything.

I know there have been some questions regarding licensing although Wez' blog entries have cleared most of that up. I definitely think that in order for PHP to continue to be a market leader and kick some of our competitor's butts (you know who you are), it is important to offer the capability for companies to build their solutions on top of something they know won't get them into legal trouble. Today, most companies who are actually doing commercial work around PHP, are building everything from scratch exactly for this reason, which at the end of the day is a big waste of good talented cycles. Software vendors (e.g. SugarCRM) have to be careful because they are building their commercial business around their PHP based application. If you don't have a license to the code you're selling, it can get you in a lot of trouble, therefore Sugar had to build everything from scratch.

So by us putting a CLA in place which is almost identical to the Apache CLA and by having a license which is pretty much a replica of the PHP license, we are enabling non-crippling widespread commercial & non-commercial use and allow users to feel very comfortable with the integrity of the code on which they are building their solutions. In regards to Lukas's post, I'd like to point out that by signing a CLA one doesn't assign their IP to another entity, but rather grant a license, and in addition, make a declaration that the contribution is truly yours and not taken from a third-party. So at the end of the day, contributors are still 100% free to do what they want with theirown code, but just giving us permission to use it in the framework.

I've also seen some comments regarding PEAR, and have had discussions with some of the main PEAR guys and contributors over the past week. I'm glad that the folks that I talked to sees things similar to me. There's a good portion of our community, for who the issue of IP is not significant to their day to day business, who are likely to make usage of PEAR components in conjunction with the Zend Framework. And there's no real reason for it not to be so. There are some great packages in PEAR and the Zend Framework is not aiming at being as rich in functionality as PEAR. Rather, we are trying to take what we think is the important foundation for next-gen Web applications and building that in a very straightforward and simple way, making it easy to build powerful apps on top of it.

Anyway, the main focus right now is to get something ready which we can actually show (re: Vaporware). We are working as hard as we can to get something out quickly. Creating a simple and uniform framework is definitely not an easy task, which is why having a small focused group is so important.

I am planning to give a Webcast with php|architect within a bit over a month where we'll talk more about the framework and hopefully also have some stuff to show. If there's enough to show before that, I'll definitely do so.

Back to work. Thanks again for all the feedback and emails. Keep it coming.

Reporting for PHP

Jason Weathersby, BIRT evanglist, just posted a blog entry giving some background for the need of reporting in the PHP world, and briefly mentions our plans for bringing the BIRT reporting system to PHP users.

The BIRT project is being led by Actuate, one of the leading Business Intelligence and Reporting companies, who have openly embraced open-source in the past year, and decided to create an open-source project in their field of endevour. The project includes both a run-time and a WYSIWYG drag&drop environment for easily building reports.

The main reason why I'm so excited about bringing this to PHP, is that like Jason stated, I've seen first hand that the majority of PHP applications have some kind of reporting needs, but a lot of time is spent on building reports and their queries from scratch. A few weeks ago I posted a COM/Excel PHP class on my blog. This class was used in order to create internal reports for our support system. We, like most PHP shops, didn't have a reporting tool at hand so we started with one general report, which became 5, then the reports became more complicated, we needed graphs, we needed more complex queries, and without knowing, we had a dedicated developer on these reports for a couple of months. I believe having reporting tools accessible to the PHP developer, will make a lot of lives easier, and will allow companies not to waste time on reinventing the wheel.

The only problem I see in adoption, assuming the technology is successfully brought to PHP in a simple PHP-spirited way, is in general the low awareness regarding reporting in the PHP space. However, this lack of awareness also exists in other communities, and I believe the availability of tools and best practices would increase awareness.

If you have any thoughts, questions, or feedback please drop me an email.

Ning launched!

I was excited to discover that Ning has finally gone live.
It's a playground for building and hosting social applications, and Ning users are provided access to PHP 5 in order to create their apps.
I think the idea behind Ning is great and hopefully won't we only see a new breed of cool composite apps, but its success would most probably also expose PHP to new communities.

As Ning allows applications to "mutate" by giving users to copy and change other's applications, it will be interesting to see, a few months down the road, what kind of applications emerge.

Zend looking for PHP developers!

We're looking for good PHP developers to work either locally at our Cupertino, California office, or work from remote (preferably from North. America).
If you fit the following profile, please send resume and and code samples to Mike, who's email is mike.n at our domain (spam DBs probably recognize the "at" and "dot" trick :)

Qualified candidates must posess the following:

- Preferrably 2+ years PHP or equivalent experience
- PHP 5 experience
- Database experience
- Strong Object-Oriented Programming skills
- Understands and uses Design Patterns
- Source Code Management (CVS or SVN)
- Team player, goal-oriented, able to work independently.
- Zend Certified Engineer a plus

The following additional experience is also highly desired:

- .NET or J2EE web development experience
- Familiar with Test-Driven Development
- Web Services and SOA experience
- Understands XML, DOM, and other W3C standards
- Front-end experience (XHTML, CSS, Javascript)

Qualified candidates will have a solid work history in web development or related technologies with excellent references.

Automatic Salesforce Excel reports with PHP

Today, I gave a talk at Salesforce.com's dreamforce conference as part of their "Gearing Up: Tools for Your Next Project" developer tools session.

I must admit that I was pleasantly surprised as to how many in the audience were actually using PHP. It must have been about 50% of the audience and this was without PHP being explicitly mentioned on the session agenda.

In my talk I showcased two features of PHP 5, the new SOAP extension and the rewritten COM extension. The example I used is a script that creates an Excel report (with graph), of the geographic distribution of Salesforce leads.

The real interesting part of this example is actually how to create the Excel graphs. Probably one of the easier ways to do that is to use Visual Basic from within Excel. However, as at Zend we want to do everything with PHP, and there are advantages of automating the process from the server, our challenge was how to actually create the Excel files from PHP. We decided to automate Excel using COM and PHP on Windows. The main challenge for us was the lack of good Excel COM documentation. Creating graphs using COM is not a trivial task, especially as a lot of the material isn't well documented by Microsoft. The only somewhat useful reference is the Excel Visual Basic CHM (called VBAXL10.CHM), however, a lot of those features don't map directly into COM, nor are the constant values of the graph types listed in the docs, so you have to do a lot of guess working to actually get it working. We literally had to guess the constant ids for creating the various Excel graphs. After quite a lot of guess work we finally managed to brew up a class which made it easy for us to populate Excel with Data, Worksheets, and create the required graphs. This work is freely available at http://gutmans.org/COM_excel.php. If you use or enhance this code, if possibe, please be sure to share it with me. I'd like to hear from your experiences. Currently, it is very much tailored to what our requirements were.

The second piece of the example is actually getting the data out of Salesforce. Zeev and George have both blogged about accessing Salesforce so I won't add much more. In a nutshell what my code does is query Salesforce for leads, calculate the distribution by country, and display an Excel graph with the resulting information (the results are skewed so that I don't give away real Zend info but it really works...)

I've put up the script which glues the SOAP interoperability and Excel together at http://gutmans.org/SF_COM_example.php. Besides the username, password and exact query itself the script is complete.

I hope this info, especially the Excel class helps people out. Share your experiences!

PHP OCI8 Driver Updated!

Antony just sent an email that he finished commiting the updates to the PHP OCI8 driver and giving a short overview of the bug fixes and improvements.

The OCI8 extension has had a lot of bugs in the past few years, and it became clear that if this extension was to become supportable, it would need a serious face lift and architectural improvement.

I'd like to thank everyone who contributed to the extension. This includes Christopher Jones from Oracle who has been very active over the years on bugs.php.net trying to support the Oracle users; the OCI team including Srinath, Luxi, and Shoaib who helped a lot in understanding how to best use the OCI API, how to optimize the driver, and even learnt to read PHP extensions and provided feedback for the code itself, Wez who played a huge role in rearchitecting the extension, and of course Antony, who did all the hard work of implementing the extension, rewriting the documentation, writing the gazillion new tests cases, and putting up with the constant nitpicking for improvements (and of course, stepping up in the past to become the OCI8 maintainer and help with damage control).

I encourage all Oracle users to test the new extension. In addition to resolving the many bugs, it also has some performance improvements, mainly in defaulting to a 10 row prefetch, and by supporting statement caching. Also, please review the new documentation which has been significantly improved.

If you bump into any problems, please email Antony or open a bug report at http://bugs.php.net.

Enjoy!

Cute PHP/MySQL Comic

Today I was pointed at this humerous PHP/MySQL comic. Although in reality I think PHP tends to enter the organization more bottom-up as a result of its large developer community, I definitely see an increasing trend of managerial awareness, even if some of them just know the buzz words, that's good enough if it furthers PHP.

Translations of PHP 5 Power Programming

Today I received both German and Polish translations of the PHP 5 Power Programming book. I co-wrote this book with Derick Rethans and Stig Bakken. Very exciting to see it being translated, especially as each translation has its own unique look&feel :)

Finally Google released their toolbar for FireFox!

I've been waiting for a long time for the official Google toolbar for Firefox. I always felt that the unofficial Firefox Googlebar was never quite as good as the official Google toolbar for IE. Seems I was right because the official one is definitely slicker and as usual, Google has got it just right! It's a BETA release but quality wise it feels like a release. If you're running FireFox you better get this!

Open source is inevitable

Not sure how many have seen the following Redhat video.
Personally, I'm not a big fan of this kind of FUD, especially if Redhat wants to paint a picture of being the honest alternative to the likes of Microsoft.
I think the open-source world should win on its own merits and not by spreading FUD. That's very much been my philosophy with pitching PHP. If I bash Java here and there, I try and keep it real and give real examples :)

PHP 5.1.0 Beta 1 Released!

Today, we released PHP 5.1 Beta 1.
I'm very excited about this new version as it is yet another important milestone in PHP's rise to market dominance :)
It features PDO, improved performance, PCRE 5.0, SOAP and more...

Personally I believe PDO (thanks Wez) is something I have been expecting for a long time. I think the most important contribution of PDO is to finally provide stable and tested database support across all database servers (due to all drivers being built on top of a common framework), and therefore, strengthening PHP's DB agnostic nature and vendor neutrality. Other exciting new features are performance related, including a new execution architecture for the Zend Engine II, C-level realpath() caching for increased performance in real-world production Web server deployments, and an improved garbage mechanism or more precisely lack of (we managed to nuke that whole mechanism).
Other notable features are PCRE 5.0 support (thanks to Andrei), SPL improvements (thanks Marcus), stream improvements (thanks to Sara), and lots of other fixes and improvements from the likes of Dmitry, Ilia, Jani, Derick, Antony and lots of others.

Although talk of the beta had started several months ago, it was only released now because of constant improvement of the PHP code base. I think when there is so much progress being made on many fronts, it is hard to find the perfect moment for a release. That said, I think the major goal for PHP 5.1 of PDO, improved performance, stability and functionality have definitely been accomplished. Of course, there is still plenty to improve upon, which is always the case. If it weren't then the project would be dead.

Looking into the future, in my opinion, the most exciting upcoming new feature is Unicode support. This has been led by Andrei, and with Dmitry's help, the PHP core and the Zend Engine is already quite Unicode friendly. Once 5.1 goes release candidate, I expect to branch of 5.1.x, shut down the 5.0.x dev branch, and we'll start merging Unicode support into HEAD. This will give an opportunity for the developer community to start making the necessary changes in PHP extensions to play nicely with the Unicode support.
Needless to say, with the direction of sharing data via RSS/ATOM and Web Services & PHP being deployed all across the globe, Unicode is key to continue PHP's current growth.

Enjoy!

Good Web Help for PHP?

I have been searching a lot for a decent help system for PHP applications. The idea is something similar to the Microsoft HTML Help (CHM) or Web help generated by Macromedia Robohelp. I'd be interested to hear more from people about what their thoughts are regarding this topic.

In general, such a system should be a set of XSLT stylesheets to compile DocBook help into HTML and PHP, so it is easily deployable over the web. It should be able to compile any existing DocBook documentation without modifying it (for example the PHP manual).

The following is a detailed list of requirements for such a system:

1. It should be server-based, so it can contain PHP scripts.
This is necessary primarily, to implement fully-functional search capabilities, and in addition, to reduce the number of files generated for keyword index entries (because it'd be possible to generate keyword index as a PHP array rather then generating a separate HTML document for every index keyword)

2. It should look a lot like Microsoft's HTML help, for example MSDN docs.
It should have the same basic layout (text in the right frame; context/index/search/favorites tabs in the left frame). Also it should open in a new window, so the user can browse it independently from the main application.

3. It should be able to group more than one DocBook document, each one containing its own ... tags, into one documentation tree exposing each book as a subroot.

4. It should separate a whole document into a number of pages, analogously to the chunked HTML output of the standard DocBook XSLT stylesheet.

5. It should have five navigation buttons (next page, previous page, forward, back, root). The next/previous buttons should work analogously to chunked HTML created by XSLT of the DocBook XSLT distribution; forward and back buttons should simply implement browser's forward and back functions applied only to the main text frame.

6. The left frame's contents tab should contain a navigation tree like in HTML Help preferably in DHTML.

7. The Index tab of the left frame should consist of two subframes: the first (upper) one containing a list of index keywords, by clicking on a keyword a request would be sent to the server; the server would look up a number of links using a mapping file, probably best implemented as a PHP array, and would display all links in the lower frame. Clicking on these links would open the appropriate page in the main text frame.

8. The search tab should have a search textbox together with standard search options: search whole words/phrase/any word. It also should contain a combobox for selecting a section, when the help consists of more than one DocBook. Search would be done server-side using an index, generated by the transformation (and probably some post-transformation processing).

9. The possiblity to store bookmarks (in a permanent cookie) would be nice.

10. It should be possible to create context-sensitive help by linking to specific places inside the document from the application. For this, the id attribute of DocBook tags should be used.
When the help is then called, it should accept as a parameter suchan id and open at the according place.

11. Also it would be nice to have a back linking mechanism: when the user clicks on a link in the help, a specific page opens in the calling application. This can be implemented for example using JavaScript callbacks with a specific link ID. Probably more of a nice-to-have than a critical features :)

12. Differently from the standard XSLT stylesheet the generated help should heavily use CSS stylesheets. This would allow users to customize the appearance of the help without modifying XSLT styles.

OK that's quite a long and thorough feature request list. I'd be happy to hear feedback from people of what their thoughts are. It probably wouldn't take more than 3 weeks or so for something like this to be implemented.

Finally a Firefox Toolbar for Zend Studio!

At last we have officially published Mozilla and Firefox Toolbar plug-ins for Zend Studio. They are now available directly from the Zend website. The Mozilla/Firefox plugins allow developers to easily debug and profile PHP applications directly from the browser. Users can debug and profile all forms on a Web site or repeatedly debug the same form in real time, in an easy and efficient manner.
In my opinion, the browser plug-ins are one of the cooler Zend Studio features and really allow a developer to be much more productive.

Zend/PHP Conference Speaker Compensation

We've heard that there have been some questions and confusion surrounding the compensation that will be provided to speakers at the Zend/PHP Conference in October. Let me try to set the record straight.

It is our intention to cover the majority of expenses for all session speakers. The compensation will include a full conference pass, one night paid hotel accomodation per session delivered, and a reasonable reimbursement for travel. That reimbursement will clearly be higher for speakers coming from a farther distance (e.g. Europe). We will work out the details for each speaker as their talks are accepted.

The goal here is to enable speakers from all over the world to present at our conference without incurring a large personal financial burden.

I'd like to personally encourage anyone interested in speaking at our conference to submit a session proposal with confidence that we'll be able to cover their expenses.

If you're interested, the Call For Presentations can be found at the conference web site

IBM to join PHP community!

Great news for the PHP community! IBM has decided to embrace PHP and help endorse and promote its use. IBM's endorsement further legitimizes PHP as a prime-time Web application development platform. Not only is IBM planning to make use of PHP technology but also help in furthering it by allocating R&D resources to enhance functionality including Web Services, enabling unified data handling by providing Service Data Objects to PHP, and more. IBM recognizes that being part of the PHP community means giving back in what counts, source code.
In the short term, Zend is helping IBM with providing a supported PHP distribution to their DB2 & Cloudscape installed base, where PHP adoption is still in its infancy.
I wonder how this will effect 2005's TIOBE programming language index. 2004 was a great year for PHP (and down year for Java), where PHP was chosen as the programming language of the year.