Loïc Faugeron is back again with the next part of his "Mars Rover" series of tutorials. In this new article he refactors the current code even more to make it more flexible in the long run.
In this series we’re going to build the software of a Mars Rover, according to the following specifications. It will allow us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD). Previously we’ve created a navigation package, and in it a LandRover class that validates input parameters for our first use case.
We’ve also started to refactor it by extracting coordinates in their own class. In this article we’re going to further refactor LandRover
He found that the coordinates could become floats (or have additional values) and that the orientation could become an angular degree/be vertical. To help this situation, he pulls this logic out into an
Orientation class. True to the TDD methods, he starts with the phpspec test and generates the skeleton class based on them. He makes some simple edits to make the tests pass and updates the main
LandRover class to use the new
Orientation class for these positions.
The PHP development group has officially announced the release of the latest alpha in the PHP 7.1.x series: PHP 7.1.0 Alpha 3. This is a preview release and should not be used for production applications.
The PHP development team announces the immediate availability of PHP 7.1.0 Alpha 3. This release is the last alpha for 7.1.0. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system.
This release includes new features including an Iterable type, HTTP/2 server push support, creating closures from callables and more precise float values. You can see the full list of additions and changes in the NEWS and UPGRADING files. If you’re interested in trying out this latest alpha, you can get the latest source release from here and the Windows binaries here.
The QaFoo blog has a post today about outside-in testing, two design patterns – Adapter and Facade – and how they relate.
As part of our workshops on Test-Driven Development we explain to our customers how testing from the outside-in can help find the right test-mix.
The technique puts a focus on test-driven-development, but instead of the traditional approach starts at the acceptance test level. The first test for a feature is an acceptance test and only then the feature is implemented from the outside classes first. […] Outside-In testing leads to interfaces that are written from what is useful for the client object using them, in contrast to objects that are composed of collaborators that already exist. Because at some point we have to interact with objects that exist already, we will need three techniques to link those newly created interfaces/roles to existing code in our project
These three techniques are:
- using the adapter pattern to interface with third party code
- the facade pattern to "layer" your own code
- continuous refactoring of interfaces/implementations
In this post they focus mostly on the adapter pattern. They show how to use it in interfacing with remote systems in a Symfony application (for example) based on a remote XML file. They also include the test to verify it’s functioning correctly and the PHP code to make the mocks and interfaces you’ll need for the test.
php[architect] Magazine has just published their latest issue for July 2016: Harnessing Magic. This latest issue features articles like:
- "RegEx is Your Friend" (Liam Wiltshire)
- "Removing the Magic with Functional PHP" (David Corona)
- "Implementing Cryptography" (Edward Barnard)
- "Reference Counting : The PDO Case Study" (Gabriel Zerbib)
There’s also all of the usual columns from some of the regular authors, the "Education Station", "Community Corner" and the "Security Corner". If you’re interested in the content but just want a sample, be sure to check out this month’s free article covering mailing lists and MailChimp. You can pick up either just this issue or a full year subscription directly from the php[architect] website.
In a new post to his site Stoimen Popov makes the recommendation to not call the destructor explicitly in your code and provides some alternatives.
PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++” says the documentation for destructors. […] Well, as you can not call the constructor explicitly […] so we should not call the destructor explicitly. The problem is that I’ve seen this many times, but it’s a pity that this won’t destroy the object and it is still a valid PHP code.
He talks about
__destruct and it’s role in PHP’s set of "magic methods" and what they exist to do. He then gets into a few examples of what code could look like that uses a destructor and the difference between normal handling calling the destructor explicitly. The main differences is that calling it explicitly does not destroy the object, it’s basically like calling any other method. He does include an interesting method for destroying the object – setting it to null – and notes that the destructor fires then too. He also points out a few interesting things about cloning objects and how object references work when setting nulls as in the previous example.
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+.