Alexey Hog

Последняя цифра - это остаток при делении на 10.
const lastDigit = 765 % 10; // -> 5

тут изначально очень не правильный подход. не нужно делать "дефолтную конфигурацию" через глобальные переменные.

class DbConnection
{
    private string $userName;
    private string $password;
    private string $dbname;

    public function __construct(string $userName, string $password, string $dbName)
    {
        $this->userName = $userName;
        $this->password = $password;
        $this->dbname = $dbName;
    }
}


class AuthController
{
    private DbConnection $dbConnection;

    public function __construct(DbConnection $connection)
    {
        $this->dbConnection = $connection;
    }
}

$dbSettings = include('dbconfig.php');
$connection = new DbConnection($dbSettings['login'], $dbSettings['password'], $dbSettings['dbName'] );
$controller = new AuthController($connection);

а в файле dbconfig.php

return [
'login'=>'myLogin',
'password'=>'myPassword',
'dbName'=>'myDbName'
];

Воспользуйтесь данной библиотекой.

https://github.com/StephanWagner/svgMap
https://www.npmjs.com/package/svgmap

Либо сделайте по аналогии.

Вызываем справку:

docker run --rm -v ${PWD}/:/var/task -u 0 node:15-alpine sh --help
BusyBox v1.31.1 () multi-call binary.

Usage: sh [-/+OPTIONS] [-/+o OPT]... [-c 'SCRIPT' [ARG0 [ARGS]] / FILE [ARGS] / -s [ARGS]]

Unix shell interpreter

Таким образом:

docker run --rm -v ${PWD}/:/var/task -u 0 node:15-alpine sh -c "cd /var/task && npm install && npm ci"

А можно и так:

docker run --rm -v ${PWD}/:/var/task -u 0 --workdir="/var/task" node:15-alpine sh -c "npm install && npm ci

Или вообще так:

docker run --rm -v ${PWD}/:/var/task -u 0 --workdir="/var/task" node:15-alpine npm install && npm ci

PS
https://docs.docker.com/engine/reference/run/

Добрый день, можете просто добавить еще один знак # к тегу a
вот так
<a href="##">
тогда не будет слетать вверх

Классическое решение - пробежаться циклом по массиву:

<?php
$query = "select * from equipment";
$stmt = $pdo->prepare($query);
$stmt->execute();
$equipments = $stmt->fetchAll(PDO::FETCH_ASSOC);

$result = array_reduce(
	$equipments,
	function($res, $el) {
		if(!is_array($res[$el["equipment_id"]])) {
			$res[$el["equipment_id"]] = [
				"equipment_id" => 141491,
				"speed" => []
			];
		}
		array_push(
			$res[$el["equipment_id"]]["speed"], 
			[
			    "datetime" => $el["datetime"],
            	"value" => $el["speed"],
            	"distance" => $el["distance"],
			]
		);
		return $res;
	},
	[]
);

var_export(array_values($result));

Run PHP and SQL online

SQL решение:

<?php
$query = "select 
	equipment_id, 
	json_arrayagg(
		json_object(
		  'datetime', `datetime`,
		  'value', `speed`,
		  'distance', `distance`
		)
	) speed
from equipment
group by equipment_id;";

$stmt = $pdo->prepare($query);
$stmt->execute();
$equipments = $stmt->fetchAll(PDO::FETCH_ASSOC);


var_export($equipments);

Test code here

Есть много способов, но мне нравится вот такой трюк.

Для того чтобы правильно писать catch, надо писать осмысленный код.

А здесь мы наблюдаем очаровательный пример карго-культа.
Узнав, что "толстый контроллер - это плохо, а сервисы - это хорошо", автор небрежным движением руки замел весь мусор под ковёр перенёс весь код из контроллера в "сервис". Ну а что? Контроллер худой, весь код в сервисе!
Тот факт, что сама кривая структура проекта осталась, по сути, той же самой, нас не смущает.
Как и то, что сервис вдруг начал выполнять функции НТТР контроллера и кидать почему-то НТТР исключения. Что с этими исключениями делать в случае, если тот же сервис будет вызван из консольной команды - загадка.

Но самое забавное, что при всём при этом контроллер всё равно пытается выполнять работу модели. Казалось бы, какое отношение интерфейс для обслуживания НТТР запросов имеет к транзакциям в базе данных? А вот поди ж ты!

Чтобы сделать этот код осмысленным, контроллеру всё-таки придется потрудиться, и выполнить какую-то работу самому, а не перекладывать на "сервис". А так же отдать модели то что ей принадлежит.

В общем транзакцию перекинуть в createDefault. причём не напрямую, а ещё ниже - в слой для работы с БД. Стартовать транзакцию до валидации данных - это как бы *не совсем логично*, мягко говоря. И в итоге, как по волшебству, весь этот говнокод исчезнет как страшный сон.
При этом в параметрах передавать не НТТР реквест чохом, а осмысленный набор параметров, вынутый предварительно из реквеста!
В частности, если модель сама проверяет права доступа, то и передавать ид пользователя из авторизации.

При этом модель не должна кидать НТТР исключения. Она должна кидать исключения бизнес-логики. Которые контроллер уже может ловить и транслировать в хттп. Но тут видимо уже сложнее, поскольку это ж ларавель судя по всему.

В любом случае, уж catch (Exception $e)-у тут точно не место

Но это если рассматривать твой конкретный случай.
В общем же случае правильный код написал Илья.

То есть внутри трая операции с БД и коммит.
в кетче роллбэк и перевыброс исключения. Только ловить надо Throwable

try {
  DB::beginTransaction();
  // запись в БД
  // запись в БД
  // запись в БД
  DB::commit();
} catch (\Throwable $e) {
  DB::rollBack();
  throw $e;
}

Это хороший вопрос, который довольно часто задают новички, поскольку они все поголовно подвержены очень распространенному заблуждению - что опасность заключается в самих данных, и их, следовательно, можно как-то "обезопасить". Что "данные" в приложении - это некий универсальный абстрактный объект, который можно универсально же обработать.

Но если подумать, то ответ становится очевидным: не бывает таких "проверок", которые автоматически делают данные "безопасными".
Поиск таких универсальных проверок - это такая же глупость, как поиск "базовых правил безопасности для человека". Ты встречал кого-нибудь, кто все время носит каску, наколенники, бронежилет и презерватив? Независимо от того, собрался он кататься на роликах, на войну, или на свидание?

Данные не бывают "опасными" или "безопасными" сами по себе.
Всё зависит от контекста.
А любая обработка "просто на всякий случай" тупо испортит данные.
К примеру твоя strip_tags() изуродует математический текст, в котором встречаются символы "больше" и "меньше".

Поэтому и надо форматировать данные перед использованием, в зависимости от конкретного контекста, а не заранее. Используем в SQL? Применяем подготовленные выражения. Используем в HTML? Применяем htmlscpecialchars. Используем в URL? Применяем urlencode. Используем в яваскрипте? Применяем json_encode. И так далее. Тебе уже самому должно быть смешно, глядя на этот набор "базовых проверок", если их накатывать все скопом.

Плюс не надо путать форматирование данных и их валидацию.
Валидация, в принципе, хорошая вещь, но надо понимать что во-первых, она не имеет никакого отношения к безопасности, и не может заменить контекстное форматирование данных, а во-вторых, уж тем более не может быть "универсальной" по определению.

Функция mail() в PHP по сути вызывает встроенную в систему почтовую программу - стандартно, это sendmail в linux (также, возможно использовать qmail, postfix, но для этого надо сначала сконфигурировать PHP через .ini файл).
Подробнее про Mail в PHP: https://www.php.net/manual/ru/book.mail.php
И про основную проблему кроссплатформенного использования: https://habr.com/ru/post/26518/

PHPMailer - это мощная библиотека, реализующая почтовые транспорты, а не использующая sendmail как стандартная mail() функция. Имеет из коробки большое количество возможностей, таких как (в списке представлена лишь малая часть):

• полная поддержка SMTP, Qmail, POP3, IDN, DKIM;
  
• поддержка SSL и TLS;
  
• работает на любой win32 и *nix платформе;
  
• гибкость отладки;
  
• определяемые вручную заголовки писем;
  
• совмещение нескольких сообщений и вложений;
  
• встроенная поддержка изображений;
  
• умеет посылать письма с множественными: адресатами (TO), копиями (CC), BCC и REPLY-TO;
  
• многослойные/альтернативные сообщения для клиентов, которые не могут читать HTML письма;
  
• поддержка 8 бит, base64, бинарного режима, и пригодного для печати формата;
  
• перенос слов (word wrap);
  
• сообщения в виде HTML (шаблоны);
  
• библиотека проверена на множестве SMTP серверах: Sendmail, qmail, Postfix, Imail, Exchange, Mercury, Courier;
  
• библиотека используется под капотом таких гигантов: WordPress, Drupal, 1CRM, SugarCRM, Yii, Joomla;
  

Подробнее можно прочитать тут:
https://jino.ru/journal/articles/pochta-phpmailer/
https://www.sesmikcms.ru/pages/read/ischerpyvajusc...

Помимо PHPMailer существуют и другие крутые библиотеки, оставляю список для интересующихся:
Swiftmailer
(Symfony) Mailer

Если вы активно пользуетесь функцией mail() при разработке на PHP и до сих пор ещё не сталкивались с проблемами при её использовании на хостингах или на своих собственных серверах без соответствующего правильно настроенного окружения, то mail() вам идеально подходит. А когда столкнётесь с проблемами или захотите иметь больше возможностей из коробки, станут очевидными плюсы PHPMailer и других специализированных библиотек.

https://yandex.ru/search/?text=php%20Очистка%20POST
https://www.cyberforum.ru/php-beginners/thread1697...