On the SitePoint PHP blog there’s a new tutorial posted showing you how to use the Halite package to encrypt the contents of emails. The Halite library sits on top of the libsodium functionality to provide tested, hardened cryptographic results.
Cryptography is a complex matter. In fact, there is one golden rule: „Don’t implement cryptography yourself.“ The reason for this is that so many things can go wrong while implementing it, the slightest error can generate a vulnerability and if you look away, your precious data can be read by someone else.
[…] Some libraries out there implement cryptography primitives and operations, and leave a lot of decisions to the developer. […] Nevertheless, there is one library that stands out from the rest for its simplicity and takes a lot of responsibility from the developer on the best practices, in addition to using the libsodium library. In this article we are going to explore Halite.
The tutorial then starts of helping you get the libsodium package installed on your system (assuming it’s unix-based). They then start on the sample application – a basic "email" client able to send/receive messages between users. They set up RESTful endpoints to get the messages, use the Doctrine ORM for a database interface and show the use of the Halite
Crypto class to encrypt/decrypt the message contents.
Matt Stauffer has a new post to his site where he’s put together an in-depth look at Laravel Echo, a feature included in newer versions of the framework that makes it easy to integrate websockets into your Laravel-based application.
A few weeks ago, Taylor Otwell introduced another branded product within the Laravel line: Laravel Echo. So far, the only coverage it’s gotten has been his Laracasts video intro, but I recently wrote it up for my book and wanted to share that with you. What follows is an excerpt from Laravel: Up and Running, heavily modified to make sense in a blog format.
The TutsPlus.com site has posted the next part of their series showing the use of the PHP CodeSniffer tool with WordPress. In the first part of the series they introduced "code smells" and build on that in part two with the installation and use of PHP CodeSniffer to detect these smells.
In the first article of this series, we defined code smells and looked at a few examples of what they are and how we may refactor them so the quality of the code is improved.
[…] Ultimately, we’re working towards implementing WordPress-specific code sniffing rules, but before we do that it’s important to familiarize yourself with PHP CodeSniffer. In this article, we’re going to take a look at what PHP CodeSniffer is, how to install it, how to run it against an example script, and how to refactor said script. Then we’ll look at how we’re going to move forward into WordPress-specific code.
The tutorial then shows you how to get the tool installed using Composer, not the PEAR method. They help you install Composer then create the simple project with a
composer.json configuration file defining the dependency. They provide a sample bit of code to run the analysis against and an example of the output showing violations of the coding standard.
Jordi Boggiano has posted some updated statistics around the use of the Packagist site around PHP version requirements and the relation of package downloads to PHP versions.
Last year I posted stats about PHP versions, and the year before as well, both time in November. However this year I can’t wait for November as I am curious to explore the PHP7 uptake!
A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last 28 days for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.
He compares the previous statistics against the ones gathered back in November 2015, both in numbers and graphs. He shows the stats for the PHP versions being used and for the PHP versions that are required. It’s interesting to see that there’s been a good uptick in supported versions including PHP 7.0+.
On the SitePoint PHP blog there’s a new tutorial posted from Bruno Skvorc showing you how to use Nitpick CI to "nitpick" over coding standards and rules in your PHP code.
There are many ways to make sure your code respects a given code standard – we’ve covered several before. But enforcing a standard team-wide and making sure everyone knows about mistakes before they’re applied to the project isn’t something that’s very easy to do. Travis and Jenkins can both be configured to do these checks, but aren’t as easygoing about it as the solution we’re about to look at: Nitpick CI.
He starts by getting a sample project bootstrapped and pushes it up to GitHub so the Nitpick service can access it. He then switches over to the Nitpick side and shows the setup of an account and a new project pointing to the newly created repo. He then includes the process and results of two kinds of pushes: non-code (README update) and both a valid/invalid code update. He shows examples of the comments the Nitpick service makes directly on the code and a patch to fix the issues.
The Toptal.com blog has posted a new tutorial that wants to help you make the most of your application via testing. They show you how to use Codeception to create a set of tests to ensure your application is working as expected.
Before moving on to Codeception and PHP, we should cover the basics and start by explaining why we need testing in applications in the first place. Perhaps we could complete a project without wasting time on tests, at least this time?
Sure, you don’t need tests for everything; for example, when you want to build yet another homepage. […] However, you definitely do need testing when: your team uses BDD/TDD, your Git repo contains more than a couple commits, [and] you are a proper professional, working on a serious project.
They start with a look at the kinds of things testing solves in your development process and the different kinds of tests you can create. From there they introduce Codeception, an alternative testing tool to the widely used PHPUnit. The tutorial helps you get it installed and shows you how to make a simple, first test. It helps you execute the test, debug issues that might pop up and the different assertions you can use. With the fundamentals in place, they move on to more details on using it for functional and unit testing.
The Laravel News site has posted the latest episode of their podcast covering Laravel Echo, Valet and the PHP-FIG "implosion".
In this twenty-two minute episode, we talk about Laravel Echo and new changes to Laravel Valet.
You can listen to this latest episode either through the in-page audio player or by downloading the mp3 of the show for offline listening. If you enjoy the show and want to hear more, be sure to subscribe to their feed and get the latest as they’re released.
In this new tutorial Zsolt Szende talks about dependency injection and how to handle objects and related needs at runtime rather than the pre-configured method that some injection containers/systems have defined.
In this short article I would like to demonstrate a way to inject dependencies that are not known until runtime. There are many use cases for this and in essence it is about choosing between concrete implementations of some common interface. In object oriented design this is known at the Strategy pattern. The choice itself can be made in various ways, for example via a configuration option or a command line parameter in case of a console command, and I think the dynamic nature of the choice is the most interesting part of the pattern.
The article provides a practical example of an XML/JSON reader pulling information from an external source. A simple interface is defined and two implementation classes put it to use. Then the "command" pattern is used to apply it to an executable script and how injecting a reader type directly overrides the one from the provided option. This is taken a step further and refactored into a "resolver" to determine the best logic to apply based on the input argument.