In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn't mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can't run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

He talks about some of the "dying" that PHP is good at (like making general website-related requests) but notes that if you try to have it do much more, PHP acts up. He points to the complexity of web-based applications and notes that, while PHP is good for some of it, it's not a fit for all functionality. He also covers the bringing of processes to the foreground that are best left in the background and how - despite the best of intentions - making a PHP daemon to solve the problem isn't a viable option.

Do you see the pattern? I've inherited projects where PHP was used for daemons or other stuff that's not just regular websites (yes, I'm a hired keyboard), and all of them shared that same problem. No matter how good or clever your idea looked on paper, if you want to keep the processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That's nothing you can really control, it's because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.

He lists five different pain points he discovered when trying to use the extension:

• Lack of a true Semaphore
• Undefined error handling
• Undefined behavior of sem_get()
• Cannot disable semaphore auto-releasing
• A semaphore may be deleted when other processes are waiting to acquire it

The semaphore extension provides a PHP-based wrapper for the System V IPC family of functions (including semaphores, shared memory and inter-process messaging).

[Outdated tutorials and information is] one of the reasons why new PHP programmers are so frequently blamed for ugly, outdated, or insecure code. They can't help it if the first Google result was a four year old article teaching a five year old method! This document tries to address that. It's an attempt to compile a set of basic instructions for what can be considered best practices for common and confusing issues and tasks in PHP. If a low-level task has multiple and confusing approaches in PHP, it belongs here.

The site has sections for topics like:

• PHP & MySQL
• Single vs Double Quotes
• PHP regular expressions
• Validating emails
• Checking null and false values

If you're interested in helping out and adding more content to the site, contain the maintainer and let him know.

Today what you get is an example of integrating with JIRA's REST API, because their recent "upgrade" locked me out of the issue listings pages completely and I really do need to be able to see a list of bugs! Their bug editing screen is quite usable, so it's just the list that I need here, but you could easily call their other API methods as you need to. These examples are PHP and use the Joind.in Jira tracker), parsing the JSON results and displaying the results as a simple list, looping with a foreach and outputting some HTML.

]]> Wed, 28 Mar 2012 10:57:56 -0500 http://www.phpdeveloper.org/news/16838 http://www.phpdeveloper.org/news/16838 Matt Farina has a new post today looking at an "underutilized gem" he's found in the offerings of the Standard PHP Library (SPL) - the SplFixedArray.

Arrays in PHP are not arrays per the typical array data type. Instead, as Matt Butcher recently pointed out arrays in PHP are similar to hashes in other languages. This can be a very important point to know when tracking down bugs in code and to programmers coming to PHP from other languages. But, what if we wanted something like a traditional array data type? Maybe something that preserved numeric order. Enter SplFixedArray.

He gives an example of using the SplFixedArray object versus the normal array variables in a simple PHP snippet showing the preservation of numbering order. He also touches on the memory consumption difference between the two, with the fixed array coming in quite a bit lower than the normal array data type (around 25% based on his basic testing). There are some catches to using it, though including incompatibility with array methods and the fact that it doesn't implement things like Iterator or Countable interfaces.

]]> Fri, 09 Sep 2011 10:43:11 -0500 http://www.phpdeveloper.org/news/15919 http://www.phpdeveloper.org/news/15919 In a new post to the Zend Developer Zone, Ralph Schindler has posted about this month's Bug Hunt Days for the Zend Framework. They start today (Thursday, February 17) and run through Saturday.

For those who haven't put the reoccurring event in their calendar, this announcement is for you: Zend Framework Monthly Bug-hunt is here again! This Thursday, Friday and Saturday of February (the 17th, 18th and 19th 2011), we'll be hosting our monthly bug hunt. For those of you unfamiliar with the event, each month, we organize the community to help reduce the number of open issues reported against the framework.

Last month the event closed 24 issues with a tie for first. If you're wanting to get involved and close even more of those issues, the post has the steps you'll need (including filing a CLA with Zend).

]]> Thu, 17 Feb 2011 06:58:01 -0600 http://www.phpdeveloper.org/news/15717 http://www.phpdeveloper.org/news/15717 Lorna Mitchell has a handy tip for those PHPers out there that use Github and want to pull off the issues from their project's Issues List quickly and easily - use their API (super simple).

I looked around for some export functionality for github but I got a lot of posts complaining it wasn't there. Since I hate applications that take your data and refuse to let you remove it, I was disappointed by this news but further inspection showed that although there might be no "export from github" button, there's an API that more than has it covered.

She gives an example of how to fetch only the currently open issues (the important ones) and pull then back through the API as a JSON message. Her little code snippet uses file_get_contents, but this can obviously be adopted to whatever use you might want. You can find out more about the things you can do with the Github API on the develop.github.com site including features to work with organizations, users, pull requests and gists.

]]> Tue, 11 Jan 2011 09:56:26 -0600 http://www.phpdeveloper.org/news/15349 http://www.phpdeveloper.org/news/15349 Lukas Smith has a new post to his blog looking at some of his experiences with working with JSON in the upcoming version of the Symfony framework (Symfony2), specifically in using the DoctrineUserBundle and load views via JSON.

Unfortunately right now there are quite a few issues with taking a 3rd party Bundle which wasn't specifically build to be accessible via JSON. So in the end I build a MultiplexController that can JSON-ify any controller. The name derives from the fact that it also supports calling multiple routes at once and returning all the data from all these routes in one request. But being good OSS citizens here at Liip, we decided to use this opportunity to try and come up with a more sustainable solution. The goal would be to make it essentially possible to have a 3rd party controller return JSON without having to do anything on the controller level.

He talks about the "magic" that lets you define the output format you'd like and how it works on the backend with the templating system to use templates based on the requested file. He points out a few issues with the method - a form request problem and that there's no good way to call json_encode from inside a twig template (as well as redirecting after submission).

]]> Thu, 28 Oct 2010 12:13:43 -0500 http://www.phpdeveloper.org/news/12042 http://www.phpdeveloper.org/news/12042 On the Blue Parabola blog Keith Casey asks the question "how do you measure an individual's contribution?"

In the past few weeks, I've been working fast and furious at getting web2project to our v1.0 milestone. As part of that effort, I track open issues, problematic modules, community feedback via the forums, death threats via all methods, and other related aspects.

He suggests a few different ideas for measuring how much a user has contributed: lines of code, commit count, issues they've reported, number of issues closed or community involvement. Of course, none of these can truly measure how much an individual has participated in a project, especially since it could be a mix of several of them combined into a whole as the "involvement persona" of any given person.

]]> Mon, 02 Mar 2009 08:45:19 -0600 http://www.phpdeveloper.org/news/7837 http://www.phpdeveloper.org/news/7837 In his search for "contact grabber" classes, Jonathan Street came across one posted to the PHPClasses.org website recently, the Contact Grabber class, and decided to give it a shot and report back his findings.

I haven't tried it yet but apparently it can connect to hotmail, yahoo, gmail, orkut, rediff and myspace. It is an impressive collection of scripts. [...] Generally speaking I wouldn't have a problem with the script being included in another project. In fact I would encourage it. In this instance though there are a few problems.

He breaks it up into a few different kinds of issues: inaccuracies, updates, licensing problems, and that the author wouldn't make contact back to Jonathan about some of his problems.

]]> Mon, 14 May 2007 12:38:00 -0500