Forwarded from запуск завтра
Мы перезапустили Вебиум!
Вебиум — ведущая онлайн-школа по подготовке к ЕГЭ. 30 тысяч школьников, тысяча наставников, тысячи вопросов и домашних заданий на сотни тем. Перед нами стояли 3 задачи:
1. Сделать так, чтобы фичи, которые хочет бизнес, разрабатывались быстрее и более предсказуемо. Обостряю для ясности, с чем часто сталкивается бизнес: «давайте добавим вот эту маленькую штуку; конечно, будет завтра (возвращаются через две недели), ой нет, это займет полгода» (и это ещё хорошо, если вернутся с таким честным ответом);
2. Нанять технического директора и создать внутреннюю команду разработки, чтобы в будущем не зависеть от аутсорса;
3. Сделать всё это «на лету», без остановки образовательного процесса, без потерь для бизнеса.
14 специалистов «Феди и Самата», 21 сотрудник Вебиума, год работы, 340 пользовательских сценариев на старте, 2900 коммитов, 5400 автотестов и я твердо говорю: все три задачи выполнены.
У Вебиума одна из самых сложных админок и систем кросс-сайтовой аутентификации, с которой я сталкивался. Мы сделали свой собственный мессенджер, информативный и при этом простой календарь, автоматическую систему распределения учеников по группам и продвинутую систему контроля доступа. Каждая из этих систем достойна отдельного рассказа.
Я прицепил скриншотами, как реагируют на запуск школьники.
В ближайшие недели мы поделимся, что неожиданно оказалось самым трудным, где и как мы накололись и чему научились.
А пока хочу поблагодарить ребят, без которых проект бы не получился:
- Миша Бурмистров, ведущий фронтендер, руководитель проекта
- Леша Чудин, ведущий бэкендер
- Саша Нестеров, фронтенд
- Эдуард Степанов, бэкенд
- Андрей Бацунов, фронтенд
- Антон Давыдов, архитектор
- Ксюша Сафронова, менеджер проекта
—
- Владимир Тарановский, фронтенд
- Вячеслав Набатчиков, бэкенд
- Леша Богословский, фулстек
- Николай Кирьянов, бэкенд
- Тимур Брачков, фронтенд
- Никита Лазаренко, бэкенд
- Никита Алешников, бэкенд.
Горжусь ребятами. Это одна из самых сильных команд разработки, с которыми я работал.
Мы сделали этот проект совместно с командами разработки, аналитики, техподдержки и тестирования Вебиума. Отдельное спасибо:
- Роксане Боровик, руководителю Вебиума, за доверие;
- Вике Гармаш, продакту Вебиума;
- Никите Савостину, техдиру Вебиума.
У вас трудности с разработкой и текст выше кажется нереальным? Пишите @samatg, мы любим сложные задачки :)
Вебиум — ведущая онлайн-школа по подготовке к ЕГЭ. 30 тысяч школьников, тысяча наставников, тысячи вопросов и домашних заданий на сотни тем. Перед нами стояли 3 задачи:
1. Сделать так, чтобы фичи, которые хочет бизнес, разрабатывались быстрее и более предсказуемо. Обостряю для ясности, с чем часто сталкивается бизнес: «давайте добавим вот эту маленькую штуку; конечно, будет завтра (возвращаются через две недели), ой нет, это займет полгода» (и это ещё хорошо, если вернутся с таким честным ответом);
2. Нанять технического директора и создать внутреннюю команду разработки, чтобы в будущем не зависеть от аутсорса;
3. Сделать всё это «на лету», без остановки образовательного процесса, без потерь для бизнеса.
14 специалистов «Феди и Самата», 21 сотрудник Вебиума, год работы, 340 пользовательских сценариев на старте, 2900 коммитов, 5400 автотестов и я твердо говорю: все три задачи выполнены.
У Вебиума одна из самых сложных админок и систем кросс-сайтовой аутентификации, с которой я сталкивался. Мы сделали свой собственный мессенджер, информативный и при этом простой календарь, автоматическую систему распределения учеников по группам и продвинутую систему контроля доступа. Каждая из этих систем достойна отдельного рассказа.
Я прицепил скриншотами, как реагируют на запуск школьники.
В ближайшие недели мы поделимся, что неожиданно оказалось самым трудным, где и как мы накололись и чему научились.
А пока хочу поблагодарить ребят, без которых проект бы не получился:
- Миша Бурмистров, ведущий фронтендер, руководитель проекта
- Леша Чудин, ведущий бэкендер
- Саша Нестеров, фронтенд
- Эдуард Степанов, бэкенд
- Андрей Бацунов, фронтенд
- Антон Давыдов, архитектор
- Ксюша Сафронова, менеджер проекта
—
- Владимир Тарановский, фронтенд
- Вячеслав Набатчиков, бэкенд
- Леша Богословский, фулстек
- Николай Кирьянов, бэкенд
- Тимур Брачков, фронтенд
- Никита Лазаренко, бэкенд
- Никита Алешников, бэкенд.
Горжусь ребятами. Это одна из самых сильных команд разработки, с которыми я работал.
Мы сделали этот проект совместно с командами разработки, аналитики, техподдержки и тестирования Вебиума. Отдельное спасибо:
- Роксане Боровик, руководителю Вебиума, за доверие;
- Вике Гармаш, продакту Вебиума;
- Никите Савостину, техдиру Вебиума.
У вас трудности с разработкой и текст выше кажется нереальным? Пишите @samatg, мы любим сложные задачки :)
Печеньки для взрослых людей
Несмотря на развитие парольных менеджеров, 1password — единственный, кто в 2022 году нормально заполняет пароли на ВСЕХ сайтах. Остальные косячат, каждый в своём — Keychain не справляется со сложными динамичными формами, где пароль появляется после логина, Dashlane, бывает, просто зависает.
Хочу немного похвастаться — мы в f&s, внезапно, перешли с обычного платного на бизнес-аккаунт. Не потому, что нам нужен лог использования паролей или интеграция с OneLogin, а просто потому, что осознали, что многим тяжело платить за международные сервисы, а 1password даёт всем участникам команды на бизнес-тарифе бесплатный личный доступ, который можно пошарить на семью.
Вообще я с осторожностью отношусь к смешению личной и рабочей жизни вроде сбора денег на день рождения/свадьбу, корпоративной ДМС или оплачиваемых спортзалов (хотя последние два экономят налоги) — взрослым людям лучше платить живые деньги в достаточном количестве, чем навязчиво предлагать помощь в личной жизни. У нас в компании даже общие сборы необязательные — можно просто не приезжать без объяснения причин.
Но сейчас я немного поменял своё мнение — кажется что корпоративный VPN, фундаментальные цифровые сервисы и айтишная ипотека — это уже маст-хев: компании это почти ничего не стоит, а ценности команде приносит много. Может знаете что-то ещё?
Несмотря на развитие парольных менеджеров, 1password — единственный, кто в 2022 году нормально заполняет пароли на ВСЕХ сайтах. Остальные косячат, каждый в своём — Keychain не справляется со сложными динамичными формами, где пароль появляется после логина, Dashlane, бывает, просто зависает.
Хочу немного похвастаться — мы в f&s, внезапно, перешли с обычного платного на бизнес-аккаунт. Не потому, что нам нужен лог использования паролей или интеграция с OneLogin, а просто потому, что осознали, что многим тяжело платить за международные сервисы, а 1password даёт всем участникам команды на бизнес-тарифе бесплатный личный доступ, который можно пошарить на семью.
Вообще я с осторожностью отношусь к смешению личной и рабочей жизни вроде сбора денег на день рождения/свадьбу, корпоративной ДМС или оплачиваемых спортзалов (хотя последние два экономят налоги) — взрослым людям лучше платить живые деньги в достаточном количестве, чем навязчиво предлагать помощь в личной жизни. У нас в компании даже общие сборы необязательные — можно просто не приезжать без объяснения причин.
Но сейчас я немного поменял своё мнение — кажется что корпоративный VPN, фундаментальные цифровые сервисы и айтишная ипотека — это уже маст-хев: компании это почти ничего не стоит, а ценности команде приносит много. Может знаете что-то ещё?
Новый набор на Асинхронную архитектуру
Мы открываем набор на четвёртый поток Асинхронной Архитектуры, нашего фундаментального курса о проектировании больших систем, который прошло уже больше 1000 студентов.
Курс полезен всем, кто имеет дело с продакшен-проектами, в которых больше одного репозитория. Даже если вы джун, который пилит монолит в маленьком стартапе, курс вам поможет: мышление проектировщика позволяет писать более понятный и изолированный код.
В прошлом потоке мы устроили эксперимент с факультативными встречами, где Антон с ребятами делали Event Storming для архитектурной каты. Эта практика классно зашла, поэтому в этот раз планируем провести ещё по тем темам, которые будут наиболее востребованы.
Некоторые ученики рассказывают, что курс помог им найти новую работу или улучшить положение на старой. Некоторые получали оферы даже во время собеседования. Верим, что тенденция продолжится и на рынке окажется больше инженеров, которые справлюятся с асинхронными взаимодействиями в распределённых системах.
Обучение стартует 23 сентября и длится 4 недели. Это последний поток в этом году. Промокод 102G24 даёт скидку 10% до 9 сентября.
Смотреть программу и пробный урок →
Мы открываем набор на четвёртый поток Асинхронной Архитектуры, нашего фундаментального курса о проектировании больших систем, который прошло уже больше 1000 студентов.
Курс полезен всем, кто имеет дело с продакшен-проектами, в которых больше одного репозитория. Даже если вы джун, который пилит монолит в маленьком стартапе, курс вам поможет: мышление проектировщика позволяет писать более понятный и изолированный код.
В прошлом потоке мы устроили эксперимент с факультативными встречами, где Антон с ребятами делали Event Storming для архитектурной каты. Эта практика классно зашла, поэтому в этот раз планируем провести ещё по тем темам, которые будут наиболее востребованы.
Некоторые ученики рассказывают, что курс помог им найти новую работу или улучшить положение на старой. Некоторые получали оферы даже во время собеседования. Верим, что тенденция продолжится и на рынке окажется больше инженеров, которые справлюятся с асинхронными взаимодействиями в распределённых системах.
Обучение стартует 23 сентября и длится 4 недели. Это последний поток в этом году. Промокод 102G24 даёт скидку 10% до 9 сентября.
Смотреть программу и пробный урок →
#вопрос В анонсе Вебиума увидел упоминание менеджера проекта, который дополняет руководителя. Стало интересно: за что они отвечают у вас в команде и почему захотелось добавить такую роль?
Когда мы с Саматом запускали аутсорс, мы вообще не хотели видеть менеджеров в команде. Типа раз самостоятельному разработчику не нужен менеджер, чтобы сдавать задачи в срок, а все разработчики у нас самостоятельные — нафига нанимать лишних людей?
После нескольких проектов, запущенных без менеджера, мы признали эту идею неудачной — программистам, которых мы ставили на такие проекты, было очень некомфортно. Любой проект (даже не в аутсорсе) — это не только скоуп и дедлайны. Есть ещё много всего:
— Развивать отношения с заказчиком/бизнесом. Клиенту нужен советник, которому доверяют, и я знаю очень мало программистов, которые хотят быть таким советником. Я их понимаю — код писать интереснее.
— (Помогать) принимать тяжёлые решения: порезать скоуп, попросить у нас с Саматом больше ресурсов (или наоборот, не просить), выложить вонючую рыбу.
— Поддерживать прозрачность. Фиксировать договорённости, актуализировать статусы, поддерживать календарь. Довольно большой пласт работы, который гораздо лучше получается не у программистов.
— Организовать и следить за обменом бухгалтерскими документами. Акты/договоры/сверки могут съедать много времени у больших клиентов.
Теперь мы разделяем ответственность — есть менеджер и «главный технарь». Один отвечает за менеджерскую часть, другой — за технологии. Конечно, это не так ёбко/утопично, но работает точно лучше.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Когда мы с Саматом запускали аутсорс, мы вообще не хотели видеть менеджеров в команде. Типа раз самостоятельному разработчику не нужен менеджер, чтобы сдавать задачи в срок, а все разработчики у нас самостоятельные — нафига нанимать лишних людей?
После нескольких проектов, запущенных без менеджера, мы признали эту идею неудачной — программистам, которых мы ставили на такие проекты, было очень некомфортно. Любой проект (даже не в аутсорсе) — это не только скоуп и дедлайны. Есть ещё много всего:
— Развивать отношения с заказчиком/бизнесом. Клиенту нужен советник, которому доверяют, и я знаю очень мало программистов, которые хотят быть таким советником. Я их понимаю — код писать интереснее.
— (Помогать) принимать тяжёлые решения: порезать скоуп, попросить у нас с Саматом больше ресурсов (или наоборот, не просить), выложить вонючую рыбу.
— Поддерживать прозрачность. Фиксировать договорённости, актуализировать статусы, поддерживать календарь. Довольно большой пласт работы, который гораздо лучше получается не у программистов.
— Организовать и следить за обменом бухгалтерскими документами. Акты/договоры/сверки могут съедать много времени у больших клиентов.
Теперь мы разделяем ответственность — есть менеджер и «главный технарь». Один отвечает за менеджерскую часть, другой — за технологии. Конечно, это не так ёбко/утопично, но работает точно лучше.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Developer Experience
В айтишечке давно уже известна разница в производительности между разными программистами — фактор производительности одного программиста относительно среднего может быть от -1x (серьёзно, увольняешь человека — команда ускоряется), и до мифических 10х (я в них, если что, верю). Такая же разница в производительности есть и между командами — один талантливый профессионал может закрыть задачу гораздо быстрее, чем 10 программистов из регионального аутсорса. Эту разницу видел каждый каждый, кто хоть раз работал с последними.
Кажется, разница между этими двумя крайностями — в пользовательском опыте программиста\, он же Developer Experience:
— Профессионал давно подобрал себе и освоил лучший в индустрии тулинг. Он идеально освоил десятипальцевый метод печати, использует все фичи vim/vscode/IDE, у него последний макбук и bleeding edge инструменты разработки.
— Профессионал скорее всего не будет ковыряться в говне. Если проект не покрыт тестами, а чтобы его развернуть, нужно потратить три дня — профессионал откажется от работы или попросит кучу денег.
— Хотя в индустрии и принято браться за задачи без Definition of Done, профессионал работает только с хорошо декомпозированными задачами — или декомпозирует сам, или требует от менеджера.
— Гигиена труда: у профессионала скорее всего есть кабинет со «стерильной кабиной», а региональный джун сидит в жужжащем опенспейсе.
— Психогигиена: на профессионала не наорёшь, никакими манипуляциями не заставишь его работать в непродуктивном состоянии. Профессионал не боится ошибаться, потому что не боится признавать свои ошибки.
Получается, профессионалы сами проектируют себе нормальный DX — работают только там, где у них хорошо это получается, оттуда и такая колоссальная разница в производительности. В командах, соответсвенно, DX проектируют тимлиды.
Думаю, хороший Developer Experience можно сделать почти везде: наши с Саматом запущенные проекты — отличное тому доказательство. Когда мы, к примеру, перезапускали блоги на Снобе, мы командой из 4-х разработчиков за полгода закрыли задачу, которую не могла закрыть собственная клиентская команда в течение нескольких лет. Такой результат получился именно из-за DX: старая команда была вынуждена ковыряться в легаси на трёх языках, развёрнутым на непонятной инфраструктуре — я три дня не мог запустить его на своей тачке. В новой команде мы придумали решение, как обособить программистов в удобной среде, которая способствовала производительности.
Компании, которые делают удобный DX тратят на разработку намного меньше ресурсов.
В айтишечке давно уже известна разница в производительности между разными программистами — фактор производительности одного программиста относительно среднего может быть от -1x (серьёзно, увольняешь человека — команда ускоряется), и до мифических 10х (я в них, если что, верю). Такая же разница в производительности есть и между командами — один талантливый профессионал может закрыть задачу гораздо быстрее, чем 10 программистов из регионального аутсорса. Эту разницу видел каждый каждый, кто хоть раз работал с последними.
Кажется, разница между этими двумя крайностями — в пользовательском опыте программиста\, он же Developer Experience:
— Профессионал давно подобрал себе и освоил лучший в индустрии тулинг. Он идеально освоил десятипальцевый метод печати, использует все фичи vim/vscode/IDE, у него последний макбук и bleeding edge инструменты разработки.
— Профессионал скорее всего не будет ковыряться в говне. Если проект не покрыт тестами, а чтобы его развернуть, нужно потратить три дня — профессионал откажется от работы или попросит кучу денег.
— Хотя в индустрии и принято браться за задачи без Definition of Done, профессионал работает только с хорошо декомпозированными задачами — или декомпозирует сам, или требует от менеджера.
— Гигиена труда: у профессионала скорее всего есть кабинет со «стерильной кабиной», а региональный джун сидит в жужжащем опенспейсе.
— Психогигиена: на профессионала не наорёшь, никакими манипуляциями не заставишь его работать в непродуктивном состоянии. Профессионал не боится ошибаться, потому что не боится признавать свои ошибки.
Получается, профессионалы сами проектируют себе нормальный DX — работают только там, где у них хорошо это получается, оттуда и такая колоссальная разница в производительности. В командах, соответсвенно, DX проектируют тимлиды.
Думаю, хороший Developer Experience можно сделать почти везде: наши с Саматом запущенные проекты — отличное тому доказательство. Когда мы, к примеру, перезапускали блоги на Снобе, мы командой из 4-х разработчиков за полгода закрыли задачу, которую не могла закрыть собственная клиентская команда в течение нескольких лет. Такой результат получился именно из-за DX: старая команда была вынуждена ковыряться в легаси на трёх языках, развёрнутым на непонятной инфраструктуре — я три дня не мог запустить его на своей тачке. В новой команде мы придумали решение, как обособить программистов в удобной среде, которая способствовала производительности.
Компании, которые делают удобный DX тратят на разработку намного меньше ресурсов.
Марьяна написала классный пост о том, как не платить за образование. С нашими курсами это тоже работает, кстати :-)
Forwarded from Продукты, книги и любовь
Никогда не платить за обучение
Однажды, работая в найме, я подумала, что будет справедливо, если за мое обучение будет платить компания. Потому что чаще всего обучение, которое мне нужно — необходимо для решения рабочих задач. Почему я продолжаю платить сама?
Тогда у нас не принято было, чтобы сотрудники учились за счет компании. А я была рядовым сотрудником, который ничем особым не выделялся. Но у меня было дикое желание сходить на одну конференцию и не было своих свободных денег, чтобы оплатить самой (там еще были расходы на поездку в другой город).
Вообщем, я решила попросить у руководителя, чтобы за меня заплатили. Он либо согласится, либо откажет. И чтобы повысить свои шансы — начала думать о том, почему это может быть выгодно компании.
Мои размышления свелись к нескольким пунктам:
1/ все новое всегда приносит СЕО, а остальные руководители хлопают ресницами и забирают новые задачи. Если я стану источником новостей в нашем отделе — мой руководитель получит дополнительные очки.
2/ если я туда схожу — у меня повысится мотивация, я познакомлюсь с другими людьми и буду лучше понимать рынок. На языке бизнеса это значит лояльный сотрудник и нетворк, который может превратиться в найм новых сотрудников, пополнение базы подрядчиков, и т.д.
3/ я могу сходить на конференцию, а потом рассказать самое важное коллегам. А если получится — переложить еще услышанное на наш контекст. По цене одного билета знания получит как минимум несколько человек.
На мой взгляд, эти поинты были достаточно убедительными. Но чтобы наверняка, назначила встречу на полчаса, вместо того, чтобы писать письмо.
В итоге встреча длилась 5 минут. Я даже не успела рассказать дальше первого пункта, когда руководитель сказал «добро». Он был безумно счастлив, что я попросила денег на обучение. Оказывается, бюджет всегда был, но никто не просил, а когда руководители предлагали сотрудникам — те обычно неохотно соглашались. Поэтому топ менеджмент тратил эти деньги на свое обучение. Я себя показала как инициативный сотрудник.
Потом тоже самое я повторила еще много раз в компаниях разного размера и типа культуры. И в 9 из 10 случаев мне одобряли полную сумму или хотя бы половину. Иногда мне удавалось брать еще кого-то с собой.
В итоге для себя я сформулировала следующее:
1/ Если в компании не принято платить за обучение сотрудника — это не значит, что нет на это денег. Даже когда глобально есть фокус на оптимизацию — деньги всегда можно получить. Как минимум половину оплаты. Это вопрос переговоров.
2/ Деньги, которые ты просишь — глобально это копейки для компании. Даже если оно стоит 100-200К. Главное чтобы потом были изменения. Если ты их покажешь — в будущем тебя закрытыми глазами будут согласовывать расходы.
3/ Чтобы повысить вероятность — подумай, как вяжется твое обучение с целями или болями бизнеса. Ключевой вопрос: «Почему они должны за меня заплатить?»
4/ Если видишь, что обучение про изменение и тебе сложно будет тащить изменения — проси сразу пойти нескольких сотрудникам. Вместе легче затаскивать.
5/ Если в компании сложно с культурой оплаты за обучения сотрудников, и ты сольешься в процессе обучения — в следующий раз будет сложнее или не возможно согласовать.
6/ Такие вопросы никогда не решай письмом. Особенно пока процесс не налажен, а к тебе нет доверия. На личной встрече ты всегда лучше сможешь контролировать ситуацию и по необходимости снять возражения.
#коммуникации
Однажды, работая в найме, я подумала, что будет справедливо, если за мое обучение будет платить компания. Потому что чаще всего обучение, которое мне нужно — необходимо для решения рабочих задач. Почему я продолжаю платить сама?
Тогда у нас не принято было, чтобы сотрудники учились за счет компании. А я была рядовым сотрудником, который ничем особым не выделялся. Но у меня было дикое желание сходить на одну конференцию и не было своих свободных денег, чтобы оплатить самой (там еще были расходы на поездку в другой город).
Вообщем, я решила попросить у руководителя, чтобы за меня заплатили. Он либо согласится, либо откажет. И чтобы повысить свои шансы — начала думать о том, почему это может быть выгодно компании.
Мои размышления свелись к нескольким пунктам:
1/ все новое всегда приносит СЕО, а остальные руководители хлопают ресницами и забирают новые задачи. Если я стану источником новостей в нашем отделе — мой руководитель получит дополнительные очки.
2/ если я туда схожу — у меня повысится мотивация, я познакомлюсь с другими людьми и буду лучше понимать рынок. На языке бизнеса это значит лояльный сотрудник и нетворк, который может превратиться в найм новых сотрудников, пополнение базы подрядчиков, и т.д.
3/ я могу сходить на конференцию, а потом рассказать самое важное коллегам. А если получится — переложить еще услышанное на наш контекст. По цене одного билета знания получит как минимум несколько человек.
На мой взгляд, эти поинты были достаточно убедительными. Но чтобы наверняка, назначила встречу на полчаса, вместо того, чтобы писать письмо.
В итоге встреча длилась 5 минут. Я даже не успела рассказать дальше первого пункта, когда руководитель сказал «добро». Он был безумно счастлив, что я попросила денег на обучение. Оказывается, бюджет всегда был, но никто не просил, а когда руководители предлагали сотрудникам — те обычно неохотно соглашались. Поэтому топ менеджмент тратил эти деньги на свое обучение. Я себя показала как инициативный сотрудник.
Потом тоже самое я повторила еще много раз в компаниях разного размера и типа культуры. И в 9 из 10 случаев мне одобряли полную сумму или хотя бы половину. Иногда мне удавалось брать еще кого-то с собой.
В итоге для себя я сформулировала следующее:
1/ Если в компании не принято платить за обучение сотрудника — это не значит, что нет на это денег. Даже когда глобально есть фокус на оптимизацию — деньги всегда можно получить. Как минимум половину оплаты. Это вопрос переговоров.
2/ Деньги, которые ты просишь — глобально это копейки для компании. Даже если оно стоит 100-200К. Главное чтобы потом были изменения. Если ты их покажешь — в будущем тебя закрытыми глазами будут согласовывать расходы.
3/ Чтобы повысить вероятность — подумай, как вяжется твое обучение с целями или болями бизнеса. Ключевой вопрос: «Почему они должны за меня заплатить?»
4/ Если видишь, что обучение про изменение и тебе сложно будет тащить изменения — проси сразу пойти нескольких сотрудникам. Вместе легче затаскивать.
5/ Если в компании сложно с культурой оплаты за обучения сотрудников, и ты сольешься в процессе обучения — в следующий раз будет сложнее или не возможно согласовать.
6/ Такие вопросы никогда не решай письмом. Особенно пока процесс не налажен, а к тебе нет доверия. На личной встрече ты всегда лучше сможешь контролировать ситуацию и по необходимости снять возражения.
#коммуникации
#вопрос А что такое «стерильная кабина» из предыдущего вопроса?
Когда-то услышал об этой штуке от Марьяны. «Стерильная Кабина» — это из воздушных перевозок (вот даже в Википедии статья есть). Идея в том, что пилоты, в определенные моменты управления самолётом, исключают вообще все отвлекающие факторы — к примеру, ни при каких условиях не обсуждают ничего, что не связано с полётом. Буквально: все слова, которые они произносят в такие моменты, они произносят по регламенту. Вот посморите, как это выглядит.
Стивен Кинг в «Как писать книги» говорил, что самая главная вещь в кабинете писателя — это дверь. Хоть программисты — это не писатели, но дверь нам нужна точно так же, как и писателям. Я у себя даже устроил кабинет таким образом, чтобы в поле зрения не было вообще ничего, кроме монитора: у меня нет кипы неразобранных бумаг, фотографий близких, иконок или обоев на рабочем столе. Близкие знают, что если в кабинете закрыта дверь, в неё можно стучаться только в случае пожара (или если ты кот). Я даже храню в ящике беруши на случай, если сосед начнёт сверлить, а у меня в этот момент будет настроение поделать творческую работу.
Если бы у меня дома не было отдельного кабинета — ходил бы в коворкинг. Стерильную кабину можно организовать даже в шумном офисе — надеть хорошие заметные наушники с шумоподавлением, забиться в самую дальнюю переговорку.
Стерильная кабина настолько же необходима для работы, как нормальная оплата, понятная задача или хорошее окружение.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Когда-то услышал об этой штуке от Марьяны. «Стерильная Кабина» — это из воздушных перевозок (вот даже в Википедии статья есть). Идея в том, что пилоты, в определенные моменты управления самолётом, исключают вообще все отвлекающие факторы — к примеру, ни при каких условиях не обсуждают ничего, что не связано с полётом. Буквально: все слова, которые они произносят в такие моменты, они произносят по регламенту. Вот посморите, как это выглядит.
Стивен Кинг в «Как писать книги» говорил, что самая главная вещь в кабинете писателя — это дверь. Хоть программисты — это не писатели, но дверь нам нужна точно так же, как и писателям. Я у себя даже устроил кабинет таким образом, чтобы в поле зрения не было вообще ничего, кроме монитора: у меня нет кипы неразобранных бумаг, фотографий близких, иконок или обоев на рабочем столе. Близкие знают, что если в кабинете закрыта дверь, в неё можно стучаться только в случае пожара (или если ты кот). Я даже храню в ящике беруши на случай, если сосед начнёт сверлить, а у меня в этот момент будет настроение поделать творческую работу.
Если бы у меня дома не было отдельного кабинета — ходил бы в коворкинг. Стерильную кабину можно организовать даже в шумном офисе — надеть хорошие заметные наушники с шумоподавлением, забиться в самую дальнюю переговорку.
Стерильная кабина настолько же необходима для работы, как нормальная оплата, понятная задача или хорошее окружение.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Всегда ревьюить модель данных и язык API
Я — сторонник positive code review, когда ответственные ребята могут пушить в прод без дополнительных одобрений. В результате positive review на прод может попадать код, который смотрел только один человек. В большинстве команд это норм, но есть исключение — всегда, хоть и после релиза, нужно проверять модель данных и схему API, ошибки в этих местах исправлять сложнее всего.
Скажем, если в схему заложено, что у одного обращения пациента может быть только один диагноз и один доктор, который его поставил, то впихнуть в вашу БД несколько диагнозов за одну госпитализацию (как в любой серии Доктора Хауса) будет стоить неимоверно дорого. Придётся переписывать все места, где вы ходите за диагнозом — ведь у обращения может быть не один диагноз, а множество, да ещё и с разным статусом.
Или вы делаете REST API, построенное вокруг сущностей с двумя разделами «автор» и «книга», и связь между ними — через поле author_id в сущности book. Затем вы пытаетесь в это API запихнуть результаты парсинга национальной библиотеки конгресса, в которых один автор может быть записан как «Mark Twain», «Twain, Mark» или «Mark Twan». Получается, либо вам нужно переделывать все эндпоинты, чтобы они принимали имя автора вместо id и дальше разбирали на бекенде, либо придётся впихивать в клиент логику определения имени автора.
Возможно, в ваших фреймворках есть ещё вещи, которые сложно переделывать, но модель данных и язык API — это стопудово штуки, достойные нормальной настройки CODEOWNERS.
А на что порекомендуете настроить CODEOWNERS вы? Пишите в комментарии, я потом вынесу в основной пост.
Я — сторонник positive code review, когда ответственные ребята могут пушить в прод без дополнительных одобрений. В результате positive review на прод может попадать код, который смотрел только один человек. В большинстве команд это норм, но есть исключение — всегда, хоть и после релиза, нужно проверять модель данных и схему API, ошибки в этих местах исправлять сложнее всего.
Скажем, если в схему заложено, что у одного обращения пациента может быть только один диагноз и один доктор, который его поставил, то впихнуть в вашу БД несколько диагнозов за одну госпитализацию (как в любой серии Доктора Хауса) будет стоить неимоверно дорого. Придётся переписывать все места, где вы ходите за диагнозом — ведь у обращения может быть не один диагноз, а множество, да ещё и с разным статусом.
Или вы делаете REST API, построенное вокруг сущностей с двумя разделами «автор» и «книга», и связь между ними — через поле author_id в сущности book. Затем вы пытаетесь в это API запихнуть результаты парсинга национальной библиотеки конгресса, в которых один автор может быть записан как «Mark Twain», «Twain, Mark» или «Mark Twan». Получается, либо вам нужно переделывать все эндпоинты, чтобы они принимали имя автора вместо id и дальше разбирали на бекенде, либо придётся впихивать в клиент логику определения имени автора.
Возможно, в ваших фреймворках есть ещё вещи, которые сложно переделывать, но модель данных и язык API — это стопудово штуки, достойные нормальной настройки CODEOWNERS.
А на что порекомендуете настроить CODEOWNERS вы? Пишите в комментарии, я потом вынесу в основной пост.
В пятницу стартует обучение на четвёртом, финальном в этом году, потоке Асинхронной Архитектуры.
Как менеджер я первый раз задумался, что архитектура — не такая уж и ненужная фигня, когда поел говна с простой, на первый взгляд, интеграцией бекофиса и магазина в ГдеМатериале. Проблема была в том, что мы использовали один и тот же эндпоинт API для всех мест, откуда падают заказы: создание заказов из сайта, интеграции с партнёрами, несколько разных интерфейсов во фронтенде.
API было одинаковым для всех потребителей, и для всех потребителей было одинаково неудобным. Самая жесть была на сайте — там выстроилась сложнейшая многослойная система: внутри celery (это питоний background processing) мы запускали сервис, который преобразует заказ из состояния, в котором он приходит от фронтенда сайта в приемлемый для бекофиса вид. Celery нужна была на случай обрыва связи при отправке заказа — у нас там были настроены даже правила ретрая. Надо ли говорить, что вся эта конструкция не спасала от изменений API, и если бекофис начинал четырёхсотить или пятисотитить — заказы всё равно терялись.
Сейчас я бы просто вкорячил в это место RabbitMQ, а если бы было время — ещё и строго типизировал бы события.
В общем, если не хотите самостоятельно разбираться с детскими ошибками и распределёнными монолитами — приходите на курс, ещё можно успеть, даже с оплатой по безналу. Говорим об асинхронной коммуникации и эволюции событий, о брокерах, аунтификации, тестировании и много о чём ещё.
Как менеджер я первый раз задумался, что архитектура — не такая уж и ненужная фигня, когда поел говна с простой, на первый взгляд, интеграцией бекофиса и магазина в ГдеМатериале. Проблема была в том, что мы использовали один и тот же эндпоинт API для всех мест, откуда падают заказы: создание заказов из сайта, интеграции с партнёрами, несколько разных интерфейсов во фронтенде.
API было одинаковым для всех потребителей, и для всех потребителей было одинаково неудобным. Самая жесть была на сайте — там выстроилась сложнейшая многослойная система: внутри celery (это питоний background processing) мы запускали сервис, который преобразует заказ из состояния, в котором он приходит от фронтенда сайта в приемлемый для бекофиса вид. Celery нужна была на случай обрыва связи при отправке заказа — у нас там были настроены даже правила ретрая. Надо ли говорить, что вся эта конструкция не спасала от изменений API, и если бекофис начинал четырёхсотить или пятисотитить — заказы всё равно терялись.
Сейчас я бы просто вкорячил в это место RabbitMQ, а если бы было время — ещё и строго типизировал бы события.
В общем, если не хотите самостоятельно разбираться с детскими ошибками и распределёнными монолитами — приходите на курс, ещё можно успеть, даже с оплатой по безналу. Говорим об асинхронной коммуникации и эволюции событий, о брокерах, аунтификации, тестировании и много о чём ещё.
Пока, backblaze
Бекапы — важная штука. Для сервера, как мы с вами в прошлый раз решили, самый хороший вариант — borg (и borgmatic). Для десктопа всё сложнее: рабочая машина включена далеко не всегда, по крону бекапы не запустишь.
Я раньше пользовался двумя системами бекапов — встроенным TimeMachine (к которому подключал большой SSD по понедельникам) и backblaze. Недавно решил отказаться от backblaze, оставив только TM. Причина простая — за два года с backblaze я заплатил им почти 300$, и ни разу не воспользовался восстановлением. Один раз попытался, но интерфейс там был настолько сложным, что мне быстрее оказалось заново написать удалённый кусок кода. Это я не говорю о куче машинного времени, которое съел демон синхронизации.
Сейчас у меня остался один TimeMachine, документы в icloud и привычка делать git push хотя бы раз в 30 минут. Недавно добавил asimov — штуку, которая исключает из бекапа всякие ненужные node_modules.
Как думаете — достаточно, или стоит поискать что-нибудь более серьёзное?
Бекапы — важная штука. Для сервера, как мы с вами в прошлый раз решили, самый хороший вариант — borg (и borgmatic). Для десктопа всё сложнее: рабочая машина включена далеко не всегда, по крону бекапы не запустишь.
Я раньше пользовался двумя системами бекапов — встроенным TimeMachine (к которому подключал большой SSD по понедельникам) и backblaze. Недавно решил отказаться от backblaze, оставив только TM. Причина простая — за два года с backblaze я заплатил им почти 300$, и ни разу не воспользовался восстановлением. Один раз попытался, но интерфейс там был настолько сложным, что мне быстрее оказалось заново написать удалённый кусок кода. Это я не говорю о куче машинного времени, которое съел демон синхронизации.
Сейчас у меня остался один TimeMachine, документы в icloud и привычка делать git push хотя бы раз в 30 минут. Недавно добавил asimov — штуку, которая исключает из бекапа всякие ненужные node_modules.
Как думаете — достаточно, или стоит поискать что-нибудь более серьёзное?
Типы в Python
Я познакомился с типизацией в Python ещё в 2018 году. Вернее не совсем познакомился — просто мы начали писать какие-то аннотации, без правил: кто хотел, тот и писал. С виду довольно бесполезное занятие — автодополнения не было, по рукам, если накосячил, никто не бил. Дальше такой опциональной типизации мы тогда не пошли — нормального инструментария не было.
Даже в такой типизации была польза: когда пишешь код с типами, начинаешь гораздо больше думать об API и данных, чем об алгоритмах и синтаксисе языка. Сдвиг мышления похож на то, что происходит с TDD — с ходу не видишь пользы, но если вкуришь, то мышление траснформируется и больше не возвращается обратно.
В 2021 году я наконец-то смог сделать проект по фен-шую: с django-stubs и mypy. На мой взгляд, стало гораздо лучше: помимо автодополнения и стандартизации кодовой базы, радикально улучшилась читаемость. Последний пункт особенно важен сейчас, когда я захожу в проекты пару раз в месяц, и с ходу должен понять, над чем работает команда.
С типизацией согласны далеко не все: и в нашей команде и в питоньем мире в целом есть чуваки, которые думают, что типы в коде забирают больше времени, чем экономят. Я этих ребят понимаю — сам несколько лет не мог определиться. До сих пор отдаю решение об обязательности типов в команду проекта: если хотят писать с нестрогими типами или вообще без них — пожалуйста.
В общем для согласных, несогласных и тех, кто хочет радикально улучшить знания по типизации, мы с Марьяной позвали в Школу Никиту Соболева. Если вдруг не знаете Никиту — он один из авторов django-stubs, член Django Software Foundation, коммитит в mypy, typeshed и CPython. Никита прочитает цикл из трёх вебинаров — об устройстве типов, о тайпчекерах и о практическом применении всего этого.
Курс — бесплатный: времена располагают, да и сообществу надо помогать. Для желающих получить обратную связь есть тариф с домашкой и сертификатами, 30% выручки от которого пойдёт на развитие системы типов в Python.
Стартует 11 октября, читаем по одному вебинару в неделю, заканчиваем 31 октября.
Зарегистрироваться →
Я познакомился с типизацией в Python ещё в 2018 году. Вернее не совсем познакомился — просто мы начали писать какие-то аннотации, без правил: кто хотел, тот и писал. С виду довольно бесполезное занятие — автодополнения не было, по рукам, если накосячил, никто не бил. Дальше такой опциональной типизации мы тогда не пошли — нормального инструментария не было.
Даже в такой типизации была польза: когда пишешь код с типами, начинаешь гораздо больше думать об API и данных, чем об алгоритмах и синтаксисе языка. Сдвиг мышления похож на то, что происходит с TDD — с ходу не видишь пользы, но если вкуришь, то мышление траснформируется и больше не возвращается обратно.
В 2021 году я наконец-то смог сделать проект по фен-шую: с django-stubs и mypy. На мой взгляд, стало гораздо лучше: помимо автодополнения и стандартизации кодовой базы, радикально улучшилась читаемость. Последний пункт особенно важен сейчас, когда я захожу в проекты пару раз в месяц, и с ходу должен понять, над чем работает команда.
С типизацией согласны далеко не все: и в нашей команде и в питоньем мире в целом есть чуваки, которые думают, что типы в коде забирают больше времени, чем экономят. Я этих ребят понимаю — сам несколько лет не мог определиться. До сих пор отдаю решение об обязательности типов в команду проекта: если хотят писать с нестрогими типами или вообще без них — пожалуйста.
В общем для согласных, несогласных и тех, кто хочет радикально улучшить знания по типизации, мы с Марьяной позвали в Школу Никиту Соболева. Если вдруг не знаете Никиту — он один из авторов django-stubs, член Django Software Foundation, коммитит в mypy, typeshed и CPython. Никита прочитает цикл из трёх вебинаров — об устройстве типов, о тайпчекерах и о практическом применении всего этого.
Курс — бесплатный: времена располагают, да и сообществу надо помогать. Для желающих получить обратную связь есть тариф с домашкой и сертификатами, 30% выручки от которого пойдёт на развитие системы типов в Python.
Стартует 11 октября, читаем по одному вебинару в неделю, заканчиваем 31 октября.
Зарегистрироваться →
Из коробки
Важное понятие в мире хорошего DX — «из коробки». Это из сленга линуксоидов — когда ты устанавливаешь ubuntu на thinkpad, а у тебя всё работает без танцев с бубном — камера, сканер отпечатков пальцев, управление питанием по крышке и куча других вещей, о которых владельцы макбуков даже не подозревают.
Для рабочих проектов, к сожалению, не существует такого же радикального решения как макбук, поэтому и здравствуют горы репозиториев, которые нужно разворачивать по несколько дней: искать старые или несуществующие зависимости, ставить определённые версии языка, демонов и внешних либ, добавлять какие-то файлы, которых нет в репозитории, или вообще править код.
Представьте, как почувствует себя новый программист в первый день работы, когда сталкивается с таким бардаком? Чувак «бьёт копытом», хочет приносить пользу, а вы его заставляете заниматься тупой механической (и скорее всего плохо документированной) работой. Это как если бы менеджеров, прежде чем допустить до первой встречи с клиентом, заставляли мыть туалеты.
Любой проект должен разворачиваться одной командой, желательно в более, чем 90% случаев. Конечно, для этого придётся проделать огромную работу — одвенадцатифакторить приложение, вылечить менеджер зависимостей, докеризовать всё что можно, протестировать на разных операционках. Эта работа может показаться пустой, но когда вы увидите новичков, которые пушат в прод на первой неделе работы — поймёте, что оно того стоит.
Важное понятие в мире хорошего DX — «из коробки». Это из сленга линуксоидов — когда ты устанавливаешь ubuntu на thinkpad, а у тебя всё работает без танцев с бубном — камера, сканер отпечатков пальцев, управление питанием по крышке и куча других вещей, о которых владельцы макбуков даже не подозревают.
Для рабочих проектов, к сожалению, не существует такого же радикального решения как макбук, поэтому и здравствуют горы репозиториев, которые нужно разворачивать по несколько дней: искать старые или несуществующие зависимости, ставить определённые версии языка, демонов и внешних либ, добавлять какие-то файлы, которых нет в репозитории, или вообще править код.
Представьте, как почувствует себя новый программист в первый день работы, когда сталкивается с таким бардаком? Чувак «бьёт копытом», хочет приносить пользу, а вы его заставляете заниматься тупой механической (и скорее всего плохо документированной) работой. Это как если бы менеджеров, прежде чем допустить до первой встречи с клиентом, заставляли мыть туалеты.
Любой проект должен разворачиваться одной командой, желательно в более, чем 90% случаев. Конечно, для этого придётся проделать огромную работу — одвенадцатифакторить приложение, вылечить менеджер зависимостей, докеризовать всё что можно, протестировать на разных операционках. Эта работа может показаться пустой, но когда вы увидите новичков, которые пушат в прод на первой неделе работы — поймёте, что оно того стоит.
#вопрос Скажи, как ты меряешь красоту архитектурных решений, когда оцениваешь, сколько стоит разработчик?
Красота и правильность архитектурных решений проверяется только временем. Для меня основной критерий для таких решений — это устойчивость к изменениям. Думаю каждый сталкивался с абстракциями, которые выглядят красиво до первой встречи с бизнесом, на которой выясняется что оказывается, чтобы добавить эту красную кнопку, надо всё переписывать.
С архитектурой систем то же самое — смотрим, насколько быстро новые разработчики способны понять устройство системы, насколько легко в неё добавляются новые проекты.
Некоторая насмотренность позволяет мне сходу оценивать решения джунов и некоторые решения мидлов. Ну а если я в себе не уверен — у команды всегда есть право облажаться, так что просто сижу и жду, что покажет время :-)
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Красота и правильность архитектурных решений проверяется только временем. Для меня основной критерий для таких решений — это устойчивость к изменениям. Думаю каждый сталкивался с абстракциями, которые выглядят красиво до первой встречи с бизнесом, на которой выясняется что оказывается, чтобы добавить эту красную кнопку, надо всё переписывать.
С архитектурой систем то же самое — смотрим, насколько быстро новые разработчики способны понять устройство системы, насколько легко в неё добавляются новые проекты.
Некоторая насмотренность позволяет мне сходу оценивать решения джунов и некоторые решения мидлов. Ну а если я в себе не уверен — у команды всегда есть право облажаться, так что просто сижу и жду, что покажет время :-)
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Действия как лекарство от тревоги
Осознал, что история с мобилизацией в эмоциональном плане проходит для меня гораздо легче, чем 24 февраля — я всего пару вечеров читал медузу, и до сих пор остаюсь функциональным и бодрым, хотя после 24 февраля приходил в себя несколько недель.
Подумал и нашёл разницу — в то время вселенная не требовала от меня никаких действий: в первые пару недель мы просто охреневали, читая новости, никаких шагов предпринимать не было нужно. Даже карты начали блокировать в первую неделю марта, то есть через две недели. А сейчас требуется совершить сразу кучу действий: отыскать военные билеты; оформить команде документы для отсрочки; помочь проектам не остановиться от того, что их участники стоят на границе.
За всеми этими действиями, времени переживать у меня просто не остаётся — вот всё и идёт спокойно. Кажется, это универсальный совет — если конвертировать тревогу не в потребление контента, а в производство важных для себя вещей, она пройдёт гораздо быстрее. Если нет важных вещей для себя — есть близкие\родственники\друзья и волонтёрство. Все кто угодно, кроме издателей СМИ, которые зарабатывают на переживаниях.
Возможно совет банальный, но не могу не поделиться, простите.
Осознал, что история с мобилизацией в эмоциональном плане проходит для меня гораздо легче, чем 24 февраля — я всего пару вечеров читал медузу, и до сих пор остаюсь функциональным и бодрым, хотя после 24 февраля приходил в себя несколько недель.
Подумал и нашёл разницу — в то время вселенная не требовала от меня никаких действий: в первые пару недель мы просто охреневали, читая новости, никаких шагов предпринимать не было нужно. Даже карты начали блокировать в первую неделю марта, то есть через две недели. А сейчас требуется совершить сразу кучу действий: отыскать военные билеты; оформить команде документы для отсрочки; помочь проектам не остановиться от того, что их участники стоят на границе.
За всеми этими действиями, времени переживать у меня просто не остаётся — вот всё и идёт спокойно. Кажется, это универсальный совет — если конвертировать тревогу не в потребление контента, а в производство важных для себя вещей, она пройдёт гораздо быстрее. Если нет важных вещей для себя — есть близкие\родственники\друзья и волонтёрство. Все кто угодно, кроме издателей СМИ, которые зарабатывают на переживаниях.
Возможно совет банальный, но не могу не поделиться, простите.
На бесплатный курс Никиты Соболева про типизацию в Python записалось уже больше 800 человек. Это в 2 раза больше самой большой группы, которую мы когда-либо обучали! Волнуюсь за организацию курса и даже немного радуюсь, что не стали делать на английском — Никита довольно известный и продуктивный опенсорсер, пришло бы ещё больше участников.
На платном тарифе с домашкой и обратной связью места тоже пока есть. Это довольно странно, учитывая известность Никиты, но всё же — если хотите с гарантией разобраться в том, как улучшить питоний код при помощи типизации, то сейчас самое время записаться, стартуем в следующий вторник, больше потоков не будет. Ну и сертификат получите.
На платном тарифе с домашкой и обратной связью места тоже пока есть. Это довольно странно, учитывая известность Никиты, но всё же — если хотите с гарантией разобраться в том, как улучшить питоний код при помощи типизации, то сейчас самое время записаться, стартуем в следующий вторник, больше потоков не будет. Ну и сертификат получите.
Перезапуск Вебиума
Выложили статью о проекте, который делали целый год (!) — полном перезапуске разработки Вебиума. Вебиум — онлайн-школа с огромным количеством учеников и сложной LMS.
Моя персональная гордость — во время этого проекта я научился не писать код — с марта добавил в репу всего несколько строк.
Горжусь командой и собой!
Выложили статью о проекте, который делали целый год (!) — полном перезапуске разработки Вебиума. Вебиум — онлайн-школа с огромным количеством учеников и сложной LMS.
Моя персональная гордость — во время этого проекта я научился не писать код — с марта добавил в репу всего несколько строк.
Горжусь командой и собой!
Блог Фёдора Борщёва
Часть первая: перезапуск магазина. Сентябрь 2021 - февраль 2022
Вебиум — онлайн-школа для подготовки к ЕГЭ. 30000 школьников, 1000 наставников, 20000 вопросов и 2000 домашних заданий
Цель сообщения
Тупое правило, которое иногда не соблюдают даже хорошие менеджеры — в удалённой работе у каждого сообщения должна быть конкретная и чётко понятная из него цель. Так, чтобы тот, кто получил ваше сообщение мог с одного взгляда понять, что вы от него хотите.
Цели бывает три:
— Задать вопрос: «Федя, у нас тут A и B. Не понимаем C. Подскажешь?»
— Согласовать: «Федя, у нас тут D и E. Хотим сделать F. Норм?»
— Попросить: «Федя, нам надо G. Без тебя не можем. Сделаешь?».
Если ваше сообщение не задаёт вопрос, не спрашивает разрешения и ни о чём не просит — скорее всего это пустое сообщение, которое лучше не писать.
Тупое правило, которое иногда не соблюдают даже хорошие менеджеры — в удалённой работе у каждого сообщения должна быть конкретная и чётко понятная из него цель. Так, чтобы тот, кто получил ваше сообщение мог с одного взгляда понять, что вы от него хотите.
Цели бывает три:
— Задать вопрос: «Федя, у нас тут A и B. Не понимаем C. Подскажешь?»
— Согласовать: «Федя, у нас тут D и E. Хотим сделать F. Норм?»
— Попросить: «Федя, нам надо G. Без тебя не можем. Сделаешь?».
Если ваше сообщение не задаёт вопрос, не спрашивает разрешения и ни о чём не просит — скорее всего это пустое сообщение, которое лучше не писать.
#вопрос Ты топишь за 12 факторов. А как ты поддерживаешь второй фактор — зависимости, к примеру imagemagick? Оборачиваешь окружение в докер? А на локальной тачке?
Для прода мы используем либо Docker, либо билдпаки от Heroku, которые точно так же явно показывают зависимости.
С локальными зависимостями сложнее. Если мы разворачиваем бекенд на машине фронтендера, то там, используем тот же dockerfile, что и на проде. Если бекенд нужно развернуть на машине бекендера — я рекомендую работать на bare metal, а в докере держать только инфраструктуру, вроде PostgreSQL или RabbitMQ.
Считаю, что бекендер не должен отвлекаться на проблемы с inotify или искать сложные пути, как зайти в контейнер и посмотреть, что там происходит. Работать на локальной тачке не так страшно, как это может звучать, по крайней мере в питоньем мире. Даже если на машине нет каких-то бинарей вроде ImageMagick, скорее всего бóльшая часть эндпоинтов всё равно будет работать корректно и без них. А если прилетит фича на эндпоинт, которому нужно специфичное окружение — уж будь добр, разберись, ты ж бекендер.
Если кускам приложения нужно сложное окружение, лучше вынести эти куски в отдельный сервис, даже не имея нормальной архитектуры. К примеру у нас в школе есть сервис генерации дипломов, у которого образ может собираться 10 минут — туда приходится паковать кучу шрифтов и headless chrome. Конечно, я не хотел бы видеть все эти зависимости в основном монолите, который приходится пересобирать по несколько раз в день, вот и вынес их в отдельный образ, который неспешно меняется раз в пару месяцев.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Для прода мы используем либо Docker, либо билдпаки от Heroku, которые точно так же явно показывают зависимости.
С локальными зависимостями сложнее. Если мы разворачиваем бекенд на машине фронтендера, то там, используем тот же dockerfile, что и на проде. Если бекенд нужно развернуть на машине бекендера — я рекомендую работать на bare metal, а в докере держать только инфраструктуру, вроде PostgreSQL или RabbitMQ.
Считаю, что бекендер не должен отвлекаться на проблемы с inotify или искать сложные пути, как зайти в контейнер и посмотреть, что там происходит. Работать на локальной тачке не так страшно, как это может звучать, по крайней мере в питоньем мире. Даже если на машине нет каких-то бинарей вроде ImageMagick, скорее всего бóльшая часть эндпоинтов всё равно будет работать корректно и без них. А если прилетит фича на эндпоинт, которому нужно специфичное окружение — уж будь добр, разберись, ты ж бекендер.
Если кускам приложения нужно сложное окружение, лучше вынести эти куски в отдельный сервис, даже не имея нормальной архитектуры. К примеру у нас в школе есть сервис генерации дипломов, у которого образ может собираться 10 минут — туда приходится паковать кучу шрифтов и headless chrome. Конечно, я не хотел бы видеть все эти зависимости в основном монолите, который приходится пересобирать по несколько раз в день, вот и вынес их в отдельный образ, который неспешно меняется раз в пару месяцев.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Вы приняты: второй поток
Мы запускаем второй поток нашего самого актуального (🥲) на сегодня курса — «Вы приняты». Курс помогает программистам найти работу за рубежом. Делая домашку, вы пройдёте все этапы поиска работы — докрутите линкедин-профиль, составите шорт-лист компаний, подготовитесь к собеседованию и даже научитесь тороговаться за офер.
Вторая штука, кроме знаний, — поддержка: на тарифе «в тусовке» вы попадёте в чатик таких же переезжающих программистов, как вы сами. На первом потоке ребята отчитывались о собеседованиях и даже находили работу прямо в процессе обучения, такие вещи придают уверенности.
Главный эксперт курса — Дима Рожков: переехал в Германию в 2014 году, поработал в Амазоне, знает много о других фаангах и десятками нанимает разработчиков в Twilio, где работает сейчас.
Посмотрите первый урок, даже если не собираетесь покупать курс — это самые полезные 12 минут, посвященные переезду, которые я видел.
Ну а если собираетесь — стартуем 4 ноября. До 26 октября действует промокод 2Y1ET со скидкой 10%.
P.S. У нас есть 20 мест для тех, кто находится рядом с боевыми действиями, но имеет силы учиться. Напишите нам, если вас это касается.
Мы запускаем второй поток нашего самого актуального (🥲) на сегодня курса — «Вы приняты». Курс помогает программистам найти работу за рубежом. Делая домашку, вы пройдёте все этапы поиска работы — докрутите линкедин-профиль, составите шорт-лист компаний, подготовитесь к собеседованию и даже научитесь тороговаться за офер.
Вторая штука, кроме знаний, — поддержка: на тарифе «в тусовке» вы попадёте в чатик таких же переезжающих программистов, как вы сами. На первом потоке ребята отчитывались о собеседованиях и даже находили работу прямо в процессе обучения, такие вещи придают уверенности.
Главный эксперт курса — Дима Рожков: переехал в Германию в 2014 году, поработал в Амазоне, знает много о других фаангах и десятками нанимает разработчиков в Twilio, где работает сейчас.
Посмотрите первый урок, даже если не собираетесь покупать курс — это самые полезные 12 минут, посвященные переезду, которые я видел.
Ну а если собираетесь — стартуем 4 ноября. До 26 октября действует промокод 2Y1ET со скидкой 10%.
P.S. У нас есть 20 мест для тех, кто находится рядом с боевыми действиями, но имеет силы учиться. Напишите нам, если вас это касается.