The latest episode of the "/dev/hell" podcast has been released - Episode 4: "The Cool Kids Club".

Our fourth episode is all ready for your listening pleasure. In this exciting episode we focus on "The Conference Experience" and discuss why programming conferences are so important to developers. Chris talks about why CodeMash was so awesome and the awesome talks full of awesomeness that he attended. Ed talks about his own experiences with speaking and attending conferences, complete with a total derail by Chris on why a certain conference rubbed him the wrong way. Oh yeah, you also find out our opinions on what constitutes a "well-written PHP application". I'm sure you will be surprised by our answers.

You can either listen to this latest episode either via the in-page player or you can download the mp3 directly.

In a new post to his blog, Joshua Thijssen documents some of his first steps into the world of the Symfony2 framework (as a developer who has lived mostly in a Zend Framework/CodeIgniter world). His post doesn't compare the frameworks, it's just his discovery along the way.

A friend of mine who is a big supporter of Symfony told me to give Symfony1 a shot. Off course I was skeptical since I knew less about symfony1 than I did on Zend_Tool. That, plus the fact we needed to autoload, bootstrap and get two frameworks up and running simultaneously. What could possibly go wrong! Conclusion: I've got my tool up and running about a 45 minutes later...

He talks about the process he went through to download, setup and configure the framework and start using a "task" to create a simple executable script. He also briefly compares Symfony1 to Symfony2, noting that SF2 is a bit more "out-out-of-the-box friendly" than SF1. The overall experience was a positive one, though. You can find out more about Symfony1 here and Symfony2 here.

On the CohereCommunity.com blog has a (slightly older, but still good) post about communities and the "when" and "where" of them happening.

I'm talking about people trends and community and HOW. WE. CONNECT. I decided to start old school stylie, and looked up the word 'community' in the dictionary. [...] So community literally means to give gifts to and among each other. Which in turn means my community is a group of people who welcome and honor my gifts, and from whom I can reasonably expect to receive gifts in return.

They go on to talk about the three key elements any good community relies on - the people that make it up, the places they meet (real or virtual) and the "things" that bring them together.

If I could make a single plea to every researcher, academic, economist and reporter it would be to stop counting us and start communicating with us. Learn more about where, why, and how our communities form, and why they're so important to us (even when they don't make us any money).

If you're not already involved in a local user group or haven't attended a conference, it's an experience completely different than sitting behind the keys, hacking day to day. PHP.net has a list of both PHP conferences and upcoming events - find one near you and make plans to attend. You'll be glad you did!

As a result of the ZendCon advisory board for this year's event, Joe Devon has posted a guide that wants to help you get your talks accepted to conferences in the future (both PHP-related and not).

For those who don't know what an advisory board is, conference organizers get loads of proposals and need help deciding who should speak. So they ask others in the industry to provide some feedback. It was quite a learning experience.

He talks some about the "speaker backlash" that comes from being rejected, a lack of professionalism in some submittors and some basic (common sense) recommendations like:

• fill out the form completely, even if you don't think it's all useful
• start locally and then move up. A major conference isn't the place to try out your speaking first-shot
• whet the board's appetite - make them want to hear more about the topic or come up with something new
• share your unique experience with the technology
• use sites like Joind.in, Meetup and SlideShare to your advantage

In a new post to his blog Jigal Sanders shares some of his experience in working with Doctrine 2.1 in a Zend Framework-based (1.11.9) application for his database interface needs.

I hadn't been using Doctrine for a while and decided to pick it up two weeks ago, as we wanted to see if we can implement it for our CMS at our office. So I setup a clean installation of the zend framework (1.11.9) and tried tried to implement Doctrine. The main goal was to see if we can reverse engineer existing databases and then start doing some queries.

There were three things he found in the process that caused a few issues:

• A confusing set of terms and features that weren't explained well enough to know their use
• Getting things like autoloaders working with the Zend Framework to make things work well together
• A potential bug with the "name" property on an object and some automatic namespacing Doctrine tries to do

There are already a lot of resources available on the Internet. I have looked at various configurations, like for example the 'bisna' project from Guilhere Blanco. But I keep saying that it's really difficult and has a steep learning curve. Doctrine 1.2 was really simple. Doctrine 2.x is a lot more difficult to get into.

On the Smashing Magazine site there's a post some of Paul Tero's favorite programming mistakes he's come across and heard of in his time programming.

I like to classify these mistakes into three broad groups: cock-ups (or screw-ups in American English), errors and oversights. A cock-up is when you stare blankly at the screen and whisper "Oops": things like deleting a database or website, or overwriting three-days worth of work, or accidentally emailing 20,000 people. Errors cover everything, from simple syntax errors like forgetting a } to fatal errors and computational errors.

Included in his list are things like:

• Leaving Debug Mode On
• Turning Debug Mode Off
• Wrong Variable Type
• 1p Errors

Examples of each are included with both code and descriptions as well as "lessons learned" to help you not make the same mistakes in your applications.

Those developers out there currently looking for a job (you shouldn't have to look too far) might want to read Michelangelo van Dam's take on job hunting 101 for of his experiences when recruiters contacting him.

In this day and age, everyone uses the internet for finding new jobs or to find a new employee, but more and more I sense that it's all turning into one big mess. This blog post is devoted to all those people contacting me because they have the best job position. [...] I know it's a tough market out there, lot's of competition and so many technologies and skills to keep track off. I know, but it is [you, the recruiter's] business! You decided to dive right into the job chaos, so don't cry if you have to do a bit of work. Do you think we just turn on the computer and it writes code itself ? You do your job, I do mine.

He points out a few specific times a recruiter has sent emails about a "direct hire position" that needs filling immediately or a Java developer (when, clearly, Michelangelo is a PHP developer). He also points out to recruiters that, despite what they may think, they're almost never the only one getting in contact about the same job.

if you're out looking for a new PHP job, go check out the community itself. Most of us have a list of companies with PHP job vacancies or we have a shortlist of trustworthy, understanding recruiters that have touched base with the PHP community and won't let you down once you sign up.

Following passing the Zend Framework Certification exam, Joshua Thijssen did some more thinking about other certifications that are out there to help developers show how well they know their stuff.

Today I've passed the Zend Framework Certification exam and with that I can finally close my new years resolution for 2010: doing 12 (tech related) exams in 2010. So I've seen a lot of exams, good ones and bad ones and I want to share with you my experience by creating a top-5 of must-have certifications for PHP programmers...

He suggests that certifications are a good way to prove your knowledge to others like customers or colleagues. He talks about the exams and certifications he's taken this year (20 of them) and some of the things he's learned along the way:

• Like unit-testing, mocking is everything.
• Failing is not a shame
• Don't do what I do, unless you know what you are doing.
• The top-5 of certifications that every PHP should have (according to me)

Dave Marshall has posted some of the notes he made when he ported an application from a language he didn't know (very well), Ruby, into PHP.

I'm porting from a language I'm not familiar with, and I'm porting code that I don't necessarily understand! I've written a couple of rails apps, but they were very basic, and I have no real clue with the delicacies of the ruby language.

He talks about the project - a migration tool - and how he had to work through things like the current file structure, converting functionality like exceptions and getting over Ruby's singleton use. He also shows how he could replicate some of the Ruby functionality with closures and how he set it all up to use Zend_Tool as the application structure.

After recently taking the Zend PHP 5.3 Certification exam, Alexei Shuga has decided to share some of his thoughts on his experience to hopefully give other developers out there a better idea of what was involved.

First of all, the exam is quite complex, yet it's pretty much easy to pass if you're writing PHP code using latest additions like namespaces, late static binding or lambda functions. Even if you do not use these techniques in your code, but you're aware of them and saw PHP syntax for those features (including restrictions like "namespace" keyword proper placement), it would not be a problem for a candidate to pass Zend PHP 5.3 exam.

He includes a few things that could trip you up in the exam including questions one differences in file system functions and some that were just, as he puts it, "stupid." (some were matters of opinion)