Dave Marshall, a developer from Hull, England, has posted a few recommendations he thinks could help you land that next PHP job.

After reading this thread, I thought I'd spend some time writing about what I feel are some measures you can take to landing a job in PHP. This first part is going to concentrate on the kind of technical matters I think any PHP developer should at least have knowledge of, if not some kind of experience.

He suggests: as much programming experience as possible, experience with the full development lifecycle, knowing how to work with external libraries and frameworks, being able to adapt to development tools, knowing web application security, and some work with web services and a touch of system administration. He's not saying that you have to have all of these - just that the more you know, the better off you could be.

If you just can't get enough information on the Zend Framework and are looking for a good overview of where it's come from and where it's going, you should check out the latest issue of php|architect magazine with the cover article from Mike Naberezny.

From his blog:

In the article, I begin by introducing Zend's motivations for creating a framework and how it relates to their PHP Collaboration Project. More information on these topics can be found on the Zend Framework website. I then dive into a tutorial where I take a business scenario and show how the components included in the Zend Framework can be put to work.

The article demonstrates a workflow where invoice data is retrieved from a web service, an invoice in PDF format is then built from that data, and finally the resultant file is emailed to a customer. The components Zend_XmlRpc_Client, Zend_Pdf, Zend_Mail, and Zend_Search_Lucene are explored along the way.

You can purchase both a print and electronic (PDF) copy directly from the php|architect site - no need to subscribe and a single issue only costs $3.50 USD.

In a response to these comments made by Paul Jones concerning the Prado framework, Mike Naberezny shares his thoughts on the framework, the "PHP way", and how the majority of site functionality out there can really be divided up pretty simply.

RADO is getting some new attention because it was completely revamped earlier this month. It's certainly matured considerably since the contest and is the most well-known component framework for PHP. However, in all that time since PRADO was first introduced, the idea of a component framework hasn't been adopted by the majority of PHP developers. Why is that?

Although PRADO is a nice piece of software, Paul surmises that a component model as used by Microsoft .NET (Visual Web Developer now free!) and its close cousin PRADO is not the "PHP way" or "PHP spirit". For the most part, I agree with this. Although, I don't think it's necessarily a PHP-specific issue. I think it speaks to a larger architectural decision - how far to abstract out the HTTP request/response paradigm.

He summarizes the functionality in three different methods of handling: "page/file based", "action based", and "component based". He also notes that the interesting fact is that the "page/file based" method seems to be so dominant in the PHP world, only emphasizing the fact that PHP is more of a "get it done" language than anything.

On the Make Me Pulse blog, there's a look at PHP6's support of Unicode in the SPL (Standard PHP Library) TextIterator handler.

I've just install the last version of PHP6 dev and I've decided to test the famous new feature, the PHP Unicode Support. I will not explain new things about PHP6 or Unicode or TextIterator, it's just my discoveries test on this features.

He steps through the process he followed - enabling Unicode support, testing various output methods (including just an echo and using the TextIterator) as well as some of the manipulation methods (next/first/current) that can be used to get certain characters out of a string.

In his latest blog entry, Mike Naberezny takes a look at the Symfony framework and shares some of his opinions on it.

One thing that I think Symfony gets right is that it appears to use partitioned PHP code for its templates, in the spirit of Paul's Savant system.

I noticed in the Symfony demo that there is no separation of scope between variables passed to the template from the controller and local variables in the template. I'd like to see them scoped properly ("$this->products") but I can certainly understand why they did it this way. Using "$this->" in the template everywhere quickly gets messy.

He mentions a few other items he saw as well, including a way to correct the above mentioned problem (two ways - one more single-instance, the other more global).

On the WebMonkey site today, there's a new tutorial that looks at one of the most "pervasive" sites to come along in a long time, del.icio.us and how to interact with it's API via PHP.

Who's that with the catchy URL that's getting all the clicks?

Why, it's del.icio.us! No matter where you are on the "Web 2.0" lash or backlash, the pervasive influence of this little bookmark aggregator can't be denied.

The site offers a myriad ways of accessing its database, from HTML and RSS feeds, to JSON data, to browser integration of various types. Let's take a look at the public API, which offers flexible and easy access to del.icio.us.

In his example, he creates a script that, given the contents of an email message, filters out the URL, breaks it into its parts and sends it off to the del.icio.us API to be bookmarked under his account.

Mike Naberezny has posted this new item on his blog today with a look at why __get() is a perfectly good alternative to __autoload() in a class structure.

__autoload() is a magic function introduced in PHP 5 that provides a mechanism for on-demand loading of classes. After its inclusion in PHP, many argued that using such a feature is too magical or not a good design practice. Putting the religious debates over the appropriateness of __autoload() aside, its implementation does have one significant drawback: it is a function declared in the global scope. Once a function is declared, it cannot be redeclared. This means __autoload() can't be used effectively in shared libraries, since any other code could have already declared it.

Similar lazy-load functionality can be achieved on the class level by using __get().

He gives a short code example where the __get() call mimics the functionality of __autoload(), but the resulting object created is public, not global...

Skaldrom Sarg pointed us towards a new project he's been working on - an interface for PHP that allows it to use the UWA-Widgets from the NetVibes Universal Widget API system.

The PHP-UWA library allows a facilitated use of UWA-Widgets with PHP. It gives you access to the preferences and some convenience-functions. In theory, it should work with every UWA-compliant widget (even the broken ones which use html in the JS-Parts or the body). Mini-Apis do sometimes work too. An example is included.

You can see an example in this screenshot, try out a demo or just download the library and get testing.

Alex Netkachov has posted some of his own thoughts about Microsoft's recent SQL server 205 driver for PHP:

I can add that a few years ago I had bad experience with MS SQL PHP extension. It was just impossible to use it in production environment. These days MS understand that PHP is a very popular programming language and step forward to the community

He also includes a list of some of the things that the driver includes/makes possible such as the fact that it's not a PDO or OOP driver, that there's no source posted for it and that it does support data streams.

Jeff Moore has posted and shared an interesting graph showing something I'd never thought about comparing one language versus another on - the number of keywords it uses.

Well, I like programming language comparisons, so how could I resist this chart (via) promoting the simplicity of the io language by pointing out how few keywords it has. The interesting thing about this is that Java and PHP are tied on this measure of simplicity with 53 keywords.

Though not too meaningful, it is interesting to see how the different languages stack up in the number of reserved words you can't use for anything else. So, does that mean that Perl is the list limiting?