In a post to his site Matthew Weier O'Phinney shares some notes about GraphQL usage that he's gathered over the last week or so of working with it.

The last week has been my first foray into GraphQL, using the GitHub GraphQL API endpoints. I now have OpinionsTM.

The promise is fantastic: query for everything you need, but nothing more. Get it all in one go. But the reality is somewhat... different.

He talks about his experience working with the results and the amount of data manipulation that was required to actually get at what he wanted. He shares the query he used, the result the API provided and what he ultimately wanted. He also mentions the less than useful documentation, issues with pagination and an update based on comments of pulling data from the GraphSQL API versus the REST API.

Continuing the theme of posts related to using PHP on the OpenWhisk serverless platform, Rob Allen has posted a few notes for working with the PHP runtime.

These are some notes for working on the OpenWhisk PHP Runtime, but are probably applicable to the other runtimes too.

His notes cover:

• some basic setup
• building the two containers (PHP 7.1 and 7.2)
• running tests
• using the container interactively
• checking the format of Scala files

Commands are included for each item along with some of the output to expect.

In a recent post to his blog Jeremy Kendall has posted a guide to deploying a PHP application with Capistrano. There's been enough changes in recent versions of the tool where information and configuration was difficult to find.

I spent quite a bit of my day yesterday trying to work out a painless, scripted, idiot-proof deployment process with Capistrano for my photo-a-day website. I’ve been doing a lot of work on the site lately, which means a lot of deployments, and I’ve been very unhappy with myself for implementing what amounts to “deployment worst practices” when it comes to my personal projects. The last time I worked with Capistrano was about two years ago, and a lot has changed since then. Capistrano v3 was released in June of 2013 and brought with it a lot of great changes, but for a guy who doesn’t know ruby and relies on tutorials and Stack Overflow questions for help, the version bump brought a lot of pain as well.

He starts with a list of some of the immediate challenges he hit against including that every tutorial is wrong (because they're for v2) and that the Capistrano v3 official documentation is lacking. From there he shares the steps he followed to get the whole process working:

• Installing Ruby and Capistrano
• Preparing the configuration files for the deploy
• Server configuration/SSH forwarding
• Getting Composer to work on deploy (with a Ruby gem)

There's also a few other random helpful hints around linked files/directories and variables.

In this discussion on Reddit, there's talk about the user comments feature on the PHP.net site and the value they provide to the language and community.

The question, however, has always been "how useful is this feature really and does it bring more harm than good?". It's not that easy to answer since there are so many notes submitted by a wide range of users and some will likely go unnoticed while others seem to get undue attention due to their positioning near the top of the user-notes section of a particularly trafficked page.

The poster proposes a few things that could help make them a bit more effective (and useful overall) including voting on the note contents, flagging potential issues and sorting the notes based on popularity/age. He's put together a proof of concept as seen here with some of the new features.

Brandon Savage has a reminder for both those familiar with PHP and a warning for those new to the language - take the examples in the comments of the PHP.net with a grain of salt.

This morning, I was reviewing the weekly list of topics with the most comments throughout the PHP manual, and I stumbled upon the following code in the documentation for the date() function. This code is designed to tell you the day of the week for any valid date you give it. [...] I’m sure that this user put a lot of work and effort into this function. I’m sure they were excited to share it with the PHP community. I’m sure they thought they had stumbled on a solution to a problem that everyone needed to solve. I’m sure they had no idea that this code is a great example of using PHP precisely the wrong way.

His example, one that uses around 30 lines of code to do something that date could accomplish in one, is a perfect example of why blindly following the advice of others without thinking things through can be disastrous for your code. Do a bit of research before you cut and paste and remember that with someone else's code could come someone else's problems - think before you implement.

In this new post to his blog Adam Harvey shares his opinion on unmoderated notes dropped directly into the PHP manual - "they're bad, mkay?"

I’ve had a couple of whinges on IRC lately about why I’m not thrilled with having user notes in their current form in the PHP manual; we get entirely too many questions in ##php from people who’ve copied code out of a note and are then annoyed when it turns out the code is wrong, broken, horrible, or all of the above.

His gives an example (one of many currently in the manual) that shows a round-about way of getting a date string that could be done better in a single "format()" function call on a DateTime object.

I don’t know what the answer is - moderation has its own problems to do with workload, as PEAR can attest - but a system that's letting that go up as recommended practice (and stay up for a month) has to be looked at.

As Andrei Zmievski points out, the notes from the PHP Developers Meeting have been posted to the php.net wiki.

Taking advantage of php|tek bringing a lot of people together, we had a PHP developers meeting over 2 days before the conference. Day 1 was dedicated to technical issues in PHP 5 and 6, and day 2 was spent discussing potential features, migration issues, current roadblocks, etc.

The notes cover PHP versions 5.3, a possible 5.4 and looks forward to 6.0. There's some interesting stuff in there, so read over it if you get a chance.

Jamie Hemmett has a few suggestions for local user groups out there on what to do and not to do to help make their group successful. Some of it was gathered from personal experience, other tips from the recent user group panel discussion from this year's ZendCon.

I just listened to the PHP User group Panel discussion from the Unconference session at ZendCon. While I listened I took some notes to try and help our Irish PHP Users Group be awesome like some of the other groups out there. I reckon the podcast and great tips it contains will help other User Groups out there too (not just PHP).

Some of the observations/comments she mentions include:

• Freelancing PHP developers may not feel like attending a group with "the competition"
• Several factors dissuade developers from attending (distance, confusing schedules, timing)
• Some ideas that groups out there could use to attract and keep more members
• Why the groups can make you a better developer
• and some sponsorship/promotion ideas to help grow and better the group

This is a great post packed with some good suggestions and observations. If you're involved at all in your local group (or would like to be) be sure to read it.

In a new post today, Ben Ramsey continues on from some previous thoughts on a different sort of method for using the Views in the Zend Framework. This time, he focuses on a more automated way implement them in the same way.

Just as views can be automated—that is, you don't have to instantiate a Zend_View object; the controller does it all for you when you call $this->render() from any controller action—you do not have to explicitly tell Zend_View where your helpers reside, as the manual suggests. Instead, place your helpers in a special "helpers" folder where the Zend_Controller_Action’s initView() can find them.

He includes how the directory structure would be altered (the addition of the helpers folder) and how to name the helpers so they can be used in an application (Zend_View_Helper_*). Also, check out the post for some of his interesting thoughts on a recent visit of his to New York City.

In a new post today, Ben Ramsey continues on from some previous thoughts on a different sort of method for using the Views in the Zend Framework. This time, he focuses on a more automated way implement them in the same way.

Just as views can be automated—that is, you don't have to instantiate a Zend_View object; the controller does it all for you when you call $this->render() from any controller action—you do not have to explicitly tell Zend_View where your helpers reside, as the manual suggests. Instead, place your helpers in a special "helpers" folder where the Zend_Controller_Action’s initView() can find them.

He includes how the directory structure would be altered (the addition of the helpers folder) and how to name the helpers so they can be used in an application (Zend_View_Helper_*). Also, check out the post for some of his interesting thoughts on a recent visit of his to New York City.