Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Dylan Bridgman:
Writing highly readable code
Jul 30, 2015 @ 12:29:55

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

  • the overall style of the code
  • the structure of the application (directories, libraries used, etc)
  • naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

tagged: write readable code tips style structure naming convention comments

Link: https://medium.com/@dylanbr/writing-highly-readable-code-94da94d5d636

Tideways.io:
Essential Macro Optimizations to Improve PHP Performance
Jul 09, 2015 @ 10:19:16

The Tideways.io blog has posted a set of four macro-optimizations you can do to help improve the overall performance of your application. Note the "macro" here, not "micro", so these are larger, more platform-level changes.

This blog post describes four macro-optimizations for PHP applications that are essential to consider before investigating other possible optimizations. [...] While its fun chasing after small micro optimizations, often it is debatable if the developer time is well spent. After all I/O is the more important bottleneck in almost every application. [...] But its much more efficient to fix the big issues first. The changes I present in this post can be done quickly and their gains can be massive.

The four suggestions he makes cover different areas of a standard application:

  • Upgrade PHP to a recent version
  • Use accelerator such as APC or OPCache
  • Close Session for Writes
  • Don't run XDebug in Production

Each tip comes with a bit of background on why it's a good idea and some have links to other resources supporting the change or update proposed.

tagged: macrooptimization performance application version opcode cache session write xdebug

Link: https://tideways.io/profiler/blog/essential-macro-optimizations-to-improve-php-performance

Eric Wastl:
Your Job Is Not to Write Code
Dec 04, 2014 @ 09:05:04

Eric Wastl has written an open letter to software developers out there in response to this post and sharing some of his own thoughts (and corrections) about what it suggested.

Dear [Software] Engineers, Your job is not to write code. Rather, your job isn't only to write code. Your job is to design and build software, and one of the steps in that process happens to be explaining to a computer how to do its new job. An article appeared on Medium recently that writing code isn't really a big deal and it's not really what your job is about. It is. You can smell "Product Manager" miles before the signature line of the article. The article goes on to talk about how your job is to improve your products for your users. This is not the job of an engineer - this is the job of every person at your company.

He talks about some of the "other jobs" the Medium article suggests a software developer be doing including making sure the "code runs the way it should" (devops, testing, etc) and that it "actually gets merged and pushed into production" (a release engineer). He points out the dissonance between the request for things to "run under all conditions" and when it makes sense to add analytics to your code.

Because your job is to write code. Your job is to write the best code you can, as quickly as you can, within budget, meeting all of the expected features, in a maintainable way, and a million other things, and still make the users happy. [...] Your job is to tell someone when you make a mistake. Your job is to work together with your testers and with operations and with product and finance and, yes, even the other engineers. Your job is to figure out what product will ask for before they ask for it, and build the code so that if and when they do, adding the feature is easy because the code wasn't written in a way that requires a year-long refactoring project to do it in a way that wouldn't make Cthulhu literally gleeful at the thought of it.
tagged: software engineer write code opinion correction medium

Link: http://hexatlas.com/entries/5

Nikita Popov:
The case against the ifsetor function
Jan 13, 2014 @ 09:22:52

In his latest post Nikita Popov aims to make a case against the introduction of the "ifsetor" function to be introduced into the PHP language. This function takes in a variable to find and, if found returns it. If not, it doesn't produce an error (or warning).

Recently igorw wrote a blog post on how to traverse nested array structures with potentially non-existing keys without throwing notices. The current “idiomatic” way to do something like this, is to use isset() together with a ternary operator. [...] Someone on /r/PHP pointed out that there is an alternative approach to this problem, namely the use of an ifsetor function.

He goes on to talk about by-reference argument passing, why requesting an undefined array index doesn't really throw an error and how writes don't have the same issues as reads. He then gets into his own issues around the "ifsetor" function, namely:

  • Creation of dummy values
  • No notices for nested indices
  • Null values treated as non-existing
  • Default is always evaluated
  • By-reference passing often forces a copy

He summarizes most of the issues in one statement - "there is way too much by-ref magic involved". He then looks at some of the ways that this could be helped but opts instead for something more like "get_in" as proposed by Igor.

tagged: ifsetor getin array read write problem byreference

Link: http://nikic.github.io/2014/01/10/The-case-against-the-ifsetor-function.html

Mikko Koppanen:
PHP extension writing
Oct 21, 2013 @ 10:35:15

Mikko Koppanen has written up a quick post sharing some work he's done to help make writing extension in PHP a little bit easier. He's created a new project that shares some of his experience in extension development.

I plan to add practical examples related to extension writing. There won’t be extensive written documentation outside the code, but hopefully the code itself contains enough nuggets of information to be useful. As the README says, if you need a specific example or clarification on something just open an issue in Github.

The project is still in its early stages, but plans are to have quite a bit more examples as time goes on. Also, as Johannes Schlüter points out in the comments, there's also another example like this - Marcus Boerger's demoext (with accompanying slides).

tagged: extension write demo example github project extsample

Link: http://valokuva.org/php-extension-writing/

Kevin Schroeder:
More - The file system is slow
Sep 30, 2013 @ 10:44:29

As a follow-up to his previous article about the (minimal) overhead from logging, Kevin Schroeder has this new post focusing on the common belief that writing to the file system is the slowest method.

I had a conversation the other day by a person I respect (I respect any PHP developer who knows how to use strace) about the cost of file IO. My assertion has been, and has been for a long time, that file IO is not the boogeyman that it is claimed to be. So I decided to test a cross between those two posts.

His test was to write one million log records to two different sources - the normal physical file system, a RAM drive - one run with a file handle that's left open and the other with a new handle each time. He shows how he made the RAM drive and the PHP he used for the test (running in a VM). He graphs out the results with some interesting results...but you'll have to read the post for that.

tagged: file system slow write log overhead benchmark ramdisk graph

Link: http://www.eschrade.com/page/more-on-the-file-system-is-slow/

Derick Rethans:
Mongo is dead, long live MongoClient
Nov 28, 2012 @ 09:13:51

In this recent post to his site Derick Rethans mentions the shiny new "MongoClient" class that the latest release of the Mongo PHP drivers provides.

This afternoon we published version 1.3.0 of the MongoDB PHP driver. Besides a number of bug fixes since RC2 and RC3, this new release also includes a new MongoClient class. This new MongoClient class serves as a replacement for the Mongo class. The old Mongo class is now deprecated and will be removed in a future release, although we are keeping it in place for now because of backwards compatibility reasons. We have already removed it mostly from the documentation, and are working to update all our other material as well.

The main change that comes with the MongoClient class is that it now has acknowledged writes on by default (a "safe mode"). This option determines wether or not the client waits for a confirmation from the server when a write has happened. He includes a bit of code showing how to: turn it off, keep it on or using replica set acknowledged writes. You can also set it on a per-query basis.

tagged: mongo class driver release mongoclient class confirm write

Link:

Qafoo Blog:
Webinar: "Writing Testable Code"
Mar 21, 2012 @ 12:54:49

As Tobias Schlitt points out in this recent post to the Qafoo blog, the recording of a webinar he did (for Zend) about "Writing Testable Code" has been posted for listening online.

In this session you will gain insight into the secret of writing easily testable code and you'll learn how this relates essentially to good object orientation.

The recording is just one of many webinars Zend offers on a wide range of development topics, including:

Almost all presentations also come with PDF versions of their slides attached, too.

tagged: webinar write testable code qafoo tobiasschlitt

Link:

Kevin Shroeder's Blog:
Zend_Log with multiple writers
Sep 14, 2010 @ 10:39:34

Kevin Schroeder has a recent post to his blog about a handy trick Zend Framework developers can use to have Zend_Log write out to multiple sources at once pretty easily.

If you were not aware, Zend_Log provides facilities for writing to multiple logs through the same log instance. Additionally, you can do this via configuration options when using a Zend_Application resource plugin. Together those make for very powerful logging mechanisms. "How?" you ask? It's really easy.

The trick lies in the application.ini file configuration. He includes an example of how you can set this up showing how to make two different environments log differently - development writes to log/firebug and production just writes to the log. He includes some sample code for a basic controller showing you how to use it.

tagged: zendlog zendframework tutorial multiple write development production

Link:

Derick Rethans' Blog:
Available for PHP Extension Writing
Mar 16, 2010 @ 09:40:24

Derick Rethans, realizing that he wasn't ready to jump back into a full-time position just yet has decided to refocus his efforts on helping make PHP a better place with work on PECL extensions and on internals-related issues.

Instead I will be available to work on (custom) PHP extensions and internals related issues. Extensions are a great way around PHP's limitations and performance issues.

His first project is a QuickHash extension to interface with the popular StumbleUpon and works more efficiently by using more clearly defined data structures. There's no stable release yet, but keep an eye on the subversion repository for the latest enhancements.

tagged: extension write stumbleupon pecl

Link: