Rob Allen has published another post covering the use of serverless technology and PHP to run your applications. In this new post he shows how to use img2lambda to publish your Serverless PHP layer out to an AWS Lambda instance.

[The] img2lambda tool will take the layers of a Docker container and convert them to AWS layers for use in Lambda.

I poked around with Clare’s example and updated my lambda-php project in order to understand how it works. I also rewrote my runtime’s bootstrap to make it clearer.

The clever thing from my point of view is that you can build your PHP runtime layer locally using Docker and then publish the layers to AWS for use in your Lambda functions. This means you can now use the layer in different projects and have them all reference the same PHP runtime.

He digs deeper into the tool, looking at the "magic" happening under the covers using Docker. He provides an example of the Dockerfile it creates and walks through what it does. He then shows how to create the layer in AWS and use a serverless framework and a PHP runtime to execute the "hello world" application. He wraps up the post showing how to test it locally, building from the Dockerfile and using a docker run on the result with simple user input.

Tomas Votruba has a tutorial posted to his site showing you how to update your Symfony application to make all of your services use auto-discovery rather than hard-coded configuration settings.

Do you use Symfony autodiscovery services registration everywhere and your configs have no extra lines? Skip this post and rather read another one.

But if you have many configs with manual service registration, tagging, and autowiring, keep reading. I'll show you how you can convert them easily be new Symplify package.

He starts off by talking about a few e-commerce projects he's been working with lately that define service configurations manually. He then mentions a package that's been created to help convert these over easily to autodiscovery rather than having to change them one by one. He provides the instructions to use this package and mentions some of the things that could go wrong in the conversion process to keep an eye out for.

Based on the responses to a tweet he posted about the Have I Been Pwnd PHP package he created for PHP (found here), Michelangelo van Dam attempts to clear up how the package works in order to help calm some fears about how it handles passwords.

Yesterday evening I posted a Tweet about improving user entered passwords using Troy Hunt's service Have I Been Pwnd. [...] It went viral over night with many likes and retweets. But I also got a ton of questions regarding the usage and the security of this package. It turns out many people are scared to send passwords over the internet and are afraid to just use a package (like mine) for password checking.

In his post he explains how the password lookup works, sending only the first five characters of the hashed version of the password to the HIBP server (not the plain-text password). He includes a helpful graphic to illustrate the process and includes an example - not directly from the package - of how the request might work. His package makes it much simpler to perform this validation in your application.

The Laravel News site has posted the latest part of their "Building a Laravel Translation Package" series focusing on a pre-launch checklist of items to get in place before it's finally released.

In the last part of the series, we finished up building the Laravel Translation package. With this completed, we are ready to start thinking about releasing the it to the world. However, before we do, there are few important steps we need to take.

The post covers some of the final non-code items to take care of:

• Good documentation
• Defining contribution guidelines
• Providing issue templates for easier reporting of bugs/issues by others
• Selecting a license
• Setting up continuous integration for running tests, checking code style, etc.

Each item in the list includes a brief summary of what's involved and, for some, links to other resources and tools that can help get it accomplished.

In a post to his site Tomas Votruba introduces something that can be helpful for those working with Symfony 4 and Flex to make the "zero-setup configuration" easier to work with: effective use of the Symfony Flex Loader.

Symfony 4 and Flex is heading in direction of zero-setup configuration - no bundles, no extensions, no configuration. You already know how to get rid of Configuration. Flex now loads services instead of Extension class.

But it has an extra price, a lot of new boilerplate code in Kernel. Today you'll learn how to keep your Kernel Flex-ready and clean at the same time.

He starts with an example kernel that loads an extra directory (defined by a "custom path"). He shows how to refactor these examples to "make them small again" making use of the Flex loader package that reduces the number of lines required to accomplish the same end result.

On the Laravel News site they've posted the latest tutorial in their series covering the creation of a translation package. In this latest article they cover the creation of the database driver to replace the previous file-driven content handling.

In the previous article of the series, we talked about how to handle missing translations, which brings us very close to making the package feature complete. To finish up the build phase of this series, we will discuss how we go about adding a database driver.

Thanks to defining the interface for the data handling previously, redefining the handler for the database is simpler. He includes the code for:

• the migrations to create the languages and translations tables
• the models for both tables and their relations to each other
• creation of the database driver using the interface

His code includes methods for getting either single or multiple translations including fetching them by language. He then updates the "resolve" method to allow defining the driver to use in the configuration rather than being hard-coded.

The Laravel News site has published the latest part in a series covering the creation of a translation package for use in a Laravel-based application. In this new post they focus on how the package will handle missing translation keys.

In the last installment of this series, we talked about building the frontend translation management tool. In this article, we are going to move away from the frontend and follow the process of building another backend feature.

One of the most frustrating things about translation management in a Laravel application is forgetting to add translations to the corresponding language file. This has the undesirable result of either the translation key or the default language being rendered on the page rather than the translation for the current language.

To remediate this issue, they design the package so that it will search the whole project and return the keys that don't have translations currently defined. They walk you through the creation of this functionality complete with the configuration and code required to locate the missing translations and update the configuration to add them.

In a post to his site Tomas Votruba takes a look at the "rocket science" behind the migration of DocBlocks to typehints in your PHP application.

What if you could add scalar typehints int, bool, string, null to all parameter type and return type by running a CLI command? But also all classes, parent, self and $this?

Do you think it's an easy task to move @param int $number to (int $number)?

He talks about some of the current tools that handle the conversion of type-hints to type checks, but points out that some of them break the code (as they don't have the right context). He shares the results of some of his own research using these tools and issues that can come up with code changes. He also includes issues that could come up with the use of self/parent and namespacing. The post ends with some instructions on using the rector/rector package to handle this refactoring in a bit better way (including the configuration required).

In a recent post to his site Leonid Mamchenkov has shared a few links to packages that provide country and currency lists and a new one he's discovered that does an even better job.

Many software projects deal with the lists of countries and currencies. Some of the most common tasks include country an currency dropdowns, country flags next to the IP, or pre-filling country codes in phone numbers.

All of that information is of course standardized and you often just need a library or two to provide and use it. And there are many of those. [...] Today, however, I came across a better option – antonioribeiro/countries, which is a collection of country and currency information for Laravel PHP framework. Laravel is not required though.

The package, easily installable via Composer, provides information for over 250 countries and 250 different currencies. There's also flags, maps, states, cities and more. Check out the repository for the full list of data it offers.

Liam Hammett has written up a post to his site covering the use and creation of helpers for Laravel's Blade templating. He shows the use of a package he's created to help make using them with custom callbacks simpler.

Laravel’s Blade templating engine offers a ton of convenient directives you can use to make your view files beautiful and abstract anything that may be too complex or verbose to live inside HTML. It even gives a really handy way to add your own custom directives using the Blade::directive(…) method.

However, the callback in custom directives only receives a single parameter?—?the raw string expression from the view file. [...] As this seems to be the most common use case, I put together a package that attempts to help make these helper functions that little bit easier to define without the boilerplate of returning the string or having to consider what an expression may be when creating a directive.

In his package he introduces a new method that defines the name of the method and the name of the function to call. This second option can also be a custom callback function, making it even more flexible.