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.
Following up on his previous post about anonymous classes and a factory to generate them, Mark Baker has posted about the results of some additional research he’s done on the topic and four options he’s come up with.
A week or so ago, I published an article entitled “In Search of an Anonymous Class Factory” about my efforts at writing a “factory” for PHP7’s new Anonymous Classes (extending a named concrete base class, and assigning Traits to it dynamically); and about how I subsequently discovered the expensive memory demands of my original factory code, and then rewrote it using a different and (hopefully) more memory-efficient approach.
Since then, I’ve run some tests for memory usage and timings to assess just how inefficient my first attempt at the factory code was, and whether the new version of the factory really was better than the original.
His four options that finally worked somewhat as he’d wanted were:
- A factory that returns an instance of a concrete class using the traits he wants
- A factory that returns an anonymous class extending a concrete class that uses the traits
- His original Anonymous Class factory and extending the result with the traits
- His second version of the Anonymous Class factory that creates the instance, caches it and returns a clone
He also includes the code he used to run the tests of each factory method and shares some of the resulting benchmarks (with a few surprises).
In this recent post to his site Adam Wathan about writing your own custom test doubles (fakes) to help make your tests cleaner and improve their overall readability/maintainability.
Once in a while I run into a situation where trying to use a mocking library hurts the readability of my test. For example, say I’m building out a basic user registration flow where someone signs up and receives a welcome email. […] To test that an account is created correctly, I can make a request to the endpoint and verify that the new account exists in a test database. […] This covers creating the account itself, but what’s the best way to test the welcome email?
He goes through a few of the options that could be used to test this including using Mockery to replace the mailer class with a spy or actually sending emails. There’s downfalls to both of these methods and he suggests using a custom "fake" where the mailer class is swapped out with an "in-memory" option with the same kind of interface. He does point out a few issues with this method, however, and offers a few tips to remember when using them.
The Scotch.io site has a tutorial they’ve posted showing how to prototype a site quickly using Laravel and its built-in server/SQLite support.
If you are a seasoned Laravel developer, you know the usual project setup drill that involves creating a new project, a fresh database, and adding a virtual host entry to Apache.
If you are starting from scratch, the Apache and MySQL installation can take some time and slow things down for you. However, I will show you how you can jump start your Laravel development without Apache and MySQL.
The tutorial shows you how to use the internal PHP server to host the application, run a Laravel site inside it and integrate SQLite as the database. Each section comes with some example code and the commands/configuration you’ll need to make the system work. They also take a "deep dive" into Larvel’s
serve command and how it bootstraps the Laravel instance for the PHP built-in server. The post ends with a look at switching back to MySQL and a comparison of SQLite vs MySQL (as well as using SQLite for production).
On the QaFoo.com blog they’ve made a recommendation in their latest post – they suggest that you never use null.
When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.
Let’s go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.
They talk about some of the most common uses they see for using
null in PHP applications including setters for class properties (injection). They point out that in PHP 7 a missing value on a property would result in a Fatal error and make the functionality harder to test overall. They suggest that all required dependencies be injected on object construction instead, making it easier to know the current state of the object on testing. They also talk some about using
null as a return value, how it could make debugging difficult and a solution that could make more sense – throwing an exception instead.
On the Viva64.com site they’ve posted the results of their own evaluation of PHP 7 in terms of both the source of the language itself and the libraries it makes use of.
Sometimes checking a project one more time can be quite amusing. It helps to see which errors were fixed, and which ones got into the code since the time it was last checked. My colleague has already written an article about PHP analysis. As there was a new version released, I decided to check the source code of the interpreter once again, and I wasn’t disappointed – the project had a lot of interesting fragments to look at.
They start with a brief look at PHP 7 including when it was released, some of the features/functionality included and the tool they used to do the analysis. They talk about some of the difficulties in the analysis process and how the widespread user of macros tripped it up a bit. They includes some code examples from PHP’s source and the warnings that their PVS-Studio returned. The post ends with a brief look at the third-party libraries PHP uses and the responsibility the project takes in including them.
The SitePoint PHP blog has a post to their site introducing SparkPost, an email delivery service (in the same vein as Mandrill) that you can hook into your PHP applications to prevent the need to run your own mail servers.
I’ve used Mandrill for as long as I can remember. It sends transactional email, like the kind you receive when you sign up for a new account. Like me, many have been happy to use a free account for sending a relatively low number of emails a month. That is, until recently, when Mandrill caused a bit of a stir. The heart of the matter is that Mandrill removed their free tier. Anybody wishing to send mail through Mandrill now requires a paid-for MailChimp account
[…] Mindful that people are looking for alternatives (to power their personal newsletters or whatever), I spoke to Aydrian Howard. Aydrian is the Developer Advocate at SparkPost, whom I met at FluentConf. We talked for a bit about SparkPost and what makes it different from MailChimp.
After the little bit of Q&A about the service, the tutorial gets in and shows you how to get SparkPost set up for your application. They help you install their own client library and send a first test email using your account. Code is provided showing the configuration of the client with your key and the options you can define when sending the message.
The ZendCon conference has just announced the opening of the Call for Papers for their 2016 event. The conference will once again be happening at the Hard Rock Hotel and Casino in Las Vegas, Nevada in October (18th-21st).
We’re pleased to announce the ZendCon 2016 PHP Conference, the most anticipated PHP centric event of the year, where community and enterprise PHP developers from around the world gather to share and learn the latest hot trends and technologies in today’s professional PHP development.
We know speakers are key to the success of a conference and hope you will submit a talk. In appreciation for the efforts provided, our speakers package ensures they will not need to worry about anything other than delivering the best talks.
They’re not just looking for PHP topics either. They’ll consider a wide range of topics including PHP frameworks, devops, source control, continuous delivery and many more. The Call for Papers ends May 31st, 2016 so be sure to get those submissions in early (and often) before time runs out.
Christian Mackeprang has a new post to his site with some of his thoughts on why software estimates are impossible in any realistic project development process.
When you, as a programmer, start a new project, you will often not know full well how to do it, for many reasons. But you are a professional, and you’ve completed similar tasks in the past, so you either try to figure it out, or find someone who can, and ask them how, or just google it.
[…] The problem comes down to the difference between tasks which require a lot of thinking, and routine tasks which you already have some practice with.
He gives an example of solving a Rubik’s cube, how most people take a very long time to figure it out but there are some that can do it in a matter of seconds. He talks about unexpected complexity and how that can blow previous estimates out of the water. He points out that complexity can be cumulative (related to the number of tasks) and the difference between creative and mechanical tasks.