TutsPlus.com has continued their series of posts covering some of the basics of the PHP language with their latest article. In this newest tutorial they cover reading from and writing to files using functionality already included with the language.

In this tutorial, you'll learn several important functions in PHP which are sufficient for all your basic file reading and writing needs. You'll learn how to read a file, write to a file, write to a text file, and check if a file exists.

Luckily, PHP provides a lot of functions to read and write data to files. In this tutorial, I'll show you the easiest ways to read data from a local or remote file and how to use flags to write to files exactly how we want.

The tutorial is broken down into several sections:

• checking if a file exists
• reading data from a file
• writing data to a file
• reading and writing data to files

Each section comes with a bit of description and code examples showing it in action. The post wraps up with some final thoughts and "gotchas" that you need to know when working with files in PHP (especially large ones).

Sergey Zhuk has posted another article to his site covering functionality provided in ReactPHP. In this latest tutorial he covers the PromiseStream handling of the library allowing for the translation from promise to stream (and back).

One of the patterns that are used to deal with streams is spooling: we need the entire resource data available before we start processing it. One approach is to collect each chunk of data received from the stream.

But, imagine that we have some client code that wants to process some data from a file. It doesn’t care about the streams, it only needs to receive the entire data from the file. With this approach, this code should be called inside the callback for the end event of the stream. So, the client code should now about streams, events, and callbacks. But sometimes it’s impossible.

Example code is included to illustrate the problem above and an answer is provided in the form of ReactPHP promises. This allows the data to move into the promise as the data is being read from the stream's source. The tutorial goes on to talk about the functionality behind this transition including the buffer method to create the promise with chunked data, the all method to build the promise from the full data in the stream and the first method that works with events on the stream. The article then covers the reverse, showing how to pull information from a promise and push it back out to a stream via the unwrapReadable and unwrapWritable methods.

Phillip Shipley has written up a post for his site walking you through the process of using PHP to read from and write to Google Sheets via the Google Sheets API.

This past week I needed to be able to read some data from a Google Sheet and then update a column for each row after processing it. This sort of thing should be simple, Google is built on APIs and has client SDKs for just about every language. I’ve also integrated with several Google Admin APIs previously so I expected this to be a breeze. I was wrong.

I started out by reading the Quickstart for Sheets API with the PHP Client, but almost immediately I could tell it was not written for my use case. [...] My use case is to use a backend process to function as a service account and batch process data. So the whole API credentials process was wrong for me.

He tried a few different approaches and finally, after some guessing, discovered how to share a sheet with the email address for the application. He then includes the steps to follow to get this same setup configured for your application and the code (using the Google_Client) to read and write to the sheet.

In this new tutorial from the SitePoint PHP blog Christopher Pitt once again takes on an unconventional question around the use of PHP: "is it possible to write/run PHP code on an iPad?"

I love the iPad. It’s a fantastic form factor for media consumption and gaming; and it also works well as an e-reader. The trouble is I don’t use it nearly as much as I could. Most of the time I’m consuming media (Netflix, Twitch, YouTube), I’m coding in parallel.

I can do that on my MacBook, but I’ve never been able to do that until now. [...] Today I’m going to show you how I code on an iPad. I won’t pretend it’s a perfect workflow (what workflow is?), but this is as exciting for me as the first time I used a laptop instead of a desktop.

He briefly covers some of the hardware you'll need to get started including a good keyboard you're comfortable with and a way to hook it up (either Bluetooth or manually via USB). He then gets into the software and mentions DraftCode and WorkingCopy as his tools of choice. He then helps you get started writing your first PHP script, using SQLite in-memory and using Working Copy to pull the latest code from your external source. Now that you're comfortable with the setup, he shows you how to install a Laravel application and the changes you'll need to make to get it up and running. Finally he shows the push of the code the remote source, updating the repository with these latest changes.

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).

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.

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.

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.

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).

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.