The TutsPlus.com site has posted another tutorial spotlighting a component of the Symfony framework. In this latest tutorial they cover the Symfony Filesystem component, a module that provides useful wrapper functionality for common file system-related needs.

In this article, we're going to explore the Symfony Filesystem component, which provides useful methods to interact with a file system. After installation and configuration, we'll create a few real-world examples of how to use it.

The tutorial starts with a brief introduction of the component including a listing of functionality it provides. It then moves on to the installation (via Composer) and use in some sample code. From there they show how to use it to:

• create a new directory
• create a new file and add contents
• copy a directory
• remove a directory

Each of these includes both a code example and a brief summary of what's happening.

Matthias Noback has continued his series of posts covering mocking and testing at the "architectural boundaries" of your application. In this second post he offers two more suggestions of these "edges" where mocking could be useful: filesystem interfaces and randomness.

In a previous article, we discussed "persistence" and "time" as boundary concepts that need mocking by means of dependency inversion: define your own interface, then provide an implementation for it. There were three other topics left to cover: the filesystem, the network and randomness.

He starts with the mocking of the filesystem handling and makes the recommendation of using either vfsStreamor Flysystem to provide an interface that's more easily testable. These libraries abstract away the filesystem and make it easier to mock out the functionality rather than going directly to PHP's filesystem functions. His second example, randomness, is a bit tougher as the output isn't predictable. He still recommends abstracting it out, however, and offers suggestions as to what might be possible to test.

Sergey Zhuk has posted another ReactPHP tutorial to his site, this time focusing on working with the filesystem from a ReactPHP application.

I/O operations in the filesystem are often very slow, compared with CPU calculations. In an asynchronous PHP application this means that every time we access the filesystem even with a simple fopen() call, the event loop is being blocked. All other operations cannot be executed while we are reading or writing on the disk.

[...] So, what is the solution? ReactPHP ecosystem already has a component that allows you to work asynchronously with a filesystem: reactphp/filesystem. This component provides a promise-based interface for the most commonly used operations within a filesystem.

He starts the code with a bit of setup, creating the initial event loop, the related Filesystem instance and a pointer to a "test.txt" file. He then walks through the basic filesystem operations and the code required: reading in the file contents, creating a new file and writing content back out to a file. The next section goes through the same functionality for directories. He ends the post with a look at symbolic link creation, read and delete operations.

On the Weebly Engineering blog there's a new post showing you how to combine PHPUnit and vfsStream to mock out file system operations away from the actual file system.

Recently I found myself needing to write tests for a small class that read from a json file. The class needed to read a json file, validate its existence and content, provide a method to inform the user if a certain key exists, and provide a method to retrieve a value for a given key.

[...] Testing this class in isolation can be tricky because it currently has a dependency on the file system. Storing test json files to test this class would work, but is not ideal because it leaves a dependency on the file system in your tests. As with any external resource, there might be intermittent problems with the file system and could result in some flaky tests. This is where vfsStream shines.

The post includes an example class under test that pulls in the JSON files and operates on the contents. To make the testing easier they introduce vfsStream, a wrapper that allows for a virtual "file system" that can be operated on through the usual interfaces. They include an example of its use in a test on the same class making it easier to check the JSON based on a pre-defined value (essentially a mock of the file and its contents).

On the SitePoint PHP blog there's a new tutorial posted suggesting a method for hassle-free filesystem operations during testing in your applications. Traditionally external sources, including the file system have proved difficult to test mostly because connection/state issues or conflicts.

When working with the filesystem in our tests suites, a big concern is cleaning up the temporary files after each test runs. However, if for any reason the test’s execution is interrupted before the cleanup phase, further tests might fail, as the environment has not been cleaned up.

In this post, we will use a library named vfsStream to create filesystem mocks. It’s little more than a wrapper around a virtual filesystem, which also works very nicely with PHPUnit.

They start by creating a simple FileCreator class that just uses a file_put_contents call to write data to a provided path. They start with the traditional approach in testing - just writing to the actual file and ensuring it exists. Then comes vfsStream, changing up the testing to use mocks of the directory and file and it's own checks to ensure existence. These mocks work in basically the same way as a directory/filesystem structure would without the external interaction making it much easier to test in isolation.

Mattias Noback has posted a three part series of tutorial articles around the refactoring of a "CatApi" class. These articles take the class from a jumbled mess of functionality with both direct file access and remote requests mixed in into something much more maintainable and flexible.

t turned out, creating a video tutorial isn't working well for me. I really like writing, and speaking in public, but I'm not very happy about recording videos. I almost never watch videos myself as well, so... the video tutorial I was talking about won't be there. Sorry! To make it up with you, what follows is a series of blog posts, covering the same material as I intended to cover in the first episodes of the tutorial.

In part one he introduces the current state of the "CapApi" class and some of the problems with it, both in testing and in structure. He does some basic refactoring to split out some of the logic here and moves on to part two. In the second part of the series he focuses on refactoring the HTTP request and the local file system functionality into abstract, injectable objects. Finally in part three he adds in some verification around the data being passed back and forth between objects including both simple checking and the use of value objects.

The ServerGrove blog has posted another in their series of Symfony2 component spotlights with a look at the Filesystem component.

The 15th post of the Symfony2 components series is focused on the Filesystem component, which provides some basic utilities to work with the filesystem. It extends PHP built-in functions such as mkdir() or copy() to make them more portable and easier to use and test.

They start by stating the common problems with working in the file system from PHP and the warnings/errors that can come with them. They show how this kind of thing can be prevented with the Filesystem component and the functionality it provides. They also list some of the other useful functions (besides mkdir and touch previous mentioned) including: chmod, rename, makePathRelative and mirror. They also briefly mention the file locking ability the component has to prevent issues with multiple services interacting with the same files.

The SitePoint PHP blog has a new tutorial today from Lukas White showing you how to work with abstract file systems that aren't local. In this case, the file system is virtual and living on a remote system.

Reading and writing files is an integral aspect of any programming language, but the underlying implementation can vary enormously. For example, the finer details of writing data to the local filesystem compared to uploading over FTP is very different – yet conceptually, it’s very similar. In addition to old warhorses like FTP, online storage is increasingly ubiquitous and inexpensive – with scores of services available such as Dropbox, Amazon’s S3 and Rackspace’s Cloud Files – but these all use subtly different methods for reading and writing. That’s where flysystem comes in.

He shows how to install the flysystem library (via Composer) and a few examples showing how to make connections to:

• an Amazon S3 instance
• a Dropbox account
• SFTP
• even Memcache

Examples of both reading and writing to this virtual system are also included as well as a few other features like handling visibility, listing files/directories and mounting the remote filesystem locally.

On PHPBuilder.com today they continue their series looking at working with clustered file systems and PHP with this new post, the second part in the series (part one is here).

In part one, Introduction to Clustering in PHP, we explored the concepts of load balancing, PHP sessions, and how to set up a rudimentary PHP cluster that allows for redundancy as well as load balancing. The final configuration was one load balancer exposing an NFS share for all of the client PHP servers to use for session storage. While effective, this still gives us a single point of failure (the load balancer). More load balancers can be added, but sits us squarely back on our original problem: All of the sessions are on the first load balancer, not the second.

They talk about the GlusterFS networkable file system and talk about its concepts of "drives" and "bricks". The rest of the post is centered around helping you get GlusterFS servers set up and a brief mention of pointing your PHP session storage to the resulting setup.

In this new post to his site Kevin Boyd introduces a tool that you can use to scan your logs for login abuse, Fail2ban, and how to use it with your application's login attempts to ban IPs as needed.

Fail2Ban is a Python-based utility that hooks directly into the system's firewall to ban malicious IP addresses, and I'm going to show a few easy steps to make your site safer by blacklisting brute-force attackers. If you maintain a web application that doesn't have built-in authentication throttling, this might be the how-to you're looking for - alternatively, this would work as an additional way to punish pesky rogue connections.

His example uses the Fail2Ban ability to read files on the local system, as written by PHP and containing the failure message and an IP address, and adds IP blocks accordingly. He includes some sample code for the format you'll need to follow and a bit about setup and configuration of the Fail2ban tool.