21 ноября состоится митап про страхи в php http://it.skyeng.ru/php21 Я там буду участвовать в качестве спикера в том числе. Кому интересна какая-то из тем или кто хочет пообщаться регистрируйтесь и приходите!

Мои предсказания о будущем php
https://habr.com/ru/company/skyeng/blog/474724/

В php 8 будут объедиенные типы. https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md Подавляющим количеством голосов предложение принято. Выглядит как возвращение к тому, от чего пытались уходить.

Рутинная работа, наверное одно из самых демотивирующих явлений. Как подумаешь что прежде чем сесть за интересную задачу, которую руки чешутся решить, нужно сначала разгрести таск-трекер, так сразу настроение начинает идти вниз.
Думаю пора начать серию постов о своем опыте автоматизации рабочих процессов и не только рабочих. Эта серия зрела давно. В двух словах сказать все что набралось невозможно. Поэтому постараюсь по порядку осветить все то, с чем пришлось столкнуться и что получилось успешно решить с помощью автоматизации.
И начну пожалуй с самой частой проблемы, о которой немного сказал вначале. Проблемы рутины. Давным-давно, когда я еще занимался работой на аутсорсе с небольшой командой, столкнулся с проблемой актуальности статусов и другой информации о задаче в таск-трекере. Приходилось ежедневно вручную контролировать этот вопрос, что утомляло и занимало время. В команде использовался redmine и он поддерживал интеграцию с git из коробки. Если указать в названии коммита номер задачи и статус, то он сменится в задаче автоматически. Но как заставить разработчиков не забывать правильно оформлять сообщения коммитов? Даже если они ответственные люди, все равно не исключен человеческий фактор и нарушения форматов будут, а это значит, что надеяться на этот механизм нельзя и нужно продолжать контролировать вручную. Безнадега.
Изучив тему, решил попробовать воспользоваться pre-receive хуком, который запускается на стороны сервера до того, как изменения будут приняты в репозиторий. Написать этот хук можно на bash/pyton/php и других скриптовых языках. Мне было это проще сделать на php. Скрипт занимался тем, что проверял сообщения коммитов на четко заданный формат, примерно такой "#{task-id}-{status} | {message}". Список возможных значений для status был жестко ограничен, так как соответствовал статуса в redmine. Хук не пропускал коммиты с неправильными статусами или неверными форматами сообщений. Он просто не давал пушить. Первое время это частенько кого-нибудь выбешивало, когда забывал оформить по правилам. Приходилось даже делать rebase когда коммитов в пуше не один и просто ammend не мог помочь. Но скоро уже все привыкли, комиты оформлялись правильно на автоматизме и проблема исчезла. В дальнейшем этот хук стал также проверять и статус задачи, например, не давая пушить в закрытые задачи. Это было несложно доработать с помощью Redmine API и даже нашелся [готовый php-клиент](https://github.com/kbsali/php-redmine-api).
Реализация заняла у меня часа 4-5 в сумме. Если не считать первых попыток на bash, которые не увенчались успехом в виду моих не достаточно глубоких познаний в этом инструменте. В итоге статусы в задачах стали меняться автоматически, в каждой задаче был список коммитов, на которые можно было перейти и посмотреть что именно мы меняли. В истории git была привязка к задачам, в рамках которых делались изменения, я этим кстати часто пользовался, чтобы посмотреть для чего делались те или иные правки, смотрел переписку по задаче. Также часто помогало поиском по истории собрать воедино все правки по проблеме когда коммиты разбросаны. Вообщем время это экономило массу и привнесло порядка. Ну и конечно же я перестал беспокоиться об актуальности статусов и просто начал ими пользоваться. Если стоит статус released значит задача в мастере, если ready for development - значит ни одного коммита еще не сделано и т.д.
Все в команде настолько к этому привыкли, что как-то раз, когда этот хук внезапно отвалился, это вызвало небольшую волну возмущений, "а почему статусы перестали проставляться". Хук конечно же быстро починили.
Но правда одно ограничение все же есть. Pre-receive срабатывает на стороне сервера. И если у вас облачный github/gitlab/bitbucket, то использовать эту возможность не получится. По крайней мере я не нашел способа. Если кто-то его знает, то за подсказку в личку буду благодарен.

Недавно писал пост про переработки в другой канал

Привет, Антон @antgubarevcom Губарев продолжает поднимать вечные и холиварные темы. Сегодня он хочет поговорить с вами

Про переработки ⏳🎡

Тема переработок, наряду с зарплатой, входит в топ вопросов, которые кандидаты поднимают на моих собеседованиях. Да я бы и сам его задал. Потому что релизы, срочные задачи, аварии и “бизнесу нужно вчера” — это часть нашей жизни, и важно знать политику компании на этот счёт.

У нас в Skyeng в официальной вики четко прописано, что переработки не приветствуются. Но я:

• всё ещё встречаю рассказы о компаниях, в которых переработки не только распространены, но и поддерживается на уровне руководства 🤦‍♂️

• вижу ситуации, когда сотрудники пытаются перерабатывать по своей воле 🧟‍♂️

Одни перерабатывают, потому что не очень справляются с обязанностями, но не хотят отставать. Другие гиперответственно относятся к поставленным срокам. Таких людей важно вовремя выявить (это легко), определить главную причину их "неуспеваемости" и устранить её. Например, дать более простые или менее срочные задачи, либо перевести в другую команду. Ведь если человек начнёт работать эффективнее, пусть даже и над другими задачами, это принесёт больше пользы всем.

Хуже, когда в коллективе заводится трудоголик или карьерист. Человек, готовый работать по 60 часов в неделю просто потому, что для него это норма (ну или он так думает)🤖 Казалось бы, вот он, локомотив, который способен затащить задачи, которые другим не под силу. Но вид такого “стахановца”, скорее всего, будет демотивировать неуспевающих. И исправить их неуспеваемость станет сложнее. Да и неспроста выгоревший трудоголик — всё более частое явление.

40 часов на работу в неделю

https://meetups-online.ru/php-may-2020 В эту субботу буду рассказывать как мы в непростых условиях смогли избавиться от очень старого легаси монолита и не упасть в грязь лицом перед бизнесом.

Этот анонс напомнил мне о том что на этом мероприятии будет интересный доклад от слепого разработчика.

На ближайших выходных сразу два крутых PHP-мероприятия. Ребята уже скоординировались и больше таких коллизий не будет. Ну а в этот раз можно насладиться выбором.

Про 3-й виртуальный PHP-митап вы наверняка уже слышали. Но если вдруг нет, то в субботу, 30 мая, будет 5 докладов, включая историю от того самого слепого разработчика, и зум с крутыми гостями.

Кроме того, 30 и 31 мая будет проходить PHP fwdays online. Программа вот тут https://fwdays.com/en/event/php-fwdays-2020#program-event.

Сам жду доклад Макса Рафалко (Infection) о принципах проектирования пакетов. Уж очень понравился его документ о выделении пакета из Infection https://github.com/infection/infection/issues/922.

Организаторы PHP fwdays предоставили пару билетов для розыгрыша — он в следующем сообщении.

Вот говорят, программисты умные.. Почему тогда обычные дворники догадались заведенному трактору на передаче ось поддомкратить, чтобы пробег мутился, а Яндексовые автопилоты с инженерами внутри до сих пор в районе МГУ километры накручивают?

https://github.com/walkor/Workerman Новый набирающий обороты инструмент для асинхронного программирования на пыхе. Сомнительное использование пыха, но инструмент может быть полезен

https://github.com/golang/pkgsite Теперь опен сорс!

Решил сделать и свой скромный вклад в опенсорс. Открыл два проекта на симфе.
https://github.com/antgubarev/bizon-backend Этой мой пет прожект на который я потратил полгода примерно или больше. В итоге не смог затащить поскольку работа отняла все свободное время а конца и края проекта было не видно. Как-нибудь обязательно опишу эту историю подробнее. Если вкратце то это бэкенд для сервиса учета финансов в малом бизнесе.
https://github.com/antgubarev/crypt-backend Когда-то это был коммерческий проект, но не взлетел и теперь лежит пылится. Тоже на симфе. Агрегатор новостей из мира крипты.

https://www.vedomosti.ru/media/articles/2020/06/18/832936-roskomnadzor-telegram РКН официально признал свою несостоятельность.

Пример персонального блога, который написан по принципу портирования страниц из Notion в html статику https://github.com/kjk/blog Все мы знаем Notion и его удобнейший редактор.
Сам я много перебрал различных готовых инструментов (в итоге на hugo остановился), но ничего подобного не находил даже рядом.
https://habr.com/ru/company/ruvds/blog/501012/ Вот тут человек тоже пробовал решить аналогичную проблему и до конца так и не решил

В апреле прошлого года я находился в поиске работы, так как стартап в котором я работал не взлетел и медленно загибался. Я прошел несколько интервью в том числе одно из них в компанию OneFit. Это фитнес агрегатор. Покупаешь один абонемент и ходишь в один из нескольких сотен спорт-клубов. Удобно для крупных городов.

Интервью проводили продакт и CTO. Общение показалось вполне себе адекватным и в итоге я получил оффер, который в последствии и принял. Сам стартап не был прибыльным и существовал на инвестиционные деньги, но при этом на носу были следующие инвестиционные раунды. Продакт очень убедительно рассказывал про светлое будущее и перспективы и это меня подкупило. Работу я менял до этого очень редко, а еще реже приходилось иметь дело с работой по найму, в основном занимался аутсорсом поэтому не ожидал никаких подвохов и не сильно вдавался в детали.

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

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

Первая задержка случилась 20 июня, в срок выплаты ЗП за июнь. Мне сказали что будет небольшая задержка на неделю. Ну ок. Через неделю ничего не пришло и срок был сдвинут. Еще через несколько дней мне сказали что сокращают всю команду кроме меня и мне какое-то время надо будет тащить проект в одиночку. Тут наконец-то до меня дошло и я стал искать другую работу. Нашел довольно быстро, но как честный человек подвязался отработать 2 недели, хотя оформлен был не официально. Не хотелось уходить просто хлопнув дверью, к тому же мне еще надо было получить свою ЗП.

Через 2 недели я вышел на работу в Skyeng. Шли недели и потом уже месяцы и шансы на возврат долга все таяли. Меня кормили обещаниями, а потом и это закончилось. В итоге ЗП за полтора месяца работы я так и не получил а в декабре компания объявила себя банкротом.

[Об этой истории не так давно писали на vc.ru](https://vc.ru/offline/101723-bolshie-skidki-i-dolgi-pochti-na-5-mln-rubley-pochemu-zakrylsya-agregator-fitnes-klubov-onefit). Там чуть подробнее обо всем.

Какой вывод я сделал из всего. Идя работать в стартап:
1. Подумайте много раз перед тем как выбрать стартап

2. Подумайте еще много раз

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

4. Гуглите компанию и основателей.
5. Проверяйте компанию по доступным базам: налоговая, арбитраж и тд.

Успешных всех должностей!

Продолжаем истории вложений в собственное образование. https://twitter.com/devellloper/status/1285174182456766465

Недавно обещал рассказать про свой незавершенный стартап. Как я примерно полгода пилил код. В конце расскажу какой профит я все же получил, и стоит ли оно того. Так же расскажу про ошибки, которые не стоит повторять.
https://www.youtube.com/watch?v=VII8099ekZo&t

https://habr.com/ru/company/lingualeo/blog/515530/ Интересный опыт. А интересен он в первую очередь даже не техническими решениями, а то как они принимаются и продвигаются. Это самое сложное в таких историях.
Убедить всех, что твое предложение принесет прибыль, а не убытки, это немалое количество затрат времени, сил и мыслетоплива. И главное готовность взять на себя ответственность, если что-то пойдет не так.
Я столкнулся с похожей проблемой когда пришел в Skyeng. Но мне было проще в том плане, что команду я собирал изначально с нуля (ее не существовало до меня) и не пришлось расставаться со старыми людьми. Мы выпиливались из очень старого монолита и не все прошло гладко (как это часто и бывает), но в итоге профит получили огромный. Мы работаем с сервисами, а не с монолитом. Команда затаскивает новые фичи довольно быстро и главное безболезненно как для себя так и для бизнеса. Выше в канале есть записи моих выступлений как именно это было сделано, но там скорее техническая сторона.
К чему я это все. К тому что автор статьи поступил абсолютно правильно, что не стал дальше работать с тем, что есть, а рискнул и выиграл. Сейчас во многих компаниях много подобного легаси, и много лидов и разработчиков, которые бояться или не хотят что-то менять. Причин может к этому может быть много. Но совершенно точно, что изменения нужны как бизнесу так и команде. Самое главное - реализовать процесс без ущерба для обеих сторон.