Рубрика: Разработка

Как с "пользой" провести 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)

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

А вот и второй пост из этой серии — подписание xml-запросов по xmldsig с помощью php и openssl — https://habr.com/en/post/710532/

Дождался публикации своего первого поста на хабре — https://habr.com/en/post/710462/
Пост о боли насущной — до сих пор преследующей меня интеграции с ГИС ЖКХ
В этой части только про подключение, завёрнутое в докер

Я на этой неделе💀

Никогда бы не подумал, что напишу это, но я снова занялся любительским геймдевом
Предлог простой — вспомнить и получше изучить джаву, потому что до этого знаний о ней было крайне мало, хотя я вообще весь свой путь в программировании начал именно с неё
С 2015го по 2020 я с переменным успехом ковырялся с MonoGame — фреймворк для написания игр на c#
Не особо что выходило, играми это назвать точно было нельзя, хотя и цели сделать игру не было — мне был интересен именно сам процесс, планирование и проектирование
В этот раз цель всё та же, так как всё, что я когда-либо хотел сделать это клон Minecraft, но до этого может не дойти никогда
Однако, изменился подхо — раньше я просто говнокодил, чтобы хоть как-то работало. Сейчас я всё так же говнокожу, но пытаюсь максимально развязать компоненты
Вообще, в голову пришла идея отделить "бэкенд" от "фронтенда", то есть выстроить систему так, что игровой мир общается с gui посредством событийной шины. Всё в лучших традициях распределённых систем и микросервисов, откуда собственно идея и пришла
Вообще, советую любому разрабу иногда залезать в совершенно другую область разработки, многие принципы могут пригодиться + это нехилая встряска мозгу, мыслить приходится совсем по-другому.

Ссылка на гитхаб, на всякий случай — https://github.com/ddruganov/libgdx-test

Кстати, за последние пару дней, пока ведётся работа уже успел найти кучу недостатков в джаве в плане удобства языка по сравнению с шарпом, так что где-то одним из следующих постов именно такое сравнение и будет, знай своего врага в лицо)

Меня всегда интересовала возможность отменяемых действий, в частности удаления записей из БД. Каждый раз прибегал к deleted_at, но минимальный набор проблем включает в себя необходимость добавления ко всем запросам deleted_at is null
Тут в двух статьях описано что с этим паттерном не так и как это все просто решается:
https://brandur.org/soft-deletion
https://brandur.org/fragments/deleted-record-insert

@artemmarenkoff я призываю тебя и представляю отличную статью на тему монорепизации проектов: https://www.devtip.co/monorepo/
Если кратко: монореп это хорошо, а мультиреп нужен далеко не всегда