I created a similar version for Vue 3

import { ref, computed, onMounted, onUnmounted } from 'vue'

const HAPTIC_DURATION = 10

function detectIOS(): boolean {
  return /iPad|iPhone|iPod/.test(navigator.userAgent) && !(window as any).MSStream
}

export function useHaptic(duration = HAPTIC_DURATION) {
  const inputRef = ref<HTMLInputElement | null>(null)
  const labelRef = ref<HTMLLabelElement | null>(null)
  const isIOS = computed(() => detectIOS())

  onMounted(() => {
    const input = document.createElement('input')
    input.type = 'checkbox'
    input.id = 'haptic-switch'
    input.setAttribute('switch', '')
    input.style.display = 'none'
    document.body.appendChild(input)
    inputRef.value = input

    const label = document.createElement('label')
    label.htmlFor = 'haptic-switch'
    label.style.display = 'none'
    document.body.appendChild(label)
    labelRef.value = label
  })

  onUnmounted(() => {
    if (inputRef.value) document.body.removeChild(inputRef.value)
    if (labelRef.value) document.body.removeChild(labelRef.value)
  })

  function triggerHaptic() {
    if (!isIOS.value && navigator?.vibrate) {
      navigator.vibrate(duration)
    } else {
      labelRef.value?.click()
    }
  }

  return { triggerHaptic }
}

Which can then be used as so…

<script setup lang="ts">
import { useHaptic } from '@/composables/useHaptic';

const { triggerHaptic } = useHaptic();
....

function handleClick(type: string) {
    triggerHaptic();
// other code here
}
...

Simple, and it works just fine.

Maybe in 2027 we’ll get the ability to provide haptic feedback in regular web apps natively without hacks?

Measuring over time will give you a sense of which areas of your code are improving, and which areas might need some more attention.

As with many quality tools, the measurements and grading are opinions, but those opinions are generally based on industry-accepted views.

• Following a single standard coding styles is preferable to each file being formatted differently.
• Smaller code blocks are preferable to larger code blocks
• and so on…

phpinsights uses php_codesniffer under the hood, and provides its own out of the box default set of configurations (in other words, its own opinions).

It’s a nice and easy package to get a quick overview of the state of things. Folks with more time on their hands can dig in to its configuration and set things up the way they’d like, or may wish to dig in to php_codesniffer directly.

$ phpqa phploc ./app

This will give a summary of lines of code, separating out comments and non-comments, then gives you a whole lot more.

The cyclocmatic complexity measure is possible one of the more useful tools. Understanding that you have classes and methods that might be ‘too complex’ is the first step in dealing with that.

Why should you care about complexity? Less complex code provides

• Ease of long-term maintenance
• Ability for new folks to understand the code more quickly
• Smaller focused methods to test

if ($locationId === 8) {
  // do something awesome
}

probably seems OK to start with, but the next person (including yourself!) coming at this later will wonder what the heck ‘8’ is. And… if you want to search for any other reference to this ‘magic’ location ID… good luck searching your code for the number 8…

Collapsed output in the image below, just to fit it in the picture.

docker run --init -it --rm -v "$(pwd):/project" -v "$(pwd)/tmp-phpqa:/tmp" -w /project jakzal/phpqa phploc ./

will run the phploc tool on your current folder

But… you can alias the tool, then simply run

$ phpqa <toolname> <params>

to run any of the tools on any code.

No having to add any new dependencies to your composer, no modifications to existing code.

CyclopsMonitor is a web monitoring service – checking if a web address is up, how fast it responds, if specific content is available, when SSL/TLS certs expire, when domain name expires, and… sending you notifications when problems occur. Currently, this supports email, SMS and Slack notifications – general webhooks and voice calling are on the horizon (but not yet on the actual roadmap!)

As with many services, this grew out of something I’d started to build for myself and then a bit later, a client. Service has been up for a couple months at this point, and while there’s a ‘payment’ system in place to charge for various levels of service, that’s not yet enabled. It’s open for folks to use and test right now, so please have at it.

I modified it to ask it to provide a prefix tag like ‘feat:’ or ‘doc:’ or ‘fix:’ or similar, to summarize the type of commit, along with its regular summarization. It worked like a champ the last few days, and I’ll be keeping it around. I’ll be checking out more of the configurable prompts to see what other benefits I can wrangle from this AI service.

Both are useful, but there’s typically one piece missing. Activity log packages will log *who* initiated a change, but not who the person may have been impersonated by. If I log in as me, then impersonate user X, then make changes, the activity log will typically just show ‘user X made these changes’. However, it was really *me* doing it on behalf of person X.

There’s a few ways one could handle this, and I’d initially looked at request middleware (and still might move in that direction), but with the Spatie activitylog package, I added a ‘pipe’ during the call to initialize logging options.

Here’s a bit of code I use with the Spatie Activitylog package and the laravel-impersonate package.

<?php

namespace App\Services\ActivityLog\Pipes;

use Closure;
use Spatie\Activitylog\Contracts\LoggablePipe;
use Spatie\Activitylog\EventLogBag;

class AddImpersonatorPipe implements LoggablePipe
{
    public function __construct(protected string $field)
    {
    }

    public function handle(EventLogBag $event, Closure $next): EventLogBag
    {
        $manager = app('impersonate');
        if ($manager->isImpersonating()) {
            $impersonatorId = $manager->getImpersonatorId();
            $event->changes[$this->field] = $impersonatorId;
        }

        return $next($event);
    }
}

As you can see, I’m simply adding the originating impersonator ID to the ‘change’ list. It’s not a separated activity log property, nor a separate column in the database table where logged activity lives. That’s certainly possible, but I was trying to handle this without any database changes at this point.

On each model I log changes on, I have a ‘getActivitylogOptions’ method (via a trait) that adds the pipe code above to the logger’s pipeline.

    public function getActivitylogOptions(): LogOptions
    {
        self::addLogChange(new AddImpersonatorPipe('impersonator_id'));

        return LogOptions::defaults()
            ->logAll();
    }

What I’ve not tested yet is if non-model ‘activity’ log behaviour would still have the impersonation processing in place if it’s no model is invoked in the request. For example, just logging that an api call was made. However, pretty much every request has at least the User model invoked, which has the getActivitylogOptions() call in place, so I’m not sure there’s ever a time that would not be invoked.

Also… reviewing this out loud… the self::addLogChange() call may be being invoked once per object instantiation (or at least initial model instantiation) which may be redundant. I’ll need to investigate more.

There doesn’t seem to be a standard process for this, but it’s definitely useful information to log, even if you choose to log it a separate way.

The toBase() method will instruct the query builder to skip the step of turning the query results in to full blown Eloquent objects, and instead, return standard PHP classes – the ‘stdClass’.

The resulting objects are bare. You can’t call any methods on them, because there are none to call.

Client::query()->where('owner_id', 7)->get();

let’s say this returns 70 client records. Each of those needs to be instantiated in to an Eloquent object. If you *need* that functionality – for example, you’re going to loop through this client list and call some operation on each client (sending a notification, or attaching resources, or whatnot..) the full Eloquent objects may be needed.

More often than not, however, I’ll see

$clients = Client::query()->where('owner_id',7)->get();
return response()->json(['clients'=>$clients);

You’ve just iterated through 70 records, created new Eloquent objects, then immediately set about converting them to JSON.

toBase() saves a tremendous amount of CPU time in the case above

$clients = Client::toBase()->query()->where('owner_id',7)->get();
return response()->json(['clients'=>$clients);

I’m not going to give full detailed benchmarks here – you can simply try this out for yourself.

I can say that with a minimally complex ‘Client’ object and about 600 records in the database:

$c = Client::query()->toBase()->get();

is roughly twice as fast as

$c = Client::query()->get(); 

A 50% speed up is nothing to sneeze at.

I recently took an API endpoint having to do with retrieving client records and associated addresses. With a little bit of rewriting – including toBase() – this went from 1.1 seconds down to ~200ms. This gets called multiple times per minute at heavy times, and having faster response times for the end users has been duly appreciated.

I believe this can be achieved in Doctrine with “HYDRATE_ARRAY” mode, and likely similar in other tech stacks (hibernate, etc).