A shameless bit of self-promotion here: I am pleased to say that my Service Component Architecture for PHP article was published in International PHP Magazine this week. It is more or less the same structure and same material as the presentation I gave at Frankfurt, since I wrote them one after another. It is nice to have the words written down, though. Sadly, I was lazy about submitting a photo, so I appear in the guise of International Man of Mystery:
The same issue has an article by colleagues of mine, Graeme Johnson and Zoe Slattery, in which they describe the outcome of a fairly radical experiment. Poor fools, they set out to make a PHP engine using technology already to hand (bits of the Java Virtual Machine, a bit from IBM Research) but absolutely not using the existing engine itself. And this is the hard bit: they wanted to be able still to host the PHP extensions, unchanged. The difficult thing, if I have understood the article correctly, is that the extensions often have quite deep dependencies on the internals of the engine: they depend heavily on macros which in turn expect to know where to find various fields in various structures. This surely must hold back the evolution of engine and extensions since no one can move without breaking something. In the Java world the equivalent interface (JNI = Java Native Interface) manages to keep all the details hidden behind a few opaque handles. Quite an interesting experiment, and an unusual perspective on the PHP engine, I thought.
Matthew Peters[Read More]
I got back from the Zend Conference a few days ago and thought it worth a mention (the conference, not my returning!). I got to attend quite a few session. Rob Richards gave an excellent XML and Web service tutorial. The Amazon and Google presentations were also very interesting. I particularly enjoyed Adam Trachtenberg's pitch on eBay and how to build a business using their API. The example he used was, "Dude, Where's My Used Car" (http://www.dudewheresmyusedcar.com/), a site that he wrote for fun, which mashes eBay Motor listings and Google maps. I'd like to give this a try with SCA, to see whether, a) it works! and b) whether it's any easier. Look out for http://www.excusemesirbutcouldyoupleasetellmewheremyusedmotorvehicleis.co.uk (the thoroughly British subsidiary ;-) ).
Of the main sessions, I found Chris Anderson's Long Tail pitch very interesting and I'm looking forward to reading his book. As ever, Robert "r0ml" Lefkowitz gave an entertaining and thought provoking pitch comparing the evolution of language and literacy over the centuries to the evolution of programming languages and programming literacy. Using this analogy, it appears programming is currently somewhere around the 10th century and programmers are the equivalent of scribes; being paid to read and write for someone else. Another nugget which I believe was attributed to Donald E Knuth's Literate Programming, was the idea of writing programs for humans (the fact that it runs on a computer is incidental). This is something I think we should all do to ensure what we create can be maintained, embraced and furthered by others.
All in all a very good conference, very well organized. A big pat on the back goes to the Zend folks...Graham Charters
Foremost, we would like to thank the developerWorks editors for giving us the opportunity to christen this blog.
Wed like to begin by saying how excited we are with IBMs announcement of embracing PHP. In a way, this brings closure to our romance with IBM which has its roots in the very birth of PHP, as we know it, about eight years ago. Those who read the fine print at the bottom of the PHP 3.0 CREDITS file
, may remember our joint thanks to Michael Rodeh, who taught our Compilation Techniques course in the Technion, Israel Institute of Technology, and also supervised our university project that was later to become PHP. During this period he played a decisive role in the way PHP history unfolded and today happens to be the Director of the IBM Research Labs in Haifa, Israel. As such, some of the first PHP brainstorming sessions happened within the corridors of IBM and therefore, this turn in events seems very natural.
Needless to say, the announcement doesnt only close a loop to a story that began eight years ago, but opens a brand new and exciting landscape. A company the magnitude of IBM putting its know-how and experience behind PHP is something PHP enthusiasts have been awaiting for a long time. We all followed what happened when IBM embraced Linux. Similar to how Linux was a few years ago, PHP today is a great technology that millions of people already use, and that is growing rapidly. However, it has been lacking the necessary endorsement from a serious industry player such as IBM in order to penetrate the mind share of many corporations and the software industry as a whole. We are confident that just like what happened with Linux, IBMs endorsement will lead to a whole new ballgame for this powerful technology.
In order to fully realize the significance of IBMs involvement in PHP, its important to note that it will not sum up in just a marketing stamp of approval. IBMs support will be backed by contributions of technology, and PHP will benefit from IBMs position in the forefront of the software industry. If previously PHP had to adapt itself to standards written with other languages in mind, the day where standards will evolve around PHP is right around the corner.
At this point you may wonder what exactly this blog will contain. Wonder no further. This shared blog will host thoughts and ideas regarding PHP and Web development at large, coming from people with first hand experience in development and deployment of open source technologies, primarily PHP and Apache. In addition to us, you can expect to read thoughts from evangelists including Sam Ruby, Ken Coar and Mark Pilgrim. In addition, this developerWorks section
will host a variety of white papers and articles dealing with a wide range of PHP-related topics, from technical documents and all the way to roadmap discussions. It should be quite interesting around here!
To conclude our maiden post, wed like to extend a warm gratitude to the PHP community, including (but not limited to) the developers, documenters, bug fixers, quality testers, and anybody else who has contributed to the PHP project throughout the years. Each and every one of you has a share in IBMs announcement. PHP would have never been what it is today without you!Andi Gutmans & Zeev Suraski
As promised in my previous entry (albeit a little late), here are the SDO slides
I used at the PHP Quebec conference
The conference was very well organised and there were a good number of very interesting talks. They don't appear to be available on the conference site, but Chris Shiflett's blog has a list of quite a few that are available elsewhere.
The SDO presentation was well received, with some very good feedback. The demos went well and were free from "gremlins", with a number of people expressing an interest in getting hold of the code. I'll see about adding them as samples to the SDO package.
Graham Charters[Read More]
Some people who attended my SDO for PHP
talk at php|tek in Orlando wanted to be able to try out the demonstration programs. I've recently uploaded them to CVS
. If you'd like to try them out, copy the whole /scenarios directory under your document root, and browse to it. Some of the commentary is bit terse, so do let us know if you can't make them work or find any problems.Incidentally, we've recently published a new article Streamline working with XML in PHP using Service Data Objects
, which uses the same Half-baked Blog
program shown in the demonstrations to illustrate working with SDOs and XML.
People at the talk had some interesting ideas about how they might use SDOs to solve problems - if you did go home and try them out, I'd be pleased to hear how you got on, and any opinions you'd like to share, positive or negative. I had great time at php|tek, especially hearing about so many diverse areas that people are working in - everyone seems to have something special about their requirements or their environment. I also liked watching the alligators in the lake, and taking my morning swim in the open air (not in the lake).
In recent months we've had some requests from developers who would like to contribute to the SDO for PHP project. We recently added a Contributor License Agreement file to the project, so we can now welcome any developer who would like to be involved. There are instructions in the file about where to send it. Our CLA is based on the Apache CLA, and does not ask you assign the rights to your code, or inhibit you from using it for any other purpose. It simply serves to state the the code is yours to give, and that you do not impose any restrictions on its use.
Caroline Maynard[Read More]
We recently shipped version 1.0.3 of SDO for PHP
. This was the first version to ship with the C++ SDO library from the Apache Tuscany
open source project - in this case the Milestone 1 release, which was their first packaged version. Currently it's bundled with the SDO for PHP libraries, but as it becomes more stable, we should be able to use Tuscany as an external library too.
Apache Tuscany has both C++ and Java implementations of the SCA specification, as well as SDO. There's a growing community developing lots of exciting new stuff, who post news to http://apache-tuscany.blogspot.com/.
Caroline Maynard[Read More]
I've had a few requests for the SDO
slides used at the Zend/PHP Conference
. A pdf version of the presentation can be found here
The slides give an overview of the main concepts behind SDOs, followed by a few scenarios showing how to use them to work with relational and XML data. As I mentioned in a previous blog
, the presentation could have done with a few more scenarios to address SDO's strengths and the questions which arose, but unfortunately time was short. I therefore intend to use this blog to cover these over time.
If you have any comments or questions on the SDO project
, please let us know.Graham Charters
The week before last I was in Montreal, Quebec, Canada for PHP Quebec Conference 2005. One of the presentations I gave was about using PHP scripts instead of normally static files like
robots.txt, and it gratifyingly raised a couple of eyebrows.
robots.txt a dynamic file can have a definite impact on performance, but it lets you answer queries a little more specifically. For example, three nasty types of robots are:
- Those which scan without even asking for
- Those which request
robots.txt and either ignore it or use its information to crawl through areas which it explicitly forbids; and
- Those which look at the various clients defined in
robots.txt and then come back disguised as one with more access.
I'm not sure if there actually are any Type III robots out there, but if I can think of it I'm sure some perp somewhere already has as well.
robots.txt is a dynamic file, it can handle Type III malbots by only responding with a single client's permissions those of the client to whose request it's responding. Type I malbots might be caught through the use of spider traps, and Type II can be identified by putting spider traps into a forbidden area and noting that the malbot requested
robots.txt. The fact that it asked for the file and then fell into a trap in a forbidden area is a dead giveaway. :-)
The nasty part of the whole process is reliably identifying the perp. In these days of cable and DSL providers handing out DHCP addresses, labelling a particular IPA as being a perp is only valid until the address is assigned to someone else. And identifying by client identification (the
User-Agent request header field) is unreliable because it's easily spoofed and often good software is used to do bad things.
Of course, sometimes the client ID is a dead giveaway, such as
User-Agent: EmailSiphon, or the IPA might be in a fixed range known to be assigned to people of debatable virtue, but for the most part a lot of eyeballing is going to be necessary to settle on rules. The area is fallow for enhancing the response scripts to understand client/IPA combinations, requests per time t, and other heuristics. And I'm even working on some of those. :-)
At last month's Zend Conference I was fortunate enough to attend Christian Wenz's tutorial on XML and Web services. This covered the use of technologies such as DOM and SimpleXML for working with XML data. As the title of this blog entry suggests, SDO provide a simple way to construct or extend XML documents.
The example below shows an XML schema used by an application which records information regarding quotations people have made (Thanks go to Christian Wenz for the scenario which is from his book entitled, "PHP Phrasebook", SAMS Publishing.). An XML document following this schema will contain a quotes
element containing a number of quote
elements, each of which consists of a phrase
and an author
element and a year
<?xml version="1.0" encoding="UTF-8"?>
<xs:element maxOccurs="unbounded" ref="quote"/>
<xs:attribute name="year" use="required" type="xs:integer"/>
<xs:element name="phrase" type="xs:string"/>
<xs:element name="author" type="xs:string"/>
The code extract below shows how SDO can be used to load the XML schema and a quotes
document and then add a new quote
entry to that document.
1 $xmldas = SDO_DAS_XML::create('./quotes.xsd');
2 $xdoc = $xmldas->loadFromFile('./quotes.xml');
3 $quotes = $xdoc->getRootDataObject();
4 $quote = $quotes->createDataObject('quote');
5 $quote->phrase = $_POST['quote'];
6 $quote->author = $_POST['author'];
7 $quote->year = $_POST['year'];
8 $xmldas->saveDocumentToFile($xdoc, './quotes.xml');
The eight lines of code above do the following:
1. create and configure a new XML Data Access Service (DAS) with an XML schema.
2. use the XML DAS to load and validate an instance document.
3. retrieve the quotes currently contained in the document.
4-7. create a new quote and populate it with information posted from a form.
8. save the quotes (including the new quote) back to the xml file.
The same task takes 14 lines of code in DOM and in my opinion, DOM code is far less intuitive. I found it more difficult to understand the data structure from the code, because of the generic XML vocabulary of the DOM APIs. However, it is worth noting that the XML Data Access Service requires the existence of an XML schema, whereas DOM does not.
Because SDO knows about the XML schema, it lets you access the elements and attributes directly by name. The same is true of SimpleXML, however SDO can also be used to create new documents from scratch, or in this case, new fragments of XML. SimpleXML is limited in this regard because it only has knowledge of an instance document, rather than the schema. Again, it is worth noting that SimpleXML does not require the existence of an XML schema.
The SDO API does not reveal which names correspond to XML elements and which to XML attributes, but still outputs XML which follows the provided XML schema. Personally, I think this is quite neat, because often the choice to use an element or attribute in schema design is arbitrary and down to personal taste. This article
nicely sums up the feelings I had when I created my first ever XML schema.Graham Charters
Next week sees the Zend/PHP Conference and Expo
in San Francisco. It promises to be a great experience, with a goodly number of big industry keynote speakers, lots of hands-on tutorials, and three parallel session streams.
I'm presenting an introduction to Service Data Objects (SDO) on the first day which should give people the basic 101-level understanding of SDO and how to use it with XML and databases. I've included a few scenarios to hopefully keep it *real*. I'm really pleased to have been scheduled first on the parallel sessions, so I can then relax and enjoy the rest of the conference :-) .
I'm really looking forward to finally getting to meet members of the PHP community who've helped us in the creation of the SDO project
. The support and guidance we've received throughout has been fantastic.Graham Charters
Tomorrow I leave for Montreal to attend the PHP Quebec 2006 conference
. It promises to be a really good event, with presentations from many prominent community members, including Rasmus
I myself will be presenting and demonstrating SDO for PHP
, and given I have a 90 minute slot, I thought it might be an opportunity to look into some of the theory. To that end I've been doing a bit of "design pattern archaeology" - hunting for design patterns after the fact. Armed with Martin Fowler's, "Patterns of Enterprise Architecture"
, and with help from other SDO project members, we quickly identified the following four:
- Data Transfer Object: An object that carries data between processes in order to reduce the number of method calls
- Mapper: An object that sets up a communication between two independent objects.
- Unit of Work: Maintains a list of object affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
- Optimistic Offline Lock: Prevent conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction.
There are others, but there's only so far you can take this kind of activity!
The demos I have show how to use SDO to work with relational and XML data. They include a simple Contacts management application, a noddy Blog/RSS feed, and WSDL generation.
If you're not able to make it to Montreal and are interested in SDO, the docs can be found here
, and I'll post the presentation on this blog after the conference.Graham Charters
I presented an introduction to SDO
for PHP at the Zend/PHP Conference and Expo a couple of weeks ago. The session was very well attended and there were some good questions at the end. Overall the presentation went well, but I could have done with more scenarios to address SDO's real strengths and the questions which arose. To continue the discussion and help clarify a few things, I thought I'd blog a little about SDO. So here goes...
One question which came up during the presentation was to do with the Relational Database Access Service and whether it optimizes the SQL queries it creates in order to remove redundancies. The short answer is, "no", but that's simply because it doesn't have to; SDO does the optimization for it.
The first thing to note is that SDOs keep a change summary, however, this summary only holds the information required to re-create the data object's original state, not any intermediate states. This is important when it comes to understanding how the updates are optimized.
Consider an example of a contact database (as described in this article
). The contact database table contains a "shortname" column (e.g. "Fred") and a "fullname" column (e.g. "Frederick Flintstone"). Let's assume we've retrieved a set of contact SDOs from the database into the variable
. We then perform the following four modifications:
// Create and set a new contact.
// The change summary records the fact that the new contact was created.
$new_contact = $result->createDataObject('contact');
$new_contact->shortname = 'Bertie';
// Delete the new contact.
// The change summary entry for the new contact is cleared.
// It's as if 'Bertie' never existed.
// Change the name of the first contact to "Sally Smith".
// Sally was previously called "Sally Barker", so the old
// name is stored in the change summary.
$result->contact->fullname = 'Sally Smith';
// Change the name of the first contact to "Sally Jones".
// The intermediate value of "Sally Smith" is not recorded
// in the change summary.
$result->contact->fullname = 'Sally Jones';
The create and delete cancel each other out and the intermediate value of "Sally Smith" is not recorded, so the resulting change summary would only show that "Sally Barker" had changed her name to "Sally Jones". Consequently, when the Relational Data Access Service is asked to apply the changes back to the database, the only update it would see and perform is the name change.
The resulting SQL UPDATE statement would look like this:
UPDATE contact SET fullname=? WHERE id=? AND fullname=?
with a parameter list of ("Sally Jones", primary key value
, "Sally Barker")
Useful links:SDO for PHP ProjectSDO for PHP documentationRelational Data Access Service documentationGraham Charters
At the suggestion of a friend, I added yet another twist to my watermarking script: rotating the watermark a random amount each time.
While cool in theory, it turns out that the practice is a little more difficult. For one thing, PHP's ImageRotate() function creates a new image resource sized large enough to hold the entire rotated image. Even though I'm using a circular watermark, the image it's in is rectangular. So if you rotate a rectangle and put a bounding box around it, you get a lozenge wider and taller than the original one.
For another thing, getting ImageRotate() to do the Right Thing with the transparency is turning out to be a hassle. I'm working with one of the developers of the PHP image library on figuring that one out; it's unclear whether the issue is my boneheadedness or an actual bug in PHP.
When it's finished, or at least far enough along, I'll post more technical details
A few months ago, I talked to one of the leading CMS industry analysts and he mentioned how surprised he was to find the dominance of PHP in this market.
The available CMSs are anything from open-source freeware to proprietry to supported open-source.
Some familiar names (in no particular order) are Drupal
and of course, the popular PHP-Nuke
If I'd go through the whole list of great CMS systems I know in PHP, this post would start getting boring.
As I am asked very often what CMS I recommend, and with all the excellent packages out there it's hard to do so, I decided to post a link to The CMS Matrix
which is a nice site that provides some initial matrix comparisons between the various CMS. Of course, at the end of the day you'll have to install some of them and actually try them to see if they suit your needs.Andi Gutmans
Different programming languages excel at different things. I employ a number of different programming languages, and make my choice based on the task at hand. My presentations tend to be powered by Perl. My weblog
is powered by Python. But my private applications tend to be written in PHP.
The developerWorks PHP Resources site
will cover PHP from a perspective that may be new to some PHP users, covering such topics as Access an enterprise application from a PHP script
The developerWorks PHP Blog
, however, will often touch on topics that may be new to enterprise (typically Java) programmers.
My first post on this site will cover an application I wrote in about an hour to cover a specific need. It breaks a number of "rules" that guide the development of scalable enterprise applications - in particular it does not separate presentation from content. Consequently, this application does not contain any reusable components that will ultimately find their way into a Customer Relationship Management system. I'm entirely OK with that.
Still, the application is centrally managed, requires zero deployment, is accessible everywhere and portable across a wide range of client operating systems and browsers. All good traits to have.
The application is a vocabulary test. My daughter weekly gets a list of words and their definitions to study. At the end of the week, there is a test where she needs to match the words with the definitions. At first, I helped her study using flash cards, but this seemed like an obvious candidate for automation.
The UI for this application was obvious... I precisely mimicked the layout of the test
The application itself consists of a single source file
and a single data file
Nothing in this application couldn't have been done with JSP. However, to do so would have required additional effort, effort that does not result in a more functional end result.
And it wouldn't have been as much fun.
Not everybody may have the diverse set of skills required to pull together such an application in one sitting. However, a quite larger set of people can copy such an application and successfully make meaningful changes to it.
In my experience, that's how people tend to learn languages such as PHP. Some refer to this as Progressive Disclosure