Opbeat закрывается
Грустная новость: закрывается Opbeat — гибрид Sentry и New Relic для энтузиастов. Гибрид — потому что умел мониторить производительность приложений и фиксировать ошибки. Для энтузиастов — потому что имел офигенный бесплатный тариф, которого хватало для небольших проектов.
Закрытие прошло как-то странно, не было ни постов в блоге, ни уведомлений — просто пришел Final Reminder. На замену предлагают Elastic APM, который тянет за собой целый огород из всех продуктов Эластика, а вместо нормальной SaaS версии предлагает жутко энтерпрайзный Elastic Cloud.
Немного напоминает поглощение и закрытие Kadira для Метеора — там тоже взамен готового решения предложили кучу исходников, которые непонятно было как запускать. Однако у разработчиков Метеора была понятная цель — всех загоняли на свою хостинговую платформу, со встроеной Кадирой.
Цели Эластика я не очень понимаю. Кому мешала SaaS-версия? Почему никто не тестировал другие тарифы или модели монетизации?
А пока ждем, когда провайдеры hosted ELK подтянут к себе новую функциональность, и юзаем Датадог и Сентри.
Грустная новость: закрывается Opbeat — гибрид Sentry и New Relic для энтузиастов. Гибрид — потому что умел мониторить производительность приложений и фиксировать ошибки. Для энтузиастов — потому что имел офигенный бесплатный тариф, которого хватало для небольших проектов.
Закрытие прошло как-то странно, не было ни постов в блоге, ни уведомлений — просто пришел Final Reminder. На замену предлагают Elastic APM, который тянет за собой целый огород из всех продуктов Эластика, а вместо нормальной SaaS версии предлагает жутко энтерпрайзный Elastic Cloud.
Немного напоминает поглощение и закрытие Kadira для Метеора — там тоже взамен готового решения предложили кучу исходников, которые непонятно было как запускать. Однако у разработчиков Метеора была понятная цель — всех загоняли на свою хостинговую платформу, со встроеной Кадирой.
Цели Эластика я не очень понимаю. Кому мешала SaaS-версия? Почему никто не тестировал другие тарифы или модели монетизации?
А пока ждем, когда провайдеры hosted ELK подтянут к себе новую функциональность, и юзаем Датадог и Сентри.
Сергей Шабалин рассказывает о прекрасном правиле: никогда не говори «я же говорил». Для удаленной команды и долгосрочных отношений — вообще мастхев.
http://shabalinsergey.ru/all/ne-govorit-ya-uzhe-govoril/
http://shabalinsergey.ru/all/ne-govorit-ya-uzhe-govoril/
Рассказал про три варианта карьерного роста для тех, кто уже достиг уровня миддла — https://xn--r1a.website/iv?url=https://borshev.com/middle-way/&rhash=5ef08d16e14be6
t.me
Программистам: три варианта развития мидла
Итак, ты научился не проебывать дедлайны, тестировать свой код и проходить код-ревью за одну итерацию. Это значит что ты — мидл, и пора задуматься о перспективах дальнейшего карьерного роста. Их на самом деле всего три: ничего не делать, стать синьором или податься…
Пацан сказал → пацан сделал
Если приглядеться, то куча людей вокруг нас не имеют простого навыка — пообещать «написать в среду» и написать в среду. Работать с такими людьми — дорого: куча энергии и внимания уходит на банальный контроль того, что порученные задачи действительно делаются.
«Пацан сказал → пацан сделал», без шуток — самый важный критерий для оценки людей в команде. Эмпатия, умение фокусироваться над задачей, планировать время и вести переговоры — все эти навыки имеют одну проекцию во внешнем мире: умение выполнять обещания.
Если новый сотрудник нарушает обещания — это даже не звонок, а тревожный гонг. Человек, не умеющий управлять временем создает кучу неудобств — опаздывает на встречи, сдает хуйню вместо результатов, вынуждает работать над особыми формами мотивации.
Выполняющему обещания коллеге, наоборот, можно поручить что угодно. С ним я уверен, что даже если обещание не выполнится (всякое бывает), я узнаю об этом максимально быстро. Такого коллегу не нужно пинговать раз в два дня, не нужно объяснять банальных вещей того, что на письма нужно отвечать, а не игнорировать.
Команды без менеджера (или иной формы принуждения) могут существовать только там, где пацаны говорят, а потом делают, что сказали.
Если приглядеться, то куча людей вокруг нас не имеют простого навыка — пообещать «написать в среду» и написать в среду. Работать с такими людьми — дорого: куча энергии и внимания уходит на банальный контроль того, что порученные задачи действительно делаются.
«Пацан сказал → пацан сделал», без шуток — самый важный критерий для оценки людей в команде. Эмпатия, умение фокусироваться над задачей, планировать время и вести переговоры — все эти навыки имеют одну проекцию во внешнем мире: умение выполнять обещания.
Если новый сотрудник нарушает обещания — это даже не звонок, а тревожный гонг. Человек, не умеющий управлять временем создает кучу неудобств — опаздывает на встречи, сдает хуйню вместо результатов, вынуждает работать над особыми формами мотивации.
Выполняющему обещания коллеге, наоборот, можно поручить что угодно. С ним я уверен, что даже если обещание не выполнится (всякое бывает), я узнаю об этом максимально быстро. Такого коллегу не нужно пинговать раз в два дня, не нужно объяснять банальных вещей того, что на письма нужно отвечать, а не игнорировать.
Команды без менеджера (или иной формы принуждения) могут существовать только там, где пацаны говорят, а потом делают, что сказали.
Методологии разработки
Есть методологии вроде скрама, которые описывают каждый шаг, который нужно делать, чтобы прийти к результату — ежедневные встречи, берндаун-чарты, сторипоинты, вот это все.
Есть методологии, пришедшие к нам из менее развитых областей, суть которых сводится к тому, как правильно и с какой регулярностью программистов нужно пи́здить.
Но почему-то ни одна методология не рассказывает, что для достижения хорошего результата можно просто нанять ответственных людей и не ебать им мозги.
Наверное потому, что это тяжело описать: как правильно расставаться с безответственными, как заинтересовать ответственных. Как, в конце концов, построить организацию, из которой не хочется сбежать через 3 месяца.
По-моему, самая лучшая методология разработки — создать контекст, который выдавливает из себя безответственных людей и притягивает ответственных. А затем не мешать им работать.
Есть методологии вроде скрама, которые описывают каждый шаг, который нужно делать, чтобы прийти к результату — ежедневные встречи, берндаун-чарты, сторипоинты, вот это все.
Есть методологии, пришедшие к нам из менее развитых областей, суть которых сводится к тому, как правильно и с какой регулярностью программистов нужно пи́здить.
Но почему-то ни одна методология не рассказывает, что для достижения хорошего результата можно просто нанять ответственных людей и не ебать им мозги.
Наверное потому, что это тяжело описать: как правильно расставаться с безответственными, как заинтересовать ответственных. Как, в конце концов, построить организацию, из которой не хочется сбежать через 3 месяца.
По-моему, самая лучшая методология разработки — создать контекст, который выдавливает из себя безответственных людей и притягивает ответственных. А затем не мешать им работать.
Аркадий Фомич дело говорит — чтобы нанимать лучших, нужно создавать такие условия, в которых будет понятен их рост на рынке труда.
К примеру, дать громкий проект, который хочется положить в портфолио. Или адаптировать у себя радикально новые технологии, о которых все заговорят только через год.
К примеру, дать громкий проект, который хочется положить в портфолио. Или адаптировать у себя радикально новые технологии, о которых все заговорят только через год.
Forwarded from Тёмная сторона / Темнографика
Что нужно поколению Z от работы?
1. Deloitte провел исследование разницы в отношениях миллениалов и поколения Z к работе и будущему. Миллениалы – родившиеся с 1983 по 1994 год, поколение Z – с 1995 по 1999. Я обратил внимание на два слайда. Количество миллениалов, собирающихся сменить работу в течение двух лет – 43%, количество людей в поколении Z с теми же целями – 61%. Люди из поколения Z думают, что у них меньше перспектив в жизни и карьере: на 32% меньше, чем у миллениалов, и на 43-46% меньше, чем у предыдущих поколений. Дальше в отчете делаются выводы, что поколение Z бла-бла-бла что-то там. Но мне кажется, что "нет ничего нового под солнцем", а все это проявление других, но древних как мир истин.
2. Молодое поколение более остро чувствует, что радужные перспективы достанутся не всем. Они еще готовы ради этих перспектив суетиться – хотя, ничего, кроме более быстрого перебора рабочих мест, большинство из них придумать не может.
3. Чем взрослее это поколение становится, тем больше люди смиряются с тем, что у них уже есть. Зачем менять работу, если на другое работе будет почти то же самое? Давайте убедим себя, что у нас и так все хорошо – ведь у нас есть квартира и машина, семья и дети, и с работу нас еще не выгнали.
4. Кроме общих соображений по поводу того, "в чем смысл жизни", и "перспективы надо искать и создавать еще в молодости" – напрашивается еще один более конструктивный вывод. Если мы хотим привлекать к себе на работу молодежь – не надо обещать им пожизненной карьеры в своей компании. Наоборот, надо манить их перспективами научиться у нас чему-то настолько полезному, чтобы в течение пары лет они могли упорхнуть от нас куда-нибудь повыше.
Ссылка на полный текст исследования: https://documents.deloitte.com/insights/2018DeloitteMillennialSurvey
1. Deloitte провел исследование разницы в отношениях миллениалов и поколения Z к работе и будущему. Миллениалы – родившиеся с 1983 по 1994 год, поколение Z – с 1995 по 1999. Я обратил внимание на два слайда. Количество миллениалов, собирающихся сменить работу в течение двух лет – 43%, количество людей в поколении Z с теми же целями – 61%. Люди из поколения Z думают, что у них меньше перспектив в жизни и карьере: на 32% меньше, чем у миллениалов, и на 43-46% меньше, чем у предыдущих поколений. Дальше в отчете делаются выводы, что поколение Z бла-бла-бла что-то там. Но мне кажется, что "нет ничего нового под солнцем", а все это проявление других, но древних как мир истин.
2. Молодое поколение более остро чувствует, что радужные перспективы достанутся не всем. Они еще готовы ради этих перспектив суетиться – хотя, ничего, кроме более быстрого перебора рабочих мест, большинство из них придумать не может.
3. Чем взрослее это поколение становится, тем больше люди смиряются с тем, что у них уже есть. Зачем менять работу, если на другое работе будет почти то же самое? Давайте убедим себя, что у нас и так все хорошо – ведь у нас есть квартира и машина, семья и дети, и с работу нас еще не выгнали.
4. Кроме общих соображений по поводу того, "в чем смысл жизни", и "перспективы надо искать и создавать еще в молодости" – напрашивается еще один более конструктивный вывод. Если мы хотим привлекать к себе на работу молодежь – не надо обещать им пожизненной карьеры в своей компании. Наоборот, надо манить их перспективами научиться у нас чему-то настолько полезному, чтобы в течение пары лет они могли упорхнуть от нас куда-нибудь повыше.
Ссылка на полный текст исследования: https://documents.deloitte.com/insights/2018DeloitteMillennialSurvey
Namecheap включил бесплатный WhoisGuard
WhoisGuard — это сервис, который защищает от спамеров ваши контакты: домен остается зарегистрированным на вас, но никто об этом не может узнать.
В рунете это давно уже включено по умолчанию на законодательном уровне, а теперь появилась возможность получить это бесплатно от одного из самых дешевых (и понятных) мировых регистраторов.
WhoisGuard — это сервис, который защищает от спамеров ваши контакты: домен остается зарегистрированным на вас, но никто об этом не может узнать.
В рунете это давно уже включено по умолчанию на законодательном уровне, а теперь появилась возможность получить это бесплатно от одного из самых дешевых (и понятных) мировых регистраторов.
Следующий раунд борьбы Телеграма с Роскомнадзором
Сегодня вышло обновление телеграма. Официально оно содержит обновления для GPDR, неофициально — поддержку нового формата прокси — MTProto.
MTProto — нативный для телеги формат передачи данных: примерно такие сервера Дуров разворачивает пачками на разных площадках, чтобы обходить блокировки.
Выпуск прокси в паблик — очевидный шаг к децентрализации: теперь каждый может развернуть у себя сервер, который разрешает пользоваться телеграмом всему ближнему кругу. Пользователи даже могут выбирать, к чьему прокси подключаться.
С моего дивана это кажется ещё одним шагом в сторону пропасти^W DPI — такие действия вынуждают Роскомнадзор перейти от тупой блокировки IP-адресов к полноценному автоматическому изучению вашего трафика.
Это значит, что у каждого провайдера поселится специальный неебически дорогой робот, который будет решать: ага, этот пакет похож на телеграм, в жопу его. Вот там порнуху смотрят — ну пусть посмотрят. Так, а здесь что-то много трафика в Финляндию, не пойму что передают — замедлим до 32кбит/с, пусть шифруются, кек.
О том, как живут люди с DPI в Иране, можно почитать грустный тредик на гитхабе.
Тяжело придётся небольшим разработчикам, у которых вся облачная инфраструктура, включая девопс — заемная, и находится за границей. Придётся мигрировать на корявые коробочные решения, вроде гитлаба и ютрека, платить деньги за хостинг и зарплату админам.
Ну а я пойду приближать эпоху Золотого Щита, и поднимать MTProto в дополнение к SOCKS для всех, с кем хочу поддерживать связь.
Сегодня вышло обновление телеграма. Официально оно содержит обновления для GPDR, неофициально — поддержку нового формата прокси — MTProto.
MTProto — нативный для телеги формат передачи данных: примерно такие сервера Дуров разворачивает пачками на разных площадках, чтобы обходить блокировки.
Выпуск прокси в паблик — очевидный шаг к децентрализации: теперь каждый может развернуть у себя сервер, который разрешает пользоваться телеграмом всему ближнему кругу. Пользователи даже могут выбирать, к чьему прокси подключаться.
С моего дивана это кажется ещё одним шагом в сторону пропасти^W DPI — такие действия вынуждают Роскомнадзор перейти от тупой блокировки IP-адресов к полноценному автоматическому изучению вашего трафика.
Это значит, что у каждого провайдера поселится специальный неебически дорогой робот, который будет решать: ага, этот пакет похож на телеграм, в жопу его. Вот там порнуху смотрят — ну пусть посмотрят. Так, а здесь что-то много трафика в Финляндию, не пойму что передают — замедлим до 32кбит/с, пусть шифруются, кек.
О том, как живут люди с DPI в Иране, можно почитать грустный тредик на гитхабе.
Тяжело придётся небольшим разработчикам, у которых вся облачная инфраструктура, включая девопс — заемная, и находится за границей. Придётся мигрировать на корявые коробочные решения, вроде гитлаба и ютрека, платить деньги за хостинг и зарплату админам.
Ну а я пойду приближать эпоху Золотого Щита, и поднимать MTProto в дополнение к SOCKS для всех, с кем хочу поддерживать связь.
И еще вакансии
Мы в mtrl.ai растём на 20% каждый месяц. Задач становится все больше, поэтому мы открываем новый набор. Кто нужен:
— Дизайнер-продуктолог, Москва. Работа удаленная, но два-три дня в неделю нужно появляться в офисе.
— Ведущий питонист, обязательна терпимость к JS желание стать фулл-стеком.
— Джуниор-фуллстек. Если вы знаете про TDD в питоне и можете отличить vue от реакта — после года у нас начнете стоить как крутой мидл.
Продуктолог получает полный доступ к цифрам, быстрых разработчиков и крутых эдвайзеров.
Программисты — удаленную работу без менеджеров, и проект с хорошим кодом на ультрасовременном стеке.
Вы будете работать над e-коммерсом с полностью автоматической логистикой, который скоро захватит рынок стройматериалов. Ответственность и свобода в принятии решений прилагается.
Мы в mtrl.ai растём на 20% каждый месяц. Задач становится все больше, поэтому мы открываем новый набор. Кто нужен:
— Дизайнер-продуктолог, Москва. Работа удаленная, но два-три дня в неделю нужно появляться в офисе.
— Ведущий питонист, обязательна терпимость к JS желание стать фулл-стеком.
— Джуниор-фуллстек. Если вы знаете про TDD в питоне и можете отличить vue от реакта — после года у нас начнете стоить как крутой мидл.
Продуктолог получает полный доступ к цифрам, быстрых разработчиков и крутых эдвайзеров.
Программисты — удаленную работу без менеджеров, и проект с хорошим кодом на ультрасовременном стеке.
Вы будете работать над e-коммерсом с полностью автоматической логистикой, который скоро захватит рынок стройматериалов. Ответственность и свобода в принятии решений прилагается.
Тупое правило менеджера
Ещё в студии я познакомился с простым правилом управления любым проектом:
Если прошло 50% времени, проверь — выполнена ли половина работы
У многих людей в мозгу есть баг: к началу второй половины срока они обычно не осознают, что первая половина уже упущена. Грубо говоря, если вы пообещали сделать что-то через неделю, и прошло три дня, то без внешнего воздействия у вас не возникает ощущение «ааа, только половина времени осталась, пойду хуячить». Скорее будет «ой, да еще 4 дня есть, пойду погуляю».
Зато, если к вам подойти и рассказать об ушедшей половине, начинает работать магия, которая обычно включается только перед дедлайном — откидываются ненужные требования, игнорируются редкие юзкейсы, придумываются неожиданные творческие решения и т.д.
Кстати, этот вопрос можно задавать самому себе и без помощи менеджера — хватит даже самой простой системы напоминалок.
#тупое_правило
Ещё в студии я познакомился с простым правилом управления любым проектом:
Если прошло 50% времени, проверь — выполнена ли половина работы
У многих людей в мозгу есть баг: к началу второй половины срока они обычно не осознают, что первая половина уже упущена. Грубо говоря, если вы пообещали сделать что-то через неделю, и прошло три дня, то без внешнего воздействия у вас не возникает ощущение «ааа, только половина времени осталась, пойду хуячить». Скорее будет «ой, да еще 4 дня есть, пойду погуляю».
Зато, если к вам подойти и рассказать об ушедшей половине, начинает работать магия, которая обычно включается только перед дедлайном — откидываются ненужные требования, игнорируются редкие юзкейсы, придумываются неожиданные творческие решения и т.д.
Кстати, этот вопрос можно задавать самому себе и без помощи менеджера — хватит даже самой простой системы напоминалок.
#тупое_правило
Вот тут чувак анализирует вакансии в стартапах США для программистов Руби. Говорит, что спрос еще есть.
Немного смущает формулировка «еще» — кажется, что легкие в освоении MVC-решения на скриптовых языках будут жить еще долго: все-таки с ними приятно начинать бекендные проекты. На их стороне стороне документация, стабильность, количество батареек и легкость тестирования, а как следствие — очень высокая скорость разработки на одного программиста.
Кстати, на втором месте в том обзоре — моя любимая Django.
А как вы думаете, что стоит учить джуниору, чтобы найти работу в крутом айти-стартапе?
Немного смущает формулировка «еще» — кажется, что легкие в освоении MVC-решения на скриптовых языках будут жить еще долго: все-таки с ними приятно начинать бекендные проекты. На их стороне стороне документация, стабильность, количество батареек и легкость тестирования, а как следствие — очень высокая скорость разработки на одного программиста.
Кстати, на втором месте в том обзоре — моя любимая Django.
А как вы думаете, что стоит учить джуниору, чтобы найти работу в крутом айти-стартапе?
FEDOR BORSHEV via @vote
Что учить джуниору, чтобы найти работу в крутом ИТ-стартапе?
anonymous poll
Node.js😱 – 131
👍👍👍👍👍👍👍 58%
Джанго – 69
👍👍👍👍 31%
Рельсы – 25
👍 11%
👥 225 people voted so far.
anonymous poll
Node.js😱 – 131
👍👍👍👍👍👍👍 58%
Джанго – 69
👍👍👍👍 31%
Рельсы – 25
👍 11%
👥 225 people voted so far.
Фичреквесты, которые не стоит выполнять
Даже самые полезные фичи в момент появления скорее всего выглядят уродливо.
Система рассылки счетов и контроля оплаты скорее всего начиналась как просьба бухгалтера покрасить все безналичные заказы в красный цвет. Интерфейс сбора обратной связи начинался с просьбы выгрузить заказы в эксель, «чтобы менеджеры видели, куда звонить»
Чтобы сырые фичи не уходили в работу, посередине между бизнесом и программистами всегда должен стоять человек, который преобразует сырые пользовательские запросы в задачи, которые приносят пользу.
Обычно этим занимается выделенный продуктовый менеджер, или дизайнер, который умеет задавать вопросы. Если у вас таких людей пока нет — внедрите хотя бы стоп-задачи: запросы, которые НИКОГДА не обрабатываются в сыром виде:
— выгрузка в Эксель
— автоматическое письмо в посту/слэк/СМС
— добавить любую кнопку/галочку
— покрасить что-нибудь в красный/выделить жирным
Сделайте так, чтобы среди тех, кто обсуждает эти задачи, был хотя бы один человек, способный спросить «зачем?». Если вы не будете задавать такой вопрос каждой новой фиче, то ваш продукт раздуется до таких размеров, что действительно важным вещам просто не найдется места среди пяти разных выгрузок и выделений красным.
#чтобычто
Даже самые полезные фичи в момент появления скорее всего выглядят уродливо.
Система рассылки счетов и контроля оплаты скорее всего начиналась как просьба бухгалтера покрасить все безналичные заказы в красный цвет. Интерфейс сбора обратной связи начинался с просьбы выгрузить заказы в эксель, «чтобы менеджеры видели, куда звонить»
Чтобы сырые фичи не уходили в работу, посередине между бизнесом и программистами всегда должен стоять человек, который преобразует сырые пользовательские запросы в задачи, которые приносят пользу.
Обычно этим занимается выделенный продуктовый менеджер, или дизайнер, который умеет задавать вопросы. Если у вас таких людей пока нет — внедрите хотя бы стоп-задачи: запросы, которые НИКОГДА не обрабатываются в сыром виде:
— выгрузка в Эксель
— автоматическое письмо в посту/слэк/СМС
— добавить любую кнопку/галочку
— покрасить что-нибудь в красный/выделить жирным
Сделайте так, чтобы среди тех, кто обсуждает эти задачи, был хотя бы один человек, способный спросить «зачем?». Если вы не будете задавать такой вопрос каждой новой фиче, то ваш продукт раздуется до таких размеров, что действительно важным вещам просто не найдется места среди пяти разных выгрузок и выделений красным.
#чтобычто
Как мы мониторим заказы
Начинаю потихоньку публиковать наши внутренние инструкции. Начну с описания того, как мы мониторим заказы — какие письма и из каких систем приходят, и как мы на них реагируем.
Если ваша работа связана с автоматизацией екоммерса (и вы достаточно хипстер, чтобы не работать с битриксом), пишите в личку, какие инструкции еще стоит выложить.
Начинаю потихоньку публиковать наши внутренние инструкции. Начну с описания того, как мы мониторим заказы — какие письма и из каких систем приходят, и как мы на них реагируем.
Если ваша работа связана с автоматизацией екоммерса (и вы достаточно хипстер, чтобы не работать с битриксом), пишите в личку, какие инструкции еще стоит выложить.
Сервис: uptimerobot
На рынке есть куча SaaS-решений для мониторинга работоспособности — от простого statuscake родом из 2000-х, до дорогущего new relic или специализированных связок из prometheus и продуктов elastic.
При этом, обычные SMB-пользователи таких систем хотят очень простой вещи — чтобы если что-то пошло не так, об этом быстро упало уведомление.
Uptimerobot — отличное решение для тех, кто не хочет разбираться в раздутых интерфейсах и перипетиях ценообразования. Бесплатно можно мониторить до 50 ресурсов, работает интеграция с телеграмом и кучей других сервисов.
За 5,5$ в месяц дают мониторить неограниченное количество сайтов, проверяют их раз в минуту (вместо раза в 5 минут), отслеживают живость SSL-сертификатов и рассылают СМС.
На рынке есть куча SaaS-решений для мониторинга работоспособности — от простого statuscake родом из 2000-х, до дорогущего new relic или специализированных связок из prometheus и продуктов elastic.
При этом, обычные SMB-пользователи таких систем хотят очень простой вещи — чтобы если что-то пошло не так, об этом быстро упало уведомление.
Uptimerobot — отличное решение для тех, кто не хочет разбираться в раздутых интерфейсах и перипетиях ценообразования. Бесплатно можно мониторить до 50 ресурсов, работает интеграция с телеграмом и кучей других сервисов.
За 5,5$ в месяц дают мониторить неограниченное количество сайтов, проверяют их раз в минуту (вместо раза в 5 минут), отслеживают живость SSL-сертификатов и рассылают СМС.
Продолжаю публиковать отрывки из нашей внутренней документации. Здесь рассказано, как новые специалисты поднимают у себя проекты, чтобы начать разработку (спойлер — почти никак).
Инструкция будет интересна небольшим командам, которые хотят получить нормальный девопс — с ее помощью мы в mtrl.ai добились того, что новый фронтендер, знающий vue.js, может контрибьютить в прод в первый рабочий день.
Ссылки на докерфайлы ведут на закрытые ресурсы, если интересно что-то оттуда — пишите в личку, расскажу.
Инструкция будет интересна небольшим командам, которые хотят получить нормальный девопс — с ее помощью мы в mtrl.ai добились того, что новый фронтендер, знающий vue.js, может контрибьютить в прод в первый рабочий день.
Ссылки на докерфайлы ведут на закрытые ресурсы, если интересно что-то оттуда — пишите в личку, расскажу.
Красиво решать задачи
Если спросить у программиста, чем красивое решение отличается от плохого, мы услышим много ответов: понятный код, мало строк, покрытие тестами, выполнение требований.
Мой любимый критерий красивого решения — время. Причем время не календарное (если ваша команда не может делать задачи быстро, вам не до «красивости»), а относительное. Почти любую сложную задачу можно решить быстрее, чем при помощи первого пришедшего в голову варианта: не пилить микросервис, а сделать кеширование; не рефакторить все приложение, а сделать микросервис; не писать новый компонент, а допилить и переиспользовать старый.
Медленное и некрасивое решение обычно выглядит так: заказчик пришел с проблемой → уходим пилить → заказчик пришел еще с одной проблемой → проебали обе.
Красивое и быстрое — так: заказчик пришел с проблемой → быстро снимаем боль → решаем другие задачи, параллельно думаем над красивым решением → как только придумали — выкатываем, если ничего не придумали, то записываем техдолг.
К сожалению, чтобы в продукте появлялись красивые и эффективные решения, нужна целая экосистема, т.н. «культура разработки»: сильные тимлиды, отсутствие авралов, разумный техдолг, умение ставить задачи-проблемы вместо задач-решений, вести диалог и еще много всего. А без экосистемы программисты думают не над эффективностью, а над тем, как сделать, чтобы от них отъебались.
Если спросить у программиста, чем красивое решение отличается от плохого, мы услышим много ответов: понятный код, мало строк, покрытие тестами, выполнение требований.
Мой любимый критерий красивого решения — время. Причем время не календарное (если ваша команда не может делать задачи быстро, вам не до «красивости»), а относительное. Почти любую сложную задачу можно решить быстрее, чем при помощи первого пришедшего в голову варианта: не пилить микросервис, а сделать кеширование; не рефакторить все приложение, а сделать микросервис; не писать новый компонент, а допилить и переиспользовать старый.
Медленное и некрасивое решение обычно выглядит так: заказчик пришел с проблемой → уходим пилить → заказчик пришел еще с одной проблемой → проебали обе.
Красивое и быстрое — так: заказчик пришел с проблемой → быстро снимаем боль → решаем другие задачи, параллельно думаем над красивым решением → как только придумали — выкатываем, если ничего не придумали, то записываем техдолг.
К сожалению, чтобы в продукте появлялись красивые и эффективные решения, нужна целая экосистема, т.н. «культура разработки»: сильные тимлиды, отсутствие авралов, разумный техдолг, умение ставить задачи-проблемы вместо задач-решений, вести диалог и еще много всего. А без экосистемы программисты думают не над эффективностью, а над тем, как сделать, чтобы от них отъебались.
Пример решения из предыдущего поста
У нас в mtrl.ai есть понятие «виртуального склада» — это огромный массив ценовых предложений со строительных рынков, который мы накопили и постоянно обновляем. Благодаря этому массиву мы можем быстро прогнозировать конкретный рынок (и даже конкретного продавца), который лучше всего повезёт заказ.
После определённого объёма мы стали упираться в производительность базы — прогнозы нужны почти в реальном времени, а данные хранятся в нормализованном виде.
Чтобы задача не болела, мы применили тупое решение — просто увеличили в два раза ресурсы на сервере с базой.
Очевидное и правильное решение — микросервис, который хранит у себя данные в удобном для выборке виде. Его пока не стали делать — это работа на несколько дней, что невыразимо много в масштабе стартапа.
Зато, увеличение ресурсов дало возможность заняться другими делами и начать не спеша (и без дедлайна) думать над хорошим решением. В итоге просто сделали дебаунс для асинхронного генератора прогнозов, т.е. стали обновлять прогнозы не после каждого изменения в заказе, а только после последнего. Нагрузка снизилась настолько, что ещё месяца три можно не возвращаться к долгой задаче микросервиса.
В итоге мы потратили 30 минут вместо трёх дней просто за счет того, что дали себе спокойно подумать.
У нас в mtrl.ai есть понятие «виртуального склада» — это огромный массив ценовых предложений со строительных рынков, который мы накопили и постоянно обновляем. Благодаря этому массиву мы можем быстро прогнозировать конкретный рынок (и даже конкретного продавца), который лучше всего повезёт заказ.
После определённого объёма мы стали упираться в производительность базы — прогнозы нужны почти в реальном времени, а данные хранятся в нормализованном виде.
Чтобы задача не болела, мы применили тупое решение — просто увеличили в два раза ресурсы на сервере с базой.
Очевидное и правильное решение — микросервис, который хранит у себя данные в удобном для выборке виде. Его пока не стали делать — это работа на несколько дней, что невыразимо много в масштабе стартапа.
Зато, увеличение ресурсов дало возможность заняться другими делами и начать не спеша (и без дедлайна) думать над хорошим решением. В итоге просто сделали дебаунс для асинхронного генератора прогнозов, т.е. стали обновлять прогнозы не после каждого изменения в заказе, а только после последнего. Нагрузка снизилась настолько, что ещё месяца три можно не возвращаться к долгой задаче микросервиса.
В итоге мы потратили 30 минут вместо трёх дней просто за счет того, что дали себе спокойно подумать.