Задача: выбрать способ передачи сообщений в API для сервисной архитектуры

Обычно выбор делается из двух решений:
- REST
- gRPC

это сильное упрощение, потому что REST - это архитектурный стиль, а gRPC - это фреймворк. Но если рассмотреть gRPC как некий стиль, то можно выделить моменты по которым делается выбор:

- использование HTTP/2
- обмен бинарными данными (+ сжатие данных, позволяющее увеличить скорость обмена данными)
- кодогенерация
- RPC ориентированность (в том числе stream-based)

Со стороны REST кроме требований самой архитектуры обычно выделяют:
- простота
- текстовый формат обмена (удобство)

Таким образом gRPC отлично подходит для организации взаимодействия внутри сервисной (микросервисной) архитектуры, а для внешних API хорошо подходит REST стиль.

Важно отметить, что gRPC немного "тяжелее" во внедрении и сопровождении, но унифицирован, так как фреймворк. А вот REST - это всегда какая-то своя реализация, которая может сильно меняться между проектами.

SOER | PRO | Boosty

Набор в NarisApp

Всех кто хочет принять участие в разработке проекта NarisApp приглашаю принять участие.

Если коротко:
- участие бесплатное
- делаем платформу обучения и развития
- в этом наборе решаем два эпика: "интеграция с бусти" и "интеграция с телеграм"
- как принять участие написано в конце статьи (см. ссылку выше)

Подробное описание смотри по ссылке выше.

Запись техтока про валютную удаленку. Поговорили про:
- какой английский язык должен быть
- как выводить деньги
- как оформлять и где искать валютную удаленку

Дублирую на boosty архив стримов с soer.pro сегодня перенес Проектирование API

SOER | PRO | Boosty

Опубликовал статью Как определить какая доля багов/ошибок допустима и является следствием сложности программного кода?

Несколько основных мыслей (полный текст см. в статье):

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

- Основная проблема заключается в создании нездорового климата внутри коллектива, что приводит к увеличению цены ошибки и замедлению работы;

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

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

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

SOER | PRO | Boosty

Часы идут - программист работает

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

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

Но бизнес всегда хочет контроллировать работу айтишников. Это аксиома. Если вам говорят обратное - вам врут.

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

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

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

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

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

И это печально.

Эксперты соер.клуба

Я сделал специальную группу куда буду публиковать ссылки на телеграм каналы ребят, которые входят в соер.клуб. Это реально очень крутые девушки и парни, профессионалы своего дела.

По мере вступления новых людей в число экспертов буду группу пополнять.