On the TutsPlus.com site they've posted a tutorial showing you how to use a CRUD generator tool to automatically generate some of the create, read, update, and delete functionality for your application.

In this article, we’re going to review PDO CRUD - a form builder and database management tool. PDO CRUD helps you build forms for your database tables with just a few lines of code, making it quick and easy to bootstrap a database application.

[...] Today, we’re going to discuss the PDO CRUD tool, available at Code Canyon for purchase at a very reasonable price. It’s a complete CRUD builder tool which allows you to build applications by just providing database tables and by writing a few lines of code.

It works with multiple database back-ends, including MySQL, Postgres and SQLite. In this article, we’ll see how to use PDO CRUD to build a CRUD system with the MySQL database back-end.

They then walk you through the installation and configuration of the tool, defining options about the host, username, and password for the database. It then helps you create two tables that will be used as sources: employee and department. Once these are defined, you can then use the web frontend to perform CRUD operations on these tables without having to write any custom code. It also lists out some of the additional features including searching, pagination and bulk export.

The post goes on to talk about how to make modifications to how the system works with the data in the tables (like field types), creating join views and customizing the options for other tool features.

Matthias Noback has a tutorial posted to his site sharing his thoughts on when adding an interface to a class is useful. Here he's talking about using interfaces as a structure for your application, making it easier to understand and more structured.

I'm currently revising my book "Principles of Package Design". It covers lots of design principles, like the SOLID principles and the lesser known Package (or Component) Design Principles. When discussing these principles in the book, I regularly encourage the reader to add more interfaces to their classes, to make the overall design of the package or application more flexible. However, not every class needs an interface, and not every interface makes sense. I thought it would be useful to enumerate some good reasons for adding an interface to a class. At the end of this post I'll make sure to mention a few good reasons for not adding an interface too.

He then offers five suggestions of cases where an interface makes sense:

• If not all public methods are meant to be used by regular clients
• If the class uses I/O
• If the class depends on third-party code
• If you want to introduce an abstraction for multiple specific things
• If you foresee that the user wants to replace part of the object hierarchy

For each item in the list he provides a summary of the suggestion and some code snippets to back it up. He ends the post with a recommendation about how to handle most other situations where you think an interface might be useful: use a "final" class instead.

In a post to his site Robert Basic makes an interesting suggestion about older codebases (legacy code) and how they should be handled. He suggests treating legacy code like 3rd party code.

Within the TDD community there’s an advice saying that we shouldn’t mock types we don’t own. I believe it is good advice and do my best to follow it. [...] This hidden advice is that we should create interfaces, clients, bridges, adapters between our application and the 3rd party code we use.

[...] What if we start looking at our legacy code the same way we look at the 3rd party code? This might be difficult to do, or even counterproductive, if the legacy code is in a maintenance-only mode, where we only fix bugs and tweak bits and pieces of it. But if we are writing new code that is (re)using legacy code, I believe we should look at legacy code the same way we look at 3rd party code, at least from the perspective of the new code.

He suggests that legacy code and new code should live in different parts of the application's structure and that, in order to use the legacy code, the new code should use interfaces to it rather than using it directly. He gives an example, showing the use of a User class from the legacy code and interfaces that could be used from the new code to work with it.

Matthias Noback has continued his series about "mocking the edges" in your unit testing with this new post. In it, he talks about mocking "the network", those places where your application reaches out to external services to access data or perform other operations.

In this series, we've discussed several topics already. We talked about persistence and time, the filesystem and randomness. The conclusion for all these areas: whenever you want to "mock" these things, you may look for a solution at the level of programming tools used (use database or filesystem abstraction library, replace built-in PHP functions, etc.). But the better solution is always: add your own abstraction.

[...] The same really is true for the network. You don't want your unit tests to rely on a network connection, or a specific web service to be up and running. [...] The smarter solution again is to introduce your own interface, with its own implementation, and its own integration test. [...] Though this solution would be quite far from traditional mocking I thought it would be interesting to write a bit more about it, since there's also a lot to say.

In his example he shows the use of a file_get_contents call to fetch stock information. He introduces a ExchangeRateService interface with a getFor method to provide structure for the "wrapper" around the network call. He then covers the idea of an "anti-corruption layer" to change up the interface to use models instead of just a string value (code included). He ends the post talking about the inversion of the dependency - the option to have a job pull the value out-of-band and then have the application use that value.

Romans Malinovskis has a post on his Medium.com site sharing what he calls a "pragmatic approach to reinventing ORM" with his thoughts about a different approach to this commonly used database interface.

It’s been over a year, since I posted my first highly debated post on Reddit: Reinventing the faulty ORM concept. Gathered information helped me design and implement an alternative pattern to ORM with many important advantages and that has reinforced my belief that ORM is faulty.

He's broken the article up into a few sections with details and thoughts for each along the way:

• Why ORM is important?
• Why ORM is broken?
• How Agile Data differ in approach?
• How Agile Data qualify production/enterprise use?
• Notes on architectural decisions in Agile Data (OOP vs Decoupling)

That final section focuses mostly on the decoupling aspect and the Agile Data library (a Data Mapper) that can be used and solves some of the common ORM problems he mentioned in the earlier sections.

Robert Basic has a post to his site covering interfaces and their use in PHP, including what to consider when creating effective interfaces.

Creating and implementing interfaces in our code is important. It helps with swapping out components, eases testing, separates the what from the how.

But, it’s not enough just to slap an interface on a class and be done with it. We also need to consider on what are we putting that interface on.

He starts with an example of a feed (RSS) reader where an interface defines a queue handler with an add method. Eventually he makes some decisions and implements the queue in a concrete class but points out that there's something "fishy" about the example. He covers the three issues he sees including the class doing two things and how it locks the functionality into the queue. He refactors the example, abstracting things out to more correctly adhere to the Single Responsibility Principle and split out the database handling from the queue functionality.

Sergey Zhuk has written up a tutorial showing you how to implement promise-based caching with ReactPHP, a continuation of a previous post.

In the previous article, we have already touched caching (when caching DNS records). It is an asynchronous promise-based Cache Component. The idea behind this component is to provide a promise-based CacheInterface and instead of waiting for a result to be retrieved from a cache the client code gets a promise. If there is a value in a cache the fulfilled with this value promise is returned. If there is no value by a specified key the rejected promise returns.

He starts by defining the caching interface and how it would look in use to set/get a cache value. He shows how to update this with a "done" handler to output the value when the get is complete. He continues on showing how to use a fallback handler: either "otherwise" or "then". He also shows how these can be chained together to make more complex operations. The post ends with an example of this caching component in action and links to other library that use the same ideas.

On the Zend Framework blog they've posted a tutorial from project lead Matthew Weier O'Phinney showing how to use the Diactoros package to create response emitters. These emitters are just methods of output related to HTTP handling (like headers, response codes and normal text output).

When writing middleware-based applications, at some point you will need to emit your response.

PSR-7 defines the various interfaces related to HTTP messages, but does not define how they will be used. Diactoros defines several utility classes for these purposes, including a ServerRequestFactory for generating a ServerRequest instance from the PHP SAPI in use, and a set of emitters, for emitting responses back to the client. In this post, we'll detail the purpose of emitters, the emitters shipped with Diactoros, and some strategies for emitting content to your users.

He starts by describing what "emitters" are in the context of PSR-7 applications and shows the code definition of the EmitterInterface, the base of all emitter classes. After covering some of the emitters that Diactoros includes he shows how to create one to emit file information and how you can mix and match them in a emitter "stack" to perform more that one operation on the output.

In a new post to his site Paul Jones shares some of his thoughts about microframeworks, suggesting they're more "user interface" frameworks. Basically he suggests that microframeworks work best for the UI level handling and that possibly a second, more robust framework should be used for the application backend.

When we talk about “full stack” frameworks, we mean something that incorporates tools for every part of a server-side application. [...] Examples in PHP include Cake, CodeIgniter, Fuel, Kohana, Laravel, Opulence, Symfony, Yii, Zend Framework, and too many others to count.

When we talk about “micro” frameworks, we mean something that concentrates primarily on the request-handling and response-building parts of a server-side application, and leaves everything else out. [...] If the user interface is the request (as input), and the response (as output), that means micro-frameworks are not so much “micro” frameworks, as they are “user interface” frameworks.

He suggests that, if these statements are true, then microframeworks should be considered "user interface" frameworks. He makes suggestions of splitting things out into "containers" of functionality with the microframework taking care of user interactions while a second handles domain and infrastructure concerns.

On the Laravel News site today they have a post announcing a new member of the Laravel family that was announced at the current Laracon conference: Laravel Horizon.

The moment everyone in the Laravel community has been waiting for has finally arrived! Laravel Horizon is software to “supercharge your queues with a beautiful dashboard and code-driven configuration.”

[...] Laravel Horizon is designed to make it easy monitor your queues from a web interface and receive notifications when things go wrong.

They list out some of the key features including auto-balancing, code-driven configuration, queue monitoring and a notification system. They briefly describe each of these features and what they see as the "most awesome part" - that the entire thing is open source and 100% free.