The podcast hosts talk about popular trends and technology in the open source world and interview developers behind some of the useful tools you may use every day. Recent topics include Vagrant with Mitchell Hashimoto, Spine and client-side MVC with Alex MacCaw and Foundation and other Zurb goodies.

They've also spotlighted several interesting new libraries including:

• LiveReload
• Requests (for PHP)
• SpacePen
• active_attr
• sidekiq

This episode was recorded in 2011. Elizabeth now works for Orchestra.io. It's still a fun interview though because...well, it's Elizabeth.

You can find her blog here and follow her on Twitter here. If you'd like to listen to this latest episode, you can either listen in-page or download the mp3 directly.

In this edition, I talked with Stefan Koopmanschap (@skoop) the co-founder of the Dutch PHP usergroup PFZ.nl which is merged with the PHPBelgium usergroup to form the PHPBenelux usergroup. He is also an official Sensio training partner for Benelux and Germany. [...] Koopmanschap is much involved in the OpenSource world and is a very highly respected member in the PHP Community; he advocates sensible thoughts and never fails to make his point stand out in the best way he can. You can read more about him on his personal blog - LeftOnTheWeb.

Stefan answers a few questions about himself and his experience with PHP:

• A bit of background on who he is and when he got started with PHP
• How he got started with the language
• His opinion of PHP now versus when he first started
• some of the good and bad things about PHP

You can read interviews with other PHP community members here.

In this edition, I talked with Michelangelo van Dam a senior PHP/Zend Framework consultant. This man really needs no introduction; he is so much of an invaluable asset to the PHP community. As per wefollow.com, he is ranked as the 4th (out of 113) most influential person on Twitter for #zendframework and as the 25th (out of 2,543) most influential person for #php

Questions in the interview cover everything from a bit of history about Michelangelo out to how supportive the PHP community is:

Give and expect nothing in return. People appreciate it more when you give something from the heart instead of giving something as a favor for a future return.

Other questions touch on his "community animal" nickname, his community/life balance and his tracking of the work Microsoft is doing to help the PHP language.

In this edition, I talked with Enrico Zimuel a computer geek since he was 9yrs old. He has written a couple of books namely "Secrets, Spies and Cipher Codes" published by Apogeo in 1999 and the recent "How to use the digital sign" published by Tecniche Nuove in 2010. Enrico has a pretty impressive 'geek' path. He also speaks at many international conferences [...]. You can find his presentations on slideshare.

Questions in the interview include:

• How do you find PHP now as compared to when you first started?
• Based on your experience, what are the good and bad parts of PHP?
• To someone who wants to become a better PHP developer, what is your advice?
• What are some good PHP blog or resources you highly recommend?

Read the full interview here.

As of the time of this post there's about sixty-five comments posted to the thread with widely ranging opinions:

• "How is [lots of separate libraries scattered around] better than simply using a framework?"
• "This is part of the reason for the PSR0 reference for auto loaders [...] Part of the problem is an inconsistent way to load modules."
• "I would love to see this become a trend in the PHP community. I think this is exactly the direction needed to make PHP exciting again and regain mindshare in the wider dev community."
• "I know, many people are currently on that micro trip but seriously, I think that there is as much to microframeworks as there is to microoptimization"
• "A framework is a tool. If you don't need it, why use it?"
• "There's a tool for ever job, I agree some projects or companies "need" something like Zend or Symfony for their enterprise projects. Whether or not you'd want to work on a project with 1000's of classes is something else all together."

Read the full responses to Ed's article here.

Interesting they may be, but I want to address what in my opinion is the real problem: The way the communication around it was handled by different projects and the fact that the exploit could still exist at all. [...] In the presentation Wälde and Klink talk about their disclosure process. The PHP project had them wait 3 weeks for a first response while this is obviously a serious matter.

He argues that things like a commit message mentioning a DoS prevention fix instead of just mentioning the fix have the potential to do more harm than good. He also points out that other communities were notified of the problem (like Python) and some still haven't responded to the issue.

This attack was the result of good research and it is important that it is disclosed. More importantly however is the fact that organisation got by with years of not noticing it and even worse, reacted very poor after being informed. I can't say I have a ready solution to avoid these kind of things in the future, perhaps that will prove to be an interesting discussion.

I started writing a Zendcon recap post as soon as I got back. And then mis-timed a couple projects. Note to freelancers, make sure your new gig starts AFTER your old gig is over. Or you'll be working an insane schedule. Hence the lateness... First the good part. What made Zendcon special.

He notes that it was a great opportunity to meet people "in real life" that he'd only spoken with online and the overall wonderful experience it was. He mentions some specific people in the PHP community including Juozas Kaziukenas, Daniel Cousineau, some impromptu singing of Queen songs and many more (too many to name here). He also mentions some of the sessions attended including the tutorial on Zend Framework and an uncon talk from Ilia Alshanetsky about optimization.

In this second part I would like to talk about a few things Composer could do for you, and the PHP community at large, once it is broadly adopted. [...] How can [shared] interfaces be distributed in each project that uses or implements them? This is where I see Composer helping. Composer supports advanced relationships between packages, so to solve this issue you would need three parts.

The three parts all revolve around a few different packages (for their specific Caching interface example) - psr/cache-interface, psr/cache and the requiring of these into a framework needing the common interface. He talks some about what this sort of structure has to offer: simpler plugin installation, promotion of good standards, promotion of code reuse and a renewed interest in using PHP.

Reinventing the package management wheel is another thing that really should stop. Who am I to say this you ask? It is true, we are building a shiny new wheel as well. Yet I take comfort in the fact that we are trying to build a generic solution which will work for everybody.

Jason Austin gave a great presentation at CodeWorks Raleigh recently about cultivating one's passion for software development through side projects -- safe spaces where we can play with new technologies and techniques. The point's well taken: as developers, we're probably putting most of our energy towards the thing that must be solved, that keeps us employed, that pays our bills. [...] And so all of us, at one time or another, end up in a backwater of our own devising -- a locked box.

He also puts an emphasis on collaboration and community as it relates to becoming a better developer. By interacting with other code and other projects' developers, you learn not only more about other ways to develop but are exposed to ideas you may not have come across on your own.

I'd add that active participation in the local community is just as important though: the opportunities for exposure to new ideas outside your sphere are greater than your feed reader will probably provide, and the depth of information that you can get in a conversation may be better than any blog post or man page.