DEV Community: Paul Isaris

Serving Large Private Files from Laravel

Paul Isaris — Mon, 12 Oct 2026 12:58:00 +0000

Serving Large Private Files from Laravel

(image by pexels)

Introduction

Let's suppose you need to show a set of large files to a small group of users. Say a few hundred photographs, 6000 x 4000 JPEGs of about 7 MB each, straight from the camera, and only the members of a team may open them. Nobody else, logged in or not.

The reason you want to serve the originals might be scientific: the users need to zoom in and inspect details, so downscaling the images is not always a solution. The same applies to scanned documents, medical images, or any file where the detail is the point.

If you have served files from Laravel before, you know the first thing that comes to mind: php artisan storage:link, drop the files under storage/app/public, and write <img src="/storage/...">. It takes five minutes and it works. It is also the wrong tool for this case! I hit exactly this scenario in an application I work on, and this post walks through what I built instead and why.

The post is for anyone who serves files that are not public: uploads, datasets, scans, contracts, paid downloads. The code is written on Laravel 13 (PHP 8.3+), but the approach is decoupled from the framework and the version. The principles apply to any web application that needs to check who is asking before handing out a file.

The naive scenario, and why it fails

The public disk exists for files that anyone may fetch: logos, avatars, marketing assets. The symlink turns storage/app/public into public/storage, and from then on the web server hands the files out directly. Laravel is not involved in those requests at all. That is the point of the feature, and it is exactly the problem:

Anyone who has the URL gets the file. The session, the roles, and the policies never run.
The URLs are guessable. Files named 11.JPG, 12.JPG, 13.JPG can be fetched with a loop.
The symlink must exist on every server. Forget it on one deployment target and every file is a 404.
Moving the files later, to another directory or to S3, changes every URL the frontend ever rendered.

Signed URLs are the usual answer for the first two points, and they are a good one when the files live on S3. For a directory on the application server, I wanted something simpler: one endpoint that checks who is asking and then streams the file.

Keep the files where they are, point a disk at them

The files live in a directory outside the Laravel tree. In my case it is a separate git repository, cloned next to the application, because the data has its own history and its own owners. Nothing is copied into storage/. The application only needs to know where the directory is, so the path is a config value with an environment override:

// config/files.php
return [
    'root' => base_path(env('FILES_PATH', 'files')),
];

A filesystem disk is rooted at that path. It is a local disk with no url key, which means Laravel cannot build a public URL for it even by accident:

// config/filesystems.php
'files' => [
    'driver' => 'local',
    'root' => config()->string('files.root'),
    'throw' => false,
    'report' => false,
],

The database stores two things per file: the directory of the collection it belongs to (Expedition_2024) on the collection row, and the file name (11.JPG) on the file row. Together they make the path relative to the disk. The absolute path never leaves the server.

The tests get their own root: phpunit.xml sets FILES_PATH to a directory with three small committed fixtures, so the suite never touches the real data.

One authorized endpoint

The route takes the collection the user is browsing and the file they want:

Route::get(
    'collections/{collection}/files/{file}',
    [CollectionFileController::class, 'show'],
)->middleware('auth')->name('collections.file');

The frontend receives this URL inside the page payload and puts it in an <img src>. The browser sends the session cookie with the request, as with any other same-origin URL, so nothing special happens on the client.

Authorization lives in a form request. It asks two questions: may this user see files of this collection, and does this file belong to this collection? The second check matters. Without it, a member of one collection could request any file id in the database and the policy check alone would pass:

class ShowCollectionFileRequest extends FormRequest
{
    public function authorize(): bool
    {
        $collection = Collection::query()->findOrFail($this->route('collection'));

        if (! Gate::allows('viewFile', $collection)) {
            return false;
        }

        $file = CollectionFile::query()->findOrFail($this->route('file'));

        return $file->collection_id === $collection->id;
    }
}

The policy behind the gate is plain: admins, and users who are members of the collection. The controller then builds the path and streams the file:

class CollectionFileController extends Controller
{
    private const string CACHE_CONTROL = 'private, max-age=86400';

    public function show(ShowCollectionFileRequest $request, int $collection, int $file): StreamedResponse
    {
        $fileRow = CollectionFile::query()->findOrFail($file);
        $collectionRow = Collection::query()->findOrFail($collection);

        $directory = $collectionRow->directory;
        $fileName = $fileRow->file_name;

        abort_unless($this->isSafeSegment($directory), Response::HTTP_NOT_FOUND);
        abort_unless($this->isSafeSegment($fileName), Response::HTTP_NOT_FOUND);

        $relativePath = $directory . '/' . $fileName;

        abort_unless(Storage::disk('files')->exists($relativePath), Response::HTTP_NOT_FOUND);

        return Storage::disk('files')->response($relativePath, null, [
            'Cache-Control' => self::CACHE_CONTROL,
        ]);
    }

    /** A single path segment: non-empty, no separators, no parent references. */
    private function isSafeSegment(mixed $segment): bool
    {
        return is_string($segment)
            && $segment !== ''
            && ! str_contains($segment, '/')
            && ! str_contains($segment, '\\')
            && ! str_contains($segment, '..');
    }
}

Two details are deliberate.
First, both path segments come from the database, not from the request, and both are still checked. A row can be edited by hand, an import can have a bug, and ../../.env in a file name must not become a readable path. Each segment has to be a single directory or file name: no slashes, no backslashes, no ... Second, the status codes are a choice. A guest never reaches this code: the auth middleware redirects every guest to the login page, whether the collection exists or not, so anonymous traffic learns nothing. An authenticated user without access gets a 403. That tells them the id exists, and I accept it: they are known users, and a 404 for a collection they already know about is only confusing. Failures after authorization, such as an unsafe path or a missing file on disk, are a 404.

Storage::response() returns a StreamedResponse. PHP reads the file in chunks and writes them to the output, so a 7 MB file does not get loaded into memory as a string.

Cache it privately

The Cache-Control header is the one line that makes the approach practical. private tells the browser it may keep the file and tells every shared cache on the way that it may not. max-age=86400 means that for a day, opening the same file again costs no request at all. A user who moves back and forth between images gets each file once.

What is still missing is an ETag or a Last-Modified header. After the day is over, the browser downloads the file again instead of asking whether it changed. The fix is a few lines in the same controller; I left it out here to keep the example short.

The tests that pin it down

The feature test for the endpoint has eight cases, and I think the list is worth more than the code, because it is the contract:

a guest is redirected to the login page, so anonymous traffic cannot probe which ids exist;
an authenticated non-member gets a 403 (deliberate: known users may learn that the collection exists);
a member gets a 200 with image/jpeg and the private cache header;
an admin gets a 200 without being a member;
a file that belongs to a different collection gets a 403, for the same reason;
a file name containing .. gets a 404;
a collection with no directory gets a 404;
a directory containing .. gets a 404.

The fixtures are three small JPEGs committed to the repository. The real files are never needed to run the suite, which is the only way the suite stays runnable on a fresh clone and on CI.

Is streaming through PHP fast enough?

Honest answer: for the application I had in mind, yes, and I measured before deciding. One user opens one file at a time. The first load costs one PHP process for about 7 MB; every later load of the same file is served from the browser cache. And since the users zoom into details, generating smaller copies would not have replaced the original anyway; it would only have added a second set of files to keep in sync.

If your numbers are different, if hundreds of users open large files at once, keep the design and move the bytes out of PHP. nginx has X-Accel-Redirect and Apache has X-Sendfile: the controller still runs the authorization and then returns an empty response with a header that names the file; the web server streams it. The nginx side is one internal location:

location /protected-files/ {
    internal;
    alias /var/www/files/;
}

And the controller returns the header instead of the stream:

return response('', 200, [
    'X-Accel-Redirect' => '/protected-files/' . $relativePath,
    'Content-Type' => $fileRow->mime,
    'Cache-Control' => self::CACHE_CONTROL,
]);

The policy, the path checks and the tests stay the same. Only the last line changes, which is the reason to keep the authorization in Laravel in the first place.

Three things that need attention

EXIF orientation. Browsers rotate a JPEG according to its EXIF Orientation tag, but getimagesize() returns the raw sensor dimensions. If you store width and height at import time, for example so the page can reserve the right aspect ratio before the image loads, a phone photo with Orientation 6 ends up stored as landscape and displayed as portrait. Read the tag and swap the two values for orientations 5 to 8:

set_error_handler(static fn (): bool => true);

try {
    $exif = exif_read_data($absolutePath);
} finally {
    restore_error_handler();
}

$rotated = $exif !== false && in_array($exif['Orientation'] ?? 1, [5, 6, 7, 8], true);

The error handler is there because exif_read_data() emits a warning, not an exception, for files without EXIF data, and a missing tag is a normal case. exif_read_data() also lives in an optional PHP extension. Declare it, or the import fails on the first host that lacks it:

"require": {
    "php": "^8.3",
    "ext-exif": "*"
}

CMYK JPEGs. Some files come out of desktop tools in CMYK. Browsers decode CMYK JPEGs, but the colours come out wrong. Since the files are served unchanged, the fix belongs in the data: convert those sources to sRGB once. If you generate derivatives, this is where you would do it instead.

Inline serving of any type. The endpoint streams whatever the row points at, with the file's own content type, on the application's origin. For a trusted directory that is acceptable. For user uploads it is not: an SVG or HTML file served inline runs scripts on your origin. Restrict the content type to what the feature needs, or add Content-Disposition: attachment for everything else.

Trade-offs to accept

The files live outside the Laravel directory layout. Every deployment target has to provide the directory and set FILES_PATH. It is one more step in the deploy, and it must be documented, but it is a step that storage:link did not need.
Each first load of a file is a PHP process. The cache header and, if needed, X-Accel-Redirect keep that in check, but it is a cost that a static file server does not have.
Membership is checked per collection, not per file. If some members may see only some files, the form request is where a tighter check would go.
No S3 yet. When the disk becomes S3, streaming through PHP stops making sense and temporary signed URLs take over. The authorization code stays; the controller's last line changes again.

Conclusion

Private files need an endpoint, not a symlink. The endpoint has four jobs: check who is asking, check that the file belongs to what they are allowed to see, refuse to build a path from anything that is not a plain file name, and stream the bytes with a private cache header. Everything else, from where the files live to which server sends the bytes, is a configuration detail that can change later without touching the rules. Write the eight tests first; they are the part you will still rely on after the next refactoring.

Mastering Code Quality in Laravel: Pint with Git Hooks and Docker

Paul Isaris — Tue, 05 Nov 2024 18:19:00 +0000

Mastering Code Quality in Laravel: Pint with Git Hooks and Docker

(image by pexels)

This post was originally published at paulisaris.com

Introduction

As developers, we all know how important clean, consistent code is for maintaining a large-scale Laravel application. Not only does well-formatted code boost readability, but it also ensures team-wide consistency and helps avoid pesky formatting debates during code reviews.

Enter Pint, a powerful tool introduced by the Laravel ecosystem to automatically format PHP code according to opinionated best practices.

In this article, we'll explore how to integrate Pint into your Laravel application and take it a step further by running Pint inside a Docker container using Docker Compose.

This approach ensures that code formatting is consistent across environments and makes it easier for developers using different setups to maintain uniformity in their codebase.
Let's dive into the details! 🚀

Why Use Pint in Laravel?

Pint is a zero-configuration tool that formats PHP code following PHP-CS-Fixer standards. It comes preconfigured to support modern PHP standards, making it an essential part of any Laravel developer's toolkit.
Automating code formatting helps reduce human errors, eliminates minor formatting discussions in code reviews, and accelerates development workflows by enforcing consistent style across all files. 🥷

Why is this important?

Consistency: Pint ensures your code style is uniform across the team. No more personal preferences affecting how the code looks.
Readability: Clean code is easier to read and maintain. Pint automatically handles indentation, spacing, and other small details, making your codebase more readable.
Automation: By integrating Pint in pre-commit Git hooks or running it via Docker, you can automate code formatting, making it one less thing to worry about in your CI pipeline.

Setting Up Pint in a Laravel Application

Let’s walk through the steps of integrating Pint into a Laravel application. For this, we'll use a simple Laravel app as our use case.

Step 1: Create a New Laravel Application

To get started, let's create a new Laravel project:

composer create-project --prefer-dist laravel/laravel pint-demo

This will create a fresh Laravel project in the pint-demo directory.

Step 2: Install Laravel Pint

You can install Pint as a development dependency by running the following command in your Laravel project:

composer require laravel/pint --dev

This will install Pint in the vendor/bin directory, where you can run it whenever you need to format your code. You can run Pint on your PHP files using the following command:

./vendor/bin/pint

Step 3: Automating Pint with Husky and Git Hooks

Running Pint manually can become a chore. To automate this, you can set up a pre-commit Git hook to ensure that Pint runs and formats your code every time you make a commit. This guarantees that all committed code is properly formatted.

In order to make sure Pint runs automatically before every Git commit, we can use Husky, which is a tool that makes it easy to manage Git hooks in npm-based projects. Here's how to set it up in your Laravel project:

Install Husky: First, install Husky as a dev dependency:

npm install husky --save-dev

Set up Husky: Add the following script to your package.json to automatically set up Husky during npm install:

{
  "scripts": {
    "prepare": "husky install"
  }
}

Then, run npm install to initialize Husky:

npm install

Create a Pre-commit Hook: Set up a Git pre-commit hook that runs Pint before every commit:

npx husky add .husky/pre-commit "vendor/bin/pint"

chmod +x .husky/pre-commit

This command creates a pre-commit hook in the .husky directory that ensures Pint runs whenever a developer attempts to commit code.

Using Pint Inside Docker

In a modern development environment, many teams rely on Docker to ensure consistency across different machines. Running Pint inside Docker ensures that your development environment is identical, regardless of your operating system or local setup.

Step 4: Setting Up Docker for Pint

You can run Pint inside a Docker container using Docker Compose. Here's how to set it up:

First, add a docker-compose.yml file to your project if you don’t have one. Here’s an example configuration for a typical Laravel app:

version: '3.8'

services:
  app:
    image: php:8.1-cli
    volumes:
      - .:/var/www
      - ./vendor:/var/www/vendor
    working_dir: /var/www
    command: bash -c "while true; do sleep 1; done"

Modify your pre-commit hook to run Pint inside the Docker container. Open the .husky/pre-commit file and update it as follows:

# .husky/pre-commit

# Load .env variables from the project root, line by line
if [ -f .env ]; then
    while IFS='=' read -r key value || [ -n "$key" ]; do
        # Skip lines that are comments or do not contain valid key=value format
        if echo "$key" | grep -Eq '^[A-Za-z_][A-Za-z0-9_]*$'; then
            export "$key=$value"
        fi
    done < .env
fi

# Get a list of staged files
STAGED_FILES=$(git diff --cached --name-only --diff-filter=d)

# Separate PHP files from other files, only if there are staged files
if [ -n "$STAGED_FILES" ]; then
    PHP_FILES=$(echo "$STAGED_FILES" | grep '\.php$' || true)
    OTHER_FILES=$(echo "$STAGED_FILES" | grep -v '\.php$' || true)
else
    PHP_FILES=""
    OTHER_FILES=""
fi

# Exit early if there are no files staged (unlikely, but for safety)
if [ -z "$STAGED_FILES" ]; then
    echo "No files staged for commit. Exiting."
    exit 0
fi

# Run Pint for PHP files only
if [ -n "$PHP_FILES" ]; then
    if [ "$USE_DOCKER" = "true" ]; then
        echo "Running Pint in Docker for PHP files..."
        docker compose exec -T php vendor/bin/pint $PHP_FILES
        if [ $? -ne 0 ]; then
            echo "Pint failed while running inside Docker."
            exit 1
        fi
    else
        echo "Running Pint locally for PHP files..."
        vendor/bin/pint $PHP_FILES
        if [ $? -ne 0 ]; then
            echo "Pint failed while running locally."
            exit 1
        fi
    fi

    # Restage PHP files after Pint formatting
    echo "$PHP_FILES" | xargs -r git add
fi

# Restage all non-PHP files
if [ -n "$OTHER_FILES" ]; then
    echo "$OTHER_FILES" | xargs -r git add
fi

echo "Pre-commit hook completed successfully."

exit 0

This script checks if the USE_DOCKER environment variable (in your Laravel .env file) is set to "true". If it is, it runs Pint inside the Docker container. Otherwise, it runs Pint locally.

This setup gives flexibility to your team, as developers can choose whether they want to run Pint locally or in Docker.

Step 5: Running Docker Compose

To run Pint in Docker, make sure you have your containers up and running. You can start Docker Compose with:

docker compose up -d

Bonus: Best Practices for Running Pint in Laravel Applications

Here are a few tips and guidelines for fellow developers working with Pint and Docker:

Use Pre-commit Hooks: Automate Pint formatting with pre-commit hooks to enforce consistency.
Use Docker for Consistency: By running Pint inside a Docker container, you ensure that all team members have the same environment.
Customize Pint: Laravel Pint comes pre-configured, but you can customize its rules by adding a pint.json configuration file if you need to enforce specific styles.
Keep Docker Lightweight: In your docker-compose.yml file, mount only the necessary volumes (such as the application and vendor directories) to avoid performance issues.

Conclusion

Using Pint in your Laravel application is a simple yet powerful way to ensure consistent code quality and formatting.

By integrating it with Git hooks, Husky, and Docker, you can automate this process, making it part of your daily development workflow. Whether you run Pint locally or inside a Docker container, it can save time, prevent common formatting errors, and make your codebase cleaner and more maintainable!

Make Windows Terminal Awesome with ZSH and Oh My ZSH!

Paul Isaris — Wed, 15 May 2024 07:10:00 +0000

TL;DR

In this guide, we'll walk you through the installation and configuration of ZSH and Oh My ZSH on Windows, so you can
enjoy the power and flexibility of these tools without leaving the comfort of your Windows environment.

Introduction
Embracing ZSH on Windows
- Introducing ZSH: The Ultimate Shell Experience
- Oh My ZSH!: ZSH Supercharged
Step 1: Install Git + Git Bash for Windows
Step 2: Installation and Configuration of ZSH in Windows
- 2.1: Download ZSH
- 2.2: Install ZSH
- 2.3: Verify the ZSH Installation
- 2.4: Set ZSH as the Default Shell
- 2.5: Fix Displaying of Unexpected Characters
Step 3: Installation and Configuration of Oh My ZSH! on Windows
- 3.1: Installation of Oh My ZSH!
- 3.2: Customization of Oh My ZSH!
- Fonts
- Theme
Conclusion

Introduction

Are you tired of the mundane Windows command prompt?

Do you yearn for the powerful Linux terminal, but don't
want to deal with the complexities of WSL (Windows Subsystem for Linux)?

Well, rejoice, fellow developers, for there is a solution! With the
combination of:

you can transform your Windows command line experience into something truly remarkable.

Embracing ZSH on Windows

Introducing ZSH: The Ultimate Shell Experience

Image description: ZSH logo.

ZSH, or Z Shell, is a powerful command interpreter for UNIX-like operating systems. It offers advanced features
such as
improved tab completion, spelling correction, and extensive customization options.

Oh My ZSH!: ZSH Supercharged

Image description: Oh My ZSH! logo featuring a cute cartoon character with a command prompt.

But what truly takes ZSH to the next level is Oh My ZSH! This open-source framework for managing ZSH configurations
comes packed with a plethora of themes, plugins, and helpers.

Step 1: Install Git + Git Bash for Windows

If you haven't already, download and install Git for Windows from the
official website. This will give you access to Git Bash, which serves as the entry point for ZSH. You can find the
Git for Windows installer here.

Git Bash is needed so that we also have the bash shell available, which is required for ZSH to run, and also for
having the ~/.bashrc file available.
The ~/.bashrc file is installed at C:\Users\<your user name>\.bashrc.

IMPORTANT: Make sure to select the option to use Git from the Windows Command Prompt during the installation.

ALSO IMPORTANT: When opening the Windows Terminal app, make sure to select the Git Bash profile as the default
terminal profile! (Select it from the dropdown menu in the top right corner of the terminal window), and then set it as
default in the Settings.

Image description: Selecting Git Bash as a terminal profile

Step 2: Installation and Configuration of ZSH in Windows

Now that we understand the components, let's get down to business. Here's how you can install and configure ZSH and Oh
My ZSH! on your Windows machine without the need for WSL.

2.1: Download ZSH

Once Bash for Windows is set up, it is time to install ZSH:
Download the latest MSYS2 zsh package from the MSYS2 package repository. The file will be named
like: zsh-#.#-#-x86_64.pkg.tar.zst. You can find the latest version here.

2.2: Install ZSH

Extract the contents of the zip file (which will include etc and usr directories) into your Git Bash
installation directory. This will be in C:\Program Files\Git. You should merge the contents of the folder when
asked (
no files should be getting overridden).

2.3: Verify the ZSH Installation

Open Git Bash and run zsh --version to ensure that ZSH is installed correctly.

2.4: Set ZSH as the Default Shell

After installation, set ZSH as your default shell by appending the following to
your C:\Users\<your user name>\.bashrc file:

   if [ -t 1 ]; then
    exec zsh
   fi

2.5: Fix Displaying of Unexpected Characters

Fix the displaying of garbled characters on terminal by appending this line in
your C:\Users\<your user name>\.bashrc file:

   /c/Windows/System32/chcp.com 65001 > /dev/null 2>&1

Close and reopen the terminal, to save those changes. The first time ZSH will ask for some files creation.

Step 3: Installation and Configuration of Oh My ZSH! on Windows

As we said earlier, Oh My ZSH! is the cherry on top of the ZSH cake. Let's see how you can install and configure
it on your Windows machine.

3.1: Installation of Oh My ZSH!

Install Oh My ZSH!: With ZSH in place, installing Oh My ZSH! is a breeze. Simply run:

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

3.2: Customization of Oh My ZSH!

Fonts

Download and install manually
the Meslo Nerd Fonts to include
all glyphs and symbols that Powerlevel10k may need.

Theme

There are a lot of themes, with Powerlevel10k being the most popular and
powerful. To install it, check the instructions here.

Conclusion

Congratulations! You've now unlocked the full potential of ZSH and Oh My ZSH! on Windows. With its advanced features and
endless customization options, ZSH is sure to revolutionize your command line workflow. So why wait? Dive in today and
elevate your development experience like never before.

My Hacktoberfest 2022 contributions

Paul Isaris — Sat, 15 Oct 2022 06:20:09 +0000

Intro

My name is Paul, I come from the sunny country of Greece (locaten in Athens), and I am a software engineer with 8 years of experience in the field.
I work at a not-for-profit software company called SciFY, where we build software with a societal impact, like video games for the blind, assistive technologies, e-democracy tools, and more. Check out our Github profile! 🤩👨🏼‍🦽

SciFY Not-for-profit Company · GitHub

Ιnnovation using Science & IT | We bring technology and research results as usable solutions to everyday life - SciFY Not-for-profit Company

github.com

Background

I have studied Computer Science in Greece, and I much enjoy learning new things about everything! 🦾👨🏼‍🚀

Progress

I join Hacktoberfest every year, since 2017. I much enjoy the enthusiasm of the FOSS community, and the hype of open-source software during this month. I also get a chance to work again on small -yet important- updates and improvements of our open-source projects! 🎃🧙

Contributions

This year I decided to contribute to the very own projects of the organization I work for. We have some legacy application that needed revamping, and some others that are in the process of adding new features to.

More specifically:

1. ICSee (I Can See) Android app for people with low-vision

ICSee is an Android app, written in Java. It helps people with low-vision to see small texts through the phone camera, by applying special real-time filters.
In the context of Hacktoberfest 2022, I took the opportunity to upgrade the app to the latest version of OpenCV (the library we use to handle real-time image processing), as well as support new languages.

scify / ICSee

ICSee runs on small portable devices (smartphones, tablets) and makes reading and object identification easier. Simply, conveniently and always available!

ICSee

ICSee is an application that helps people with visual impairments see more clearly. It is developed by SciFY.

We created an application that allows people with visual impairments to read!

You can watch a video of the application in action here.

With ICSee:

The user can simply point their smartphone/tablet’s camera to what they want to take a better look at, and they see a processed, clearer image on their screen.
In this way, they can read a small text (e.g. the check or menu at a restaurant, the charge amount on the taxi meter the name on a doorbell).

How does it work? ICSee:

processes the image/video from a smartphone/table’s camera in real-time,
applies a series of filters, and
projects a result that’s easier to read or identify on the screen.

Abstract

It is an application for small portable devices (smart phones, tablets) that will help…

View on GitHub

2. Dianoia mobile app for people with emerging, early-stage dementia

People with dementia, due to the ongoing decline in their mental abilities, need proper care at each stage. Their carers feel they have a great responsibility in their hands. Therefore, dementia affects not only the person dealing with it, but the caregivers, too.

Dianoia is an Ionic smartphone app for family caregivers and health professionals in order to provide knowledge about simple techniques of non-pharmaceutical interventions will provide valuable insight and tools.

In the context of Hacktoberfest 2022, I took the opportunity to enrich the app with new content, fix several bugs, and make the UI look much smoother!

scify / Dianoia-app

Mobile (Ionic 3 - Angular 4) app about non-pharmaceutical activities and information for people with dementia.

Dianoia - Ionic Mobile app

A demo of the app (in Greek) can be found at scify.github.io/Dianoia-app.

Non-pharmaceutical activities for people with dementia

Pre-setup steps

This is a legacy Ionic 3 / Cordova 8 project that requires specific older versions of tools. Follow these steps carefully.

1. Node.js

It is very easy to install multiple versions of NodeJS and npm, by using Node Version Manager (nvm).

This project was built using the following versions of nodejs and npm:

node -v
v14.21.1

npm -v
6.14.17

If you are using nvm, run this command in order to sync to the correct NodeJS version for the project:

nvm install
nvm use

2. Java 8

This project requires Java 8 (1.8) - newer versions are not compatible with Gradle 4.x.

Install OpenJDK 8:

sudo apt update
sudo apt install openjdk-8-jdk

If you have multiple Java versions installed, select Java 8 as…

View on GitHub

Reflections

Like every year, it is beyond exctiting to see the software development communitu to passionate about such an innovative event. 🧑🏿‍🚀

This year, I also liked the inclusion of low-code or even no-code contributions, since I think that such endeavor will introduce open-source to an even wider audience! ❤️🥳

I look forward to participating in Hacktoberfest every year! 😄👨‍💻

PHP 8 Is here! A step in the right direction?

Paul Isaris — Sun, 11 Apr 2021 10:15:00 +0000

post photo by pexels

Introduction

PHP 8 is finally here!

PHP 8.0 is a major update of the PHP language.
It contains many new features and optimizations including named arguments, union types, attributes, constructor property promotion, match expression, nullsafe operator, JIT, and improvements in the type system, error handling, and consistency.

In this article, we will review all the new features and changes, and share some thoughts about each of the changes, as well as on the roadmap that PHP seems to be carving ahead.

You can read all about these in the official release announcement as well.

New features

Named arguments

In PHP 8, when calling a function, you can omit the non-required arguments, and pass only what is desired.

Named Parameters example

function my_awesome_function(string $name, string $value = "", int $expires = 0) {
    ...
}

Let's say now that we want to call this function, but only specify the $name and $expires attributes.

In PHP 7:

// calling the function. but we only want to specify $name and $expires
my_awesome_function('test', '', time() + 60 * 60 * 2)

In PHP 8:

// calling the function. but we only want to specify $name and $expires
my_awesome_function(name: 'test', expires: time() + 60 * 60 * 2)

My thoughts on named parameters

This is a nice and handy touch. Many languages nowadays support this kind of method calling.

However, this design can lead to functions that break the Single-responsibility_principle, by resulting in methods that "do too much" by having many parameters. So, as always, use with caution ;-)

Attributes

Attributes are the new kid in the block. It is essentially a configuration language embedded directly into code.

Attributes is a native PHP syntax that offers the ability to add structured, machine-readable metadata information on declarations in code: Classes, methods, functions, parameters, properties, etc.

Attributes Example

In PHP 7 (With PHPDocs):

class BookController
{
    /**
     * @Route("/api/books/{id}", methods={"GET"})
     */
    public function get($id) { /* ... */ }
}

In PHP 8:

class BookController
{
    #[Route("/api/books/{id}", methods: ["GET"])]
    public function get($id) { /* ... */ }
}

Constructor property promotion

The basic idea is simple: ditch all the class properties and the variable assignments, and prefix the constructor parameters with public, protected, or private. PHP will take that new syntax, and transform it to normal syntax under the hood, before actually executing the code.

Constructor properties example

In PHP 7:

class Point {
  public float $x;
  public float $y;
  public float $z;

  public function __construct(
    float $x = 0.0,
    float $y = 0.0,
    float $z = 0.0
  ) {
    $this->x = $x;
    $this->y = $y;
    $this->z = $z;
  }
}

In PHP 8:

class Point {
  public function __construct(
    public float $x = 0.0,
    public float $y = 0.0,
    public float $z = 0.0,
  ) {}
}

My thoughts on Constructor property promotion

Constructor property promotion reduces the amount of code that is required, leading to smaller and cleaner classes.

If you still want to have class properties that are not part of the constructor parameters, you can declare them in the old way, and instantiate them (or nor), inside the constructor.

Union types

Union types are a way of declaring multiple types for a property/variable.
So if a function parameter can take either string or int values, you can now declare it as string|int.

This is something that you could not do in PHP 7, only using PHPDocs (so it was not part of the PHP core libraries, but existed in the PHPDocs).

Instead of PHPDoc annotations for a combination of types, you can use native union type declarations that are validated at runtime.

Union types example

In PHP 7:

class Book {
  /** @var int|float */
  private $price;

  /**
   * @param float|int $price
   */
  public function __construct($price) {
    $this->price = $price;
  }
}

new Book('test'); // OK at runtime

In PHP 8, since Union types are part of the PHP runtime library and compiler, this will throw an error:

class Book {
  public function __construct(
    private int|float $price
  ) {}
}

new Book('test'); // TypeError

My thoughts on Union types

As a SOLID Principles advocate, I am not a big fan of this change.

I can understand that it can help speed things up and adds a level of control over my code, but I believe that if your code gets often to the point that you need to use union type for a property, then there is definitely something you need to think about.

Match expression

Match expression syntax is one of the nicest features in PHP 8 that improves the switch syntax in multiple ways.

Let's start by comparing the two. Here's a classic switch example (example from this article):

In PHP 7 (using switch):

switch ($statusCode) {
    case 200:
    case 300:
        $message = null;
        break;
    case 400:
        $message = 'not found';
        break;
    case 500:
        $message = 'server error';
        break;
    default:
        $message = 'unknown status code';
        break;
}

In PHP 8 (using match):

$message = match ($statusCode) {
    200, 300 => null,
    400 => 'not found',
    500 => 'server error',
    default => 'unknown status code',
};

My thoughts on the match expression feature

match will do strict type checks instead of loose ones. It's like using === instead of ==.
In my opinion, this is a good chance, since it makes the code stricter and more expressive.

Also, If you forget to check for a value, and when there's no default arm specified, PHP will throw an UnhandledMatchError exception.

Again more strictness, but it will prevent subtle bugs from going unnoticed.

To fix this, you should wrap the match expression inside a separate method, and deal with the UnhandledMatchError exception there, by returning a default value.

Nullsafe operator

Instead of null check conditions, you can now use a chain of calls with the new nullsafe operator.

When the evaluation of one element in the chain fails, the execution of the entire chain aborts, and the entire chain evaluates to null.

Example of nullsafe operator

In PHP 7:

$country =  null;

if ($book !== null) {
  $author = $book->author;

  if ($author !== null) {
    $address = $author->getAddress();

    if ($address !== null) {
      $country = $address->country;
    }
  }
}

In PHP 8:

$country = $book?->author?->getAddress()?->country;

My thoughts on nullsafe operator

I have mixed feelings about this.

Of course, it is a handy touch since it leads to less and definitely more readable code.

But again, by looking at the big picture, why would our code even need to check so deeply and greedily?

Should our code have Business rules that restrain such behavior?
So, again a handy new feature, but use with caution...

Saner string to number comparisons

When comparing to a numeric string, PHP 8 uses a number comparison. Otherwise, it converts the number to a string and uses a string comparison.

In PHP 7:

0 == 'foobar' // true

In PHP 8:

0 == 'foobar' // false

This is definitely a step in the right direction, but only given that PHP is trying to be a stricter language.

When we say equals, we should mean equals!

My overall thoughts on PHP 8

PHP is undoubtedly trying to become a stricter, more "serious" language.

As a big fan of OOP and SOLID Principles principles, I am totally happy and on board with this direction.

Also, as you will see in the upgrade guide, PHP 8 is generally backwards-friendly, since it does not break a lot of functionality from the previous major releases. Cool!

So let's try to use all the new features of PHP as consciously as possible, and build awesome things!

If you are content with the new PHP version, take a look at the migration guide.

What are your thoughts on PHP 8?

What’s New In the 2020 Scrum Guide Update

Paul Isaris — Sun, 29 Nov 2020 12:58:05 +0000

Post photo by pexels

Originally published on paulisaris.com

Introduction

2020 Is (finally) coming to an end, but it wouldn't leave us with anything less than another surprise!

On November 18, 2020, Ken Schwaber and Jeff Sutherland published an update of the Scrum Guide.

According to the co-creators, the Scrum Guide 2020 aims at “bringing Scrum back to being a minimally sufficient framework by removing or softening prescriptive language”.

In this article, we will review what was added, what was removed, what has not, and what you need to take care of.

For an audio version of the 2020 Scrum Guide, check this link

You can also see a side-by-side comparison of the new Scrum Guide here.

image taken from scrum.org

In a nutshell

Simpler language, more inclusion with the "Scrum team", Addition of "Why?" To Sprint Planning

The new Scrum guide adopted a simpler language and generally removed software-specific terminology.

The authors also reduced it's size, from 19 pages in 2017, to 14 pages.

No more "3 questions", no servant-leadership

The Scrum Guide is now less prescriptive, and more direct.

It eliminates many suggestions such as the Daily Scrum questions, removes the "at least one mandatory action item from the Retrospective becoming a part of the Sprint Backlog" part as well as the advice on why Sprint cancelations are rare events.

There is neither mention of the three questions during the Daily Scrum, nor of the term "servant leadership" of the Scrum Master.

No mention of "agile"

A very interesting fact though, is that there is not mention of the "agile" word!

Instead, there is an abvious shift towards getting Scrum to follow the "lean" principle.

Main motto not stated

Also, the obvious is no longer stated: Scrum is indeed not trivial to master.

In a bigger nutshell

Changes that are worth mentioning

Here are the bolder changes that are worth to review and reflect on:

1. No mention of the three questions during the Daily Scrum

OK, let's begin with the elephant in the room. No more 3 questions imposed in the Daily Scrum meeting!

Even in the 2017 versions, the three questions “What did I do yesterday that helped the Development Team meet the Sprint Goal?” and so on, were optional.

This means that the "Developers" (since there is no more a "Development Team"), can follow any structure they want, provided that it focuses on the plan for the day.

2. No more "Development Team"

That's right! The Development Team is no more. Long live the "Developers"!

This aims to eliminate the team within a team (often forming a silo) and normalize the often alienated relationship between the Product Owner and the Development Team.

Additionally, this change was to increase responsibility for the Product as one team and not just as the Product Owner.

Every member of the Scrum Team has the responsibility of the Product being built!

3. A brand new Sprint Planning

Since 2017, the focus on Sprint Planning was on "what we are building", and "how we are building it"
The Sprint Planning in 2020 has been enriched with a third topic - Why:

To make it easier for stakeholders to inspect a Product, the Scrum Team must now also focus on "Why" they are selecting the designated Backlog items, from the Product Backlog.

It's the job of the Product Owner to propose how this Sprint could increase the product’s value.

4. “Done” now creates a Product Increment

This change was made to embrace the quality of work.

According to the new guide:

"The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born."

5. Definition of Done Created By Scrum Team

Alright, so this is a big change.

From the 2020 Scrum Guide:

“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.”

While there are still explicit accountabilities for the Product Owner, Scrum Master, and Developers, all three roles must work together effectively to be successful with Scrum.

This is another evidence that Scrum now is following a more holistic approach.

A Definition of Done is most effective when created as a collaboration among the entire Scrum Team.

So, next time you are planning your Scrum and defining the Definition of Done, don't forget to also include the Product Owner and the Scrum Master in the process!

6. Don't present partially done items in the Sprint Review

That's right. we already knew that partially "Done" items were not accepted as part of the Increment.
But, this version of the guide goes a step further: Don't present them, and never speak about them until they are "Done".

"The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born."

7. A new term: The Product Goal

As the new guide states, there is a new kid around the block!

"The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. […] The Product Goal is the long-term objective of the Scrum Team."

Don't freak out, the Product Goal is not entirely new, since Scrum teams had a goal anyway. (What is the point of building software if you don't have a goal...?)

But it now has a name and it is clearly defined.

The Product Goal provides context to the Product Backlog.

It can be thought of as the "why" we are doing all of this work. It can be used as the elevator pitch to "what is the Scrum Team working on?".

So think of it more as a 1-sentence way of describing the whole product, and why you are building it!

8. Don't treat Sprint Review as a "Release Gate"

Many Scrum teams have shifted from constructive Sprint reviews to "Release Gates", making the Sprint Review just a meeting to tell the Product Owner "You can go ahead and release the increment now!".

The new Scrum guide addresses this by stating that

"The Sprint Review should never be considered a gate to releasing value."

So use the Sprint Review to learn and reflect, and detach it from the release cycle.

9. New Product Explanation

With a brand new Product Explanation, it becomes clear that Scrum now shifts beyond just software. In my opinion, it won't be long before we see Scrum implemented widely in non-software teams, as well.

"A product is a vehicle to deliver value.

It has a clear boundary, known stakeholders, well-defined users, or customers.

A product could be a service, a physical product, or something more abstract."

10. Servant leadership no longer mentioned

Even if servant leadership is not mentioned directly, I don't think that the authors aim to shape Scrum Masters to be anything else than servant leaders.

The new guide describes the Scrum Master as following:

"Scrum Masters are true leaders who serve the Scrum Team and the larger organization."

It is now likely that the "Scrum Master" job title will include a job description that is larger than the accountabilities described in the Scrum Guide since it is treated as an organization leader role.

11. The spotlight is on the Scrum team

"The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required."

This is a more holistic approach than the previous version had. Now, it is clearly stated that it's not only developers who bear responsibility for the product, but the team as a whole!

12. "Commitments"

The Product Goal, the Sprint Goal, and the Definition of Done are now mentioned as "Commitments".

This is a bridge to connect Scrum Values (commitment, focus, respect, courage, openness) with the "Scrum Empiricism": Transparency, Inspection, and Adaptation.

The Scrum Guide describes a commitment as:

“Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured.”

Each of the three artifacts now contains "commitments" to them.

Product Goal is the commitment for the Product Backlog.
Sprint Goal is the commitment for Sprint Backlog.
Definition of Done is the commitment to the Increment.

Conclusion

The 2020 Scrum Guide includes significant changes to the framework to broaden its appeal to applications beyond software development.

It simplifies the language used, and it empowers the "Scrum Team", in favor of the "Development Team".

It also makes the Sprint more meaningful, by making the Sprint Goal obligatory.
Scrum Master as a role is now treated as a leader of the organization, and not just a mere coach who acts upon request, as a servant leader.

In my opinion, the changes are in the right direction.

More responsibility to the team as a whole, and an apparent need for the Developers to start collaborating more with the Product Owner.

The Product Owner now has more responsibility for the Product Backlog, since they have to explain the current Product Goal to the whole Scrum Team.

But, don't fret. As stated on scrum.org website, Scrum is still Scrum!

What is your opinion on the Scrum Guide 2020 changes?

How to introduce a new developer to a project

Paul Isaris — Mon, 17 Aug 2020 08:03:26 +0000

Introduction

Often, there is a need to introduce a new developer to the team for a specific project.
This onboarding process is never easy and sometimes tends to be painful for the new member and frustrating for the team, which has to keep working on the already defined tasks without a significant impact on their productivity.

Of course, this process differs from team to team and is proportional to the seniority level of the new team member, as well as the time they have been working at the company.

I will try to keep the following guide as abstract as possible, to accommodate most cases. Keep in mind, though, to tailor the recommendations to fit your team's needs and post your thoughts in the comments!

This guide assumes a typical 8-hour workday. It is further divided into subsections, with ideas about what to do during each time of the day. Feel free to update it according to the habits and ceremonies of your team, to maximize value.

The 2-day plan

Day 1

This is the first day that the new team member will start working along with your team. It is a very special day, of course!
You don't want to stress them or to make them feel lost, even though it is highly likely that they will feel overwhelmed anyway.
Try to be as cool as possible and not throw deadlines and project reports to their face.
Your job is to make them feel welcome and productive.

Day 1 - Morning:

A short overview of what the business does (an hour, tops) - understanding how the company makes money is essential. If the new developer is in the company already, then a brief introduction of the project is in order, along with the business side - how the project works and how the client makes revenue.
A short overview of the high-level architecture (no more than a couple of hours). If the team has already decided upon frameworks, Database technologies, 3rd party libraries, or external APIs, this is something that should be communicated in time.
A learning plan for project-specific technologies. The new developer needs to feel not only that they have the time required to get up to speed with all the languages and the frameworks, but also that there is no time to slack off, or feel unproductive.

Day 1 - Afternoon:

Update on the learning plan; Questions, answers, and a small update of what has been taught so far. The goal of this is that the new developer does not waste time researching everything about the new language/framework, but only this 20% that will get them going and become productive, according to the Pareto Principle
** learning** how to set up a project in the new language/framework. They will need to do that anyway so that it will come in handy.

Day 2

During this day, the new team member should get cracking with real project tasks. However, this doesn't mean that the learning stops. On the contrary, the learning now has a supplementary role, and it becomes less important as the tasks progress, and the developer feels more comfortable.

Day 2 - Morning:

** project set up and initialization**. If the project has an existing codebase, the new developer will need to clone it to their machine, set it up, and get it to compile/build/run (depends on the framework). This is usually not easy, and every other developer on the team needs to pay attention here.

Often, this process reveals a lack of proper documentation of the project. Developers sometimes assume things, especially for the installation/set-up procedure of a project. So this is an excellent opportunity to revamp the documentation of the project and make sure that there are no assumptions.
A specific task which gets them familiar with just one or two files in the codebase, done with one of the more experienced programmers sitting with them to help 1:1. It is crucial for a new developer not to feel alone on a task.
The best strategy is to assign them to a task that only exposes them to as few files as possible so that they don't feel lost.

Day 2 - Afternoon:

A couple of short specific tasks with an experienced programmer dedicated to helping a "small group of starters" (typically 2–3).
Flying solo on a small task, but knowing that they can ask for help [this never stops.
Repeat, with increasingly larger tasks, covering more of the codebase.

At this point, the new developer should already feel comfortable and productive. However, remember that as the difficulty of the tasks increase, they may feel overwhelmed again, and that's usually when the Impostor syndrome occurs.
So, it becomes obvious that the new team member should feel free to ask any questions, no matter how "stupid" or "obvious" they may seem.

What to do now - action points

After you have read this guide, it's time to get cracking and create your personalized onboarding plan!
Of course, your organization has its own rules and pain points, and the team your a member of may benefit from different situations and habits.

After all, it's your responsibility to create an onboarding guide that best fits and serves your team's needs.

So, go ahead and don't be afraid to spend some time writing down ideas and situations that you and your team found difficult and unsustainable in the past. Then, write how these problems could be alleviated, by applying the 2-day onboarding plan, and ** don't be afraid to try** your plan (we only get better by trial and error!)

Last thoughts

To conclude, adding a new member to a software team is not an easy task. Sometimes we forget how important the onboarding process can be, resulting in poor estimates (as the onboarding is hugely underestimated), Impostor syndromes, and confusion for the entire team.
Having a solid and effective onboarding plan is crucial as it ensures both productivity and good morale for the entire team.

10 Tips For a Productive Virtual Meeting

Paul Isaris — Wed, 01 Apr 2020 05:41:08 +0000

Photo by John Schnobrich on Unsplash

Originally published at paulisaris.com

Introduction

It's this strange time of the "Social distancing era", because of the coronavirus bizarre situation.
Regardless of how long this lasts or whatever the world will look like after it ends, it is for sure an interesting time to be alive and trying to make a living through a pandemic.

We, as developers, are fortunate enough to be able to still work with little to no severe impacts
in our everyday tasks and projects. Most of us have set-up our homework offices, poured ourselves a cup of
coffee or tea and get cracking with our tasks.

However, with everything that is happening around the world, teams now face the challenge of doing most of their work virtually. Meetings with the team and the clients, code reviews, Scrum events, all work-related social events have been moved to the "virtual world".

What this essentially means, is that we should find a way to remain productive and professional, even in this scenario.
Some of us have been having more experience with this, while some others are just being introduced to the world of virtual meetings, and they need some guidance.

In this post, I share 10 tips for ensuring that we have productive meetings and that value is being delivered, no matter the situation.

The Steps

1. Prepare some material beforehand

It's crucial for the meeting to be targeted towards a well-known goal and subject.
Spend some time to bring together a document (which preferably can be edited online by key participants). This is very important in the case that you are hosting the meeting.
In this document, specify the meeting goal (or leave it to be completed as soon as the meeting starts).

Also, don't forget to prepare any links, presentation files, videos, application credentials and notes that you may need during the meeting.

Being well prepared is a sign of utmost professionalism, something we all like to be congratulated for!

2. Prepare and check your equipment

Nobody likes to join a virtual meeting only to find out that their camera is not working or that their microphone is hissing and making weird noises.

At least 30 minutes before the meeting starts, dedicate some time to set up your equipment. Make sure that the room has the proper lighting for the camera, and that your voice sounds as expected through the microphone.

Most software applications for virtual meetings (eg Skype, Hangouts, Zoom, etc) have a built-in process for doing the tasks above. Spend 2 minutes before the meeting starts to do a final technical check-up and be ready!

3. Please, mute your microphone!

Seriously, I can't stress this enough. As long as you are not speaking, please mute your microphone. It makes everyone's life difficult and makes people want to leave the meeting even more.

Also, when the meeting starts, remind everyone of the golden "Mute when not speaking" rule.
It's extremely easy to unmute your microphone when you want to speak or ask a question.

If the Internet connectivity is not good during the meeting, you can kindly ask the other participants to close their cameras so that you can hear them (even though you will not be able to see them).

4. Set the mood for the meeting

If you are hosting the meeting, it's always a good starter to set the mood.
Start by asking you everyone is doing so that you add a personal touch. Remember, all participants are joining the meeting from their personal space which may include crying kinds, noisy neighbors, shouting construction site workers (even though the latter is not the case in a pandemic).

Begin by sharing the document from step 1, and ask everyone to confirm that they have access to see it. Remark the meeting goal and try to come up with an estimation of how long the meeting should be so that all the participants are on the same page and can organize their after-meeting tasks better.

5. Set the rules for the meeting

Again, this is very important, especially if you are the host. Remember, that some of the participants might be using the virtual meeting software for the first time, so it's a nice idea to take some time and explain how the meeting is going to run.

For example, you can start by prompting everyone to mute their microphones (after the introductions of course) and use the "raise hand" functionality when they want to intervene.

Besides, it goes without saying that if a participant is acting selfishly (by not letting others speak for example), you should address the problem by reminding them of the rules throughout the meeting.

6. Prepare your environment for screen-sharing ;-)

When participating in a virtual meeting, you might need to share your screen for several reasons. Be it that you want to show something to the people or to showcase the application you have been working on to a client.

The thing is that during this pandemic era, we are working from our home setups. This means that you will probably be using your home computer to join the meeting.
So, your desktop, web browser and applications window should be in a "presentation-ready" state ;-)

7. Don't be afraid to close the camera

Working from home also means using the home network. Especially in the case that you are using Wi-Fi, your Internet connectivity might not be the best. To add insult to injury, remember also that, because most people are working from home, Internet networks are stressed already and you might not get a good service.

In the unfortunate event that this happens, excuse yourself by explaining the situation and feel free to close your camera. After all, the important part of the meeting is probably to be able to hear the other participants and be able to communicate with them.

8. Revise often and take notes

It is a common scenario that virtual meetings go on forever, and after a while, people don't pay attention to what is being said. After all, there is no one around to restrain them from checking their phones or open a new tab in the browser...

You should make sure that value is being delivered through the meeting. So note-keeping will both keep you concentrated on the meeting and will result in an organized after-meeting roadmap for the next steps.

Additionally, if you are the host of the meeting, you should often vocally revise what is being said, to wake up the participants who are slacking off and prompt them to voice any objections or additions they might be having.

9. Resist the urge to check your phone

As stated in the previous step, it is a common thing for virtual meetings to result in only a handful of people paying attention while all the others are checking and replying to their e-mails or checking their social media.

It's important to resist the urge to do so! Remember, participating in a meeting -whether virtual or not- means that you have the responsibility to be present in your full professional "outfit". After all, you might miss something really important which will probably result in numerous other meetings and e-mails!

10. There will be chaos. And that's OK!

Sure, everybody will try their best for the meeting to be as efficient and productive as possible. However, bear in mind that chaos (either technical or not) should be expected.

The microphones will not be operating as planned, networks will fail, whole sentences will be asked to be repeated for people who "did not quite catch the last 5 minutes of your talk".

And you know what?

This is perfectly fine. As developers, we are experienced in working with technical difficulties and finding alternate solutions to our problems: Skype is not working? Let's all switch to Zoom. Microphone not working? Fine, write in the chatbox.
The whole meeting thing is not working? Fine, let's either organize another time for it or compress it in an e-mail (after all, most meetings should have been e-mails, right?)

Conclusion

In these strange yet important times, it is more vital than ever that we are able to prove that technology is helping things keep moving and we -as a purely technological field- are obliged to do so.

What are your thoughts on virtual meetings?

Scrum Events demystified - Sprint Planning

Paul Isaris — Tue, 18 Feb 2020 15:29:18 +0000

post photo by pexels

Introduction

This post is the second part of the "Scrum events demystified" post series. You can find the first part here:

Paul Isaris

Feb 2 '20

Scrum Events demystified - The Sprint

#agile #productivity

5 min read

In order to successfully execute the Scrum tasks and maximize the Increment value, a team needs to pay attention to the chronologically first Event in the Sprint; The Sprint Planning event.

About Sprint Planning

Sprint Planning is a time-boxed event (as all events are in Scrum).
Time-boxed means that it has a predefined, specific time span,
and should start and end exactly when this period dictates.

For example, the team might agree upon having one-month Sprints.
Other teams might be more comfortable and productive with 2-week Sprints.

For 1-month Sprints, the Sprint Planning event should be 8-hours long.

Who should attend the Sprint Planning event?

Everyone (Product Owner, Scrum Master, Development team).

The Sprint Planning event's goal is to address the following topics:

Selecting the work to do in the Sprint

The product owner explains the backlog items to the Development team.
The development team determines the number of backlog items that will be brought into the Sprint Backlog
Planning how the sprint work will be done

The Development Team does this. The Development Team needs to only do necessary planning work for the first few days of the Sprint. As the development team analyses the work they selected from the backlog, they can renegotiate the work with the Product Owner.
Ideally, the Sprint Backlog tasks are decomposed so they can be finished within a business day.

During the Sprint Planning event, the Development Team is supposed to construct the Sprint Backlog, a collection of tasks that will be owned and developed by the Developers.

According to the Scrum Guide:

"The Sprint Backlog is a plan with enough detail that changes in progress can be understood at the Daily Scrum”

Most common questions and misconceptions about Sprint Planning

Why is Sprint planning important?

Sprint Planning is important because the outcomes of it are the Sprint Goal and a plan of delivering the Increment. Both the Sprint Goal and -of course- the Increment are integral parts of the product development process and define whether the product will be successful or not.

Should the Sprint Backlog remain intact after Sprint Planning?

No. The Development Team modifies the Sprint Backlog throughout the Sprint, And the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the Sprint and gains more knowledge about the work.

Should the tasks in the Product Backlog be User stories?

No. Actually, the tasks in the Sprint Backlog can be expressed however the Development Team desires, as long as they are clear and communicate the work to be done.

How are the Product Backlog items prioritized and by whom?

In Scrum, The Product Owner is responsible for maximizing the value of the product and they manage the Product Backlog as such. During Sprint Planning the Product Owner suggests the objective of the upcoming Sprint and proposes which Product Backlog Items will help achieve this objective. So, the items in the Product Backlog are ordered by value. The most important ones go at the top so that they are selected for the next Sprint Backlog.

Does the whole Scrum team agrees on the estimates for a task?

No. Only the development team creates estimates, which can, of course, be communicated with the other stakeholders (Product Owner and business stakeholders), but in no way negotiated with them.

When a task is assigned to a developer, are they solemnly responsible for it?

No. All tasks in the Sprint Backlog belong to the whole Development Team and the whole Development Team is responsible for them.

Is the Sprint Backlog just a collection of tasks selected from the Product Backlog, to be done in the current Sprint?

No. The Sprint Backlog also contains a plan of how the work will be done. It might contain tasks, sub-tasks, notes, and development guidelines.

Conclusion

In conclusion, the Sprint Planning event is a time-boxed event, during which the Scrum Team discusses the next Sprint, it's goal and how this goal will be achieved. The Product Owner prioritizes the user stories in the Product Backlog and the Development Team picks the user stories and creates estimates for them.

The team discusses in more detail how they will deliver the selected product backlog items. This may (but does not have to) include identifying tasks for the product backlog items, whether there are any dependencies between the items, and discussing the technologies or development paradigms that will be utilized.

In this series, I will be clarifying all Scrum events and demystifying the most common misconceptions about them.

Please share your thoughts in the comments, and stay tuned for the
next part of the series!

Scrum Events demystified - The Sprint

Paul Isaris — Sun, 02 Feb 2020 09:36:49 +0000

post photo by pexels

This post was originally published on my personal blog

Introduction

This post is the first part of the "Scrum events demystified" post series.
In this series, I will try to shed some light on the most common events in the Scrum framework.

First things first, let's begin by defining Scrum:

According to the Scrum Guide:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is a process framework that has been used to manage work on complex products since the early 1990s.

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.

Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

Indeed, Scrum is successfully used for many years now, from teams that want to carry out risky projects in an Agile way.
A critical part of the Scrum methodology is the Scrum Events.

All in all, Scrum (as much as most Agile methodologies) has an
allergy when it comes to long, pointless meetings that include
business people and only result in:

Countless hours lost from what could have been productive work
Developers wondering what they did to deserve one more PowerPoint presentation
A ton of calories gained from the pastries that are usually served

Today I will be presenting the heart of Scrum,
the most important of all Scrum events; The Sprint.

Disclaimer: Some might argue that the Sprint is , not
an event itself since it merely acts as a container for all other
Scrum events. This, of course, is true, but it is beneficial to treat it as an event (or a pseudo-event) to get a better grasp of what Scrum is about.

About the Sprint

The Sprint is a time-boxed event (as all events are in Scrum).
Time-boxed means that it has a predefined, specific time span,
and should start and end exactly when this period dictates.

For example, the team might agree upon having one-month Sprints.
Other teams might be more comfortable and productive with 2-week Sprints.

It is generally up to the whole Scrum Team to decide the time span,
given considerations such as the team composition, the risk of the project,
and the team members' availability.

Once the Sprint starts, the team focuses on the tasks that were selected for work and that will add up to the final Sprint Increment, for the pre-defined Sprint Goal to be completed.

These tasks (and the Sprint Goal) should have already been defined and agreed upon during Sprint Planning (another Scrum event that will be presented in the next article of the series).

During the Sprint, the team is supposed to work uninterrupted on the tasks that compose the Sprint Backlog. Any external changes and requests are not welcome, since they are destined to decrease productivity, and should either be discarded or be dealt with by the whole Scrum Team.

Most common questions and misconceptions about Sprints

What is the maximum time for a Sprint? Can the team have 2-month Sprints?

The maximum time that a Sprint may last is one month. Anything more
than that decreases focus and should be broken into multiple Sprints.

What does the team need to start a new Sprint?

For a Sprint to start, the team needs 3 things:

A Sprint Goal
The Sprint Goal is set during the Sprint planning and should not change during the Sprint. It describes what the output of the Sprint
should be and is agreed upon by the whole team
A Sprint Backlog
The Sprint Backlog is the collection of tasks that should be done during the Sprint. They are picked from the Development
Team by looking at what the Product Owner has prioritized in the Product Backlog.
A General plan of how the team should do the work
During Sprint Planning, the team decides not only what should
be done during the Sprint, but how things should be done.

This has to do with the Definition of Done the team has set for
the project and should be flexible enough to tolerate unexpected changes, and evolve with them during the Sprint.

Who is responsible for defining the Sprint Goal for a given Sprint?

The Product Owner is responsible for maximizing the value of the product
and they manage the Product Backlog as such.

During Sprint Planning the
Product Owner suggests the objective of the upcoming Sprint and proposes
which Product Backlog Items will help achieve this objective.

Can the Sprint Goal change during the Sprint?

No. As the Scrum Guide states:

No changes are made that would endanger the Sprint Goal.

If the Sprint Goal becomes obsolete or does not make sense anymore,
then the Sprint should be canceled by the Product Owner

Can a Sprint be terminated before the designated date? Who is responsible for terminating it?

Yes. As I described above, a Sprint can be canceled if ** its goal becomes obsolete*. This may happen when the business goals of the company change, or the market needs dictate so.
The only person able to cancel the Sprint is the **Product Owner*.

What if the Development Team finishes all the work that is in the Sprint Backlog?

The Sprint Backlog (the collection of tasks that the team has agreed
to carry out during the Sprint) is subject to change.

If all the tasks are done ("done" as to meet the Definition Of Done), the Development team can choose new tasks from the Product Backlog and bring them into the Sprint Backlog.

What if at the end of the Sprint there are unfinished tasks in the Sprint Backlog?

This is again very common. A remark that should be made here is that
the Development Team agrees to complete a set of tasks during the Sprint,
but is in no way obliged to complete them at any cost.

When the time is over, the Sprint is over as well. Any unfinished tasks
do not count as part of the Sprint output and are put back into the Product Backlog.
Usually, these tasks will be brought into the Sprint Backlog of the next Sprint, for the Development Team to finally complete them.

What happens between 2 Sprints?

Nothing! As soon as the first Sprint is over (and by "over" we mean that all of other events contained in this Sprint are done), the new Sprint begins right away.

What if someone from the Development Team leaves the company during a Sprint?

These changes are not common, but the Development Team and the Sprint should be Agile enough to tolerate such changes.

Usually, there may be a decrease in productivity for some time, and some tasks might remain unfinished and go back into the Product Backlog when the Sprint ends.

Conclusion

In conclusion, the Sprint is a time-boxed event, during which the Development Team works towards a pre-defined goal that will add value to the product (the Increment), and acts as a container for other
Scrum events.

In this series, I will be clarifying all Scrum
events and demystifying the most common misconceptions about them.

Please share your thoughts in the comments, and stay tuned for the
next part of the series!

Creating a pagination component in Vue JS

Paul Isaris — Sat, 12 Oct 2019 12:27:00 +0000

Introduction

This article was originally published at my blog.

post photo by pexels

Vue.js is a progressive JavaScript framework that allows you to create compelling
user interfaces efficiently and easily.

In this post, we are going to create a pagination component, able to have a dynamic number
of steps!

Our final application will look like this:

Of course, you can find the Github repo here:

PavlosIsaris / Vue.js-pagination-example

This is a simple Vue.js application showcasing a basic pagination component.

Project set up

use the vue cli to create out app:

npm install -g @vue/cli

Next, we make use of the CLI to create all the boilerplate for our app:

vue create pagination-component-vue-example

In order to verify that the initialization part was successfully completed,
let's go into our project's directory and serve our app:

cd pagination-component-vue-example
npm run serve

If everything goes as planned, we will receive no error messages, and will
see the Vue.js default page upon navigating to http://localhost:8080/:

Vue runs some initialization commands, and our project has been created.

It's time to design our app!

We will create a pagination component that will take as parameters

And we will use the app component in order to test it.

First thing first, let's get rid of the src/components/HelloWorld.vue.

We are going to create a src/components/PaginationComponent.vue which will hold
the logic for our pagination component.

In this tutorial, I will use Bootstrap in order to
style the HTML in a clean way, but feel totally free to skip this step (or use another HTML library).

Change src/App.vue to reflect the following:

<template>
  <div id="app">
    <pagination-component></pagination-component>
  </div>
</template>

<script>
import PaginationComponent from './components/PaginationComponent.vue'
import 'bootstrap';

export default {
  name: 'app',
  components: {
    PaginationComponent
  }
}
</script>

<style>
  @import "~bootstrap/dist/css/bootstrap.min.css";
</style>

For the time being, we can leave our src/components/PaginationComponent.vue empty and dumb:

<template>
   I'm an example component.         
</template>

<script>
    export default {
        mounted() {
            console.log('Component mounted.')
        }
    }
</script>

Designing our pagination component

Now, we need to converge on what our pagination component should do, what it's limitations would be,
and how it should be used by our app.

In my app, I decided that I would like to have a "only backwards free" strategy, meaning that
Once the user is on the n'th step, they should only be able to navigate to previous steps through
the navigation links.

In order fo the user to move forward, they need to click on the "Next" button.
This may come in handy when you have a paginated form with steps, in which you would like to\
perform some sort of validation before allowing the user to proceed to the next step.

Having these functional requirements in mind, we can construct a steps array that will
be passed from the app component own to the pagination component.

So, let's change our App.vue to reflect the following:

<template>
  <div id="app">
    <pagination-component></pagination-component>
  </div>
</template>
<script>
import PaginationComponent from './components/PaginationComponent.vue'
import 'bootstrap';
export default {
  name: 'app',
  components: {
    PaginationComponent
  },
  data() {
    return {
      steps: [
        {
          title: 'Introduction',
          allowNext: false
        }, {
          title: 'Second',
          allowNext: false
        }, {
          title: 'Third',
          allowNext: false
        }, {
          title: 'Final',
          allowNext: false
        }
      ]
    }
  }
}
</script>

We constructed a steps array, which will define the different "pages" in the pagination component.
The allowNext property can define whether we would like the user to be able to go to the next step by clicking on
the pagination link.

Dynamic number of slots

Next, we would like to hae a way of defining a dynamic number of slots in the pagination
component, so that we can pass as many steps as we want.
Before that, let's redesign our pagination component to reflect the following:

As we can see here, we use the steps prop in order to show the pgination header link (as a
bootstrap breadcrumb item), as well as the corresponding Vue slot.

Creating the dynamic slots

Now, its time to tie it all together!
Update App.vue to reflect the following:

As you can see, we pass a dynamic number of template components, that will serve as each
of the steps' content. The limitation here is that the number of the templates should be equal to
the number of the steps that we create in the data section of App.vue.

Example Usage

Pretty cool, huh?

How to be awesome at your daily stand-up with 7 steps

Paul Isaris — Tue, 20 Aug 2019 15:53:23 +0000

This article was originally published at paulisaris.com

Introduction

A daily stand-up meeting is an essential part of many workplaces these days.

Either when following the Scrum methodology or simply
when wanting to tighten the bonds between the team members and stakeholders,
the performance of the daily stand-up can either make or break your day.

Let's be honest here. Every workplace does their stand-ups differently.
But that's really OK! It's not another formal, dull meeting that requires you to stick
to the procedure. On the contrary, stand-up meetings are part of the Agile
approach, meaning that the practices and procedures should be adaptive and flexible.

A good and compact stand-up meeting is a great way to organize a team and plan your day.
However, sometimes the meeting gets a bad rap.
Some even argue it’s an outdated practice and a waste of time.

So, I put together the best tips and tricks to help your daily stand-up meeting run
like a lean, mean, effective machine.

What is a stand-up meeting, to begin with?

According to Wikipedia:

"A stand-up meeting (or simply "stand-up") is a meeting in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short."

But, why on earth would we want to be uncomfortable when having a meeting?

Truth be told, meetings suck. And, especially in the Software Development industry, meetings suck big time.

Endless hours, managers and other business-related people demanding financial and sales goals, powerpoint presentations, and bowls with stale cookies are usually the settings which make us, developers, wanting to jump out of the closest window.

With the introduction of Agile and Lean development methods, there is a profound need to eliminate these deadly meetings, while keeping all team members informed. And voila, we now have the stand-up meeting, aiming to be extremely compact and productive. No bullshiting, no long introductions, no stale cookies. Just the gist of the day!

So, let's see a list of rules that will help you perform well in your stand-up, and manage to get the most out of it:

1. Cut it short

Make sure you respect the stand-up rules, pal. "The discomfort of standing for long periods is intended to keep the meetings short.", so why torture your fellow co-workers?
A key point here is to plan ahead. Note down the high-level tasks you accomplished last day, and try to focus only on the main problem you face today.
This will not only help in keeping the meeting short, but it will also keep your focus on the main impedance, for which you may ask a co-worker for help after the meeting. ;)

Survival Tip: Keep notes before the meeting

2. Respect (and don't interrupt) others

I know that you want to help. I know that you are just a good comrade who has something to add to the conversation and has to do it NOW.
But for the love of God, let the speaking person finish. They are trying to squeeze a hard ay's work into 1 minute, so don't make it more difficult for them!

Also, try not to converse with others while someone is talking. It's just bad manners. The whole meeting is just a few minutes long, I bet you can wait until it's over.

Survival Tip: Keep notes during the meeting, so that you can elaborate on what others said, later on.

3. Don't look at your phone (or computer screen)

Keeping meetings sane is all about respect. And you may be disrespectful even without knowing it. Glancing at your phone to check your social, or checking your emails/perform an update on your computer may be tempting tasks to perform while someone is talking, but just imagine how you would feel when, while saying something important, everyone was staring at their screens or scrolling through Instagram...

Don't worry, an effective stand-up meeting is only several minutes long, so you will have the chance to re-connect with the online world soon enough.

Survival tip: put your phone away and turn off your screen as soon as the stand-up meeting kicks off.

4. Shape your high-level tasks

I know that you struggled with that Database connection for half a day and tried to debug that @&)&@#! outdated npm package version mismatch for the better part of this day.
Honestly, nobody wants to hear about that, not in this level.

Especially when having non-developers participating in the stand-up meeting, it is crucial to shaping your tasks in a way that will be comprehensible by all members.

Keep in mind that learning how to describe a technical task in a non-technical way is of great importance in general;
It will make you look like a human to non-developers and will boost your soft skills greatly!

Survival tip: Write down your tasks and, for each task, come up with a high-level, non-technical title.

5. Prioritize, prioritize, prioritize

I simply can't stress this enough. Just think about it: You participate in a meeting and you have seconds to describe a full day's work.
Don't make the mistake of beginning with the most recent tasks. I know that it's these tasks that pop into your mind more easily, but you should prioritize first what *would make sense for the other members, as well.

If you have a task involving another member, or if you have an update on a task that concerns someone else, please be a lamb and start with that one!
You will catch everyone's attention more easily, and they will able to chip in with their feedback as well (after the meeting has ended).

Survival tip: Start with tasks concerning other team members, before losing their attention.

6. Ask for help

You heard me. Stand-ups are not just about describing a list of tasks you did. On the contrary, they are also about ensuring that you will make it through the day so that you will be able to describe new tasks tomorrow (hehe).

If you face a problem regarding something and you are passed the point of googling it with no success, you should ask for help. Asking for help is not about being ignorant or lazy. It's about being professional. Your goal is to do your tasks and if some other co-worker can help you with that, then they can help you with your goal.

So, don't be selfish and ask for help before losing more time trying on your own. This does not mean of course that you should ask for help every time you face a problem. You should be (or become) mature enough to admit when you can't go on on your own but would like some help.

Survival tip: Make sure you ask for help on time, by forming the right questions.

7. Proactively offer help

Continuing from the previous item, it's easy to imagine that many people have a hard time when asking for help. Your job is to solve problems, so why making it difficult for them? If you pay attention to what others say during the stand-up, you will find plenty of chances to offer your help.

Being a technical problem you have faced before or a non-technical task you have already encountered, there are many things which you can help alleviate. Your co-workers will look up to you as a role model, and they will become even better at asking and offering help.

Survival tip: Listen carefully to what others say. You will find many chances to offer your help.

Conclusion

Stand-up meetings should not be another dull chore in the office.
When done correctly, they can prove a beneficial asset to any team and
can even strengthen the bonds between the team members.

With the right steps, we can make sure to make the most out of them,
by being focused on efficiency and respecting your co-workers.

DEV Community: Paul Isaris

Serving Large Private Files from Laravel

Serving Large Private Files from Laravel

Introduction

The naive scenario, and why it fails

Keep the files where they are, point a disk at them

One authorized endpoint

Cache it privately

The tests that pin it down

Is streaming through PHP fast enough?

Three things that need attention

Trade-offs to accept

Conclusion

Mastering Code Quality in Laravel: Pint with Git Hooks and Docker

Mastering Code Quality in Laravel: Pint with Git Hooks and Docker

Introduction

Why Use Pint in Laravel?

Setting Up Pint in a Laravel Application

Step 1: Create a New Laravel Application

Step 2: Install Laravel Pint

Step 3: Automating Pint with Husky and Git Hooks

Using Pint Inside Docker

Step 4: Setting Up Docker for Pint

Step 5: Running Docker Compose

Bonus: Best Practices for Running Pint in Laravel Applications

Conclusion

Make Windows Terminal Awesome with ZSH and Oh My ZSH!

TL;DR

Table of Contents

Introduction

Embracing ZSH on Windows

Introducing ZSH: The Ultimate Shell Experience

Oh My ZSH!: ZSH Supercharged

Step 1: Install Git + Git Bash for Windows

Step 2: Installation and Configuration of ZSH in Windows

2.1: Download ZSH

2.2: Install ZSH

2.3: Verify the ZSH Installation

2.4: Set ZSH as the Default Shell

2.5: Fix Displaying of Unexpected Characters

Step 3: Installation and Configuration of Oh My ZSH! on Windows

3.1: Installation of Oh My ZSH!

3.2: Customization of Oh My ZSH!

Fonts

Theme

Conclusion

My Hacktoberfest 2022 contributions

Intro

SciFY Not-for-profit Company · GitHub

Background

Progress

Contributions

1. ICSee (I Can See) Android app for people with low-vision

scify / ICSee

ICSee runs on small portable devices (smartphones, tablets) and makes reading and object identification easier. Simply, conveniently and always available!

ICSee

Abstract

2. Dianoia mobile app for people with emerging, early-stage dementia

scify / Dianoia-app

Mobile (Ionic 3 - Angular 4) app about non-pharmaceutical activities and information for people with dementia.

Dianoia - Ionic Mobile app

Non-pharmaceutical activities for people with dementia

Pre-setup steps

1. Node.js

2. Java 8

Reflections

PHP 8 Is here! A step in the right direction?

Introduction

New features

Named arguments

Named Parameters example

My thoughts on named parameters

Attributes

Attributes Example

Constructor property promotion

Constructor properties example

My thoughts on Constructor property promotion

Union types

Union types example

My thoughts on Union types