💡 Совет по Laravel

Не позволяй запросам к базе данных замедлять работу. Используй фасад Cache в Laravel для временного кэширования данных и сокращения количества обращений к базе.

👉 @php_lib

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

Когда я только начинал, я постоянно забывал про php artisan tinker (если речь про Laravel) или встроенный интерактивный шелл php -a. А ведь это супер-удобный способ быстро проверить кусок кода, протестировать работу функции или глянуть, что вернет тот или иной запрос.

Например, нужно быстро понять, как работает кастомный accessor в модели? Вместо того чтобы городить временные роуты или var_dump-ить в контроллере - открываешь tinker:

php artisan tinker

И сразу работаешь с моделью:

$user = App\Models\User::find(1);
$user->profile->full_name;

Буквально за пару секунд получаешь ответ, без лишнего мусора в коде.

Еще круто использовать tinker для тестирования сервисов или вызова хелперов. Иногда я даже проверяю SQL-запросы через Eloquent, чтобы потом использовать их в сидерах или тестах.

Короче, мой совет: если еще не используете — приучите себя чаще заходить в tinker. Это ваш "быстрый песочница", которая всегда под рукой.

А вы как чаще отлаживаете код в Laravel - через tinker, dd() или дебаггер в IDE? Напишите в комментах, будет интересно сравнить!

👉 @php_lib

Gemini API PHP Client

Клиент Google Gemini API для PHP позволяет вам использовать модель искусственного интеллекта Gemini.

Установка

composer require gemini-api-php/client


Базовая генерация текста

use GeminiAPI\Client;
use GeminiAPI\Resources\Parts\TextPart;

$client = new Client('GEMINI_API_KEY');
$response = $client->geminiPro()->generateContent(
    new TextPart('PHP in less than 100 chars'),
);

print $response->text();
// PHP: A server-side scripting language used to create dynamic web applications.
// Easy to learn, widely used, and open-source.

https://github.com/gemini-api-php/client

👉 @php_lib

Каким мог бы быть Laravel WebServer, если бы он работал через очередь?

Привет! Сегодня я хочу поделиться с вами одной интересной идеей — а что если Laravel WebServer принимал бы все HTTP-запросы не напрямую, а через обычную очередь задач Laravel Queue? Вместо привычных PHP-FPM, Swoole, RoadRunner или FrankenPHP — весь запрос обрабатывался бы как задача в очереди.

Звучит странно? Давайте разбираться, как это могло бы работать и что из этого получилось бы.

https://laravel.su/p/kakim-mog-by-byt-laravel-webserver-esli-by-on-rabotal-cerez-ocered

👉 @php_lib

💡 Совет по Laravel

Нужно проверить, что в вашем вводе существуют определённые ключи массива?

Используйте required_array_keys, чтобы убедиться, что в данных массива присутствуют конкретные ключи - идеально подходит для API-эндпоинтов, которые ожидают строгую структуру данных.

Ссылка на документацию: https://laravel.com/docs/12.x/validation#rule-required-array-keys

👉 @php_lib

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

Что я имею в виду? Это когда ты открываешь проект, а там сервисы создаются «сами собой», данные в объект попадают неизвестно откуда, а половина зависимостей подтягивается где-то «под капотом».
Вроде удобно - меньше кода писать. Но вот через пару месяцев ты сам же сидишь и думаешь: «А откуда вообще берётся этот объект? И почему тут такая зависимость?»

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

Примеры из практики:

- Использование глобальных хелперов вместо DI.
- Автоматический вызов методов через __call или __get.
- Массовая магия в Laravel (facades, hidden bindings и т.д.).

🛠 Что можно сделать:

1. Минимизировать скрытые механизмы - лучше написать чуть больше явного кода.
2. Использовать контейнер зависимостей, но регистрировать их явно.
3. Документировать «точки входа» и договориться в команде, где магия допустима, а где нет.

Когда код становится предсказуемым, ты меньше тратишь времени на дебаг, быстрее понимаешь чужие изменения и увереннее двигаешься вперёд.

А как у вас в проектах? Вы за явный код или любите, когда всё работает «само»?

👉 @php_lib

💡Знал ли вы, что…

Метод Number::abbreviate в Laravel преобразует сложные числа в удобочитаемый формат:

👉 @php_lib

💡Совет по Laravel

Определение языка пользователя

Laravel использует компонент HttpFoundation из Symfony, который предоставляет полезные возможности. Если вы работаете с локализацией и нужно определить предпочитаемый язык пользователя, просто вызовите метод getPreferredLanguage 🚀

👉 @php_lib

Совет по Laravel💡

Знаете ли вы... В Laravel есть метод `withProgressBar()`, который позволяет добавлять прогресс-бары к консольным командам.

#Laravel

👉 @php_lib

Вы когда-нибудь импортировали несколько классов из одного пространства имён вот так?

Это изящный ход или грязная ошибка? Делись мнением в комментариях!

#Laravel

👉 @php_lib

🚀 Если производительность является приоритетом в вашем проекте, возможно, стоит полностью отключить lazy loading.

Eloquent выбросит огромное исключение, если вы попытаетесь обратиться к связи, которая не была загружена заранее (eager-loaded).

👉 @php_lib

Совет по Laravel💡

Знаете ли вы .... tap() = Tweak and Return 🪄

Да, в Laravel метод tap() позволяет изменить объект и вернуть его обратно — идеально для чистого и читаемого кода.

👉 @php_lib

Совет по Laravel💡

Если вы хотите автоматически удалять старые записи, используйте трейт Prunable.
Нет необходимости писать собственные команды.

👉 @php_lib

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

Да, те самые __get, __set, __call, __toString и компания. Они вроде бы удобные: можно ловко обращаться к несуществующим свойствам, вызывать методы, которых нет, и всё работает. Но вот вопрос — а как это тестировать и поддерживать?

Когда код полагается на магию, отладка превращается в игру «угадай, откуда взялось это значение». IDE не подсказывает типы, автодополнение не работает, а дебаггер видит лишь хаос. Я не говорю, что магические методы нужно запретить. Они бывают полезны, например, в паттерне Proxy или для ленивой загрузки. Но использовать их стоит осознанно, с понятным контрактом.

👉 Советы от меня:

- Если хочешь гибкости — лучше внедри __call через интерфейс или трейт с чёткой логикой.
- Если используешь __get / __set — документируй все «виртуальные» свойства в phpdoc.
- И главное - не прячь логику под магию. Пусть код говорит сам за себя.

👉 @php_lib

Оптимизация скорости работы PHP кода 🏎️

Сегодня я покажу вам несколько простых, но эффективных способов ускорить выполнение PHP-скриптов. Оптимизация кода – важная часть работы разработчика, ведь никто не любит медленные сайты. 🚀

🔥 1. Избегайте лишних запросов к БД
Частая ошибка – несколько одинаковых запросов к базе данных в одном запросе. Используйте кэширование (Redis, Memcached), а если данные редко меняются – сохраняйте их в файл.

🔥 2. Используйте isset() вместо array_key_exists()
Функция isset() работает быстрее, чем array_key_exists(), потому что она не только проверяет наличие ключа, но и сразу его значение.

// Медленный вариант
if (array_key_exists('key', $array)) { }

// Быстрый вариант
if (isset($array['key'])) { }

🔥 3. Не злоупотребляйте foreach при больших объемах данных
Если у вас массив с десятками тысяч элементов, попробуйте array_map() или array_walk() – они работают быстрее за счет встроенной оптимизации в C.

🔥 4. Подключайте файлы правильно
Разница между require, include, require_once и include_once может сильно повлиять на производительность. require_once проверяет, был ли уже подключен файл, что замедляет выполнение. Если точно знаете, что файл не дублируется – используйте require.

🔥 5. Включите OPCache
OPCache кэширует байт-код PHP и ускоряет его выполнение в разы. Включите его в php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1

🔥 6. Используйте json_encode() вместо serialize()
Функция json_encode() работает быстрее, чем serialize(), и при этом генерирует более компактные данные.

$data = ['name' => 'John', 'age' => 25];

// Медленный вариант
$serialized = serialize($data);

// Быстрый вариант
$json = json_encode($data);

👉 @php_lib

Совет по Laravel💡

Знал ли ты… что можно импортировать несколько классов из одного пространства имён вот так☝️

👉 @php_lib

Вы предпочитаете отправлять почту напрямую в коде или использовать класс Mailable?

👉 @php_lib

Ты используешь ?? или остаёшься на isset()?

Удобное сокращение или запутанный синтаксис? Что думаешь...

👉 @php_lib

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

Многие знают о __construct() и __destruct(), но PHP предлагает целый арсенал магических методов - от __get() и __set() до __invoke() и __callStatic().

Например, рассмотрим кейс с динамическими свойствами:

class Config {
    private array $data = [];

    public function __get($name) {
        return $this->data[$name] ?? null;
    }

    public function __set($name, $value) {
        $this->data[$name] = $value;
    }
}

$config = new Config();
$config->appName = 'MyApp';

echo $config->appName; // MyApp

Мы не определяли свойство appName, но с помощью __get() и __set() сделали объект гибким, почти как массив. Это удобно для конфигов, DTO и API-ответов.

Но! ⚠️
Если переусердствовать - код становится магическим не только для PHP, но и для вас самого 😄
Отладка, автодополнение и читаемость страдают. Поэтому правило простое:
используйте магию осознанно.

👉 @php_lib

Когда вы заменяете кучу проверок isset() на optional chaining (?->):

Это умное решение или удар по читаемости?

👉 @php_lib