DEV Community: Timothy Karani

Laravel 10.x + Livewire 3.x Pre-Commit Linting and Formatting

Timothy Karani — Mon, 15 Jan 2024 23:43:19 +0000

Introduction

When creating Laravel+Livewire projects, especially for teams, pre-commit hooks come in handy by ensuring everyone on the team follows the same formatting standards and adheres to some level of code quality. In this blog-post we will use:

husky: Sets up pre-commit hooks
prettier: To format *.css, *.js and *.blade files.
@shufo/prettier-plugin-blade: A prettier plugin for formatting *blade files
laravel/pint: to format PHP files like classes, traits, etc.
larastan: does PHP static analysis.

Installation

Assuming you are creating a project from scratch, let us begin the set-up.

Create a new project, I will name mine livewire-precommits-demo:

$ composer create-project laravel/laravel livewire-precommits-demo

Open the project, initialize git and make the first commit:

$ cd livewire-precommits-demo
$ git init
$ git add -A
$ git commit -m "First of many"

Install husky, prettier, and @shufo/prettier-plugin-blade as dev dependencies:
```
$ npm i -D husky prettier @shufo/prettier-plugin-blade
```

Add Laravel Pint:

$ composer require laravel/pint --dev

To test it out in action:

$ ./vendor/bin/pint

Install Larastan:

$ composer require larastan/larastan:^2.0 --dev

Create a phpstan.neon file in the root of the project with this:

includes:
    - vendor/larastan/larastan/extension.neon

parameters:
    paths:
        - app/

    # Level 9 is the highest level
    level: 5
#    ignoreErrors:
#        - '#PHPDoc tag @var#'
#
#    excludePaths:
#        - ./*/*/FileToBeExcluded.php
#
#    checkMissingIterableValueType: false

To test if it works:

 $ ./vendor/bin/phpstan analyse

We have installed everything we need, now we can create a commit to track these changes:
```
 $ git add -A && git commit -m "Added linting and formatting packages"
```

Set Up Pre-Commit Hook

We have all the packages needed for static analysis and code formatting so now let us create a pre-commit hook that runs them before every commit:

First we should install husky's Git hooks
```
 $ npx husky install
```
Create a file under the .husky directory called pre-commit, in full (.husky/pre-commit), and add the following content:
```
 #!/usr/bin/env sh
 . "$(dirname -- "$0")/_/husky.sh"

 # Format resources
 # https://stackoverflow.com/a/6879568
 # https://stackoverflow.com/a/1587952
 ./node_modules/.bin/prettier --ignore-unknown --write $(git diff --name-only --diff-filter=ACMR HEAD -- '*.blade.php')
 ./node_modules/.bin/prettier resources/**/*.js  resources/**/*.css --write

 # Format php classes
 ./vendor/bin/pint && git add -A

 # Do static analysis
 ./vendor/bin/phpstan analyse --memory-limit=2G
```
Let us break down this command: /node_modules/.bin/prettier --ignore-unknown --write $(git diff --name-only --diff-filter=ACMR HEAD -- '*.blade.php')
- --ignore-unknown prevents the command from returning a non-zero result if no match is found in our filter
- --write tells prettier to write the formatting changes to the respective files
- --diff-filter=ACMR HEAD matches files that have either been Added, Copied, Modified, or Renamed. HEAD adds to this filter by matching files that have gone through either of the aforementioned changes, whether they have been staged for commit or not. If this is not the desired behaviour this resource should come in handy
Make the .husky/pre-commit executable:
```
 $ chmod +x .husky/pre-commit
```
Now when we do a commit, the pre-commit hook should run
Commit our changes:
```
 $ git add -A
 $ git commit -m "Added pre-commit hook"
```
Congratulations! Now linting and static analysis is done before every commit. There's one more thing we can do to help new team members install the pre-commit hook:
Update package.json and the following script. It runs right after one runs npm install:
```
 {
     "scripts": {
     ...
     "prepare": "husky install && git add .husky/pre-commit"
     }
}
```
Now an npm install should trigger the installation of the pre-commit hooks, or one can just run npm run prepare.

Resources

ORDER BY x LIMIT y Gotcha

Timothy Karani — Fri, 29 Dec 2023 21:54:11 +0000

Introduction

On a production environment I was watching a query I had just made attempts at optimizing take longer and longer as days went. Usually I would look at WHERE clauses to inform me on indexes that need creating or queries that need restructuring but often overlooked ORDER BY clauses, turns out both need equal attention.

Reproduction

I will be using Laravel for this because of easy EXPLAIN statements provided by barryvdh/laravel-debugbar and FakerPHP that we'll use to seed the database with lots of records.

Create a Laravel Project

   $ composer create-project laravel/laravel order-by-gotcha

Update .env and set DB_DATABASE, DB_USERNAME and DB_PASSWORD. I will be using mysql. You might need to create a database.
Create a Client model together with a corresponding migration and controller.

   $ php artisan make:model Client -mc

Update the migration. Only the email column is indexed, for future demonstration purposes.

   // ...
   $table->string('name');
   $table->string('email')->index();
   $table->string('phone');
   $table->timestamps();
   // ...

Update the Client model to make the columns fillable.

   // ...
   protected $fillable = [
       'name',
       'email',
       'phone'
   ];
   // ...

Update the DatabaseSeeder to seed 1,000,000 clients. This might take a bit, 6 min on my end (SSD, 8 Cores):

    public function run(): void
    {
        $records = [];
        $start_time = microtime(true);
        $iter_start_time = microtime(true);
        for ($i = 0; $i < 1_000_000; $i++) {
            // For logging, just to see stuff works
            if ($i > 0 && (($i % 10_000) == 0)) {
                $end_time = microtime(true);
                $cumulative = $end_time - $start_time;
                $iter = $end_time - $iter_start_time;

                $this->command->info("$i - Cumulative: $cumulative, Iter: $iter");
                $iter_start_time = microtime(true);
            }

            $records[] = [
                'name' => fake()->name(),
                'email' => fake()->email(),
                'phone' => fake()->phoneNumber(),
                'created_at' => fake()->dateTimeBetween('-10 Years', 'now'),
                'updated_at' => fake()->dateTimeBetween('-10 Years', 'now'),
            ];

            // Bulk insert every 1000 records
            if ($i > 0 && (($i % 1_000) == 0)) {
                DB::table('clients')->insert($records);
                $records = [];
            }
        }
    }

Now on to the ClientController class, with the following methods:

    public function index()
    {
        $client =  Client::query()->latest()
            ->first();

        return view('welcome', compact('client'));
    }

    public function index_with_where_clause()
    {
        $filter = 'ca';
        $client =  Client::query()
            ->where('email', 'like', "%{$filter}%")
            ->latest()
            ->first();

        return view('welcome', compact('client'));
    }

    public function index_order_by_email()
    {
        $client =  Client::query()
            ->latest('email')
            ->first();

        return view('welcome', compact('client'));
    }

    public function index_order_by_id()
    {
        $client =  Client::query()
            ->latest('id')
            ->first();

        return view('welcome', compact('client'));
    }

Clean up welcome.blade.php, just show the client name:

   <!DOCTYPE html>
   <html>
   <head>
       <title>Laravel</title>
   </head>
   <body>
       {{ $client->name }}
   </body>
   </html>

Update web.php to add the route:

    Route::get('/', [ClientController::class, 'index']);
    Route::get('/with_where', [ClientController::class, 'index_with_where_clause']);
    Route::get('/order_by_email', [ClientController::class, 'index_order_by_email']);
    Route::get('/order_by_id', [ClientController::class, 'index_order_by_id']);

Add laravel-debugbar and publish the config:

$ composer require barryvdh/laravel-debugbar --dev
$ php artisan vendor:publish --provider="Barryvdh\Debugbar\ServiceProvider"

Enable explain output by editing config/debugbar.php. Scroll until you find the setting then update it as follows:

'explain' => [                 // Show EXPLAIN output on queries
    'enabled' => true,
    'types' => ['SELECT'],     // Deprecated setting, is always only SELECT
],

Run migrations and seed the database:
```
$ php artisan migrate --seed
```
Start the server
```
$ php artisan serve
```

Exploring Performance

When we open http://localhost:8000/, this is what the debug bar shows us as the EXPLAIN output:

  explain select * from `clients` order by `created_at` desc limit 1

  | table   | type | possible_keys | key | key_len | ref | rows   | Extra          |
  | ------- | ---- | ------------- | --- | ------- | --- | ------ | -------------- |
  | clients | ALL  |               |     |         |     | 999001 | Using filesort |

999001 records are being loaded into memory! And the query takes 904ms. Not good. On production, a comparable query was taking 1.7 seconds.

You might think that a query with a where clause would help things, let's open http://localhost:8000/with_where to see if that's the case:

  explain select * from `clients` where `email` like '%ca%' order by `created_at` desc limit 1

  | table   | type | possible_keys | key | key_len | ref | rows   | Extra                       |
  | ------- | ---- | ------------- | --- | ------- | --- | ------ | --------------------------- |
  | clients | ALL  |               |     |         |     | 999001 | Using where; Using filesort |

Still way to many records being loaded with the operation taking 767ms.

We added an index on the email column though? Maybe let's use it when ordering instead of created_by. Let's open http://localhost:8000/order_by_email:

  explain select * from `clients` order by `email` desc limit 1

  | table   | type  | possible_keys | key                 | key_len | ref | rows | Extra |
  | ------- | ----- | ------------- | ------------------- | ------- | --- | ---- | ----- |
  | clients | index |               | clients_email_index | 1022    |     | 1    |       |

Only one row is loaded, and the index is used with the select operation taking 2.46ms. Just like that we get a significant bump in performance. On production the query went from 1.7 seconds to ~70ms. Now you can either add an index to the created_at column or leverage the primary key which is indexed by default. The email index in this example was just to show indexes help in ORDER BY statements.

Let's use the PRIMARY KEY for ordering http://localhost:8000/order_by_id:

  explain select * from `clients` order by `id` desc limit 1

  | table   | type  | possible_keys | key     | key_len | ref | rows | Extra |
  | ------- | ----- | ------------- | ------- | ------- | --- | ---- | ----- |
  | clients | index |               | PRIMARY | 8       |     | 1    |       |

This one takes 1.74ms, doesn't load close to a million records to memory, looks alright.

TL;DR

Use indexed columns when using ORDER BY clauses.

Resources for Further Exploration

Mapping Huion Keys on Linux

Timothy Karani — Thu, 14 Apr 2022 01:09:14 +0000

Introduction

This post assumes you already have the tablet working and the xsetwacom command already exists on your linux installation.

For this post I'll be mapping the buttons on my HS611 Tablet. A HS611 tablet has 8 buttons on the pad and 2 buttons on the stylus.

Setting Things Up

Let us get the name of the graphics tablet:

$ xsetwacom --list

The command above gives the output below if the connected tablet is a HS611

HUION Huion Tablet_HS611 stylus         id: 15  type: STYLUS
HUION Huion Tablet_HS611 Pad pad        id: 16  type: PAD
HUION Huion Tablet_HS611 Touch Strip pad        id: 17  type: PAD

Of importance to us are HUION Huion Tablet_HS611 stylus and HUION Huion Tablet_HS611 Pad pad

Mapping

Fire up your favorite text editor, and create bash script file with a name of your choice. For this post I'll choose set_keys.sh

in set_keys.sh:

#!/bin/sh

# PAD MAPPINGS
#top set
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 1 "key ctrl shift z"
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 2 "key ctrl z"
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 3 "key ctrl p"
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 8 "key ctrl shift ="
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 9 "key ctrl -"

#bottom set
# https://askubuntu.com/a/1193029
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 10 "key +ISO_Level3_Shift +9"
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 11 "key 4"
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 12 "key del"
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 13 "key 6"
xsetwacom --set 'HUION Huion Tablet_HS611 Pad pad' Button 14 "key +ISO_Level3_Shift +8"


# STYLUS MAPPINGS
# xsetwacom --set 'HUION Huion Tablet_HS611 stylus' Button 1 "key h" # on click
# button 1 on the stylus is triggerd when you tap the stylus tip on the tab. Simulates a "click" by default.
xsetwacom --set 'HUION Huion Tablet_HS611 stylus' Button 2 "key b"
xsetwacom --set 'HUION Huion Tablet_HS611 stylus' Button 3 "key e"

The mappings are configured with Krita in mind:

Pad Mappings:

Button	Mapping	Function
Button 1	`Ctrl` + `Shift` + `Z`	Redo
Button 2	`Ctrl` + `Z`	Undo
Button 3	`Ctrl` + `P`	Pan Mode
Button 8	`Ctrl` + `Shift` + `=` (equivalent to `ctrl` + `+`)	Zoom In
Button 9	`Ctrl` + `-`	Zoom Out
--	--	--
Button 10	`+ISO_Level3_Shift` + `+9` (aka `altgr` + `9` or `]`)	Increase brush size
Button 11	`4`	Rotate Left
Button 12	`del`	Clear Canvas
Button 13	`6`	Rotate Right
Button 14	`+ISO_Level3_Shift` + `+8` (aka `altgr` + `8` or `[`)	Decrease brush size

Stylus Mappings:

Button	Mapping	Function
Button 1	`b`	Brush Tool
Button 2	`e`	Eraser Tool

With that done, let us now give execution permissions to our script file:

$ chmod +x set_keys.sh

Now we can run the file every time we connect the tablet so as to map the keys:

$ ./set_keys.sh

Once you've mapped the keys, you can fire open Krita and draw to your heart's content :).

Tips

You can view all mappable keys/modifires with the command below. Sometimes they don't map as we expect (example [, ] and +), but with a bit of Googling you will find your solution:

$ xsetwacom --list modifiers

To test in a terminal which key is being input by the button after mapping, you could monitor either using the xev command or showkey -a.

Happy drawing :)

DEV Community: Timothy Karani

Laravel 10.x + Livewire 3.x Pre-Commit Linting and Formatting

Introduction

Installation

Set Up Pre-Commit Hook

Resources

ORDER BY x LIMIT y Gotcha

Introduction

Reproduction

Exploring Performance

TL;DR

Resources for Further Exploration

Mapping Huion Keys on Linux

Introduction

Setting Things Up

Mapping

Tips

Further Reading