I just finished part one of a two part series I am writing for PHP Magazine about design patterns. In it, I cover a variety of useful patterns that can make your PHP code more flexible and make you more able to adapt it to real-world changes.
Continue reading →

A recent article asks the same question I have asked on my own blog: “Why PHP?“–but this time, from the angle of an Oracle developer. One of the major conclusions the author makes is that, “it’s not about Oracle programmers choosing a new language; adding PHP is meant to bring more developers to Oracle. Open source developers I would assume. Fair enough.” This begs the question: “Why Oracle?” Not from a developer’s standpoint–but rather, I mean, “Why did Zend partner up with Oracle?”

Continue reading →

I was just talking to Jacques Marneweck and was again reminded of my dormant idea to write a Net_Jabber packge for Pear. With Google Talk basically being Jabber and raising the public interest yet again in instant messaging, it might be useful to make this available in Pear. And with PHP 5.1 you should be able to switch the stream context to TLS on-the-fly to handle Jabber’s TLS authentication (haven’t tested this yet, though…) In PHP4 you could use a digest or some other semi-secure mode to authenticate your “client” with the Jabber server.

I was writing a Jabber alerter for Net_Monitor and thought why not do a full-blown Net_Jabber. But, of course, I have no time. Anyone else thought of taking this on?

Well, it’s offical–my status as a Zend Certified Engineer has been posted to the Zend Yellowpages. Look for my upcoming article in the next issue of PHP Magazine to spell out the gory details of my experience. (Or whet your appetite with some of my musings on this blog–here, here, and here). And, if you’re planning to take the test, be sure to check out my free PHP Function Reference sheet.

One of the somewhat unique features of PHP is that it is not a strongly typed language. This means that in the event of a type mismatch, variables are automatically cast into whatever variable type (integer, string, etc.) the interpreter deems most appropriate for the operation. Which is typically fine and in fact a boon to most beginning programmers, and fine for experienced programmers that understand the rules of engagement. However, as I was explaining a concept in PHP to a beginning programmer earlier today, it dawned on me that the code he was looking for:

[geshi lang=php]if (in_array($user,$users)) {
//…[/geshi]

could be improved in terms of intelligibility by being written as:

[geshi lang=php]if (in_array($user_string,$users_array)) {
//…[/geshi]

That is, by building in the intentions of the author with regard to the variable type in to the variable name, the code becomes more legible, understandable, and ultimately maintainable.

The same could be done for functions, by appending the return type to the end of the name.

[geshi lang=php]function foo_bool($bar_int, $baz_string) {
//…[/geshi]

In this way, all the basic information you need about the function (return type and variable input types) is available right in the function definition. While it certainly wouldn’t do away with the need for a good description (preferably in a PHPDoc DocBlock) it goes a long way toward explaining the code within the code using simple mnemonics.

Anyone else already using this approach?