Всем привет! Недавно взял интервью у разработчика фреймворка Yii Александра Макарова (SamDark) на разные темы — IT конференции России, удаленная работа и работа за рубежом и, разумеется, про Yii Framework.   IT-мир и раньше во многом существовал в онлайне, но последние события погрузили нас туда на 100%. В 2019 году я выступал на разных IT-конференциях в России и Европе, и успел познакомиться лично со многими интересными людьми.  В этом году я решил попробовать новый для себя формат интервью и познакомить вас с теми, кто развивает ИТ-сообщество в разных уголках нашего мира. Так и родился проект MoreView. Все выпуски я буду размещать на YouTube канале, моем Хабре и в подкастах. Один из первых выпусков я записал с Сашей Макаровым, тем самым разработчиком из Yii Core Team. У Саши накопился богатый и разнообразный опыт — тимлидство, опенсорс, работа за рубежом, собственные кофейни. Обо всем этом мы пообщались в формате онлайн-трансляции на YouTube — YouTube, а текстовую расшифровку я публикую тут, на Хабре. Разговор получился объёмный, поэтому для удобства я разбил его на блоки. Также можно послушать в формате аудио здесь. Диалог строится таким образом: я общаюсь с гостем онлайн и разговор стримится на YouTube, где любой желающий задает вопросы. В расшифровке, также, есть вопросы из YouTube и они помечены таким образом — (YouTube). Перед тем как перейду к самом интервью, приглашаю на следующее интервью с Александром Афеновым (Руководитель направления разработки в Lamoda). Трансляция будет здесь. Приходите смотреть и задавайте вопросы. Автор самого интересного вопроса (по мнению гостя) получает пиццу:) Зовут меня Саша Макаров, я из Воронежа. Основное, почему меня могут знать это: Это началось давно, еще на второй работе — Siemens Business Services. Мы занимались поддержкой внешних клиентов. Задачи давались с запасом и было достаточно времени, чтобы делать что-то своё. Долгое время я занимался разработкой на Java. Хотелось делиться знаниями и возникла необходимость завести блог, но на Java развернуть его было проблематично: дорогие сервера, необходимость самому всё настраивать, не вполне простой процесс деплоя. В универе у меня был небольшой опыт в PHP, поэтому начал с него. Пробовал сначала на нем писать без фреймворков, а потом перешёл на CodeIgniter. Стало интересно посмотреть как он устроен изнутри и продвинуть свои правки, но сходу этого не удалось, потому что фреймворк уже не был в приоритете у развивающей его компании.  Так я начал искать другие фреймворки и случайно наткнулся на страницу Yii. Сам сайт был ужасен, а документация, на удивление, неплохая. А главное, всё, что было написано, — работало. После я сделал сайт yiiframework.ru. Постепенно начал предлагать какие-то наработки и идеи из codeigniter, Java и своего опыта и основной создатель фреймворка, Qiang Xue, предложил мне место в команде. Я его целенаправленно не развивал. Посмотрел какие есть русскоязычные площадки, чтобы публиковать анонсы по Yii на русском языке, которые будет приятно читать. Публикации размещаю без какого-либо определенного тайминга. Если получается что-то интересное, длинное и классное, чем я бы хотел поделится не только с читателями блога, то я пишу об этом на хабре. Сейчас еще есть посты с расшифровкой докладов с конференций команды ОНТИКО, и так как я руководитель программного комитета PHP Russia, расшифровки публикуются от моего имени. Какой-то четкой даты релиза назвать не получается. Мы работаем в мире опенсорса и не смотря на то, что я посвящаю ему много времени, — один я это все сделать быстро не могу. У активных контрибьюторов есть свои дела, своя работа. Иногда некоторые участники могут выбиваться из рабочего процесса на неопределённый срок, что бьет по нему и сказывается на сроках.  Сейчас Yii 3 уже работает. Того кода, который есть сейчас, уже достаточно, чтобы делать production проекты. Но этот код “бурлит” — мы регулярно занимаемся его доработкой. Yii3 разбит на большое количество пакетов (около 100). Через какое-то время мы будем релизить эти пакеты отдельно.  Совсем нет — я управляю этим процессом. В телеграмме сейчас самое активное сообщество @yii3ru. Там около пяти супер активных человек, которые делают практически 90% всего, что запиливается в третьей версии фреймворка. У некоторых из них есть production проект на Yii3 — они едут на автомобиле и на ходу его собирают. Конечно классно, что они получат именно то, что им нужно, но они, разумеется, рискуют.  У нас есть два способа финансовой поддержки — OpenCollective и Github. Но с Github есть проблемы. Несмотря на то, что с него средства должны поступать на OpenCollective, наделе они пока зависают на аккаунте гитхаба и деньги никуда не уходят. Так что лучше поддерживать нас через OpenCollective. Прямо совсем асинхронный код (как в ReactPHP) нет — скорее всего такого не будет. Но будет возможность запускать приложение в режиме сервера — можно будет инициализировать приложение и оно будет обрабатывать PSR запросы. Можно будет запускать проект через Roadrunner или Swoole.  Да, Github может нас всех приблочить. Но у нас в гитхабе нет ничего особо закрытого. Проект интернациональный и его заблокировать для всех и сразу не могут — могут заблокировать меня. В случае необходимости мы можем подвинуться на любой сервис — тот же GitLab, который мы будем хостить самостоятельно. Весь функционал спокойно будет мигрирован через API. Худший расклад — мы неделю не будем заниматься разработкой и будем заниматься переездом на новую площадку. И да и нет. В Yii 3 можно использовать любой PSR Logger. У нас есть свой логгер, который нас устраивает. Мы решили, что не стоит выкидывать то, что отлично работает. Если бы его не было, то мы бы взяли Monolog. Но, так как Yii 3 компонентный фреймворк, то можно подключить любые PSR компоненты. Те же Request, Response, Cache и тд. Можно будет использовать любые сторонние реализации. Например для Request и Response мы не стали делать свою реализацию. Например, ИТАР-ТАСС работает на Yii2. Магазин dns-shop.ru. Есть сайт yiipowered.com — там много проектов. Фреймворк получился хороший, но хороший для двух категорий проектов и команд: Он не очень подходит для людей без опыта, которые начинают делать сложный проект. Yii 2 не научит делать хорошо. Yii 3 попытается. Это одновременно и грустная и не грустная часть. У нас в документации, для упрощения, логика описана внутри контроллера и моделей и многие принимают это за стандарт и делают так же. Если писать документацию с усложнениями — репозиториями и т.д., то фреймворк начинает казаться сложным. А если писать как попроще, то возникает обратная сторона — пользователи думают, что это хороший пример. Мы планируем делать обширную документацию, позволяющую погрузиться в предметную область и ориентироваться в DI, архитектуре и прочем.  Я точно не помню когда именно это произошло. Я начал с того, что выступал на конференциях ОНТИКО — первые РИТы (еще до времен Highload). Позже позвали на Highload Junior рассказать про горизонтальное и вертикальное масштабирование. Примерно тогда позвали и в команду ПК. После нескольких РИТов и Хайлоадов Олег Бунин предложил организовать конференцию PHP Russia. Раньше уже были конференции про PHP. Devconf весь вырос из PHP — это раньше была конференция PHPConf. И чуть позже организаторы затащили другие языки и язык PHP в конференции немного размылся. PHP умирает уже лет 20 и никак не умрет — думаю, так будет и дальше. Мы с PHP Russia попали на пик — как раз вышел PHP 7 и внимание к языку подросло — новый свежий глоток воздуха и возможностей. YiiConf было две — в Киеве и Москве. В Киеве справились полностью своими силами, в Москве делали вместе с командой Devconf. Они брали на себя техническое обеспечение, еду и прочее. Поиск спикеров и некоторые другие организационные вопросы были на нас. Получилось хорошо и отзывы были тоже хорошие. Туда зовут:) Обычно это эксперты или бывшие/текущие спикеры конференций — люди, которых Олег Бунин и другие спикеры конференций знают и которым доверяют. Сам ПК обычно устроен примерно следующим образом — каждый член ПК делает то, что его просит делать руководитель ПК. Обычно это отбор входящих докладов и доработка докладов. Если у нас есть сомнения насчет потенциального докладчика, то мы приставляем к спикеру конкретного члена ПК, который уже занимается этим докладом.  Также если профессиональная сфера доклада совпадает со сферой кого-то из ПК, то мы доверяем этот доклад ему. Если, например, у нас есть специалист в GraphQL, то доклады про GraphQL идут к нему и он отбирает самый подходящий из них. У каждого члена ПК есть какая-то своя сфера. Но если в приходящем докладе тема не подходит никому из членов ПК, то есть 3 варианта: К Роману мы отправляем так же доклады, которые нас полностью устраивают по контенту, но стоит доработать структуру или подачу. 
Саша открывает PHP Russia 2019 Скорее всего мы будем заново открывать подачу докладов на PHP Russia. Думаю, что не все спикеры, которые подавались на май, смогут выступить осенью и мы будем добирать ещё доклады, что сделает нашу конференцию еще круче:) Если у вас есть идеи и наработки для доклада -обязательно подавайтесь, когда мы снова откроем прием заявок. Есть список тем, которые мы хотим закрывать как на англоязычной, так и на русскоязычной версии сайта. Совсем на новичков мы не рассчитываем, так как очень не просто в одной конференции уместить и хардкорные доклады и доклады для новичков. Поэтому уровень сложности начинается со среднего и заканчивается лютым хардкором. Доклады на средний уровень слушателей очень круто заходят, когда у докладчика очень хорошая подача. А если доклад подает автор какой-нибудь супер-уникальной штуки, то подача важна меньше, чем контент, хотя мы сделаем все возможное, чтобы её улучшить. Мы планируем сделать экспериментальную штуку — полностью бесплатную конференцию и полностью на английском языке. У нас есть англоговорящие докладчики, которые не могут приехать в мае и сентябре, но готовы рассказать свои доклады удаленно. Это не будет полной заменой PHP Russia. Таким образом мы никак не повредим программу осенней конференции, потому что не будем выдергивать оттуда значительное количество докладчиков. Мы будем делать расшифровки докладов — они будут переведены и выложены на Хабр. Возможно, рано или поздно, расшифруем все доклады. В большинстве случаев все происходит онлайн, т.к. есть спикеры или члены ПК, которые живут не в Москве. Но оффлайн также присутствует. За день до конференции проходят прогоны прямо на площадке конференции. Изменить что-то глобально уже не получится, но скорректировать какие-то детали по контенту и подаче можно:) Если вы находитесь в одном городе с членом ПК, то никто не против встречаться лично.  Живу в Воронеже и работаю в основном из дома. Сейчас я занимаюсь по большей части опенсорсом. Бывали периоды, когда я выезжал на пару недель в офис, чтобы тесно работать с бизнесом. У этих форматов есть свои плюсы и минусы. Хорошо и здорово чаще видеть семью, но, с другой стороны, это же и минусы — прибегают дети с гораздо более важными проблемами:) Не совсем. В офисе работают практически все представители бизнеса и операторы, разработчиков там не много.  На то, чтобы выстроить все коммуникации с этими сферами накладных расходов достаточно чтобы привезти меня в Москву. Как тимлид, я много взаимодействовал с бизнесом, саппортом, некоторыми учителями и прочими людьми, с которым заметно эффективнее было обсудить все лично.  В Skyeng это называется тимлид — это очень широкая должность с высокой ответственностью. Не во всех компаниях обязанности тимлида одинаковы.  
На TeamLeadConf 2020 Удаленное управление происходило довольно стандартным образом — разве что все коммуникации идут через slack, zoom, hangouts. Каждый шанс, который выпадает, чтобы пересечься с кем-то из команды, необходимо стараться максимально использовать. Если знаю, например, что к родственникам из Новосибирска один из разработчиков летит на 3-4 дня — надо брать билеты до Москвы и идти в паб общаться лично. Один раз поговорить лично с каждым членом команды важно.  А ещё у меня был неудачный эксперимент — сначала я подумал, что у нас много времени уходит на стендапы, созвоны и прочие коммуникации, поэтому я заменил всё это слаковым ботом, который задавал эти же вопросы и ответы закидывал мне. Все шло ок, но я со временем я стал замечать, что ребята начали выпадать из контекста и перестали ощущать себя частью команды. Складывалось ощущение, что работали в одиночку, а общались только с ботом.  Это был мой первый опыт тимлидства — раньше был опыт работы только техлидом. Было много хорошего — я мог задавать направление работы, опробовать новые технологии и т.д. Но работать было достаточно тяжело. Особенно последние полгода нагрузка была дикая. Я понял, что если я не возьму большую паузу и не буду какое-то время один сидеть и писать код, то просто выгорю.  Удаленку и конференции достаточно легко совмещать. При трудоустройстве я согласовал, что в некоторые дни буду очень плохо доступен. Разумеется о таких днях я всегда предупреждал заранее. Если предварительно оговаривать эти моменты с руководством, то проблем не возникнет.  Изначально команда мне досталась в “наследство”, но когда людей не хватало, я, конечно, нанимал сам. Руководство компании очень здорово выстраивает взаимодействие с тимлидами. Сергей Сафонов сказал, что он хочет видеть каждую из команд как черный ящик, в который закидываешь задачи, а он выплевывает решение. Что именно происходит в черном ящике — не так важно. Тимлид — это лицо команды, которое делает этот “черный ящик” хорошим. Разумеется, в реальности так работает не всегда и СТО приходится туда влезать и смотреть, что работает не так. Увольняет тоже тимлид, потому что именно он ответственен за то, чтобы команда была эффективной.  Я у себя в команде уволил двух человек. Одного достаточно быстро и принял это решение самостоятельно. Со вторым я затянул на полгода и уволил его только после разговора с СТО. Иногда этот человек работал супер-качественно и быстро, а иногда не работал вообще. В какой-то момент стало понятно, что дальше невозможно с ним взаимодействовать. Раньше было тяжело, сейчас уже нет. Во-первых, я сейчас никого не увольняю — из опенсорса особо не уволишь. Во-вторых — это большой вред для компании не уволить члена команды, который не подходит и это плохо для самого человека — он ощущает давление, претензии и так далее. Лучше расстаться и чем быстрее, тем лучше. Был не KPI, а набор вспомогательных метрик. Они никуда не выносятся (например, в оценку зарплаты и так далее). Есть как объективные метрики, которые формируются на основании данных в Jira, так и субъективные, которые я переводил в объективные после общения и личных ощущений, которые отмечал для себя.  Нет такой нормы LOC — есть норма завершенных задач за спринт. В Skyeng мы спрашивали — успеет ли разработчик за спринт сделать данный объем задачи. Если ответ положительный, то мы уже закрепляли задачу за разработчиком. Нормой является выполнение задач, которые на разработчика были назначены. Причем некоторые задачи не решаются кодом. Если тебе прилетает задача “сделать нейронную сеть, чтобы она на основе записи разговора определяла настроение человека”, ты думаешь — “А зачем? Может мы на стороне интерфейса оператора просто сделаем кнопку выбора настроения?”. Второе решение будет заметно дешевле для бизнеса и задачу решит и нет необходимости очень много кодить. По-хорошему, Product должен взять и, с точки зрения бизнеса, все оценить — какие есть альтернативы и действительно ли эта задача необходима? Иногда задачи детально не прорабатываются, ставятся в сиюминутном порыве и проходят от продукта дальше к тому же тимлиду. В данном случае уже перед лидом или разработчиком стоит задача донести, что задачу делать не стоит и это будет идеальным решением задачи — не делать её. Происходило это в городе Осло, но это была не совсем релокация — это были длинные командировки. Если в Skyeng выезды были на неделю, то в stay.com командировки были по 1-1.5 месяца. В остальное время я работал на них удаленно из дома.  Команда была не очень большая и в команде были разработчики фреймворка Yii (Qiang Xue, Wei Zhuo). Все было достаточно просто по-сравнению с работой в больших компаниях. Совсем другой способ ведения дел. Российский рынок более жесткий, поэтому требования к разработчикам и вообще ко всем, кто получает зарплату — жёсткие. Скорее всего дело в том, что зарплата у тех же PHP разработчиков не очень отличается от зарплат за границей (после вычета налогов и т.д.), но, при этом, в бизнесе, например, США это “капля в море”, а в России расходы на IT уже далеко не капля в море. И получается так, что нагрузки и ответственности гораздо больше и отношения между разработчиком и руководителем более нервные. Работать в Норвегии было спокойнее. У них в принципе другой подход к разработке и работе — они верно подметили, что “человек который устал и загнан работает хуже”. Да, он может работать, но результата будет заметно меньше. Для начала они настраивают на нормальный график работы, а потом даже с работы тебя выгоняют — “ты уже устал, плохо думаешь, пошли с нами в бар:)”. Я там был как разработчик и я считаю что это было прекрасно. У нас было время думать — когда я отдохнувший и не загнанный, то думается гораздо лучше. И, как результат, успеваешь делать те же самые задачи и в более сжатые сроки! Далеко за примерами ходить не надо — у Антона Титова в Spiral Scout подход примерно такой и вроде все работает хорошо. Шляпа настраивает меня на лад общения и публичного выступления. Разумеется, дома я не хожу в шляпе:) Со временем это стало элементом стиля. Первая шляпа была куплена совершенно случайно в одной из теплых стран, потому что было жарко. Взял супер дешевую шляпу и все. Позже, на одной из конференций, я пришел в шляпе и понял, что все вокруг без шляп, а в шляпе:)  Мне всегда было интересно это сделать. Хотелось сделать что-то, что можно пощупать, для разнообразия. У моего брата тоже Computer Science образование — он какое-то время занимался разработкой, потом попал в Bitrix и перегорел. После чего научился профессионально играть в бильярд и стал тренировать учеников.  В одной из бильярдных была кофемашина с баристой. Бариста ушла, а кофемашина осталась — он разобрался с этим делом, научился варить очень вкусный кофе и решил запустить свое заведение. Есть небольшие системы, которые строят финансовые отчеты, рисуют графики и так далее. Я бы не сказал, что там все сильно автоматизированно. Из IT туда перекочевала очень здоровая доля перфекционизма — есть некая планка, ниже которой не позволяет опускаться наш бэкграунд. Например, качество кофе. Наверное это основное, что мы взяли из IT. Правительство области запретило работать всем, кроме продовольственных магазинов. Разрешается работать на вынос — когда получается мы тоже это делаем, но, естественно, это совсем не то. Мы оптимистичные и верим, что шанс выжить конечно же есть. У меня есть пара pet-проектов которыми я иногда занимаюсь. В прошлом году были небольшие заказы на разработку библиотек, реализацию алгоритмов и т.д. Фонд Yii покрывает часть того, что мне требуется от жизни, но не все — поэтому я иногда беру заказы по разработке. До недавнего времени пожертвований на Yii хватало и до текущей ситуации с вирусом у нас с братом и женой были свои кофейни в Воронеже. Есть же разные идеи: Это определенно классная штука. У нас она не сильно распространена — у нас заведено работать через FPM. Инструмент полезный — позволяет запускать сервер на PHP. У разработчиков были некоторые конфликты и сообщество Swoole планировал бежать на RoadRunner. RoadRunner позволяет все запускать быстро и легко с минимальным количеством действий. Когда-то давно мы создали свой клан, который рубился в онлайн-игры (Quake и другие). И мы креативили разные вещи — моды, арт и так далее. Коллектив наш так и назывался — rmcreative. Со временем с проекта все поотваливались, а домен остался у меня. В итоге прижилось:) Из времен Quake 2 берёт начало часть моего ника: "sam", а "dark" прилепилось позже, тоже из игр. Тема творчества мне достаточно близка — когда-то давно у меня был графический планшет на котором я рисовал и выкладывал это на deviant art, а сейчас пытаюсь ваять что-то на гитаре. Поддерживаю инициативы ребят, которые занимаются чем-то творческим и публичным — например арт на фасадах домов. На этом закончилось наше интервью. Напомню, что посмотреть видеозапись трансляции можно здесь, аудио запись будет размещена у меня в блоге. CTO