Автор: dd

Неожиданно, но оказывается, есть простой способ настраивать конфиг docker-compose для теста и прода
Я всегда просто делал два разных файла, которые смотрят в разные папки за конфигами и запуск того или иного окружения происходит через bash-скрипт, которому в качестве аргумента можно передать dev, чтобы поднять тестовое окружение
А вот сегодня подумал, что наверное есть способ проще и да — он есть
Вообще, поиск я начал с того как бы мне с помощью флагов окружения выполнять в Dockerfile те или иные куски кода, но наткнулся вот на этот ответ на stackoverflow, где говорилось, что такой подход устарел и можно лучше — https://stackoverflow.com/a/65624157/5320740
Я и до этого видал Dockerfileы, в которых были строки типа from * as base, но разбираться почему и зачем не было нужды, а теперь понятно, что я многое упускал
Вся эта схема ещё идеально вяжется с использованием docker-compose.override.yml, который перезаписывает части конфига. Там как раз можно указать, что нам в Dockerfile нужно собрать именно dev окружение
По итогу имеем два простых конфига — один локальный, второй в репе

Сегодня ровно месяц как я работаю в новой компании и сегодня прошёл мой первый перформанс ревью. Честно говоря, не знал чего ждать, похвалы или порицания, но надеялся на лучшее. По итогу оказалось, что все всем довольны, работаем дальше, вопреки моему синдрому самозванца. Оказывается, я сильно помог компании в продвижении работ по одному из заказчиков, приятно🙂
🛠 Практически весь месяц возился со старой легаси системой и понял кое-что — дебаггер — лучший инструмент. Я не понимаю, как я без него жил раньше и чем думал, когда дебажил через логирование💀
🛠 Начал работу над новой итерацией текущей системы. Пока всё идёт туговато, потому что переписываем на Symfony, а я с ней до этого вообще не работал 💀 Но получилось уже основные архитектурные принципы воплотить, это радует.
🛠 Ещё, кстати, решили использовать GraphQL. Да, там приходится писать много обвязки, но профит от этого сумасшедший. Мне наконец-то не придётся клепать эндпоинты для получения/изменения данных на каждый чих фронтендера. Пусть сам разбирается, что ему надо 💀
💡 За этот месяц я понял, что офис дома — плохая идея. Поработав в коворкинге, уходить оттуда не хочется, там всегда какая-то движуха. Особенно хорошо, когда там собираются какие-нибудь чудики и удаётся утащить поесть💀
Вообще, неплохой месяц выдался, что сказать. Чилим дальше😎

С момента моего трудоустройства на новом месте стараюсь очень жестко соблюдать work/life-баланс, поэтому сейчас эта картинка актуальна как никогда

P.S. Давно ничего не пишу, потому что сказать пока нечего. Целыми днями штудирую бизнес-логику, практикуя страстный бдсм с легаси, но потихоньку с командой близимся к пониманию того как будет выглядеть и функционировать новая итерация🙃

Никогда бы не подумал, что маленькая статейка про XDebug сможет вызвать такой резонанс
2к просмотров, люди говорят спасибо, почти 60 человек добавили в избранное статью
Понятно, что это немного, но всё равно — прогресс) аж вдохновляет дальше писать

Вернулся ночью из командировки по новой работе
Мне не особо можно распространяться о деталях, но работаю теперь в torgi223.ru на должности "ведущего программиста", что бы это ни значило 😀
Команда просто отпад, офис того круче. Я за два дня очень хорошо отдохнул и сейчас просто с блаженством занимаюсь задачами
Сейчас, кстати, сижу в коворкинге, в своём закутке, максимальный чил)
Всем удачной недели!

Вчера в порыве радости выложил пост, а потом понял, что по той ссылке лишь часть нужной для настройки инфы
Собрался с мыслями и запилил на хабре статейку о том как пошагово настроить дебаггер в контейнере
Ссылка — https://habr.com/en/post/712670/
Наверняка схлопочу минусов, но пусть будет 😀

Как с "пользой" провести 4 часа в поезде? настройте xdebug с поддержкой docker-контейнера👍🏻
Много перепробовал статей, а учитывая отвратительный интернет — это было больно
В итоге нашёл вот такую статью и всё решилось сразу же — https://lessthan12ms.com/docker-php-xdebug-phpstorm-good-developer-experience.html
При чём до этого перепробовал кучу комбинаций ключей, указанных в статьей, но безуспешно
Видимо, что-то с портами xdebug накосячил

Давно откладывал эту статью, а тут решился всё-таки прочитать — не пожалел
В довольно подробных деталях объясняется почему "терминал"/"консоль" это на самом деле эмулятор терминала и прочие интересные вещи
Вопрос про выведение приложений из фонового режима, кстати, был на многих собеседованиях 😀
Ссылка — http://www.linusakesson.net/programming/tty/

Вот и подошёл к концу мой очередной поиск работы. Пишу этот пост, сидя в поезде до Нижнего Новгорода — еду на знакомство с командой.
Процесс поиска занял почти ровно месяц — начал искать 12.12.2022, принял окончательное решение 13.01.2023.
За это время откликнулся на большое количество вакансий, правда, не все занёс в таблицу, поэтому выборка будет куцая — 27 откликов:
1. собеседование — 17, из них:
1. оффер — 7
2. отказ — 10
2. игнор без просмотра — 7
3. отказ без собеседования — 3
Так же, на хх лежит куча заигноренных откликов, штук 20 ещё наверное, но там у компаний процент просмотров выше 60 не поднимается.
Выборка из плюшек по компаниям ещё меньше, есть данные только по тем компаниям, в которых был собес и я успел всё спросить:
1. Аккредитация — все
2. Аутстафф — 1
3. Город головного офиса:
1. Москва — 12
2. Нижний Новгород — 2
3. Санкт-Петербург — 1
4. Волгоград — 1
5. Краснодар — 1
4. Онбординг — есть у всех, но разнится от полноценного кураторства до просто ридми файла
5. Оформление по ТК — все
6. Обучение — все
7. Скрам — все
8. Оплата коворкинга — 8
9. ДМС — 10
10. Компенсация занятий спортом — 5
11. Корпоративы — 13
12. Рабочий комп — 8
13. Командировка на знакомство — 6
14. Оплата рабочего софта — 16
15. Стек:
1. php — все
2. mysql — 7
3. postgresql — 4
4. фреймворк:
1. битрикс — 1 (ядро приложений на битре, всё остальное — symfony)
2. symfony — 8
3. laravel — 3
4. yii2 — 2
Получается, в основном компании предлагают реально очень неплохие условия, но будьте осторожны с теми, кто занимается аутстаффом — продуктовая компания будет куда лучше.

Была пара пересечений с гигантами России:
1. Яндекс — дальше алгоритмического не прошёл, а жаль, пощупать собес на систем дизайн было бы очень неплохо.
2. ВК — запланирован собес на след неделе, но это будет чисто из интереса. Смотреть у них особо нечего — максимально крутые условия, но работать придётся с KPHP, который на рынке не нужен никому, а внутри компании надо сильно постараться, чтобы прыгнуть на другой стек

В целом, процесс был довольно незамысловатый — созвон с hr, технический собес, оффер (ну или нет).
Собеседоваться было гораздо проще, чем в прошлый раз, потому как, учитывая опыт, разговор можно было вести не о подробном описании того как индексы в БД работают, а о прикладных задачах, проектировании, чистоте кода и прочих реально интересных вещах. Не удивлюсь, если много раз вывозил собесы из-за софт скиллов — их, к счастью, всегда отмечали очень положительно после собесов. Оно мне только на руку)
В общем, если собираетесь менять работу, то заведите таблицу и трекайте там весь свой прогресс — это пожалуй лучшее, что я мог для себя сделать в этот раз. Записывайте всю инфу при созвоне с hr, чтобы потом сделать правильный выбор.

P.S. был курьёзный случай, когда я на собеседовании попросил командировку на знакомство с командой, а мне потом звонит hr и говорит, что я перегнул палку и что даже гендир сказал, что php-разработчику такое не полагается 😀 нужны люди — найдёте средства и возможности. А вообще, пожалуйста никогда не говорите такой чуши тем, кого берёте, особенно, если команде этот человек очень нужен (к счастью, мой случай). Чел потом спрашивал, могу ли я изменить решение по поводу выбора работы — не стал ему говорить, что он уже сделал всё что можно)

Небольшая заметка вам по поводу проектирования библиотек, которыми будут пользоваться другие люди
Для взаимодействия с телегой в пхп есть один очень широко используемый пакет: https://github.com/php-telegram-bot/core
У него куча звёзд и куча форков. Значит он норм, так? Не совсем, апи, которое этот пакет предоставляет, далеко не самое удобное.
Рассмотрим максимально простой пример — нужно отправить сообщение.
Естественно, мы создаём клиента, через которого будем слать сообщения: $bot = new Telegram(YOUR_API_TOKEN)
Дальше всё просто, отправляем сообщение: $bot->sendMessage($message, $params). А, стоп. Метод не определён..?
Как оказалось, для любых действий нужно использовать статические методы из класса Request, например Request::sendMessage($message, $params)
Но тогда возникает абсолютно логичный вопрос — откуда вообще Request знает что-либо о том, куда слать сообщения? Всё дело в том, что когда мы делаем new Telegram(), в конструкторе этого объекта идёт инициализация класса Request через статический метод initialize.
Таким образом, чтобы отправить сообщение, код получается следующий:

php
new Telegram(YOUR_API_TOKEN);
Request::sendMessage($message, $params)

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