Почему надо знать про супервизоры

По мотивам собеса. Значит ситуация, человек запускает постгрю в докере, но контейнер не стартует потому что порт 5432 уже занят. Дальше начинается отладка, которая с большой вероятностью будет не очень успешной, если разработчик не знаком с тем как функционируют операционки. И так, поехали в разбор.

Почему порт занят, что это значит? Значит что на этом порту уже запущена какая-то программа. Почти наверняка это постгрес, который был установлен прямо в систему.

Первым делом стоит проверить, а не запущен ли уже контейнер с базой, возможно для другого проекта: docker ps. Если в выводе есть: 0.0.0.0:5432->5432/tcp, то отладка прошла, можно стопать и запускать нужный конейтенер. А если нет?

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

lsof -i :5432

NAME
localhost:postgresql->localhost:60378 (FIN_WAIT_2)
localhost:60378->localhost:postgresql (CLOSE_WAIT)

Для простоты я оставил здесь только NAME, но сам вывод показывает и команду и пид и пользователя. В общем достаточно информативно.

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

sudo kill -9 <pid>

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

Вот тут остановитесь и подумайте. А что собственно говоря происходит?

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

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

Локально все работает точно так же, даже если вы этого явно не видите. Постгрес стартует в вашей системе не сам по себе, его запускает супервизор и управлять им нужно через супервизор. В Ubuntu это systemd, в MacOS launchd. В каждой из этих систем предоставляется высокоуровневый интерфейс для работы. Вот как это выглядит для тех кто использует brew:

brew install postgresql@14
brew services start postgresql@14

brew services list

Name          Status   User File
postgresql@14 started  kirill ~/Library/LaunchAgents/homebrew.mxcl.postgresql@14.plist
php           none
caddy         none

brew services stop postgresql@14

Плюс минус тоже самое во всех остальных операционках.

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

В этом выпуске мы поговорили с Владимиром Алиповым — нейробиологом и популяризатором науки, о том, действительно ли «математический склад ума» врождён, как работают IQ-тесты и почему поменять профессию в 40 лет — реальный шанс, а не приговор. Обсудили роль интереса против генетики, разобрали мифы о способностях программистов и поделились приёмами сохранения «свежего» мозга.

А так же:

- Как «g-фактор» помогает в любой умной работе, а не только в высшей математике.
- Почему интерес к алгоритмам важнее любви к формулам, если мечтаете о коде.
- Что общего у хоккеистов и айтишников, и при чём тут месяц рождения.
- Как правильно читать результаты IQ-тестов, чтобы не сломать мотивацию.
- Какие привычки сохраняют мозг острым после сорока и кто такие супер-эйджеры.

https://youtube.com/watch?v=_tj5way-6hQ

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

Инкапсуляция не работает

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

Только если в теории. На практике поменять почти все что угодно не составляет никакого труда. Предположим что у нас есть пользователь и у него должна быть установлена хотя бы одна роль и это проверяется где-то внутри пользователя (тут не показано) при изменении списка ролей.

class User {
    private final List<Role> roles = new ArrayList<>();

    public List<Role> getRoles() {
        return roles;
    }
}

Но нам никто не машет сделать так:

user.getRoles().clear(); // теперь ролей нет
// Можно добавить дубль
user.getRoles().add(new Role("admin"));
user.getRoles().add(new Role("admin"));

Даже если геттеров нет, рефлексия пробивает любую «защиту»:

var field = User.class.getDeclaredField("roles");
field.setAccessible(true);
@SuppressWarnings("unchecked")
var roles = (List<Role>) field.get(user);
roles.clear();

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

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

p.s. Какие еще способы вы знаете как обойти private?

Программисты не верят в инструкции

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

Напоминание: мой собес это берем продакшен проект (опенсорсный), в котором классические rails. Человек его разворачивает на свой машине и делает несколько простых фиксов. Только вот до фич доходят единицы, в основном мы зависаем на сетапе. И вот почему. Ниже пара примеров.

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

В другом случае человек увидел Dockerfile и даже не заглянув в README.md проекта начал его собирать. А в этом проекте запуск в деве идет не через него. Кстати, проект так и не запустился.

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

Ну и последний пример. Видят домен .localhost и все равно идут добавлять его в hosts, хотя в инструкции нет такой установки (потому что и так работает)

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

Без проблем все проходило только у тех, кто просто выполнял команды по очереди как они даны в README.md.

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

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

Одна мысль - один абзац

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

Иногда меня подмывает поделиться чем-то таким. Было даже дело, я вел курс школа авторов по тому, как создавать обучающие материалы технической направленности. Хотя говорят что он полезен всем кто этим интересуется. Вот тут есть ссылка: https://making.hexlet.io/

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

> Срезы — основной способ работы с коллекциями в Go. Чтобы обрабатывать такие структуры, чаще всего используются циклы. Go предлагает два подхода: классический цикл с индексом и удобный range, каждый из которых подходит под разные задачи.

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

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

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

p.s. Ребят, если вам интересно про все это, поставьте лайк, если нет - дизлайк

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

Легаси != говнокод

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

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

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

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

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

Давайте об этом поговорим немного (или много). Как вы определяете говнокод? И допустимо ли так делать?

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

Долгожданный выпуск про DDD. Местами даже получились дебаты :) Смотрим, слушаем, наслаждаемся!
https://www.youtube.com/watch?v=03FnrgYLkV8

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

Наткнулся на твит, где человек пишет: "вам не нужен ORM, если вы знаете SQL" — и прикладывает вот такой пример:

SELECT u.*, COUNT(c.id) as comment_count
FROM users u
LEFT JOIN comments c ON c.user_id = u.id
WHERE u.active = 1 AND c.created_at > NOW() - INTERVAL 30 DAY
GROUP BY u.id
HAVING comment_count > 5;

И его версию в Laravel:

User::select('users.*', DB::raw('COUNT(comments.id) as comment_count'))
    ->leftJoin('comments', 'comments.user_id', '=', 'users.id')
    ->where('users.active', 1)
    ->where('comments.created_at', '>', DB::raw('NOW() - INTERVAL 30 DAY'))
    ->groupBy('users.id')
    ->having('comment_count', '>', 5)
    ->get();

Я абсолютно согласен, что знать SQL для бекендера важно и нужно, но этим все не ограничивается, а еще:

- То что здесь описывается это не ORM, а Query Builder
- Конкретно тут показан Query Builder Laravel, который нельзя назвать эталоном среди QB
- Запросы с группировкой составляют доли процента от обычных запросах в типовых веб-проектах (Аналитические запросы не считаем их вообще делают во внешних системах)
- Сам запрос это еще полдела, в статически типизированных языках еще придется фигачить маппинг если не пользоваться никакими либами
- Чистый SQL это полное отсутствие типобезопасности
- В такой запрос невозможно нормально вставить условные конструкции, например если понадобится фильтрация. Мы сразу попадем либо в склеивание строк, либо в необходимость затаскивать Query Builder

А на картинке к посту пример на drizzle-orm, в котором обеспечивается 100% типобезопасность: проверка всех условий (включая возможность выполнить join), всех операций, всех имен (таблиц и полей). Естественно автокомплит и рефакторинг в наличии.

Естественно это отдельный язык (хотя и крайне близкий к sql), но в современном мире ИИ, подобные запросы могут генериться без проблем, особенно в drizzle-orm, с его описанием схемы.

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

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

Программирование на флагах

Недавно я упомянул этот термин в одном и постов и получил неожиданно большое количество комментариев "что это?". Тема заслуживает раскрытия, поэтому пост.

Возьмем пример с sql:

SELECT *
FROM users
WHERE active = 1;

Почти наверняка это поле из двух состояний активен/не активен (1/0), где активность определяется подтверждением емейла. В Postgresql это было бы true/false.

В целом, этот код выглядит совершенно нормально и очень хорошо работает. До поры до времени. А потом выясняется, что «неактивный» бывает как «удалённый», так и «заблокированный». Или, например, мы (бизнес) захотим давать работать на сайте тем кто зарегистрировался, но не подтвердил емейл. Подтверждение емейла будет работать как способ получить больше функций. В сумме мы получаем:

⁃ зарегистрированный
⁃ активный (подтвержден емейл)
⁃ удаленный
⁃ забаненный

Поскольку в базе уже есть active, то разарботчик, вероятно, пойдет по наиболее легкому пути - начнет добавлять новые флаги. Это просто и не требует хитрых миграций, чтобы обеспечивать обратную совместимость (для zero downtime). В итоге в базе появятся флаги:

active, email_convirmed, banned, deleted

и с этого момента начинается то самое программирование на флагах.

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

⁃ Комбинаторный взрыв состояний - пользователь может быть active = true, но при этом banned = true и deleted = true. Что это значит? Он активен или нет?
⁃ Неявные правила - чтобы понять, что такое «активный пользователь», нужно лезть в код и смотреть, как именно проверяются флаги (active && !deleted && !banned && email_confirmed)
⁃ Сложность изменений - добавление нового флага или изменение бизнес-логики требует правок во множестве мест, потому что условия размазаны по коду и SQL-запросам.
⁃ Повышенный риск багов - достаточно забыть один флаг в проверке и все, приплыли.

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

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

Мы кстати с этого и начали, когда перечисляли возможные состояния пользователя.

type UserState = 'active' | 'banned' | 'deleted' | 'waiting_email_confirmation'

Фактически такой подход гораздо лучше ложится на то, как мы думаем об этом, чем флаги. Более того, это и намного нагляднее с точки зрения кода. Таким образом мы сразу решаем проблему синхронизации, переход из одного состояния в другое это одно действие и отсутствие багов в стиле "флаги не согласованы"

Есть еще один немаловажный плюс. Допустим у нас изначально два состояния и мы решили, что не будем бежать впереди паровоза. Мы делаем в базе boolean и попадаем в ситуацию, что когда добавится третье состояние, придется менять тип колонки на строку и все значения внутри него. Опытные разработчики сразу будут этому сопротивляться, потому что ломать обратную совместимость в базе нельзя, поэтому правильным способом, будет создать новую колонку и выполнить миграцию туда. Оно нам надо? То есть использования состояния это безопасно и расширяемо в отличие от флагов.

Но даже этого может быть недостаточно. Следующим шагом будет использование конечных автоматов https://github.com/eram/typescript-fsm (в том случае если нужна реакция на переходы, а сама структура переходов не линейная)

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

Мы с Саматом раньше лично не были знакомы, но всегда крутились в одной технической тусовке. Я давно хотел записать с ним выпуск, потому что мне интересен путь, который он прошёл — как технарь превращается в предпринимателя. Я регулярно делаю подкасты на эту тему, и нам было важно разобрать его историю: он пришёл к бизнесу через запуск собственного аутсорса, а не через стартапы. В этом разговоре мы обсудили, как из разработчика вырастаешь в владельца сервиса, переход от аутсорса к продуктам, изменения на рынке и почему продажи часто важнее кода. Мы говорили о найме и проверке разработчиков, об испытательном сроке как фильтре, а также о скучных, но прибыльных нишах, автоматизации рутины и подводных камнях работы с клиентами.
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