Хорошая статья! Хотелось бы отметить, что на практике порой большей проблемой является попытка совместить бизнес-логику разных версий API.
Классический пример. Есть crud-набор API-методов работы с пользователями. У пользователей есть поле phone. Делаем фичу, чтобы пользователи могли указывать несколько телефонов. В новой версии API или в текущей же вводим поле-коллекцию phones. И возникает вопрос, что делать, когда через старую версию API редактируют пользователя, передавая новый телефон в phone, когда в базе у редактируемого пользователя уже лежит несколько телефонов, установленных ранее через новую версию API.
Расскажите, пожалуйста, как первично формировался этот документ. Вы собирались вместе и накидывали или кто-то инициировал, накидав костяк, а потом начал дополняться?
Насколько тимлиды ему следуют, как вам кажется? Это просто рекомендации или вы стараетесь давать фидбек тимлидам, если они придерживаются другого мнения по каким-то из пунктов?
Спасибо за доклад. Хотелось бы лучше понять следующие моменты:
1. Вы говорите, что есть bootcamp, новый разработчик ходит по командам, работает по 2 недели в каждой и выбирает ту, что больше понравилась. Но, обычно, у нас есть спрос на новых людей в определенных командах больше, а в других меньше. А разработчик выберет команду, где сейчас расширение команды и не требуется особо. При распределении новичков вы как-то учитываете запрос самих команд на пополнение?
2. Идея с виртуальными командами и ротацией интересна. Не получается ли так, что была команда из ребят, которые все в московском офисе, а в ходе ротации пришел человек из, условно, новосибирского офиса. И из-за этого им нужно сильно менять процессы в команде? Я понимаю, когда более менее равномерно распределенная команда или полностью локализованная. Но как вы организуете эту ротацию с учетом нескольких локализованных команд, если у вас таковые есть, конечно.
3. Еще один вопрос про виртуальные команды. А тимлиды команд тоже могут ротироваться? Или в этой точке команды неизменными остаются.
В более менее крупном проекте билдить проект на боевых серверах – не очень хорошая затея. Допустим, у нас 10 серверов. Во-первых, билдиться будет 10 раз на каждом из серверов. Во-вторых при билде проекта выполняются ресурсоемкие операции. Например, разогрев кеша крупного symfony-проекта нормально так догружает сервер. Т.е. у нас все сервера, которые под боевой нагрузкой, одновременно начинают параллельно нагружаются деплой-процессом, а это может привести к печальному результату, например к просадке времени отдачи страниц у пользователей.
Мы билдим готовый собранный проект с разогретым кешем и статикой и просто раскатываем его на сервера, где остается только выполнить миграции и переключить симлинки.
А как в универсальном коннекторе решаются вопросы разных возможностей API например у Slack и Telegram. Например, в Telegram есть custom keyboard, это, получается, не доступно?
Саша, посыл хороший, но, конечно, важно и то, чтобы семья не страдала: жена, тем более дети запомнили типичное состояние отца не за экраном монитора, а в общении с ними, а также то, чтобы это не переросло в разряд маниакальной мании трудоголизма и кодинга, от которой за год выгораешь. Сам таким страдаю порой и пробую сейчас найти баланс в этом вопросе.
В текущей реализации в некоторых местах используются переменные PHP вместо статичных переменных из-за ряда текущих ограничений Zephir-а. Ощущение, что это может также изменить цифры по Зефиру. А так да, сам ожидал несколько других цифр.
Да, можно прожить без замыканий. По передаче параметра по ссылке есть таск github.com/phalcon/zephir/issues/203, в нем я вижу ряд коммитов, возможно, направят в нужное русло.
На втором скриншоте видно, что в заголовке адрес сайта, а рядом фильтр по серверам. Т.е. вы видите отчеты по сайту в целом, но если он крутится на нескольких серверах, то можете посмотреть отчеты по работе сайта на каждом отдельном сервере.
Первый раз я потратил достаточно много времени, пока поставил патченный libssh2 и libpssh c pssh_extension. Я описал процесс установки в отдельном мануале.
Используем его в бою, выполняется все моментально, плюс дает полную гибкость в деплоинге, в отличие от минималистичных деплоеров типа Laravel Envoy или Deployer, которые просты в освоении, но неудобны для кастомизации и медленны.
Для dplr отмечу отдельно (возможно и в тексте стоит отразить) — он использует libpssh от badoo, что позволяет асинхронно и параллельно деплоить на множество серверов одновременно.
Нам как раз персентелей и не хвататало, я заметил, что они недавно появились, это очень здорово, будем переходить на них. А в остальном мы только дампим отчеты пинбы, чтобы видеть их за предыдущие периоды и логгируем медленные, тяжелые и 500-ые страницы.
Хорошая статья! Хотелось бы отметить, что на практике порой большей проблемой является попытка совместить бизнес-логику разных версий API.
Классический пример. Есть crud-набор API-методов работы с пользователями. У пользователей есть поле
phone. Делаем фичу, чтобы пользователи могли указывать несколько телефонов. В новой версии API или в текущей же вводим поле-коллекциюphones. И возникает вопрос, что делать, когда через старую версию API редактируют пользователя, передавая новый телефон вphone, когда в базе у редактируемого пользователя уже лежит несколько телефонов, установленных ранее через новую версию API.Интересно было бы узнать следующее:
Расскажите, пожалуйста, как первично формировался этот документ. Вы собирались вместе и накидывали или кто-то инициировал, накидав костяк, а потом начал дополняться?
Насколько тимлиды ему следуют, как вам кажется? Это просто рекомендации или вы стараетесь давать фидбек тимлидам, если они придерживаются другого мнения по каким-то из пунктов?
1. Вы говорите, что есть bootcamp, новый разработчик ходит по командам, работает по 2 недели в каждой и выбирает ту, что больше понравилась. Но, обычно, у нас есть спрос на новых людей в определенных командах больше, а в других меньше. А разработчик выберет команду, где сейчас расширение команды и не требуется особо. При распределении новичков вы как-то учитываете запрос самих команд на пополнение?
2. Идея с виртуальными командами и ротацией интересна. Не получается ли так, что была команда из ребят, которые все в московском офисе, а в ходе ротации пришел человек из, условно, новосибирского офиса. И из-за этого им нужно сильно менять процессы в команде? Я понимаю, когда более менее равномерно распределенная команда или полностью локализованная. Но как вы организуете эту ротацию с учетом нескольких локализованных команд, если у вас таковые есть, конечно.
3. Еще один вопрос про виртуальные команды. А тимлиды команд тоже могут ротироваться? Или в этой точке команды неизменными остаются.
Мы стабильно видим, особенно разница быстро выявляется на серверах баз. Один из дисков в 2 раза раньше умирает.
Мы билдим готовый собранный проект с разогретым кешем и статикой и просто раскатываем его на сервера, где остается только выполнить миграции и переключить симлинки.
Используем его в бою, выполняется все моментально, плюс дает полную гибкость в деплоинге, в отличие от минималистичных деплоеров типа Laravel Envoy или Deployer, которые просты в освоении, но неудобны для кастомизации и медленны.