Задача: выбрать способ передачи сообщений в 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

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

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

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

Опубликовал Техток про пассивный заработок

SOER | PRO | Boosty

Что если вы эффективнее других членов команды?

Вчера на стриме очень много возникло споров вокруг "работать 4 часа и скрывать это от руководителя"

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

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

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

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

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

- Если руководитель не согласен с вашей оценкой труда?
Ответ: обсудить и понять есть ли реальные предпосылки для вашей оценки.

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

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

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

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

SOER | PRO | Boosty