Сегодня хочу рассказать вам про одну ошибку, которую я часто встречаю у начинающих PHP-разработчиков — неправильную работу с датами и временем.

Когда вы используете функции вроде date(), strtotime(), time() напрямую без явной установки временной зоны (timezone), ваш код может начать вести себя непредсказуемо. Особенно если ваш проект запущен на серверах в разных регионах.

Чтобы избежать проблем:
- Всегда задавайте временную зону явно через date_default_timezone_set('Your/Timezone'); в начале вашего приложения.
- Или лучше используйте объекты DateTime и DateTimeZone, они гораздо удобнее для работы с временными зонами и манипуляциями с датами.

Пример хорошего подхода:

$date = new DateTime('now', new DateTimeZone('Europe/Moscow'));
echo $date->format('Y-m-d H:i:s');

И еще одна рекомендация — всегда храните даты в базе данных в формате UTC, а уже при выводе преобразовывайте их в нужную временную зону для пользователя.

Небольшая дисциплина в работе с временем сэкономит вам кучу нервов в будущем. Проверено на реальных проектах!

👉 @php_lib

FastExcelWriter — избавление от проклятия PhpSpreadsheet

Наверняка каждый php-разработчик, хоть раз сталкивавшийся с чтением или записью Excel-файлов, знает про библиотеку PhpSpreadsheet (в прошлом - PHPExcel). Это мощная библиотека на чистом php, которая позволяет читать, а, главное, создавать Excel-таблицы. И все с ней хорошо, пока работаешь с небольшим набором данных. Но при работе с большими файлами PhpSpreadsheet начинает чудовищно отжирать память, да и производительность резко падает, и php-скрипт, использующий библиотеку, часто просто отваливается по таймауту. И проблема - в архитектуре библиотеки.

Библиотека PhpSpreadsheet, казалось бы, спроектирована очень правильно: листы таблицы, строки, ячейки, прочие сущности - это все классы, стили, форматы и всевозможные свойства тоже состоят из классов. И когда создается таблица, то в памяти создается огромное количество связанных между собой объектов, им задаются свойства, выполняются всевозможные манипуляции, ячейки заполняются данными, всё-всё это держится в памяти, и пишется в файл только в момент сохранения.

https://habr.com/ru/articles/904710/

👉 @php_lib

Сегодня я покажу вам, как быстро и удобно организовать автозагрузку классов в PHP без использования Composer.

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

Вот базовый пример:

spl_autoload_register(function ($class) {
    $baseDir = __DIR__ . '/src/';
    $classPath = str_replace('\\', '/', $class) . '.php';
    $file = $baseDir . $classPath;

    if (file_exists($file)) {
        require $file;
    }
});

Что здесь происходит:
- spl_autoload_register регистрирует анонимную функцию, которая будет вызываться при попытке использовать неизвестный класс.
- Класс App\Services\MailService превратится в путь src/App/Services/MailService.php
- Если файл существует — он подключается.

Это суперудобный способ структурировать код и избавиться от бесконечных require.

Если хочется чуть больше гибкости — можно добавить поддержку нескольких базовых директорий, логирование ошибок или даже кэширование найденных путей.

Вопрос к вам:
А вы когда-нибудь писали свою автозагрузку? Или полностью доверяете Composer?

👉 @php_lib

Сегодня я покажу вам, как безопасно работать с пользовательским вводом в PHP — тема старая, но до сих пор частая причина уязвимостей.

Часто вижу в коде что-то вроде:

$id = $_GET['id'];
$query = "SELECT * FROM users WHERE id = $id";

Если вы всё ещё так делаете — пора остановиться. Это прямое приглашение для SQL-инъекций. Даже если вы думаете "ну я же intval() применяю", это не решение.

Правильный подход — использовать подготовленные выражения (prepared statements). Пример на PDO:

$id = $_GET['id'];
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $id]);
$user = $stmt->fetch();

Если вы используете mysqli, там тоже есть prepare() — не игнорируйте его. Никогда не вставляйте переменные напрямую в SQL-запросы.

Также стоит помнить: фильтрация ≠ экранирование, и экранирование ≠ защита. Настоящая защита — это изоляция данных от SQL с помощью prepare().

✍️ А как вы валидируете и обрабатываете пользовательские данные? Используете ли какую-то свою обёртку или ORM? Поделитесь в комментариях.

👉 @php_lib

Сегодня я хочу поделиться приёмом, который сильно упростил мне жизнь при отладке в PHP.

🛠️ Как дебажить сложные объекты в Laravel удобно?

Когда ты работаешь с коллекциями, запросами или вложенными структурами, dd() или dump() часто захламляют вывод. Но есть куда более изящный способ:

logger($someObject);

Этот метод не прерывает выполнение скрипта, в отличие от dd(), и пишет в storage/logs/laravel.log. И вот тут начинается магия:

📌 Хочешь, чтобы лог был читаемым? Добавь кастомный формат:

logger()->info('User data', [$user->toArray()]);

Или ещё лучше — используй Laravel-помощники вроде tap():

tap($response, fn($res) => logger($res->toArray()));

💡 Это особенно удобно, когда ты хочешь просто взглянуть на данные, не роняя приложение.


🔥 Бонус: в .env можно задать LOG_LEVEL=debug, и ты увидишь всё, даже что делает сам Laravel под капотом.

Такие мелочи превращают обычную отладку в аккуратный контроль за происходящим в приложении.

А как ты обычно дебажишь в Laravel — через dd() или есть свои фишки?

👉 @php_lib

Сегодня я покажу вам, как элегантно избавиться от жёсткой зависимости от фреймворков в ваших PHP-проектах. Особенно это актуально, если вы работаете с Laravel, Symfony или любым другим тяжеловесом, и со временем начинаете чувствовать, что проект стал слишком «завязан» на конкретную экосистему.

💡 Проблема: вы используете, скажем, Illuminate\Http\Request, Illuminate\Support\Collection, или ContainerInterface из Laravel — и всё, вы уже внутри. Попробуйте вынести бизнес-логику в отдельный пакет — и он сразу неработоспособен вне Laravel.

🎯 Решение: разделяйте инфраструктуру и домен.
Вот несколько практических шагов:

1. Вводите интерфейсы в домене.
Вместо Illuminate\Http\Request — свой App\Contracts\RequestInterface. Это можно реализовать через адаптер или DTO.

2. Убирайте фреймворк из бизнес-логики.
Доменный код не должен знать про контроллеры, контейнеры и фасады. Он должен работать с чистыми данными, переданными через интерфейсы или value-объекты.

3. Интеграция на уровне Application Layer.
Фреймворк используется для "склейки" — он передаёт данные в домен и получает результат. Например, Laravel Controller вызывает сервис, но сервис не зависит от Laravel.

4. Проверяйте независимость.
Попробуйте запустить доменную часть проекта в консольном скрипте или тесте вне Laravel — если всё работает, вы на правильном пути.

📦 В результате вы получаете код, который легко тестировать, переносить между проектами, использовать вне фреймворка — хоть в Laravel, хоть в Symfony, хоть в чистом PHP.

✍️ Я лично начал писать всю бизнес-логику как Composer-пакеты без зависимости от Laravel. Это не просто — особенно поначалу — но это окупается на 100%.

Как вы решаете проблему зависимости от фреймворков? Поделитесь опытом 👇

👉 @php_lib

Сегодня расскажу про одну из самых частых болей в любом проекте на Laravel — отладку запросов с Eloquent и N+1 проблемой.

Ты наверняка сталкивался с ситуацией: всё работает, но чуть-чуть замедляется. Начинаешь копать и видишь кучу повторяющихся SQL-запросов. Это классическая N+1 проблема — когда вместо одного запроса Laravel делает десятки.

👀 Как это проявляется?

У тебя есть, например, список постов и у каждого поста автор:

$posts = Post::all();

foreach ($posts as $post) {
    echo $post->user->name;
}

Laravel выполнит 1 запрос на посты и N запросов на пользователей. А должен был бы — 2 запроса максимум.

🛠 Решение простое — eager loading:

$posts = Post::with('user')->get();

Теперь Laravel сначала загрузит всех постов, а потом сразу всех юзеров одним вторым запросом.



📦 Но как быстро выявить такие ошибки?

Используй Laravel Debugbar или Clockwork. Они наглядно показывают все SQL-запросы и сразу виден N+1.

Ещё один вариант — в проде подключить Laravel Telescope, если это безопасно, или поставить простую логику, которая логирует количество SQL-запросов на каждый HTTP-запрос.


⚠️ Совет: всегда используй with() при выборке данных для списков, особенно если в шаблоне дергаешь связанные модели.

👉 @php_lib

Сегодня я расскажу вам о том, как настроить эффективное логирование ошибок в PHP-приложениях с помощью библиотеки Monolog.

В повседневной разработке критично не упустить важные ошибки и события, но при этом не завалить логи мусором. Monolog позволяет:

1. Группировать логи по каналам
Вы можете создавать каналы для разных частей приложения:

   use Monolog\Logger;
   use Monolog\Handler\StreamHandler;

   $dbLogger = new Logger('database');
   $dbLogger->pushHandler(new StreamHandler(__DIR__.'/logs/db.log', Logger::WARNING));
   

2. Использовать разные обработчики (handlers)
Отправка ошибок в файлы, на почту или в Slack:

   use Monolog\Handler\NativeMailerHandler;
   $emailHandler = new NativeMailerHandler('you@domain.com', 'DB Error', 'app@domain.com', Logger::ERROR);
   $dbLogger->pushHandler($emailHandler);
   

3. Добавлять процессоры (processors)
Автоматически дополнять каждый лог юзер-агентом, IP и временем выполнения:

   use Monolog\Processor\WebProcessor;
   $dbLogger->pushProcessor(new WebProcessor());
   

4. Форматировать вывод
Пример простого форматера:

   use Monolog\Formatter\LineFormatter;
   $formatter = new LineFormatter("[%datetime%] %channel%.%level_name%: %message% %context%\n");
   $handler->setFormatter($formatter);
   

🎯 Совет на практике: заведите отдельные файлы логов под разные уровни важности (INFO, WARNING, ERROR), чтобы при поиске нужных записей достаточно было открыть один файл.

❓ А как вы организуете логи в своих проектах? Делитесь опытом в комментариях!

👉 @php_lib

🚀 Открой для себя идеальный путь к лидерству с карьерным тестом от ОЭЗ «Алабуга»! 🌟

Мечтаете о карьере в крупной компании, где ваш потенциал раскроется на полную? Наш тест поможет вам определить вашу уникальную лидерскую роль. Может быть, именно вы станете тем лидером, который выведет команду на новый уровень?

После прохождения теста вы можете заполнить заявку и получить приглашение на эксклюзивную лидерскую программу. Участие в программе открывает реальные перспективы трудоустройства в ОЭЗ «Алабуга», предоставляя шанс начать путь к профессиональному признанию.

Сделайте первый шаг к своему будущему сегодня! Пройдите тест, подайте заявку и начните строить свою карьеру вместе с нами. 🎯

Сегодня расскажу вам про одну простую, но очень полезную привычку для любого PHP-разработчика — вести чек-листы по задачам прямо в коде.

Когда проект становится чуть больше "визитки", начинают скапливаться мелкие задачи: что-то подправить, где-то доделать, что-то не забыть протестировать. В итоге куча мыслей крутится в голове, а шанс что-то упустить растёт. Как я с этим борюсь?

Я просто добавляю короткие TODO-комментарии в нужных местах кода. Например:

// TODO: Проверить валидацию email после изменений
// TODO: Перевести этот блок на отдельный сервис

Каждый раз перед коммитом быстро пробегаюсь по проекту поиском по "TODO" — и вижу все свои маленькие хвосты. А когда задач становится много, использую расширения для IDE (например, "TODO Highlight" в VSCode) — и визуально сразу видно все невыполненные задачи.

Почему это работает:

* Не надо держать всё в голове.
* Любой разработчик быстро вникает в текущие проблемы кода.
* Легче планировать рефакторинг.
* Сложно забыть про важную доработку.

Советую прямо сегодня попробовать добавить пару своих TODO в код. Дай знать, пользуешься ли ты таким приёмом или предпочитаешь другие методы? Пиши в комментариях!

👉 @php_lib

💡Совет по Laravel

Знаешь ли ты, что можно выбрасывать исключения условно всего в одну строку с помощью throw_if() — идеально для лаконичного кода в контроллерах и сервисах.

👉 @php_lib

💡Совет по Laravel

Строишь URL с динамическими параметрами для HTTP-запроса?
Не нужно вручную склеивать длинную строку!

Используй URI-шаблоны с методом withUrlParameters() — так код станет чище и понятнее при работе с API.

https://laravel.com/docs/12.x/http-client#uri-templates

👉 @php_lib

strlen() vs mb_strlen(): Почему 71% PHP-разработчиков ошибаются

В этой статье разберем, как PHP работает со строками и почему даже простой вызов strlen() может привести к неожиданным результатам. На примере крайне простой задачи "что выведет echo strlen('привет!');" посмотрим, что и как влияет на подсчет длины строки, заглянем внутрь реализации strlen() и развенчаем миф о строках как массивах.

https://habr.com/ru/articles/919192/

👉 @php_lib

Сегодня я покажу вам, как быстро разрулить хаос в проекте с кастомным фреймворком, где нет нормального логирования.

Ситуация: клиент дал старый проект, ошибок — куча, но логов нет вообще. В коде try-catch, а в catch — пусто. Что делать?

Вот мой быстрый чеклист, который спасал не раз:


1. Глобальный обработчик ошибок и исключений

set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    error_log("[PHP ERROR] $errstr in $errfile:$errline");
    return false;
});

set_exception_handler(function (Throwable $e) {
    error_log("[UNCAUGHT EXCEPTION] " . $e->getMessage() . ' in ' . $e->getFile() . ':' . $e->getLine());
});

Добавил в index.php, и уже вижу, что именно валится.


2. Простой логгер на каждый чих

Создал файл logger.php:

function log_debug($msg) {
    file_put_contents(__DIR__.'/debug.log', date('[Y-m-d H:i:s] ') . $msg . PHP_EOL, FILE_APPEND);
}

В нужных местах пишу log_debug('что-то случилось');. Дёшево и сердито, зато работает.


3. Прокинул заголовки и запросы

В самых первых строках запроса:

log_debug("REQUEST: " . $_SERVER['REQUEST_METHOD'] . ' ' . $_SERVER['REQUEST_URI']);
log_debug("HEADERS: " . json_encode(getallheaders()));
log_debug("POST: " . json_encode($_POST));

Теперь видно, с чем именно клиент ломает мой старый код.


Не всегда есть время подтягивать Monolog и делать всё красиво. Иногда нужно быстро найти, где горит — и потушить. А уже потом наводить красоту.

А вы как действуете в таких ситуациях? Есть свои приёмы?

👉 @php_lib

👉 @php_lib

Laravel lazy() против get()

Знаешь ли ты… что можно обрабатывать большие объёмы данных из базы с помощью lazy() — это гораздо эффективнее по памяти, чем get().

👉 @php_lib

💡Совет по Laravel

Знаешь ли ты… о методе skip в планировщике Laravel?

С помощью skip() можно указать, когда команда не должна выполняться.

👉 @php_lib

Простой, но полезный приём для дебага в Laravel — логирование SQL-запросов в человекочитаемом виде.

По умолчанию DB::listen() в Laravel выводит запрос с плейсхолдерами ?, а значения параметров идут отдельно. Это не всегда удобно — сложно быстро понять, что реально выполняется.

Вот сниппет, который собирает полный SQL-запрос с подставленными значениями:

DB::listen(function ($query) {
    $sql = $query->sql;
    foreach ($query->bindings as $binding) {
        $binding = is_numeric($binding) ? $binding : "'{$binding}'";
        $sql = preg_replace('/\?/', $binding, $sql, 1);
    }
    logger()->info("Executed query: {$sql}");
});

📌 Пример:

select * from users where email = 'john@example.com' and age > 18

Очень удобно, когда ты хочешь понять, почему условие WHERE не сработало или почему запрос медленный.

Можно кинуть это в AppServiceProvider::boot(), и на локальной машине всегда видеть, что реально уходит в базу.

👉 @php_lib

💡 Совет для Laravel‑разработчиков

Используйте Crypt facade — он уже есть в Laravel:

- Работает на вашем APP_KEY
- Шифрует данные через AES‑256‑CBC
- Защищает от подделки (MAC) 🔐

Храните API‑токены, пароли и секреты безопасно — прямо из коробки.

👉 @php_lib

Совет по PHP/Laravel 🚀

Когда у вас есть два случая для кастомных исключений, относящихся к одному и тому же домену, вместо создания нескольких классов исключений можно использовать один класс с разными методами!

Так код будет чище и лучше структурирован! 💪🔥

👉 @php_lib