I know PHP. I mean, I really know PHP. Not just the syntax, or the idioms and idiosyncrasies, but why. I can tell you why something works the way it does, under the hood; and I was probably around when the decision was made to do it that way. Thirteen years with any language is a long time. [...] Ultimately, it comes down to: Is it the right tool for the task? Because of this, ultimately when I come to write a web site, PHP is my tool of choice. Know thy tool well, and it shall treat you well. Then along came Engine Yard, and I was exposed to just a ton of fantastic engineers who happen to choose Ruby as their tool of choice.

His project was the site for the Distill conference Engine Yard is putting on in August. He lists a few "WTF" moments he came across when learning and creating the site with Ruby including issues with parentheses on metod calls, method naming rules, implicit returns and variations on control structures. He also talks about some of the other technologies used to power the site like OAuth and S3 for image uploads (via paperclip). He finishes out the post by wrapping up the experience and talking some about the benefits of getting outside your comfort zone and learning something wildly new (language or other technology) to give you perspective.

Recently, I was pondering why it is that programmers and employers have different attitudes toward the quality of the projects they collaborate on. The people who do the work are usually the ones who care more about quality. Why? [...] The people who are paying for the work care much less about quality. Why?

He touches on some of the answers to the "why" questions above and points out that it's not so much about the care one has over the other on quality. It's the differing definitions of quality they both have on the parts they work with.

• Andrei Zmievsky
• Stuart Herbert
• Lorenzo Alberton

If you've posted your own thoughts and experiences from this year's PHP UK Conference and it's not on our list, send it over and we'll get it added!

Most PHP talks are given from the point of view of people who work on a project internally. These people are mostly developers, designers, project managers, QA's and there's even an occasional business man who shares his opinion on PHP. I would like to talk about PHP through the eyes of a hoster.

His talk covered some of the things a hosting company has to worry about including support issues and what to do when things go wrong. You can listen to the episode either via the in-page player or by downloading the mp3 directly. The slides are also available.

My starting point with Wicket was basically zero, at least Java-wise: I had never used any Java web app framework, so I didn't really know what to expect. Since as I said I've mostly used PHP and Python, I assumed the program flow would be something like in them. Of course, this was a completely wrong assumption.

He includes one specific example - handling a form submission. In PHP you work with the POSTed values and do something (insert into a database, email, etc) but with Wicket you really just display the form again - with a few other bits of configuration of course. You worry more about what's in the form instead of how to handle the results. He notes that it's a lot like working with a desktop application environment and recommends it as "an interesting way to do things".

As PHP extends its reach further into corporate networks, IT managers have yet another technology that they have to understand so that they can properly deploy. In many situations, PHP code is being developed that - running on its own - creates a bad user experience because of the nature of the language. [...] Much of this delay, and the user unhappiness that always accompanies it, can be mitigated with the proper opcode caching solution. The list in this article was compiled to help managers understand what their options they have. These are the most popular or recent PHP opcode caching solutions.

He lists three of the more popular choices - the Alternative PHP Cachie, Zend Optimizer+ and the WinCache - touching briefly on what each has to offer.

At our Techportal Cal Evans gave an overview of the important changes, to make migration easier for developers. In this post,I'm going to look at the migration from a less technical angle, and explain when migration to PHP 5.3 is a good idea and when not.

He talks about why you should consider the move up to PHP 5.3 and some of the things you should use to handle (and pay attention to) the migration.

I took some time to actually understand the perspective transformations properly using the excellent ImageMagick examples (mainly created by Anthony Thyssen) as a reference. The basic idea of perspective distortion seems simple: to distort the control points to new locations.

His example uses a checkerboard as the image to manipulate and, based on an array of settings (source, destination) sets control points for the image to twist and turn from. The final output is echoed from a call to distortImage.

With other programming languages designed for the web, there's typically a framework that works hand in hand. [...] I imagine people will always write from the ground up with PHP, some people do it to learn, some I suspect think there's nothing out there that can do what they want, where as others perhaps do it just to prove themselves, or to gain fame. Good luck to them all, some of them are probably going to do a good job, but alas - I imagine most are wasting their time.

He breaks his opinions out into two sides of the argument - the business issues and the developer side, each with their own plusses and minuses. Overall, though, he definitely suggests learning some kind of framework, even if you don't end up working with it - it's just good experience.

• Nick Halsead
• Elizabeth Smith
• Matthew Turland
• Ivo Jansch
• Sebastian Bergmann
• Davey Shafik Matthew Weir O'Phinney

Stay tuned to this post for more contributions from the community as they are posted.