In a new post to the Paragon Initiative blog Scott Arciszewski has shared a helpful reference for those that might be a little confused by the naming and functions involved in the use of libsodium in PHP. In this quick reference he lists out each of the functions, what type they are and an example use case.

Last Friday at Day Camp 4 Developers, I presented a talk titled Cooking with Sodium in PHP 7.2, which was largely live-demoing the various cryptography features provided by libsodium. One of the questions I was asked by attendees was about knowing which feature to use to solve specific problems. This is the sort of problem that I suspect many people run into, so here's a quick reference table followed by a detailed explanation.

In the table below, all encryption modes utilize authenticated encryption.

Following the quick reference table he then gets into more detail on each of the functions, describing in depth what they're for and examples of how to most effectively use them.

On the Laravel News site they've introduced a package from Adam Wathan that cam help simplify the use of the popular Guzzle package for making HTTP requests. Zhttp is a wrapper around Guzzle and tries to make the code to make the requests simpler and easier to follow.

Zttp is a new PHP package by Adam Wathan that is a Guzzle wrapper designed to bring an expressive syntax and simplify common use cases. [...] Zttp simplifies the code to make the request and automatically returns the JSON response.

A few other examples of requests using the tool are provided: POSTing with parameters, sending a PATCH/PUT request, adding an Accept header and how to prevent the request from following redirects. You can find out more on the project's GitHub repository and grab the latest release to try out in your own code.

Loïc Faugeron continues his series of "Mars Rover" tutorial posts with the latest covering the driving of the rover.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES), Test Driven Development (TDD)

We just finished developing the first use case, so we can now get cracking on the second one, driving the rover.

As is tradition in this series, he starts with the phpspec testing, defining the DriverRover spec requiring driving instructions to be provided. He generates the code for it and fills in the brief functional details handling the instruction property. He also adds in some validations as far as what instructions it can be given and re-runs the tests to ensure they all pass.

In an article on Thedo.fr Tristan Roussel introduces you to some of the concepts behind Clean Architecture based on a talk he recently attended at a local Symfony user group.

One particular talk retained my attention and I want to tell you about it. Let me warn you first, this is just an introduction, and I’m not going into much detail, don’t hesitate to post comments if you feel something is not clear, or deserves a better exposure! [...] So. What is Clean Architecture? It’s so fresh that it doesn’t even have a Wikipedia article.

He starts off with what the idea of Clean Architecture is trying to accomplish and where some of the ideas have evolved from. He includes some of the objectives and guiding principles as well as a diagram of how this architecture might be laid out. He gets into an actual use case for this type of structure and where abstract entities, controllers and presenters fit into the picture. He links to some of the code as provided as part of the presentation and some of the things to consider when trying it out for your application.

On the Symfony blog today they've posted a use case that talks about Symfony meeting some high performance needs and some of the development that was done to make it happen.

For most people, using full-stack frameworks equals slowing down websites. At Octivi, we think that it depends on correctly choosing the right tools for specific projects. When we were asked to optimize a website for one of our clients, we analyzed their setup from the ground up. The result: migrate them toward Service Oriented Architecture and extract their core-business system as a separate service. In this Case Study, we'll reveal some architecture details of 1 Billion Symfony2 Application. We'll show you the project big-picture then focus on features we really like in Symfony2. Don't worry; we'll also talk about the things that we don't really use.

They start with some of the business requirements they needed to meet and how it influenced the overall architecture of the application. They cover some of the things they liked the most about using the framework including bundles and using the EventDispatcher component. Some example code is also included for the custom handling they created for routing, CLI commands and request handling. There's also a mention of using the Profiler, Stopwatch and Monolog trio to do some performance analysis on the resulting application. Finally, there's a brief mention of some of the tools they're not using and why (two of them): Doctrine and Twig.

In his latest post Michael Dowling looks at a recently proposed PSR standard (the HTTP message one, created by him) and some of his thoughts around it and what it could do for the community.

There's been a lot of talk lately about the PSR HTTP message proposal, PSR-7. The purpose of the proposal is to create a shared interface that can be used by projects to interact with HTTP messages for both clients and servers. When I created the proposal, I envisioned the purpose is not to say projects that utilize HTTP messages need to make breaking changes to use the proposed interfaces, but rather give projects an interface for which they can create an adapter.

He points out that the major part of the proposal that's being debated is the message body methods and structure. He gives a quick overview of this API and how streams could fit in with it, providing a flexible abstraction layer over the actual data. He includes a few ideas for some functionality that could make streams work relatively easily with the proposal (using a StreamInterface):

• No Auto-registering of stream protocols and filters
• Exceptions cause warnings in stream wrappers and filters
• Functionality is spread over many functions

He also shares an example (based around the Guzzle HTTP library) showing how this interface could be put to work. He also talks some about one of the major concerns voiced right now, getting the actual stream itself to work with, and shows how the "detach" method matches this goal.

In Lukas Smith's latest post he looks at one of the magic methods that's built into PHP to help transform objects into strings - the __toString method. In the post he explores what it's for and what it might be used for.

The __toString() belongs to the family of methods and functions called "magic functions". They are magic because for the most part they do not get called explicitly but rather intercept operations. Unfortunately there are limits to its magic, specifically the only "context" the method is aware of is its design contract: to return a string. But its not clear what purpose that is. Should this be for some internal debugging or logging purposes? There one would be most interested in internal identifiers and object state. Is it for some frontend UI where the user will most likely be interested in some textual identifier that isn't too long as to not clutter the UI. There in lies the dilemma in the magic, while useful there is no way to ensure that the given context is passed on.

He looks at use cases for UI output (for consistent output) and contexts as well as the more internal-facing usage, like for logging and debugging purposes. Being able to get the context of the object as a string and pushed into a log at the time of error could be immensely helpful for debugging. He also links to some discussions happening on Twitter about the internal versus external uses of this magic method.

Robert Basic has a new post to his blog today with an use case for Zend Framework 2's event manager to solve a problem he has with "repetitive code" in some of his models.

Basically, this allows us to have one piece of code to trigger an event and to have one or more listeners listening to this event. When the event gets triggered, the listeners are called and then we can do *something*, like caching or logging. Logging or caching. [...] See, that’s my problem. All the event examples stop at logging and caching. Truly there must be some other example for which this event stuff can be used for.

In his example code, he's used the EventManager in one of his models to add listeners to validate the post and "slugify" the post's title for use on the URL. You can find his code on github if you're interested in the full implementation.

On PHPMaster.com today there's a new article emphasizing something that lots of developers forget to make a part of their process when writing code - creating useful documentation to help make your code that much clearer.

If you’re writing code that will be shared with others, put yourself in their shoes. Don’t let your project lose potential users, community members, and possible contributors all because of insufficient documentation.

He (Matthew Turland) suggests a few things to keep in mind as you're writing up your documentation - the content is "king" (an emphasis on good descriptions/examples/use cases), open it up to external contributions using things like wikis (or even stored in the source code repository) and a focus on technical writing skills. Even the best tools out there can suffer if there's poor or no documentation.

Timothy Boronczyk has posted about an interesting concept you could use in your applications - currying (made possible in PHP 5.3.x and above):

What happens if you don't have all the arguments handy for a function, but you want to give whatever arguments you do have now and then provide the rest of them to the function later? This is called currying, and is a core concept in functional programming. It's messy, but possible to curry functions in PHP now that closures have been added.

He starts with an example from OCaml/F# to illustrate the point and moves to a PHP example - changing a normal function that requires three parameters into one that makes it possible to only submit the parameters you'd want to use. He also includes a more "real life" example of how it could be used in array filtering.