DEV Community: Paweł Płotka

A few words of shared understanding, i.e. a review of Jeff Patton's books User Story Mapping

Paweł Płotka — Wed, 01 Sep 2021 14:11:16 +0000

Recently I have finished Jeff Patton's books User Story Mapping. As we can read in the book summary, Jeff will explain the technique called user story mapping. In practice, in his book, the author shows us plenty of real-world examples, all of which serve another goal of usage story mapping and the consequences of not using it. So, we have the example of Gary, who is a music producer. Thanks to the story mapping, Gary was able to search the big picture and limit the scope of the project.

More examples discover other possible usages:

using user story mapping to coordinate work of teams
using user story mapping to better estimation
using user stories to choose features for MVP and then faster validate this MVP

In each example, Jeff smuggles a few tips on how to lead a user story workshop. Despite this, I regard this book too long and its examples too detailed. The actual content could easily fit in half of the book’s length.

For me, the main takeaway is shared understanding being the most vital. All stakeholders should understand the system goal and its features in the same way, which is more important than good written, detailed documentation.

On my scale, the book gets 3/5. I recommend these books to every developer that would like to be more than only a coder.

Insomnia - transform Collection to Document.

Paweł Płotka — Wed, 21 Jul 2021 03:19:37 +0000

This post comes from a series of short tips, where I publish brief stories on how I resolve every day small (and sometimes easy) issues.

Some time ago, Insomnia added a new type of project called Document Design. It allows you to group and share API specifications, requests, and unit tests in one application.

The implementation of this change has brought forth the following result: there are now two types of workspace - Design Document and Request Collection. Having run the research, I discovered that the new features may be attractive for me and might improve my work with APIs. This has encouraged me to try a new type.

However, I came across one problem: how to transform one project type into another. A built-in feature is nowhere to be found. So, the first thing I did was create a ticket to support. The answer came in immediately (big thanks to Insomnia's support). Next, following the support’s suggestion, I created the issue on Github. But…I needed solutions for that moment. Thus, I compared two import files and found certain differences, the result of which I‘m presenting the instructions below.

When you have a project of Request Collection type in Insomnia and you’d like to transform it into Document Design type, you must follow these steps:

Export current project (Request Collection) with Insomnia v4 JSON format.
Remove this project from Insomnia.
Open the exported file in your favorite text editor.
Find JSON section where parameter _type has value workspace.
Change the value of parameter scope from collection to design.
Import (go to Application -> Preferences -> Data -> Import -> From File) this document as the new project.

Wordpress - Move cron jobs to CLI

Paweł Płotka — Sun, 20 Jun 2021 19:04:22 +0000

Some time ago we started to observe performance issues in our company’s site built with WordPress. One of the issues we have observed was calling crons in random user requests. It is realized by calling URL https://yourdomain.com/wp-cron.php. Although in this file WordPress calls PHP method fastcgi_finish_request, which sends a response to the user as soon as possible, the cost of calling sub-requests during the main request is worth acknowledging and improving. There are other drawbacks of this:

Calling crons in request context means that it is limited, e.g. by php-fpm setting. We often have limited resources (such as memory or time limit) for HTTP requests.
What’s worse, calling cron as http request utilizes resource (e.g. php-fpm pools that might be necessary to handle our traffic).

On the Internet, there are a lot of tips on how to disable making subrequest to call crons and move them to CLI. But there is one problem. A lot of these tips suggest calling these scheduled tasks using crontab by calling curl (or other http callings). This addressed first problem and makes user request free of sub-requests, but does not resolve two abovementioned problems. It is surprising because WordPress comes with wp cron command, which supports running scheduled tasks in CLI without making HTTP calls.

In order to do this, you have to add one line to your crontab:

*/5 * * * * wp cron event run --due-now --path=path_to_your_wp

In this case, we call the scheduled task every 5 minutes. WordPress is responsible for choosing a concrete task to run and runs it.

Of course, you also have to disable calling sub-request to /wp-cron.php file. In order to do that, add the following to your wp-config.php file:

define('DISABLE_WP_CRON', true);

In my opinion, you should also deny access to wp-cron.php file (because some bots might DDoS our site requesting this endpoint). I suggest making it on the application server level. For example, if you use Nginx, add the following to your host configuration:

location = /wp/wp-cron.php { deny all; }

Sylius Behat scenarios in Chrome Headless inside Docker

Paweł Płotka — Mon, 24 May 2021 18:34:42 +0000

Since this PR, Sylius has started using Chrome Headless to run their Behat scenarios tagged with @javascript (scenarios that require Javascript engine to run correctly - in short, Javascript suits). After the implementation of this change, it turned out that Javascript suits had sped up from 13 minutes to 8.5 minutes. So, I decided also to run my Javascript suit using Chrome Headless. However, there was one problem, namely my whole environment (development, test on the local machine, and test in CI) is based on Docker. Until now, I’ve been using Selenium image to run Chrome. This short post shows you how to configure your Docker environment to work with Chrome Headless.

You might see this post when you still want to use Selenium with Docker for Javascript suits:

How to test your Sylius plugins with Selenium?

Dylan Ballandras ・ Mar 12 '20

#php #sylius #behat #selenium

First of all, I assume that you work with Sylius Standard Edition. If you have a custom Docker configuration, there is no problem with adopting this solution, but it will require more effort from you.
Sylius Standard comes with two docker-compose files: one for development purposes and the second for production. For running Behat scenarios, I suggest creating the third one. We might call it docker-compose.behat.yaml. In this file, we might configure Chrome Headless as a Docker service and (optionally) override or create new services.

For brevity, in this blog post, we only create a Chrome service and override the environment setting for the application service. So, our docker-compose.behat.yaml file looks like this:

version: "3.4"

services:
  php:
    environment:
      - APP_ENV=test_cached
  chrome:
    image: zenika/alpine-chrome
    shm_size: "2gb"
    command: "--enable-automation --disable-background-networking --no-default-browser-check --no-first-run --disable-popup-blocking --disable-default-apps --disable-translate --disable-extensions --no-sandbox --enable-features=Metal --headless --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --window-size=2880,1800 --proxy-server='direct://' --proxy-bypass-list='*'"
    volumes:
      - .:/srv/sylius:rw,cached

A few lines that require explanation:

First of all, you have to override the application service (in our case, called php to run in test_cashed environment).
For Chrome, we use zenika/alpine-chrome image. You might use another one (but not all images work correctly, this one is also well documented) or create your image (but it might be a waste of time).
It is necessary to change the shm size. Without this change, Chrome crashes during tests. So I suggest setting the shm_size option to 2gb.
The next thing worth noting is the command for the Chrome container. I use the same command as is used in the Sylius CI configuration.
Last but not least, the volume needs the correct setting. It is very important, and remembering about it might save your time for debugging a problem. It is necessary to upload files in the scenario’s steps. Without this line your test execution returns timeout for all scenarios placed after that one that tries to upload a file. In my example, I’m sharing all codebases, but it is possible to share the only directory with fixtures.

The second file we should change is behat.yaml. We have to configure the MinkExtension's (so we focus only on the Behat\\MinkExtension section in this file) base_url option. In our case, the correct value is http://nginx/ (it points to the entrypoint of our application).
Since we run Chrome Headless as a service in a container (instead of the same machine or container as an application), it is also necessary to change the option of chrome_headless sessions. This option refers to url to Chrome API, and for us, it is http://chrome:9222.

That's all. It's time for testing. For this purpose, run the command below:

docker-compose -f docker-compose.yml -f docker-compose.behat.yml exec php vendor/bin/behat --colors --strict --no-interaction -vvv -f progress -f pretty --tags="@javascript && ~@todo && ~@cli"

You might use composer's script or Makefile to alias long commands.

I hope that this configuration allows you to speed up your test, especially in CI (I wish to show you a comparison of Selenium and Chrome Headless in the next blog post).