SitePoint PHPSourcehunt: Idea of the Month and 6 Interesting Repos! (21.2.2017, 16:57 UTC)

It's time for our monthly hunt for new open source libraries to use and contribute to!

If you're new to Sourcehunt, it's our monthly post for promoting open source projects that seem interesting or promising and could use help in terms of Github stars or pull requests.

It's our way of giving back - promoting projects that we use (or could use) so that they gain enough exposure to attract a wider audience, a powerful community and, possibly, new contributors or sponsors.

Sourcehunt logo


genkgo/archive-stream [5 ★]

We stumbled upon this package following this very interesting read about streamed file zipping and downloading in PHP.

This package provides a memory efficient API for streaming ZIP files as PSR 7 messages. It comes with certain limitations, namely that only the Zip64 (version 4.5 of the Zip specification) format is supported, and files cannot be resumed if a download fails before finishing, but apart from that, using it is incredibly straightforward if you're already wading through the PSR-7 waters:

$archive = (new Archive())
    ->withContent(new CallbackStringContent('callback.txt', function () {
        return 'data';
    }))
    ->withContent(new StringContent('string.txt', 'data'))
    ->withContent(new FileContent('file.txt', 'local/file/name.txt'))
    ->withContent(new EmptyDirectory('directory'));

$response = $response->withBody(
    new Psr7Stream(new ZipReader($archive))
);

The library, while having many contributors who have done a professional job of fool-proofing it, and being over 8 months old, lacks exposure. Oddly enough, there are no issues (the issues feature itself is disabled) and no PRs to review, but the authors could always use more testers, tech writers to present the lib in blogs, and maintainers.

How do you usually send ZIPs, if at all? Why not give this a go?

Continue reading %Sourcehunt: Idea of the Month and 6 Interesting Repos!%

Link
Adam CulpSetting up local step debugging with Zend Studio (21.2.2017, 14:30 UTC)

Setting up debugging in an IDE with a local PHP development environment has gotten so easy it can be done in a couple automated steps. In this post I will demonstrate how to get step debugging functioning with Zend Studio and Zend Debugger when the server is set up on a local environment.

To begin with, I had the following:

  • Local installation of Zend Server 8.5.+ (basic LAMP stack, but with Zend Debugger included in the Zend Server installation). Alternatively I could have had a vanilla LAMP environment with Xdebug.
  • Ensure that Z-Ray is active in the Zend Server settings.
  • A local project set up on Zend Studio, without the server set up in the Zend Studio project configuration. (in this example I have a Zend Expressive Skeleton ready)
  • The local project set up as an Apache virtualhost.

Ensure Zend Studio is running with the project we will debug open.

In a browser with the application rendered I click the debug icon in the Z-Ray toolbar at the foot of the window, and select the desired debugging action.

This will cause Zend Studio to prompt if we desire to use the Debug Perspective after it receives the debug connection from Zend Debugger. In most cases we can simply click Yes and let things happen normally.

That’s about it, we are debugging!

Closing

This was a very simplistic local development environment setup. We didn’t have a firewall to contend with, and the server was set up locally rather than inside a virtual machine. I have other posts, linked below, to help with some of these alternative setups.

Happy Debugging!

Other posts on Debugging you may find helpful:

Link
Paul M. JonesWikiMedia, Clean Architecture, and ADR (21.2.2017, 13:30 UTC)

tl;dr: Action-Domain-Responder is a natural fit for the HTTP user-interface portions of Clean Architecture (or Hexagonal), especially with Domain Driven Design. Just be sure to remember to separate the HTTP response presentation from the action code.


I.

Jeroen de Dauw has a fantastic post on Implementing the Clean Architecture in PHP, with Domain Driven Design elements. You should read the whole thing, and examine the implementation codebase, for a number of useful insights. Though I might quibble over some elements of the implementation, I think it is a good offering, and serves as a solid reference point.

In his article, Jeroen notes they are using Silex for their HTTP user-interface system, and describes the logic of each route action:

Inside this [Silex action] we construct our framework agnostic request model and invoke the Use case with it. Then we hand over the response model to a presenter to create the appropriate HTML or other such format.

That is a very near paraphrase of Action-Domain-Responder:

  • The Action marshals input from the HTTP request
  • The Action invokes a Domain element with that input and gets back a result
  • The Action passes that result to a Responder to build the HTTP response

In Jeroen’s implementation, each Action is a closure defined in the routes.php file. The Action marshals input from the HTTP request using a “request model” (an input object tailored to the domain) and passes it to a “use case.” Each “use case” is an entry point into the Domain, and returns a “response model” (the domain result).

The only place where Jeroen’s implementation deviates from ADR is that the Action code builds the presentation itself, instead of handing off to a Responder. (This may be a result of adhering to the idioms and expectations specific to Silex.)

Because the rest of the implementation is so well done, refactoring to a separated presentation in the form of a Responder is a straightforward exercise. Let’s see what that might look like.

II.

First, as an example, review the code in the check-iban action. The following reorganization of that action code makes the ADR pattern more obvious:

<?php
$app->get(
    'check-iban',
    function( Request $request ) use ( $app, $ffFactory ) {

        // marshal input
        $input = new Iban( $request->query->get( 'iban', '' ) );

        // invoke domain and get back result
        $result = $ffFactory->newCheckIbanUseCase()->checkIban($input);

        // presentation
        return $app->json(
            $ffFactory->newIbanPresenter()->present( $result )
        );
    }
);
?>

Very clear and straightforward. However, the presentation work is embedded in the action with the $app->json(...) call. (My guess is that’s probably a result of working with existing Silex idioms.)

Another good example is the list-comments.html action. Reorganizing the logic to make the ADR pattern more obvious gives us the following:

<?php
$app->get(
    'list-comments.html',
    function( Request $request ) use ( $app, $ffFactory ) {

        // marshal input
        $input = new CommentListingRequest(
            10,
            (int)$request->query->get( 'page', '1' )
        );

        // invoke domain and get back result
        $result = $ffFactory
            ->newListCommentsUseCase()
            ->listComments( $input );

        // presentation
        return new Response(
            $ffFactory->newCommentListHtmlPresenter()->present(
                $result,
                (int)$request->query->get( 'page', '1' )
            )
        );
    }
);
?>

Again, the presentation work is embedded in the action code.

In general, it is better to completely separate the presentation work from the action code. Remember that in an HTTP context, the presentation is not just the body of the HTTP response.

Truncated by Planet PHP, read more at the original (another 5370 bytes)

Link
Voices of the ElePHPantInterview with Chris Hartjes (21.2.2017, 10:00 UTC) Link
Matthias NobackDuck-typing in PHP (21.2.2017, 09:15 UTC)

For quite some time now the PHP community has becoming more and more professional. "More professional" in part means that we use more types in our PHP code. Though it took years to introduce more or less decent types in the programming language itself, it took some more time to really appreciate the fact that by adding parameter and return types to our code, we can verify its correctness in better ways than we could before. And although all the type checks still happen at runtime, it feels as if those type checks already happen at compile time, because our editor validates most of our code before actually running it.

To make it perfectly clear: this is all very awesome. In fact, I hope that PHP will change to become more of a static language than a dynamic one. I can very well remember the times when we actually relied on PHP doing the type juggling for us, but I'm happy we've left that phase behind. I think that nowadays many PHP developers agree that silent type conversions is not something which is very useful, nor safe.

But sometimes it's good to remember what's possible with PHP, due to it being a dynamic scripting language. I recently encountered a situation where I wanted to build a generic repository, which would be able to keep track of entities, allowing the user to store and retrieve them by their ID.

class SomeEntity
{
    public function id()
    {
        return $this->id;
    }
}

class GenericRepository
{
    public function store($object)
    {
        $id = $object->id();
        ...
    }

    public function getById($id)
    {
        return ...;
    }
}

So, what are the types we should introduce in this scenario? $id might be a simple string, although these days identifier strings will often get wrapped in their own dedicated value object. Maybe we could enforce an interface for Id type of objects? But then people won't be able to use a simple string anymore. Do I want to force that upon them? The same goes for the objects that our repository is going to store. $object might be typed as an Entity interface (since an object with identity is basically what we call "entity"), which has a method id(), which returns an identifier:

interface Id
{
    public function __toString() : string;
}

interface Entity
{
    public function id() : Id
}

Do we want to force the term Entity onto the user's code? Do we want to force users to implement the Id interface? What if there is no user we can force? What if the "entity" we want to store in our repository is defined in a third-party library?

It doesn't have to be that way. Hey, it's PHP! We only want the user to provide an object which we can use in the following way:

public function store($object) {
    $id = $object->id();

    /*
     * $id should be a string, or usable as a string (i.e. it has a __toString() method)
     *
     * In fact, we might as well just cast it to a string to be sure:
     */

    $id = (string) $id;

    ...
}

The funny thing is, whatever value the user provides, we can already do this. As long as the method id() exists on the object and PHP can successfully cast its return value to a string, we're fine. As long as we don't define any type at all for the $object parameter, PHP will do no type checking and will just try to do whatever you ask it to do, and throw warnings/errors/exceptions whenever it fails.

The only problem, one that many of us including myself will find a very big problem: our IDE isn't able to help us anymore. It won't be able to verify that methods exist or that passed function argument types are correct. It won't let us click to class definitions, etc. In other words, we loose our ability to do a little bit of the type-checking before runtime.

How to fix this? By helping your IDE to figure it out. PhpStorm for example allows you to define @var or @param annotations to make intended types explicit.

public function store($object) {
    /** @var Entity $object */
    ...
}

// or (this might show some IDE warnings in the user's code):

/**
 * @param Entity $object
 */
public function store($object) {
    ...
}

So, even when $object doesn't actually implement, it will still be treated by the IDE as if it does.

This, by the way, is known as duck typing. Type checks happen at runtime:

With normal typing, suitability is assumed to be determined by an object's type only. In duck typing, an obj

Truncated by Planet PHP, read more at the original (another 2084 bytes)

Link
Qafoo - PHPExtended Definition Of Done (21.2.2017, 09:09 UTC)
When software projects grow it is considered helpful if the software follows an established structure so that every developer finds their way easily. If the used structures and patterns change per developer or even every couple of months or years it will get really hard to maintain the software. Let's discuss the reason for this and possible fixes.
Link
Christian WeiskeSimple PHP queue worker (20.2.2017, 06:37 UTC)

During development, restarting the queue worker is tedious. Better separate worker and functionality by calling external scripts.

My search engine's crawler puts URLs that should be crawled into a Gearman task queue. A worker script runs in the background and listens for new URLs in the queue, starting the crawler whenever one is coming.

The classic worker process has two jobs: Listen at the queue and running the tasks.

During development crawler and indexer code always changes. A classic worker needs to be restarted whenever the code changes, which is tedious and annoying.

For phinde I separated queue listener and task processing:

  • The worker listens to the Gearman queue. Whenever a task is available, it starts an external script that does task processing instead of doing it itself.
  • The task processor is a command line script that does crawling and indexing.

Separating those two gave me a couple of benefits:

  1. The worker neither has to be restarted during development nor after deployment because it almost never changes.
  2. Task processing can crash hard without taking the whole queue processing down.
  3. Tasks can be started from command line, which makes development very enjoyable.

You have to decide if the payload that is passed to the workers is small enough to be transmitted as command line parameters.

Another issue is the overhead of starting new processes and their setup (database connection etc.), which might be too much if you have tiny but numerous tasks.

Link
Nomad PHPMySQL: Analysis, Understanding, andOptimization of Queries (17.2.2017, 05:01 UTC)

May 2017 - US
Presented By

Michael Moussa
May 18, 2017
20:00 CDT

The post MySQL: Analysis, Understanding, and
Optimization of Queries
appeared first on Nomad PHP.

Link
Nomad PHPCode Coverage for Total Securityin Application Migrations! (17.2.2017, 05:01 UTC)

May 2017 - EU
Presented By

Dana Luther
May 18, 2017
20:00 CEST

The post Code Coverage for Total Security
in Application Migrations!
appeared first on Nomad PHP.

Link
PHP: Hypertext PreprocessorPHP 7.1.2 Released (17.2.2017, 00:00 UTC)
The PHP development team announces the immediate availability of PHP 7.1.2. Several bugs have been fixed. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.2 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP