Процессы и лидопад

Как и многие разработчики, я выступаю за отстроенные процессы. Как ставятся задачи, происходит синхронизация в команде, шаринг знаний, релизы и так далее. Здесь замешан какой-то микс между процессным менеджментом и менеджментом команды. То есть и инструменты и взаимодействия.

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

Я тратил на это довольно много времени постоянно проводя доп обучение, создавая базы знаний и даже выпуская статьи на тот же VC, где я рассказывал про организацию приватных документов или досок в Notion. Ну и где-то получалось, где-то нет. С моей точки зрения все было не очень эффективно. А потом внезапно я посмотрел одно видео, которое перевернуло мое отношение ко всему что происходит.

Это видео Миши Гребенюка, который попал в меня на 100%. Он объяснил такую вещь. Ваш бизнес в порядке, только когда он находится в состоянии лидопада (лид это потенциальный клиент, например человек оставивший заявку. не каждый лид становится клиентом), то есть когда вас заваливает потоком заявок так, что вы не успеваете его разгребать и все процессы летят в тартарары. И как владелец бизнеса, вы должны в первую очередь обеспечить этот лидопад. Если у вас его нет, а вместо его организации вы занимаетесь отстраиванием процессов, то вы как бизнесмен занимаетесь херней, а ваш бизнес очевидно теряет, потому что спокойные времена говорят об отсутствии роста. В лучшем случае это стагнация, в худшем падение. Чем спокойнее с этой точки зрения в компании, тем хуже скорее всего идут дела у бизнеса.

Отсюда логически следует кое что интересное. Между владельцем и сотрудниками всегда существует конфликт интересов, когда одному нужен рост и желательно ускоряющийся, а другим наоборот нужно зафиксироваться, чтобы перестроиться и дальше спокойно работать. В местах где-то не так, либо задействовано государство, либо монополия.

p.s. Возможно для кого-то это будет просто очередной пост, но для меня эта мысль перевернула мир чтоли. Один из тех самых ключевых инсайтов, которые изменил меня как предпринимателя (приблизил к этому)

Ссылки: Телеграм | Youtube | VK

А между тем выпуск по плюсам уже на ютубе, вк и других площадках (включая аудио) https://youtu.be/-6RCZhM9hqU?si=IbvGURYfquEUIPFO

Альтернативные ссылки: Аудио | vk

Гости для подкаста

Сложно в это поверить, но моему подкасту недавно исполнился год. Вышло около 60 выпусков, где в основном были технические темы, но иногда я зацеплял и что-то вокруг + бизнесовые моменты.

За последние три месяца подкаст + шортсы из него посмотрели почти 5 миллионов раз! Правда тут надо учесть один шортс с Бугаенко. Он один собрал 3 миллиона и это какой-то рекорд, который я вообще не факт что смогу побить. Но даже без него получается пару миллионов, что довольно некисло.

За все время подкаста самым популярным стало видео:

⁃ Кира Кузьменько
⁃ Егор Бугаенко
⁃ Деми Мурыч

Жизнь показала, что несмотря на мой интерес к бизнесовым темам, все же сюда приходят за техническими вещами, поэтому я буду держаться этого курса с нерегулярным разбавлением разным.

Я все еще не разобрал конкретные фреймворки, системный дизайн и все что в него входит по элементно, стили программирования, концепции, computer science в целом (и лямбды и теорию типов). Никуда не делась история с лайвкодингом, дебатами и моими разборами, которые я хотел бы делать чаще. Поэтому если у вас есть видео на разбор, присылайте его.

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

Ссылки: Телеграм | Youtube | VK

Тестируем вызовы API с помощью кассет

В подкасте про TDD обсуждали такую штуку, как кассеты для тестирования. Они широко распространены в ruby мире, но за его рамками о них знают значительно меньше, хотя это очень мощный инструмент. Кстати, Илья после того подкаста так вдохновился, что пошел и сделал аналог на go.

В двух словах. Кассеты это по сути замена моков для апи вызовов (более точно стабов) снепшотами. Когда вместо того, чтобы подменить вызов и возвращать ответ сформированный в тесте, мы позволяем при первом запуске тестов сходить в настоящее API. Библиотека сама записывает ответ в нужное место и при повторных вызовах она сама подменяет вызов и делает нужный возврат. Вот как это выглядит:

class VCRTest < Test::Unit::TestCase
  def test_example_dot_com
    VCR.use_cassette("synopsis") do
      response = Net::HTTP.get_response(URI('https://www.iana.org/domains/reserved'))
      assert_match /Example domains/, response.body
    end
  end
end

В примере выше вызов происходит прямо в тесте, но это просто пример, в реальном коде, здесь будет вызываться наше приложение, которое где-то внутри себя уже делает вызов или вызовы.

Мы очень активно используем эту либу для всяких сложных штук, типа страйпа, где ответ может состоять из сотен и тысяч строк кода, причем все это возвращается в навороченной системе объектов.

Кстати порты этой либы есть наверное для всех языков. Накидайте в комментах ссылки на популярные решения для вашего стека. Рубишная вот: https://github.com/vcr/vcr

Ссылки: Телеграм | Youtube | VK

Продолжаем про подкасты 🙂 Рынок IT-найма все еще лихорадит. Количество специалистов растёт, вакансий меньше, а рекрутинг переживает, пожалуй, один из самых турбулентных периодов за последние годы. Мы говорим с Алексеем Сухоруковым — человеком, который с 2005 года занимается IT-рекрутментом помогая инженерам находить работу по всему миру

В выпуске обсуждаем, почему рынок стал «рынком компаний» и чем текущая ситуация отличается от кризиса 2008-го. Разбираем, как на найм повлияли ковид, массовая удалёнка, релокации и санкции. Отдельная часть — о том, как автоматизация и ИИ меняют процесс подбора кандидатов, почему джунам стало почти невозможно пробиться и как компании реагируют на лавину фейковых резюме и дипфейков.

Мы также говорим о переходе от удалёнки к офисам, налогах и релокации в Европу, Восточной Европе как новом центре роста, а ещё вспоминаем истории о зарождении российского аутсорса, дотком-буме и даже «сектантских» практиках некоторых ранних компаний. youtube.com/watch?v=o-LQSbo6w2s

Альтернативные ссылки: Аудио | vk

Как правильно откатывать миграции

Если коротко, то никак. В продакшене миграции могут идти только вперед. Какого?

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

Ролбек, в идеале, это просто переключение с одной версии кода на другую. Но ведь тогда возможны ошибки связанные с изменениями в базе? Если делать через жопу, то возможны. При правильном подходе, база всегда обратно совместима как минимум на одну версию. Только в этом случае мы можем обеспечить и бесшовный деплой (zero downtime deploy) и практически моментальный откат.

А это значит, что нельзя менять тип у колонок (если тип сужается), нельзя менять именования таблиц и полей. Если это все таки нужно, то существует немало техник, позволяющих сделать переход через создание новых сущностей и синхронизацией либо через код либо через саму базу (например с помощью триггеров). По этой теме даже написали целую книгу "Refactoring Databases: Evolutionary Database Design".

Получается, что любые ошибки в базе будут только накапливаться? Не совсем. Обратная совместимость обычно нужна только на текущую и следующую версию. Если у нас не коробка, а облачное решение, то одновременно могут работать только две версии. В таком случае, мы без проблем можем писать любые миграции, которые удаляют и меняют все что угодно, что уже не используется. Заметьте, это не откат, а новые миграции.

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

Ссылки: Телеграм | Youtube | VK

Тут в закромах мы готовим мощное видео с аналитикой и интервью hr на тему того как они смотрят на сопроводительные с реальными кейсами. Хотим поставить так сказать жирную точку в этом вопрос, надо ли писать и если надо то как. Вы можете принять непосредственное участие в создании, ответив на несколько вопросов из нашей анкеты про ваше отношение к сопроводительным: https://docs.google.com/forms/d/e/1FAIpQLSfubAb9OLRPZPWmYg8O8STZMFgLJY36C1MmC1aIVvHO-EAqtA/viewform?usp=header Будьте бобры 🙂 и не забудьте переслать друзьям программистам!

Ссылки: Телеграм | Youtube | VK

Пятничный пост

Решил включить эксперимент и написать что-нибудь личное, а не только профессиональное. Если зайдет, буду иногда постить, если нет, то только в инсте.

Где-то 3 года назад меня залили соседи. Залили причем так конкретно, с потолка шел можно сказать дождь. Мы все это добро зафиксировали и отправили в страховую. Заодно, по советам знакомых, заказали тест на плесень, в наших краях это крайне важно, потому что черная плесень опасна для жизни и требует эвакуации (и ее дорого удалять). Плесень нашли (слава богу не черную) и результаты тоже приложили к делу.

В конечном итоге мне прислали чек на 3500$ из которых я уже заплатил около 1000$ за тест. Честно говоря это сильно меньше, чем ремонт, который надо было бы сделать. К этому моменту я уже был наслышан про то как судятся со страховыми и решил пойти по этому пути.

Работает это так, находишь компанию, которая специализируется на подобных делах, они собирают доки и сами разбираются со страховой переодически напоминая о себе и призывая на разные мероприятия типа слушаний. Ты им ничего не платишь, но они берут процент от денег, которые ты получишь от страховой в конце.

Начали мы бодро, мне сказали что офигенный кейс, есть фотки видео, а еще плесень, красота. Насчитали что мы сможем получить около 75 000$.

Дальше был интересный процесс, который называется mediation. Все в зуме. На этом процессе есть я и мой attorney, с другой стороны представитель страховой. Между нами есть человек, что-то вроде судьи (я так понял это бывшие судьи), который ведет процесс. Идея в том, что каждый выражает свое мнение, дальше мы расходимся по комнатам где обсуждаем сумму. Мы говорим сумму подключившемуся к нашей комнате судье, дальше судья идет в комнату страховой и говорит наше предложение, они делают контрпредложение. И это реально выглядит как жесткие переговоры, с угрозами "наше финальное предложение 10 000$ или мы уходим". В общем предложили нам сумму, которая нас не устроила и attorney уговорила меня продолжить процесс.

И на этом все встало примерно совсем. Прошел год, потом другой и я уже смирился с тем, что никаких денег не увижу, когда вдруг мне написали что готовится очередной mediation. Видимо все таки, какая-то движуха за эти годы там была, может и не так активно. Короче в этот раз мы договорились до суммы в 30 000$. При этом мы не согласились на то, что ее берем, там такая фишка, что это предложение от страховой действует в течение недели и мы можем еще попытаться что-то с этим делать. Мой attorney сказала, что она сможет на фоне увеличить эту сумму, потому что они неправы. В итоге через неделю она подняла выплату до 35000$ на которую мы уже согласились.

После подписания всех нужных док мне пришел чек, но это еще не конец. Оказывается я не могу его просто так обналичить, сначала нужно отправить его в компанию, которая предоставляет ипотеку (это не банк), так как у меня могут быть задолжности перед ними. Если все ок, они отправляют его обратно и вот теперь это мои деньги, которые я могу забрать.

Как вы думаете сколько я получил? В итоге из этих 35 000$ моих там было 16 000$. Вот такая вот история

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

Ссылки: Телеграм | Youtube | VK

Редакторы кода и инструменты для разработчиков — тема, вокруг которой строится целая индустрия. Когда-то переименование переменной казалось подвигом, а сегодня IDE умеют делать десятки сложнейших трансформаций так, чтобы программа оставалась корректной. В выпуске мы говорим с Дмитрием Ивановым, руководителем платформы Sourcecraft в Яндексе, о том, как развивались JetBrains и IntelliJ IDEA, почему в СССР писали компиляторы для Алгола-68, и чем отличается подход «IDE как комбайн» от современной архитектуры LSP.

Обсуждаем истории изнутри JetBrains, появление Kotlin как ответа на невозможность поддерживать Scala, и то, как AI-тулы и LLM-редакторы вроде Cursor меняют правила игры. Затрагиваем вечный спор Vim против IDE, сравниваем глубину анализа кода и ограничения протокола LSP, вспоминаем курьёзные случаи из практики и прогнозируем, что ждёт рынок инструментов разработки к 2026 году
https://youtube.com/watch?v=mIbtxa27K4E

Альтернативные ссылки: Аудио | vk

Полиморфизм и наследование

Каждый раз, когда я слышу от кого-то описание или определение полиморфизма, там присутствует слово "наследование".

> Объясните что такое полиморфизм? Ну это когда базовый класс и наследники...

Давайте по порядку. Полиморфизмов вообще существует больше чем один. Но, все таки, когда речь идет про массовое программирование (простите функциональщики), по умолчанию говорят о полиморфизме подтипов (subtyping). Упрощенно, в этом полиморфизме мы заменяем иф на общий метод для разных типов объекта. Таким образом сам объект (его тип) определяет реальное поведение, а вызывающий код про это не знает, он просто дергает метод (или методы):

function doSomething(logger) {
  // Где-то снаружи выбирается конкретный логгер
  // Разные логгеры могут работать сильно по разному
  logger.info('hey');
}

Что мы тут получили? Возможность менять поведение конфигурированием приложения (меняем реализацию объекта во время настройки), а не тем, что ходим по ифам где выбирается конкретная реализация и меняем там код.

Нужно ли для этого наследование? Вообще не нужно и вообще не подразумевается. Типами и подтипами во всех определениях являются интерфейсы или их аналоги, но не классы. Более того, в динамических языках у вас в принципе сами по себе классы могут быть никак не связаны, главное чтобы в них был реализован один и тот же полиморфный метод.

Кстати, для реализации полиморфизма подтипов классы тоже не нужны. Есть немало языков где он есть, но там нет ни классов ни ооп в привычном варианте.

p.s. Является ли перегрузка функций полиморфизмом?

Ссылки: Телеграм | Youtube | VK