I had a great brainstorm a few weeks back with the members of the Developer Evangelists meetup on the topic of the User Journey, or as I'll call it now, the Developer Experience. The main problem we wanted to solve was how we convert new users into experts or awesoms users. In many ways, a Community Manager and/or Developer Evangelist is responsible for driving user adoption and making users successful, so this is a topic near and dear to all of our hearts. I walked away with three key things that help improve the developer experience: Great Product, Great Support and Empowerment.

This post talks about the first point - the "great product" - and notes that, if the product isn't useful and enjoyable to use, even developers won't bother with it. She also talks some about the need for quality documentation and how it can be seen as a sort of "marketing" to developers.

Work on making your product fit for an awesome developer experience. If you build it, they will come.

Some developers may notice this absence of "particles" and interaction between them in their local area, this may even cause them enough of an itch that it needs to be scratched, and thus a User Group starts forming. But how hard is it to start a group? Can anyone do it? what really am I going to have to do to get all these particles into my vacuum and end this "empty space" in my region?

He offers some suggestions of things he's done in the past to help start up user groups including things like:

• Finding local developers interested in meeting up
• Spreading the word via coworkers/other companies using PHP
• Having more than just a "one man operation" running the group
• Looking for partners/sponsors for the group and its activities

Come join the fun, being in a user group and participating is a very good, professionally and personally, you are not just helping others, you are learning, teaching and expanding you set of tools.

I was learning on my own, so I studied PHP from resources such as php.net. It's a great resource when you consider abundance of the information, but it's terrible, when you look at the quality of advise. I'll start explaining how things evolved in my head in a hope that people will catch up where they are now to understand some things further. By no means this is a "definitive" guide to PHP. Just a few tricks that might help you save your precious time and nerves.

The post includes a lot of helpful hints covering things like the inevitable evolution of the codebase and the growing pains he worked though, the use of static methods, autoloading, bad variable naming, unit testing and MVC restructuring.

I considered Amazon, Orchestra.io, and a few others, but was concerned about the idea of a ~$50/month cost for something I'm uncertain about. When I asked in #zftalk.dev, someone suggested OpenShift as an idea, and coincidentally, the very next day Zend announced a partnership with RedHat surrounding OpenShift. The stars were in alignment. In the past month, in the few spare moments I've had (which included an excellent OpenShift hackathon at ZendCon), I've created a quick application that I've deployed and tested in OpenShift. These are my findings.

He talks about getting a Zend Framework 2 application up and running with a few changes to the default directory structure they provide. He also talks about using Composer as a deploy task. He mentions a few of the tricks to watch out for as you're deploying your app and some of the "good parts" he found about the product and experience (like being able to use CNAMEs and having SSH access to the instance by default.

The year 2011 was a great success for developer communities in Zagreb. Although mobile developers started in 2010 with Mobile Monday, web developers were a bit shy and Ruby developers started first, then python meetups started and in the summer few people urged/pushed me to start organizing PHP Meetups. Besides colleagues I did not know a lot of PHP developers so I needed to spread the word about it. Twitter was the first step and it paid off. With only a few retweets there were already 10-20 people interested.

The post talks about the growth of the group, things they wish they'd done better (like involving local companies) and their work to create a custom logo for the group. If you're in the area and want to find out more about the group, check out their main page.

PHP has had microframeworks for quite some time, though I only really first saw the term being used around 3 years ago. The "grand-daddy" of modern-day microframeworks can actually be traced to Ruby, however, and specifically Sinatra. [...] Since around 2009, I've seen an increasing number of new PHP microframeworks4 that follow in the steps of Sinatra and Horde. In the various implementations I've looked at, instead of using a DSL, the authors have all opted for either a procedural or OOP interface.

He gives some code examples showing how the typical routing has been handled in most of the frameworks he's seen and how they handle passing values back to the handler. He sees three use cases for frameworks like this including small, mostly static sites and APIs. He also mentions his efforts to create a microframework using components from the Zend Framework 2 (not released). He finishes up the post with some of his own conclusions about microframeworks and the lessons he learned from his efforts.

I was lurking one day on Usenet Perl forums when I saw an announcement about the release of PHP 2.0/FI, the first truly public version of PHP. I was growing weary of trying to get PERL working via CGI and fell in love immediately with how simple and fault-tolerant mod_php with Apache was compared to CGI hell. In 1996, they didn't have sites like reddit when I was a noob. They didn't even have Google when I first learned PHP (years before google existed). Hell! php.net's search functionality barely worked. I don't remember there be any real documentation until after PHP 4 came out in mid-2000.

Other people have added their own memories to the post, mentioning how they started out with the language and some opinions on its current state.

It's been a few days since CICONF and this is my first chance to get my thoughts together after a few busy days. In all I am extremely pleased with the event, and so far I have seen nothing but positive feedback on the #ciconf hash-tag and not heard any complaints. Winner!

He goes through both days of the conference - Friday and Saturday - describing things from his perspective (an organizer), some of the speakers that presented and some of the evening activities.

I created my profile on monster.com on a Monday and made it public that night. The following Tuesday morning my telephone went nuts and my email inbox blew up with recruiters reaching out with positions that I was "perfect for". Over the course of the next week and a half (not including weekends) I spent 10-12 hours a day receiving and returning phone calls, and reading and responding to emails from recruiters.

He received calls from all over the country as well - "apparently experienced PHP developers are in short supply". He points out a few things he found interesting about the search like the fact that unit testing was never listed as a requirement (or even a "plus") in descriptions, only a few descriptions talked about memcache and that PHP wasn't the language over half of the employers were looking for.

He also shares a few hints for those looking for jobs right now, things to add to your resume or look for as far as skills most in demand:

• Have experience with frameworks
• Joomla was very commonly being used so being familiar with it is definitely a plus
• Have sample code to show your coding skills
• There's more to the world then PHP

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.