Recent posts from the PHP Quickfix site:
- Exakat 1.0.4 review - Exakat
#exacat, #review, #v1.0.4, #scanner
- Laracasts: Free Visual Studio Code Course - Laravel News
#larave, #visualstudio, #course, #free
Recent posts from the PHP Quickfix site:
On the SitePoint PHP blog, there's a tutorial posted showing you how to deal with large files without "killing your server". In this case, it's not about the upload process but about the handling of large files on the server side.
It’s not often that we, as PHP developers, need to worry about memory management. The PHP engine does a stellar job of cleaning up after us, and the web server model of short-lived execution contexts means even the sloppiest code has no long-lasting effects.
There are rare times when we may need to step outside of this comfortable boundary — like when we’re trying to run Composer for a large project on the smallest VPS we can create, or when we need to read large files on an equally small server. It’s the latter problem we’ll look at in this tutorial.
They start off by describing how they plan to measure the success of the improved file handling, mostly around the memory usage required to work with the file. It then gets into some of the options available including:
The last option, the filters, seems to be the best one. He uses this one and customizes the handling with different configurations and custom protocols. All related code is included in the post and is avaialble on GitHub.
On the Laravel News site there's a quick tutorial posted showing you how to use named routes in Lumen in writing tests for your application.
When writing tests in Lumen, I recently discovered that the route() helper doesn’t work with tests out-of-the-box.
I prefer to define named routes and make requests against them in my tests. If you follow the Lumen documentation, the typical way that you make a request for a test [of the return of a JSON endpoint results in an error message]. [...] If you inspect things a little closer, you can see the issue: [...] Interestingly, the route doesn’t look quite right, and the router is returning the / route. It looks like the localhost part of the request isn’t being set, and the route isn’t matching. We can fix that by bootstrapping the request as Laravel does.
The post then walks you through the manual process of bootstrapping things so that routes are correctly resolved. This includes changes to the code for the base test case to handle the "boot" and set the path value for the request correctly.
Sergey Zhuk has posted the latest part of his "Building a ReactPHP Memcache client" series to his site today. In this latest article, part four of the series, he focuses on unit testing the client as he's developed it so far.
This is the last article from the series about building from scratch a streaming Memcached PHP client for ReactPHP ecosystem. The library is already released and published, you can find it on GitHub. In the previous article, we have completely finished with the source code for async Memcached ReactPHP client. And now it’s time to start testing it.
He then walks through some of the steps to create the tests for the client, made a little more difficult by its asynchronous handling. He shows how to use Mockery to create tests that evaluate the results of the promises from the client, starting with a simple check on the return of a
version call. The post goes on to show testing for other parts of the client and includes all of the code and commands you'll need to execute them in your own environment.
In a new post to his site Fabien Potencier has posted an update about Symfony 4/Flex and what can be expected from this upcoming release.
Symfony 4 is just around the corner. And Symfony Flex is one of the main selling point for the upgrade. Developers love the new philosophy. And a lot of changes happened since my last blog post. Let me recap the recent changes that you might not be aware of. Most of these changes were prompted by feedback from early adopters.
Included in his list are things like the easier use of recepie contributions, Makefile support changes and minimum PHP version requirements. He also links to an upgrade tutorial and a best practices guide to help you get your application and its code prepared for this new release.
Latest PECL Releases:
On the TutsPlus.com site there's a new tutorial posted for the Laravel users out there covering a few pieces of the authorization features of the framework. The tutorial covers "gates" and "policies", introducing some of their basic concepts and providing example code to implement your own.
Today, we're going to discuss the authorization system of the Laravel web framework. The Laravel framework implements authorization in the form of gates and policies. After an introduction to gates and policies, I'll demonstrate the concepts by implementing a custom example.
I assume that you're already aware of the built-in Laravel authentication system as that's something essential in order to understand the concept of authorization. Obviously, the authorization system works in conjunction with the authentication system in order to identify the legitimate user session.
The article starts by introducing some of the basic approaches the framework takes to authorization handling and where gates and polices fit in. It then gets into the details of each including example code showing how to define them based on the interfaces provided. The tutorial then shows how to put them to use in a simple application, applying them at both the controller and view level.
On the Master Zend Framework site Matthew Setter has posted a new tutorial showing you what it takes to get started using Zend Expressive. The article is more about the environment the framework would live in (well, the application written with it) than the actual framework itself.
Ever thought that it's hard to get started with Zend Expressive? Ever think you need to know Vagrant, Ansible, Docker, Puppet, Linux, and more? Nope, you don't! In this post, I'm going to show you that, while these tools can help, if you’re just getting started with the framework (such as learning about it), you don't need them.
I want to be clear, before we go any further, that I’m not talking about doing fully-fledged development. [...] So what I’m talking about here is when you’re just starting out and getting a feel for Zend Expressive, right up to building a test application. I’m not talking about a fully-fledged, deployed application that requires copious tests, one backed by a CI/CD pipeline.
He then talks a bit about the history of Zend Framework and how one of Expressive's goals it to help take some of the sting out of using it. Following this he covers some of the possible tooling you could use including two environment tools: Docker (useful but not required) and Vagrant (handy but also not a must). Finally he gets to the actual requirement - a version of PHP 7 installed on the system. He shows how it, along with its included web server, can be used in development to host an Expressive site by itself.
Mark Baker has an interesting post to his site where he shares a suggestion for making it easier to create unit tests for some of the more difficult parts of your unit tests. In the article he shows how to extend final classes and methods by manipulating the AST (abstract syntax tree structure) of the current code under test.
We know that we should always write unit tests for our code, and mock dependencies; but that isn’t always easy when we need to mock classes define as final, or that contain final methods. This isn’t normally a problem when we’re only working with classes within our own libraries and applications, because we control whether they are final or not, and we can type-hint these dependencies to interfaces. However, when the dependencies that we use are from external libraries, we lose that control; and it can become harder to test our own classes if we do need to mock final classes and they haven’t been built to interfaces.
He talks about how one tool, Mockery, allows some of this with its functionality but can still cause issues when mocks are passed instead of actual class instances. He then starts on a solution he has been trying to implement - a mocking library that makes use of the PHP_Parser package to make it possible to modify the structure of the code itself, not just put a wrapper (mock) around it. He includes a bit of code showing how to use that and the BetterReflection library to do some class introspection, locate files for testing and how to the tool to "de-finalize" a class (make it no longer "final").
With the final release of PHP 7.2 coming on the horizon the Exakat blog wants to be sure you and your code are prepared for some of the changes. In this new post they share things to change and improvements to expect in this latest version of the PHP language.
PHP 7.2 is around the corner, and shall be out soon, thanks to the hard work of @RemiCollet), Sara Golemon (@saramg) and countless others that run tests and submit bug reports. PHP 7.2 is already RC6, and the documentation has even been updated : it is high time to get ready for PHP 7.2.
We have been hard at work, at @Exakat, to prepare the migration analysis. This is our take on this upcoming task.
He's broken the changes coming down into a few categories based on the actions required and what you can do to prepare: Know, Lint, Static (Analysis), Unit testing and Logging. A chart is then included showing each of the changes, which category they fall into and links to more information about them and what has been updated (or added).