Работа с новой архитектурой в Laravel 11

Для сравнения, просто предложения:

Можно отправить ответ с использованием представления, основанным на изменённых в посреднике данных вместо применения трансформатора.

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

Можно кинуть response с view, основанной на изменённых в middleware данных вместо применения json resource.

Когда я вижу сообщения из первого варианта, сразу складывается ощущение, что его составлял человек, абсолютно не владеющий английским языком. Ведь, дословно ни один язык не переводится, даже русский. Всегда важен контекст. И, при этом, сижу и пытаюсь понять о чём вообще пытается говорить человек.

Во втором случае понятно о чём идёт речь.

Третий случай часто встречаю у тех, кто ещё не выучил английский, чтобы свободно разговаривать, но уже пытается вставлять английские слова с целью выпендрёжа. Не понимаю я таких. Эти люди ещё говорят что-то типа "И тогда мейби ай го ту столовая перекусить" 🤮

Работа с новой архитектурой в Laravel 11

Вы спросили могу ли я прислать личные команды, я прислал. Ревью проводить не просил. А что касается их применения - это одноразовые команды под задачу и, как уже сказал раннее, как только её закрою, они также будут удалены за ненадобностью.

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

Работа с новой архитектурой в Laravel 11

Можно. Вот три недавних личных хелпера из последнего проекта:

Личные команды

<?php

use App\Data\Public\Users\RegisterDto;
use App\Services\Integrations\UserIntegration;
use Illuminate\Support\Arr;
use Illuminate\Support\Facades\Artisan;
use Illuminate\Support\Facades\Http;

Artisan::command('foo', function () {
    $service = app(UserIntegration::class);

    $service->register(RegisterDto::from([
        'email' => '[e-mail]',
        'phone' => '[phone]',
        'firstName' => 'John',
        'lastName' => 'Doe',
        'gender' => 'male',
        'birthdayAt' => '1979-12-31',
        'password' => 'qwe',
        'passwordConfirmation' => 'qwe111',
    ]));

    dd('ok');
});

Artisan::command('bar', function () {
    dd(
        preg_replace('/\[(.+)\|.+\]/', '$1', 'Проверяем [1231233 что-то ещё|https://example.com] ссылку')
    );
});

Artisan::command('qwe', function () {
    $response = Http::baseUrl(config('app.url'))
        ->asJson()
        ->acceptJson()
        ->throw()
        ->get(
            route('public.product', [
                'product' => 'E34875',
                'city' => 12
            ])
        );

    $item = $response->collect('data.items')
        ->filter(fn (array $item) => $item['id'] === 876996)
        ->firstOrFail();

    dd(
        $item['is_available']
    );
});

Держу их под рукой пока работаю над задачей. Как только закончу с ней, хелперы удалятся. И больше они такие никому не будут нужны.

Работа с новой архитектурой в Laravel 11

Общие дев команды можно и через art make:command сделать в спец неймспейсе, например. Но это делать не будут, а также у каждого из нас свои хелперы, переписываемые постоянно, т.к. нет нужды хранить их, тем более в репозитории.

Работа с новой архитектурой в Laravel 11

И получаете тонну проблем и ошибок. Не зря же в апгрейд гайде выделили фразу "не рекомендуется":

https://laravel.com/docs/11.x/upgrade#application-structure

Версионирование API в Laravel-приложениях

Даже если деплоить один раз в день пул задач, за месяц получим тьму версий. У компании не хватит ресурсов их поддерживать, да и бессмысленно это.

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

Если что-то удаляется или ломается обратная совместимость, то это "мажор", читай другая версия.

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

Версионирование API в Laravel-приложениях

Идеальный вариант версионирования достигается путём деплоя "в разные папки", грубо говоря.

На вход в приложения летят урлы, например, https://example.com/v1/foo и https://example.com/v2/foo. Сервис приёма (nginx или какая его замена) видит префикс и, в зависимости от его значения, переадресует запрос в тот или иной контейнер в случае контейнеризации либо в папку, в случае "нативного" деплоя.

Само же приложение всегда содержит лишь одну версию API с изменениями, не ломающими её функциональность. И единственная группа роутов имеет префикс v1, v2 и т.д.

Деплоим версию и всё. При возникновении критических ошибок конкретной версии, правим её и деплоим вновь.

При разработке новых критических изменений, ломающих обратную совместимость, создаём новую ветку в git с названием vN+1 (например, v3), реализуем задачу и деплоим в новую версию v3, не забыв добавить маппинг в nginx на неё.

Таким образом, получаем несколько плюсов:

1. Одно и то же конечное приложение может работать с разными версиями API;

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

3. Объём путаницы для разработчиков при работе с версиями сводится к нулю;

4. Отчётливо видно где какая версия работает.

Минусы:

1. При деплое новой версии необходимо внести изменения в nginx;

2. Добавить конфиг в supervisor и настроить крон, если они используются.

Микродозинг кофеина: новый подход к потреблению кофе

Если я плохо засыпаю - кофе с молоком и.... пулей в туалет. А потом можно и поспать))

Налоговая реформа 2025 года и ИТ-сектор: подробный обзор

Я ничего не говорил про 2 ляма да еще и в месяц. Сказал «если бы».

Налоговая реформа 2025 года и ИТ-сектор: подробный обзор

Разве я сказал что на 3%?

Налоговая реформа 2025 года и ИТ-сектор: подробный обзор

Из Гугла:

И сразу отметим, что НДФЛ с дивидендов удерживается в момент выплаты дивидендов (п. 4 ст. 226 НК РФ)

Поднимается НДФЛ и даже если дивиденды в самом начале не тронут, впоследствии запросто и к ним руки потянут.

Так что все рассуждения о том, что «это для кого-то там, а мы и не заметим» ни что иное как самообман и/или неосведомлённость, граничащая с наивностью.

А что касается с требованием повышения зарплаты, в нашей стране люди очень боятся просить лучшего для себя, поэтому перейдут на ту работу, где им на руки платят больше или, как минимум, не меньше с учётом нового налогового процента.

Если бы мне вот так пришли и сказали что НДФЛ подняли и буду получать меньше - я б в ту же минуту начал искать другую работу.

Налоговая реформа 2025 года и ИТ-сектор: подробный обзор

Поживём - увидим.

Налоговая реформа 2025 года и ИТ-сектор: подробный обзор

Допустим, товар стоит 100 рублей.

У продавца работают бухгалтер за 80 тысяч, продавец за 80 тысяч и гендиректор за 300 тысяч. Они платят налоги в размере 13%.

Налог повышают до 15% - это 45к рублей против 39к предыдущих. Дельта - 6к. С директорской, другие не попадают под процент.

Чтобы отбить эту стоимость, нужно повысить цену товара, и теперь он стоит 120 рублей.

Почему на 20%? Потому что в рублях цена не сильно выше стала, а в цифрах - на целых 20%.

Так что, по факту налог будут оплачивать абсолютно все покупатели.

И, к слову, магазины могут держать и физические лица в том числе. Они ещё регистрируются как самозанятые либо ИП (да, ИП - это физическое лицо, имеющее право на предпринимательскую деятельность).

Налоговая реформа 2025 года и ИТ-сектор: подробный обзор

Увы, это совершенно не так. Следите за руками:

Покупатель платит N денег, в который заложен процент. Продавец покупает товар, в который заложен процент. Дальше ещё цепочка из посредников может быть и в этой цепи явно больше одного человека, получающего высокую зарплату. НДФЛ полнят, а значит работодатель будет платить больший процент, чтобы сотрудник получил «столько же». Чтобы это компенсировать, налог закладывается в стоимость товара, и двигаемся в обратном порядке.

И вот, покупатель покупает товар дороже чем раньше процентов на 10-20 навскидку.

Таким образом, прогрессивную шкалу почувствуют все без исключения.

И владельца бизнесов, те самые миллионеры, также будут закладывать процент в стоимость товара. Кто ж по собственной воле будет в минус работать?

Налоговая реформа 2025 года и ИТ-сектор: подробный обзор

В столбик "минусы" блока "На что это повлияет?" прогрессивной шкалы НДФЛ запросто можно вписать повышение цен на все или практически все группы товаров в магазинах, так как продавцы будут закладывать повышение налогов в стоимость товаров, а, значит, покупатели будут вынуждены "доплачивать".

Магический API Resource в Laravel

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

Не зря поговорка есть - «волков бояться - в лес не ходить».

«Коллеги, пришлите сроки!» — повторял джун-аналитик в течение месяца…

Лучший рецепт - писать в корпоративные мессенджеры что-то вроде: "Привет, наберу на 2 минуты?"

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

Хуже этого был в моей практике случай, когда мне позвонили по телефону сказав «Зайди ко мне через 5 минут», а когда я пришёл, сказали «Твой вчерашний счёт на компьютер оплачен, можешь ехать забирать»…

А «красная паста»… Пару раз мне написали и потом я её просто перестал замечать в каком-либо виде, проигрывая в голове мысль «опять эта полоумная херню придумала да работать мешает».

И, к слову, почта штука такая что её далеко не всегда и не сразу проверяют. Лично я проверяю корпоративную почту один раз в сутки в начале рабочего дня. Чаще просто не за чем ибо это уже будет неоправданная трата рабочего времени.

Магический API Resource в Laravel

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

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

Магический API Resource в Laravel

Полностью согласен! Заходя в свою квартиру вместо того чтобы обживаться и использовать её на полную, надо максимально оградиться внутри. Желательно поставить палатку где-нибудь в углу и не выходить из неё без крайней необходимости ?

Российский аналог GitHub от РФРИТ и Минцифры отложен на неопределённый срок в связи с отсутствием финансирования

...было бы трудно привлечь новую аудиторию...

Читая между строк: "...поэтому зачем что-то делать и тратить силы при наличии мощных конкурентов..."

А потом удивляются почему это в стране толком ничего не делают.