Miro Svrtan has a recent post to his site talking about the first ever PHP meetup that happened in Belgrade in at the end of April organized by the PHP Srbija community.

With gathering of more then 250 developers this proved to be a much needed event there and congratulations to organizers for doing it. As a organizer of similar (but much smaller) PHP community in Zagreb I was in constant contact with organizers and was very happy when we were invited to join them on this occasion, especially when they approved my proposal to talk about Laravel4 there.

Even the local media picked up on the meeting and a larger venue had to be found at the last minute due to the overwhelming response. There were a few different topics mentioned (including BDD, a questionnaire, best practices in component libraries and web security) before getting to the main talk.

I would take this opportunity to thank whole PHP Srbija organization committee for inviting us & once again congratulate them on bringing such a large community together.

On the Smashing Magazine site today Brian Hoyt has some suggestions for you to use to keep your workflow organized when developing your applications (code, file structure, assets, database, etc).

Perhaps in the past you've tried to build a more complex, cutting-edge website like [our example], and the project started off with great enthusiasm, but ended up in a nightmarish mess that you couldn’t maintain. Your client lost interest when new features started getting too hard to add, and you started having to work late at night, tracking down bugs that you couldn't even find the relevant file for. After a project like that, it's not hard to see the relevance of a well-organized website project.

He talks about some general principles like "don't over-organize" and "don't mix aspects of the site" as well as some more specific things like a website size to structure recommendation and parts of a site and how to handle them - assets, stylesheets, javascript, the database structure/values and, of course, the code.

Zeev Suraski has posted about a French government-organized PHP seminar he spoke at yesterday, held by the DGME.

It was held in a conference room in one of the Minefi (Ministry of Finance) buildings, no less. Most of the attendees were coming from various governmental agencies and ministries, to learn more about PHP success stories and best practices. Presenters came from Oracle, alapage.com, DGME, Zend and others.

He describes the seminar as being the first of its kind in France, especially organized by such a large entity as the government there. As the trends in PHP adoption shift, however, things like this will be happening more and more.

Zeev Suraski has posted about a French government-organized PHP seminar he spoke at yesterday, held by the DGME.

It was held in a conference room in one of the Minefi (Ministry of Finance) buildings, no less. Most of the attendees were coming from various governmental agencies and ministries, to learn more about PHP success stories and best practices. Presenters came from Oracle, alapage.com, DGME, Zend and others.

He describes the seminar as being the first of its kind in France, especially organized by such a large entity as the government there. As the trends in PHP adoption shift, however, things like this will be happening more and more.

In his latest post, Jason Lefkowitz takes on something that's praised by PHP developers and non-PHP developers alike - the documentation for the project. There's just something he finds messy about the whole business.

Really, it has more to do with the way that PHP's structured than the actual documentation. It's just a case of art imitating life.

He also comments that the entire listing is also cluttered with other functionality, things that most developers would toss aside if they came across - they just don't need them.

His point isn't without merit - there is definitely a need to reorganize things in the manual to make them a bit more "topic friendly". The documentation is already one of the most well-maintained in the Open Source community, so the content is there, maybe it's just the structure that needs to be changed.

In his latest post, Jason Lefkowitz takes on something that's praised by PHP developers and non-PHP developers alike - the documentation for the project. There's just something he finds messy about the whole business.

Really, it has more to do with the way that PHP's structured than the actual documentation. It's just a case of art imitating life.

He also comments that the entire listing is also cluttered with other functionality, things that most developers would toss aside if they came across - they just don't need them.

His point isn't without merit - there is definitely a need to reorganize things in the manual to make them a bit more "topic friendly". The documentation is already one of the most well-maintained in the Open Source community, so the content is there, maybe it's just the structure that needs to be changed.