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.
Chris Hartjes has a new post to his blog today focusing on using a bit of the CakePHP framework's functionality from the command line.
I'm porting a spaghetti-PHP application over to using CakePHP I am moving their existing authorization system over to using Cake's Auth component. Of course, they are storing all their passwords in plaintext in the user account table, so I needed an easy way to convert all the existing passwords over to be encrypted using the same hash that Auth would use.
With the help of the shells and tasks that the framework makes availiable, he's able to make a simple 24 line class (EncryptPasswordShell) that extends the Shell object and loops through the data to push it back into the database in the correct password format.
Akash Mehta shares a helpful hint in this new post to the Developer Tutorials Blog today - testing out PHP code via the command line PHP binary.
Thankfully, PHP provides the interactive shell, allowing you to test out PHP interactively with immediate feedback. Here's how to take advantage of this mature feature of PHP.
With the help of the "-a" flag on the command line, the PHP binary will hand you an environment where you can code PHP and instantly see the results. He does mention a few quirks that make it different than working with PHP through a web server, namely moving in and out of code blocks and remembering to finish out with a semi-colon when the line is done.
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.
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.
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.
Stefan Koopmanschap has pointed out an interesting article over on the CIO magazine website that has some in the PHP community a bit up in arms about comments it makes towards the language.
The article, "You Used PHP to Write WHAT?!", covers the basics of the language - its status in the web programming world, the functionality it offers and the database interfaces it includes. They also include a hit list of reasons PHP is popular and why it's a good choice for your project.
Then things get a little strange - they move from their PHP praise to three things that have more to do with unresearched "facts" than the reality of the language:
Security and PHP
Working with PHP and the shell
Scaling and PHP (in enterprise environments)
These incorrect assumptions have lead to many comments both from the PHP community and from users of other languages (like Java and ColdFusion) sharing thoughts on the contents of the article and the language in general. Check out the article's comments to see for yourself.
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...
