Archive for the 'Programming' category

Mockery return values based on arguments

published on December 12, 2017.

Sometimes when working with Mockery mock objects, we want to tell a mocked method to return different values for different arguments. It is a rare occasion when I need this feature, but every time I need it, I’m happy it’s there.

The feature that allows us to return different values based on arguments is the andReturnUsing Mockery method, which takes a closure as an argument:

example.php

$dependencyMock = \Mockery::mock('SomeDependency');
$dependencyMock->shouldReceive('callDependency')
    ->andReturnUsing(function ($argument) {
        if ($argument <= 10) {
            return 'low';
        }

        return 'high';
    });

$dependencyMock->callDependency(10); // 'low'
$dependencyMock->callDependency(11); // 'high'

Any number of times we call our callDependency method on our mock object with a number 10 or less, it will return 'low', otherwise it will return 'high'.

Not much of an example, so let’s take a look at one a bit closer to a real world scenario.

Say we’re using Doctrine’s entity manager to get repositories for our entities in a service class:

src/ArticleService.php

<?php

class ArticleService
{
    public function __construct(EntityManager $em)
    {
        $this->articleRepo = $em->getRepository(Entity\Article::class);
        $this->authorRepo = $em->getRepository(Entity\Author::class);
    }
}

Not the best of the codes, but we’ll manage. The entity manager receives two calls to the getRepository method, once for the Article entity, once for the Author entity.

In a test case we could then set up the mocks like so:

tests/ArticleServiceTest.php

<?php

class ArticleServiceTest extends MockeryTestCase
{
    public function setup()
    {
        $this->authorRepositoryMock = \Mockery::mock(AuthorRepository::class);
        $this->articleRepositoryMock = \Mockery::mock(ArticleRepository::class);
        $this->entityManagerMock = \Mockery::mock(EntityManager::class);
    }

    public function testArticleService()
    {
        $repositoryMap = [
            'Entity\Author' => $this->authorRepositoryMock,
            'Entity\Article' => $this->articleRepositoryMock,
        ];
        $this->entityManagerMock->shouldReceive('getRepository')
            ->andReturnUsing(function($argument) use ($repositoryMap) {
                return $repositoryMap[$argument];
            });

        $articleService = new ArticleService($this->entityManagerMock);
    }
}

In the setup method we create the three mock objects that we need and then in the test method we create a $repositoryMap to help us map entities to repositories. The repository map could have been created in the andReturnUsing closure as well.

Now when we instantiate the ArticleService with the mocked entity manager, that mocked entity manager will receive two calls to the getRepository method in the ArticleServices constructor, and it will use the closure defined in andReturnUsing to return the correct repository mock objects.

More than one way to do it

Of course there is another way to achieve the same thing and that’s by using andReturn for the return value expectations, but it’s a bit more to write:

tests/ArticleServiceTest.php

<?php
    public function testArticleService()
    {
        $this->entityManagerMock->shouldReceive('getRepository')
            ->with('Entity\Author')
            ->andReturn($this->authorRepositoryMock);
        $this->entityManagerMock->shouldReceive('getRepository')
            ->with('Entity\Article')
            ->andReturn($this->articleRepositoryMock);

        $articleService = new ArticleService($this->entityManagerMock);
    }

It does the same thing as the previous thing. We might even argue that this second example is even clearer than the first example, sure, for a relatively small argument “map”. But if we need to handle a case with more than just two possible arguments, andReturnUsing can help us in those cases.

Happy hackin’!

P.S.: The proper way to do this actually would be to refactor that ArticleService to not get the two repositories from the entity manager, but to inject them directly instead.

Five days of Advent of Gode

published on December 06, 2017.

A week or so ago, Luka mentioned this Advent of Code thing. I’ve been doing coding challenges and examples before, but never have I tried the AoC (this is the third year it’s running).

Advent of Code is a series of programming puzzles, where you get 2 puzzles a day for 25 days.

Given that I have started to learn golang again, I figured might as well learn more about it by joining this years challenge.

I keep a repository with my solutions to these puzzles and try to take notes for every day and now I want to look back at the first 5 days.

I started of the first day with just a mess of a code, just pushing for the first solution that gets the correct answer. On the second day I realised I won’t be learning much like this, so I decided to bring some order to the chaos: organised the code a bit nicer (even though it’s a far cry from good), added tests, and generally tried to get to a point where it’s easier to get started with a day’s challenge.

The AoC puzzles are relatively easy so far. Day 3 was the only day so far where I had problems wrapping my head around the problem. I’ve managed to figure out the solution for the first puzzle, but for the second puzzle I “cheated” and used the OEIS. shrug

As for golang… I don’t know enough of it to say if I like it or not. I mean, I do like it, sort of, but for these 5 days the most I did was toying around with strings and integers and slices and maps. That’s hardly enough time and usage to pass judgment on it.

On golang

I like how it fails to build if there’s an unused variable laying around, but then again I tend to save often, so I write:

for k, v := range slc {
}

Hit save and the IDE underlines that entire for line. What, why?! Hover over the line to see what the problem is… Oh, k and v are unused. Well, d-uh, I’m not done yet. But I still have to double check because the bug might be real, for example if I want to range over an integer the IDE will again underline the entire line.

For some reason I’m really bad at naming things in golang, quite often the variable and function names are just bad. I’m trying my best to follow the golang styles, but… I don’t know. I’m not sold on the whole “short rather than long” thing.

I keep mixing assignment = and assignment & declaration :=. But I’ll learn it, eventually.

I like everything about the types, even though I don’t understand everything about them, yet. Maps, for example, are not ordered even though I tried to use them as such once.

On slices

Except slices. Slices are weird. Well, were weird until I understood how golang treats and works with them.

I read four different articles to get to the point where I know what a slice is, only to get a succinct explanation of “slices are mutable views of an array”. For me, that one sentence explains it better than the four articles.

Here’s an example:

package main

import (
	"fmt"
)

func main() {
	x := []int{1, 2, 3, 4, 5}
	a := make([]int, 0)
	b := make([]int, len(x))

	y := x
	copy(a, x)
	copy(b, x)

	F(x)

	fmt.Println(x) // [2 3 4 5 6]
	fmt.Println(y) // [2 3 4 5 6]
	fmt.Println(a) // []
	fmt.Println(b) // [1 2 3 4 5]
}

func F(z []int) {
	for k, _ := range z {
		z[k]++
	}
}

Notice how both x and y are the same, even though we only modify x within the F() function, without even returning anything from that function. What happens is that the array on which the slice is built gets modified, which in turns modifies the slice(s) as well. Another thing worth remembering is to only append to a slice with the append() function.

On testing

I learned how to write tests. I guess there’s more to learn about them, but so far I’m doing OK. I’m writing a lot of repetitive things like this to get data providers:

for _, tt := range footests {
    r := Foo(tt.in)

    if r != tt.out {
        t.Errorf("Got %d for %s, expected %d", r, tt.in, tt.out)
    }
}

Even if there’s no shorter/better way to handle data providers in golang tests, I’ll just create some snippets and be done with all the copy/pasting.

I like that VS Code allows to run and debug a single test function. That’s really helpful. It shows small “run test” and “debug test” links above every test method. Click and off we go!

On packages

I haven’t yet learned how to properly work with my own packages, how to organize code and name packages to import one into the other, but I didn’t really had the need for it.

What I did learn, is that I can’t name a function like an existing package. For example, I wrote my own little function called sort, which made it impossible to import the sort package from the standard library.

All in all, I’m making good progress with both the AoC puzzles and with golang. I believe this will give me a good foundation for further learning and improving. There’s still a long road before me, but I feel I’m on the right track.

Happy hackin’!

Reacting to promises

published on November 29, 2017.

I was working on the next post of my Prooph service bus series, which includes the usage of ReactPHP promises. Given that I haven’t had the chance to take a closer look at it yet, I decided that this is the right time for it.

ReactPHP has several different components, with the end goal of providing a low-level library for event-driven programming in PHP. The one component I want to talk about today is the promise component, which is a Promises/A implementation for PHP.

What this promise library allows us is a nicer workflow with asynchronous code.

With promises, when we want to execute something asynchronously we defer the work that will be executed asynchronously. The Deferred unit of work will complete sometimes in the future, but we don’t know when. But it does promise that the work will be done, one way or the other.

The Promise is a sort of a placeholder for the result that will eventually be returned from our deferred work. This promise can then either be resolved or rejected by our deferred. When a promise is resolved successfully it has an associated value, and when it is rejected it has an associated reason for the rejection.

We use the then method on the promise to register handlers that will be called when the deferred is resolved or rejected.

To install the React/Promise component, run:

$ composer require react/promise

An example

Let’s say we have some code that does some asynchronous work. Checking the HTTP status code of a bunch of URLs, for example. We could create an invokable class that extends the Deferred:

FetchStatusCodes.php

<?php declare(strict_types=1);

use React\Promise\Deferred;

class FetchStatusCodes extends Deferred
{
    public function __invoke(array $urls)
    {
        $multiHandle = curl_multi_init();

        $handles = $this->getHandlesForUrls($urls, $multiHandle);

        $this->executeMultiHandle($multiHandle);

        $statusCodes = $this->getStatusCodes($handles);

        curl_multi_close($multiHandle);

        $successRate = $this->calculateSuccessRate($statusCodes);

        if ($successRate > 50) {
            $this->resolve($statusCodes);
        } else {
            $this->reject('Success rate too low: ' . $successRate);
        }
    }
}

I’ve left out here a bunch of code that deals with the actual fetching of the status codes, just to keep the “noise” down. The full example is available in this repository.

The important thing here is that we extend React\Promise\Deferred and that at the end we call the resolve() method to resolve this deferred if the success rate is over 50%, or that we call the reject() method if the success rate is below 50%.

The set up of the actual promise and its handlers would look something like this:

promise.php

<?php

$statusCodes = new FetchStatusCodes();
$promise = $statusCodes->promise();

$promise
    ->then(
        function($value) {
            var_dump($value);
        },
        function($reason) {
            echo $reason . PHP_EOL;
        }
    );

$urls = [
    'https://example.com/',
    'https://stackoverflow.com/',
    'https://www.google.com/',
    'https://www.google.com/no-such-url',
    'https://www.google.com:81'
];
$statusCodes($urls);

We create the FetchStatusCodes deferred object and get the promise. We setup the resolve and reject handler callbacks in the then method. They don’t do much for now:

  • the resolve handler dumps the value it got,
  • the reject handler prints out the reason of the rejection.

The output for a resolved promise would be something like this:

$ php promise.php
/home/robert/projects/react-promise-example/promise.php:32:
array(5) {
  'https://example.com/' => int(200)
  'https://stackoverflow.com/' => int(200)
  'https://www.google.rs/' => int(200)
  'https://www.google.com/no-such-url' => int(404)
  'https://www.google.com:81/' => int(0)
}

We’re not done yet!

The example above where we call the then method to set up our resolve/reject handlers, isn’t quite correct. Why?

When we call the then method it actually returns a new Promise. This feature of the Promises/A specification allows us to chain promises together.

On this second promise we can again set up our resolve/reject handlers calling the then method on it, same as we do for our first promise. The resolve handler of the second promise will be called with the return value of either the resolve or the reject handler of the first promise. The reject handler of the second promise will be called when either the resolve or the reject handler of the first promise throws an exception. And the then method of our second promise again returns a new, third promise.

Let’s see if an example makes it a bit more clearer:

promise.php

<?php

$statusCodes = new FetchStatusCodes();
$firstPromise = $statusCodes->promise();

$secondPromise = $firstPromise->then(
    function($statusCodes) {
        $successCodes = array_filter($statusCodes, function ($code) {
            if ($code >= 200 && $code < 300) {
                return true;
            }
            return false;
        });
        return $successCodes;
    },
    function($reason) {
        // handle rejected promise
        // gets called when Deferred gets reject-ed
    }
);

$thirdPromise = $secondPromise->then(
    function ($successCodes) {
        return json_encode($successCodes);
    },
    function ($reason) {
        // handle rejected promise
        // gets called when $firstPromise handlers throw an exception
    }
);

$urls = [
    'https://example.com/',
    'https://stackoverflow.com/',
    'https://www.google.com/',
    'https://www.google.com/no-such-url',
    'https://www.google.com:81'
];
$statusCodes($urls);

When our FetchStatusCodes deferred resolves, it will call the resolve handler of the $firstPromise. In that first resolve handler we get only the successful status codes and return them.

With this return from the resolve handler of the first promise, we “trigger” the resolve handler of the $secondPromise where we can, for example, json_encode our success codes. By returning this JSON string from the resolve handler of the second promise, we again “trigger” the resolve handler of the $thirdPromise, and so on.

Almost done!

When we call then, we make a new promise.

To actually be done with all the promises, we need to call the done method on the last promise in our chain. With done we stop making promises and use the result of our last promise:

promise.php

<?php
$thirdPromise->done(
    function ($jsonString) {
        echo $jsonString . PHP_EOL;
    },
    function ($reason) {
        // handle rejected promise
        // gets called when $secondPromise handlers throw an exception
    }
);

If we’d run the example now, we’d get something like this:

$ php promise.php | json_pp
{
   "https://example.com/" : 200,
   "https://www.google.rs/" : 200,
   "https://stackoverflow.com/" : 200
}

We additionally pipe the output of our example script to json_pp to pretty print the JSON string.

Now we’re done

ReactPHP promises have an ExtendedPromisesInterface that include additional shortcut and utility methods that are not part of the Promise/A specification. Their docs include some more examples, and Cees-Jan Kiewiet looks at examples using the react/dns component, among other things.

When we deal with asynchronous code in PHP, using ReactPHP promises gives us a way to deal with it in a much nicer, saner way.

Happy hackin’!

PHP FPM slow log

published on November 23, 2017.

The other day I was going through the configuration file for php-fpm, when I noticed a configuration directive I haven’t before: slowlog. I guess it’s been around for a while, I just never noticed it.

The php-fpm slow log is a pool configuration, meaning that we configure it in www.conf, and has two directives for it:

  • the slowlog, which is a path to a file where the slow requests will be logged,
  • and request_slowlog_timeout is a time unit after which PHP will dump a backtrace for that request in to the slow log file. We can configure it to be in seconds, minutes, hours, or days.

What’s in the box backtrace?

It has the date and time for when the slow request happened, the pool and PID for the php-fpm process. script_filename is the entry point to the request, and the backtrace includes a list of function calls up until the moment when the request_slowlog_timeout was hit.

[23-Nov-2017 15:28:21]  [pool www] pid 8992
script_filename = /var/www/example/web/app_dev.php
[0x00007efe32a14a40] sleep() /var/www/example/src/AppBundle/Controller/DefaultController.php:18
[0x00007efe32a149d0] indexAction() /var/www/example/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:153
[0x00007efe32a14960] call_user_func_array() /var/www/example/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:153
[0x00007efe32a14470] handleRaw() /var/www/example/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:68
[0x00007efe32a14320] handle() /var/www/example/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:169
[0x00007efe32a14250] handle() /var/www/example/web/app_dev.php:29

Even though it doesn’t reveal too much, together with other profiling tools, like Xdebug and kcachegrind, it can help us a great deal on finding and fixing performance problems in web applications.

Happy hackin’!

Prooph event bus

published on November 15, 2017.

Let’s continue with the Prooph components, with another part of the Service Bus: the event bus.

As mentioned in the previous article on the command bus, the Prooph Service Bus has three kinds of buses:

  • the command bus,
  • the event bus,
  • and, the query bus.

The event bus takes one event, and that event is sent to all the event listeners that are listening for that event. If there are no listeners, the event bus will still dispatch the event, but it won’t break the application. Any listeners listening to that event, will receive the event, and then we can do something based on that event — update a database table, send an email, push a notification, etc.

Compare that to the command bus, where we send one command on the command bus, and that command must be handled by a registered handler, otherwise the command bus will throw an exception.

Events are messages of things that happened in our system, and we name them accordingly: UserRegistered, CommentAdded, RssFeedUpdated.

From the nature of the events, and from the naming convention, we can conclude that we can not prevent events, as they have already happened. When we create an account for a user, we send an event of that, but we can’t do anything to the event to prevent the creation of the new user account. We can only react to that event.

When working in a DDD fashion, sending events is a great way to notify other bounded contexts of events that happened in our models.

You’re not required to do CQRS, Event Sourcing, and DDD, to be able to use eventing in your applications. It is possible to use the event bus as a standalone component, and if all what you need is to send an event, and then react to that event, do just that. At the very least, you get to decouple the sending of welcome emails, from the actual user registration.

A quick example

The message that represents our event can be anything — a primitive, a custom DTO class, or a class implementing the Message interface from the prooph-common library.

Setting up and using the event bus is similar to setting up and using the command bus:

  • we create the event bus,
  • we create an event router that the event bus uses to route events to event listeners,
  • we route a event to its event listeners,
  • we attach the router to the event bus,
  • and finally, we dispatch the event on the event bus.

Or in code:

event-bus.php

<?php declare(strict_types=1);

require_once 'vendor/autoload.php';

use Prooph\ServiceBus\EventBus;
use Prooph\ServiceBus\Plugin\Router\EventRouter;

$eventBus = new EventBus();

$eventRouter = new EventRouter();

$eventRouter->route('A simple string')
            ->to(new ProophExample\EventListener\Primitives());

$eventRouter->attachToMessageBus($eventBus);

$event = 'A simple string';
$eventBus->dispatch($event);

The Primitives event listener in this case doesn’t do much, and isn’t even named as we would name a real event listener, but it shows how would we create an event listener:

src/ProophExample/EventListener/Primitives.php

<?php declare(strict_types=1);

namespace ProophExample\EventListener;

class Primitives
{
    public function __invoke(string $event)
    {
        echo $event . PHP_EOL;
    }
}

It just outputs the event that it got from the event bus.

Sending a welcome email

A bit more realistic example would be to send a welcome email to a user when they register with us, and to increase the total number of user accounts. Remember, we can have multiple event listeners react to the same event!

We have the UserRegistered event, that will hold the User model that was created during the registration process:

src/ProophExample/Event/UserRegistered.php

<?php declare(strict_types=1);

namespace ProophExample\Event;

use ProophExample\User;

class UserRegistered
{
    /**
    * @var User
    */
    protected $user;

    public function __construct(User $user)
    {
        $this->user = $user;
    }

    public function user(): User
    {
        return $this->user;
    }
}

We also have the event listener responsible for sending out welcome emails:

src/ProophExample/EventListener/SendWelcomeEmail.php

<?php declare(strict_types=1);

namespace ProophExample\EventListener;

use ProophExample\Event\UserRegistered;

class SendWelcomeEmail
{
    public function __invoke(UserRegistered $event)
    {
        echo sprintf("Hello %s", $event->user()->name()) . PHP_EOL;
    }
}

And we have the event listener responsible for increasing the number of user accounts:

src/ProophExample/EventListener/IncreaseNumberOfAccounts.php

<?php declare(strict_types=1);

namespace ProophExample\EventListener;

use ProophExample\Event\UserRegistered;

class IncreaseNumberOfAccounts
{
    public function __invoke(UserRegistered $event)
    {
        echo "Increasing the number of user accounts" . PHP_EOL;
    }
}

When tying all this together, we’d have something like the following example:

event-bus.php

<?php declare(strict_types=1);

require_once 'vendor/autoload.php';

use Prooph\ServiceBus\EventBus;
use Prooph\ServiceBus\Plugin\Router\EventRouter;

$eventBus = new EventBus();

$eventRouter = new EventRouter();

$eventRouter->route(ProophExample\Event\UserRegistered::class)
            ->to(new ProophExample\EventListener\SendWelcomeEmail())
            ->andTo(new ProophExample\EventListener\IncreaseNumberOfAccounts());

$eventRouter->attachToMessageBus($eventBus);

$user = ProophExample\User::register('john.doe@example.com', 'John Doe');

$event = new ProophExample\Event\UserRegistered($user);

$eventBus->dispatch($event);

We create the event bus, the event router, we route the UserRegistered event to the SendWelcomeEmail event listener, and to the IncreaseNumberOfAccounts event listener, attaching the router to the event bus. Next we register our new user, and we create and dispatch our UserRegistered event.

Running this example gives us:

$ php event-bus.php
Hello John Doe
Increasing the number of user accounts

As we can see, first the event listener responsible for sending the welcome email gets invoked, and then the event listener for increasing the number of user accounts. They were invoked in the order we attached them to the router.

Prooph Messages

In the previous article about the command bus, we saw that the messages, that is the commands, can implement the Prooph\Common\Messaging\Message interface. In that section I said that I don’t really see the benefit of having commands implement that interface, but I do think that the events benefit a great deal from that interface.

Why?

By implementing that interface, we get a UUID for that event, a date and a time when it happened, and other information. All of this is of great value because an event listener might handle an event sometimes in the future, whereas we expect a command to be handled immediately. This extra information about events can be especially useful if/when we want to have Event Sourcing in our application.

An example event that signals that a RSS feed has been updated would look something like this implementing the Message interface:

src/ProophExample/Event/FeedUpdated.php

<?php declare(strict_types=1);

namespace ProophExample\Event;

use Prooph\Common\Messaging\DomainEvent;
use Prooph\Common\Messaging\PayloadConstructable;
use Prooph\Common\Messaging\PayloadTrait;
use ProophExample\Url;

class FeedUpdated extends DomainEvent implements PayloadConstructable
{
    use PayloadTrait;

    public function url(): Url
    {
        return $this->payload['url'];
    }
}

The prooph-common library not only provides the interface, but also abstract classes that help us with implementing the methods defined in the interfaces.

Creating and dispatching this event will then be:

event-bus.php

<?php

$url = ProophExample\Url::fromString('https://robertbasic.com/index.xml');
$event = new ProophExample\Event\FeedUpdated(['url' => $url]);

$eventBus->dispatch($event);

And the listener then can access the Url, as well as the extra event information, like the date and time when the event was created:

src/ProophExample/EventListener/NotifyAboutNewArticles.php

<?php declare(strict_types=1);

namespace ProophExample\EventListener;

use ProophExample\Event\FeedUpdated;

class NotifyAboutNewArticles
{
    public function __invoke(FeedUpdated $event)
    {
        echo sprintf("There are new articles to read from %s since %s",
            $event->url(),
            $event->createdAt()->format('Y-m-d H:i:s')
        ) . PHP_EOL;
    }
}

A more real-world like example

Same as with the command bus, we wouldn’t really use the event bus as we see it in this event-bus.php example file.

We would maybe have a factory of some kind that would create the event bus, configure the event router, and attach it to the event bus. Then we would get the event bus from a psr/container compatible container where we need it, create the event, and then dispatch it on the event bus. I’ve already given an example of this in the previous article, so I don’t want to repeat myself here.

The examples shown and discussed here are available in my prooph-examples repository.

Happy hackin’!

Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2019
Get the feed