For those interested in how things work "behind the scenes" at technology conferences and how it looks from an organizer's perspective, Cal Evans has put together a video to share his own experiences.

My good friend Adam (@adamculp) and I spent a few minutes answering questions about how talks are selected in a [Call for Papers]. If you’ve ever wondered, about the process, give it a listen.

The recording was of a live Google Hangouts session they did a while back answering both some of the common questions people have and questions from their viewers. They talk about the Call for Papers process, how they've selected talks in the past and the role that passion plays. There's also discussion about speaker experience, diversity and how to find out the interest level of you topic. There's plenty more mentioned in the video as well, so if you're considering submitting to a technology conference be sure to give it a listen (well, watch...it is a video after all).

Anthony Ferrara has posted the latest in his "Beyond" series today with this new post - "Beyond Clean Code". In it he looks at the idea of "clean code" and proposed a different way to think about its creation.

This is the fourth post in my "Beyond" series. The previous three posts focused on re-imagining OOP and questioning some of the core beliefs that we have come to take for granted. This one is going to be slightly different, in that I want to talk about another angle of writing code: the process itself. We always talk about how code should be clean, but how do you write clean code?

He starts with an overview of what it means for code to be "clean" with some of the common criteria including clear code flow, short routines and using libraries for complex tasks. He proposes that a change in perspective is needed away from "pretty code" and more towards code that contributes to the business value of the product. Following through on this pattern of thought, he proposes a more effective method than focusing on just clean code - DIRTI (Develop, Isolate, Refactor, Test and Integrate).

The real beauty of this approach is that it assumes that you don't know your abstractions before you start. This will help you understand the problem (and the solution) as you write it. [...] Initially, when you don't fully understand the solution, you will develop, isolate and refactor over and over until you fully understand the solution that you're building. Once that understanding solidifies, you're going to tend to spend more time in the later parts (Refactor Test and Integrate).

On SitePoint.com's PHP blog today there's a recent post looking at technical debt - what it is, how to locate it and how to help mitigate (and prevent) it in the future.

On the one hand, technical debt refers to the quick and dirty shortcuts we take and the effect they have on future development. On the other hand, technical debt is also about the things that we don’t do, such as not commenting our code, not developing documentation, not doing proper testing, etc.

They're looking at things from more of a financial standpoint than a development view, but some things are similar between them. Having some technical debt is almost unavoidable, but having a lot is a bad thing. They discuss how it relates to the quality of the product/codebase and three strategies for dealing with debt:

• Don't ignore it
• Triage it correctly and realistically
• Impose a debt ceiling and schedule regular time to work on it

Davey Shafik, a long-time PHP developer and community member/speaker, recently had to learn Ruby on Rails for a project at work. He's shared some of the experience (from the perspective of a PHP developer) in a recent post on the Engine Yard blog.

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.

Paul Jones has a new post today looking at the disconnect in the term "quality" that there seems to be between the ones developing the code and the ones paying for the end result.

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.

Several community members have written up perspectives from their experience at this year's PHP UK Conference - both attendees and speakers alike. Here's just a few of them so far:

• 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!

New on the IBuildings techPortal today is the latest episode of their DPCRadio series - sessions recoded at the Dutch PHP Conference 2010. In this new recording, Thijs Feryn talks about PHP from the perspective of the hosting company rather than the developer.

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.

On his blog today Jani Hartikainen looks at his experience learning Wicket (a Java application framework) from the perspective of a PHP developer.

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".

On the IBuildings blog Cal Evans has taken a look at the Windows caching technology (some recently released) from a management perspective and where it fits in the overall Windows caching toolsets available.

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.

On the Ibuildings blog today Ivo Jansch has posted a look at PHP 5.3 from a slightly different perspective - how development with it affects the management.

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.