Matthias Noback has written up an article on his site covering a tool that's common in many web applications, especially for testing: fixture data. In the post he makes some suggestions about effective ways to use them to provide more "real world" results for tests.

System and integration tests need database fixtures. These fixtures should be representative and diverse enough to "fake" normal usage of the application, so that the tests using them will catch any issues that might occur once you deploy the application to the production environment. There are many different options for dealing with fixtures; let's explore some of them.

He makes four suggestions of ways to handle fixtures:

1. Generate them the "natural" way via interaction with the application and taking a snapshot of the data.
2. Generate them at runtime for the tests, reloading them each time
3. Manual insertion of custom data into the database for all tests
4. Manual insertion of custom data into the database for each test case

He finishes the post by asking a question for those considering using fixture data: do you need them at all? Testing should be isolated from external sources so maybe they're not really needed...

In a new post to his site Matthias Noback shares some of his recent experience working with a multi-tenant application and the current "contexts" that exist during the user's session. In the most he makes some suggestions about how to generate this context on each request without having to resort to a "data clumping" approach.

In the beginning we start out with a framework that has some authentication functionality built-in. We can get the "current user" from the session, or from some other session-based object. We'll also need the "current company" (or the "current organization") of which the current user is a member.

In the web controller, we take this information out of the session (which we can possibly reach through the "request" object passed to the controller action as an argument). Then we start doing the work; making queries, making changes, sending mails, etc. All on behalf of the current user and the current organization. [...] Soon this starts to feel like a code smell known as a Data Clump: the same data hanging around together.

He offers a few different steps to follow to make sure you're correctly implementing this functionality and not violating the SRP (Single Responsibility Principle):

• Injecting the session
• The Context class
• Passing contextual values on a need-to-know basis
• Fetching more data when needed

For each item on the list there's a paragraph or two explaining the changes and functionality with code examples included where necessary for illustration.

With the GDPR (General Data Protection Regulation) deadline looming on the horizon, there's no better time to make your applications compliant. Christoph Rumpel, a development lead on the Laravel-based Botman chatbot software, as posted a guide to help you ensure your chatbots are compliant.

Only one month left until the GDPR will take effect and people are already freaking out. If you haven't made yourself familiar with this topic, you need to do it now! This article will give you a summary of what you need to know and provide you with steps to make your chatbots GDPR compliant.

His article starts with a brief definition of what GDPR is and what it impacts. He then goes through and lists out some of the key changes that will have to be made to be in compliance including:

• Increased Territorial Scope
• Consent
• Process Personal Data
• Documentation

With those basics out of the way, he gets into the application of them in chatbot software. To make it easier he's come up with a listing of eleven questions to ask or steps to take to get you closer to compliance. For each he briefly describes it and provides some screenshots of the output from the bot that would be compliant.

Sameer Borate has a new post to his Code Deisel blog showing how to unpack binary data in PHP making use of the pack and unpack functions.

Working with binary files in PHP is rarely a requirement. However when needed the PHP ‘pack’ and ‘unpack’ functions can help you tremendously. To set the stage we will start with a programming problem, this will keep the discussion anchored to a relevant context. The problem is this : We want to write a function that takes a image file as an argument and tells us whether the file is a GIF image; irrelevant with whatever the extension the file may have. We are not to use any GD library functions.

He starts by briefly covering the "metadata" that binary files contain in their headers about the type of file and, more specifically, what the content for a GIF looks like. He follows this with an example of using unpack to provide a readable version of the file's binary content. He then uses this in an is_gif function to read the contents of a file, check the header format and ensure the version is either GIF87a or GIF89a. He also includes the code for another method to get attributes about the file like height, width and the aspect ratio. He ends the post with more details on the contents of the header and what each character means.

The Laravel News site has a tutorial posted that approaches a common development task - writing tests - from a data-driven approach rather than a strictly functional one.

Testing your code is an essential part of the development process, but sometimes it could also be expensive when you try to emulate many uses cases based on a set of different input data.

In many cases, you could end up with a massive directory of tests repeating the same block of code over and over for each possible user interaction.

They start with an example of a feature to test (Markdown parsing) and how traditional testing would have methods for each of the transformations. With a data-driven approach they turn the tests around and make use of data providers to set up the initial string, transformer to use and the correct result. Code is included showing an example of this kind of testing for the same Markdown parsing example and what a failure would look like in a dataset with multiple items.

On the Evozon blog there's a post that provides "a brief reality check to developers about GDPR" and how it effects them and their applications. GDPR (General Data Protection Regulation) is a regulation passed in Europe that enforces certain requirements about personal data and how it should be handled.

If you`re reading this, it means you`ve already heard about it or you`re about to receive some flash-news: there`s a new all-encompassing data privacy regulation in the EU. Ready or not, 25th of May 2018, the date when the General Data Protection Regulation (GDPR) becomes effective, will wait for nobody. If there’s any buzz around it, it`s because of a good reason: businesses will have to comply, software will have to evolve.

While there is still some uncertainty around certain parts, the article goes through some things you can do to help you prepare and make your application compliant including:

• discovering and documenting the purpose of the data that is being collected
• providing clear notification of data collection for the user
• define retention periods and deletion policies
• tracing any changes that happen with the data

The article does a good job providing a "checklist" of sorts you can use to ensure you're compliant. Of course, it's by no means an actual method of compliance but it does provide a good list to guide you in the right direction.

Alejandro Celaya? has a post to his site sharing some of his experience and advice about how to properly pass data from the outer layers of an app to the "use case" layer. In this situation, the "use case" layer is where most of the processing is happening (versus controllers, views, etc).

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

That's a task which is present in any kind of application and is very important to get properly done. You usually need to get data from different origins (a HTTP request, the input of the command line...), filter and validate it, and then use it to perform some kind of task.

He starts off by talking about some of his own previous attempts, starting with a tweet asking where filtering and validation should happen in applications. He then talks about a better approach that makes use of value objects for moving data between service layers. He then walks through a more real-world example (case study) making use of these value objects to handle a user password change.

In this post to his site Martin Hujer suggests that you don't use entities directly in your Symfony forms, opting instead for custom functionality to persist form data.

Let's start with stating that using entities for validation in Symfony Forms is widely used and widely recommend approach. Even the official documentation suggests it.

And I don't think it is a good idea! Why? [Three reasons:] an entity should be always valid, change [in the future and] layers separation.

For each of these downfalls he gets into a bit of detail about what the issue is and introduces the alternative: a custom data class. This class is then used to represent the data in the form with some simple assertions. He includes an example of this kind of class with three properties: title, content and public date. He then shows how to build a form using this class and how to handle updates, not just creates, with the same functionality.

Mohamed Said has an interesting post to his site showing how to use computed columns for faster lookups in a MySQL database containing JSON documents.

Laravel 5.3 is shipped with built-in support for updating and querying JSON type database fields, the support currently fully covers MySQL 5.7 JSON type fields updates and lookups.

He includes an example of using the Eloquent DB handling to search for the data in the JSON and the results. He links to more information about the feature, following it up with an example of the main topic: computed columns. In it he shows how to create (on the SQL side) a generated/computed column that allows for easier extraction of the data directly from the JSON. This makes it even simpler to get the data just as you would in a normal select. He also includes an example of creating it via the Schema functionality in the database migrations.

On the Zend Framework blog there's a new post from project lead Matthew Weier O'Phinney covering REST representations in Expressive and the release of two new components to help with their implementation.

We've been working towards our various Apigility on Expressive goals, and have recently published two new components: zend-problem-details and zend-expressive-hal.

These components provide response representations for APIs built with PSR-7 middleware. Specifically, they provide: Problem Details for HTTP APIs (RFC 7807) and Hypertext Application Language (HAL).

These two formats provide both JSON and XML representation options (the latter through a secondary proposal).

The post then goes on to talk about the idea of "representations" and how it relates back to the structure of the data returned and how the user knows what operations they can take on it. He also talks about the differences between normal responses and errors and gives example output helping to illustrate his points. The remainder of the post gets into the details of the two new components, their use and how to implement them in Expressive.