Мы с Саматом раньше лично не были знакомы, но всегда крутились в одной технической тусовке. Я давно хотел записать с ним выпуск, потому что мне интересен путь, который он прошёл — как технарь превращается в предпринимателя. Я регулярно делаю подкасты на эту тему, и нам было важно разобрать его историю: он пришёл к бизнесу через запуск собственного аутсорса, а не через стартапы. В этом разговоре мы обсудили, как из разработчика вырастаешь в владельца сервиса, переход от аутсорса к продуктам, изменения на рынке и почему продажи часто важнее кода. Мы говорили о найме и проверке разработчиков, об испытательном сроке как фильтре, а также о скучных, но прибыльных нишах, автоматизации рутины и подводных камнях работы с клиентами.
https://youtube.com/watch?v=T7WsVGtKZJw

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

ИИ для проверки качества уроков на Code Basics

Какое-то время назад на проекте https://code-basics.com/ru я внедрил ассистента на базе chatgpt, который помогает в каждом уроке. Причем он знает весь контекст включая задание, тесты к нему, код студента и вывод тестов после запуска. Им начали пользоваться так активно, что пришлось включить дневные лимиты, так как стали приходить нехилые счета на, по сути, бесплатном продукте.

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

А что если написать код, который будет брать вопросы пользователей каждого конкретного урока и отправлять их туда же в chatgpt с инструкцией "суммируй и предложи улучшения по уроку"? Сказано сделано, вчера буквально за пол дня зафигачил эту фичу (ее можно глянуть в исходниках). И теперь по каждому я вижу примерно такой вывод:

Семантические и логические ошибки

⁃ Не понимают, что означает пустая строка — что именно считать пустым ("" или " ").
⁃ Отсутствует понимание, что возвращать: что значит "true", "false" (пытаются явно конвертировать int к bool, чего делать нельзя).
⁃ Не разобрались с проверкой условий: >=0, >0, != "" и т.д.
⁃ Запутались с тем, является ли 0 положительным числом (спрашивают об этом).

Ну не красота ли?

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

Сложность обучающих материалов

Продолжаем тему "я у мамы методист". Когда мы пишем что-то для других людей, то один из первых вопросов, который всплывает в голове, а на какую аудиторию мы рассчитываем с точки знания предмета? Допустим мы делаем курс по реакту. Надо ли нам делать его для тех кто не знает js (не знает программирование вообще или знаком с другим языком)? А если знает то насколько? Человек уже работал с браузером и понимает как устроен DOM или ему в целом надо рассказывать основы про браузер, про события и все остальное?

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

Допустим для конкретного человека сложность вашего курса оказалась ниже чем он рассчитывал, то есть с его точки зрения этот курс для более новичкового уровня, чем его собственный. Как он будет воспринимать происходящее? В подавляющем большинстве случаев он будет проходить его дальше, если он верит в то, что дальше таки будет нужный ему материал. Если нет, то худшее что вы можете получить это реакция: "слишком поверхностно". Прямо негатив что курс полное говно в таких кейсах почти никогда не встречается.

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

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

Это не значит что не бывает курсов для профи. Бывает, но все упирается в то, как вы собираете аудиторию и что пишите в описании к курсу. Крайне важно правильно проработать ожидания, например, говорить о том, какой входной уровень ожидается. Отлично если в этом месте будут возникать входные тесты.

Пример. Школы часто пишут "курс: go с нуля" имея ввиду что с нуля в Go, но не с нуля в программировании. И на выходе мы получаем немало людей, которые в шоке от сложности контента.

p.s. Нам кстати нужны авторы курсов по программированию, тестированию, аналитике и администрированию. Пишите в комментариях если вам интересно.

https://making.hexlet.io/

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

Тот случай, когда фичи ruby позволяют создать сложный для восприятия код (if после выражения и ||=). Здесь идет попытка добавить логику, которая избегает запроса в базу если id не передан

Как бы вы переписали его? Пулреквест вот: https://github.com/hexlet-basics/hexlet-basics/pull/605 он еще не принят

Сегодня вышел выпуск подкаста Кодакода с моим участием. Мы поговорили про A-players. Сразу уточню: это не про джунов и синьоров и даже не про «10х инженеров». A-players — это отдельная тема, связанная с тем, как люди влияют на результат команды и задают её динамику.

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

И напоследок поговорили о личном: можно ли самому стать A-игроком и реально ли со временем «сойти» с этого уровня.
https://kodakoda.mave.digital/ep-89

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

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

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

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

Я тратил на это довольно много времени постоянно проводя доп обучение, создавая базы знаний и даже выпуская статьи на тот же 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('http://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. Поставьте палец вверх если интересно такое слушать, если нет - то палец вниз. Не хочу загружать канал личным, но вдруг иногда стоит делиться майамскими вайбами.