Посмотрите на альтернативу Kafka

Мы очень любим Кафку и писали на эту тему несколько постов. Но не Кафкой единой. Всегда интересно посмотреть на альтернативы. И самая интересная сейчас — red panda.

А для, тех кто заинтересовался подробностями — сложная статья с множеством бенчмарков и описанием интересных проблем. Обязательно загляните в заключение, там автор делает некоторые выводы и сравнивает Redpanda с Kafka.

#skills

Значимость второстепенных навыков специалиста

Вопрос подписчика: получается, мне, как разработчику, стоит освоить фигму и научиться писать ТЗ? На месте бизнесмена, при прочих равных, на работу я бы взял разработчика, который умеет в фигму. Получается, что он владеет большим пулом инструментов, скорее всего, он эффективнее и быстрее разберётся с новым инструментом, плюс, если завтра помрёт ui-дизайнер, запряжём этого чувака наклепать что-нибудь съедобное.
----------

В вакууме так и есть, чем больше навыков у сотрудника, тем лучше. Но дальше начинаются нюансы. В стартапе или малом бизнесе, действительно, востребованы специалисты широкого профиля. Обычно владелец этого бизнеса и разработчик, и бухгалтер, и курьер, и макеты рисует. Но найм устроен несколько по-другому. У сотрудника есть должностные обязанности, и грузить его непрофильной работой не очень здорово. У человека падает мотивация, и результат выходит так себе. Более того, если перевести в деньги. Условный разработчик стоит 200к тугриков в месяц, а условный дизайнер 80к. Просто не эффективно использовать разработчика не по назначению.

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

Если вы только начинаете свой путь в профессии, то важно попробовать разные роли. Вдруг вы станете крутым дизайнером интерфейсов? Или у вас скрытая любовь к техническому писательству, и ТЗ станет для вас отдушиной? Чтобы найти своё место в мире, надо попробовать разные варианты. По хорошему, институт должен такую возможность предоставлять.

#devfm #edu

Футбольная аналитика: что поменялось за 2 года

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

Со своим решением по видеоаналитике автор дошёл из детских спортивных команд до профессионального спорта. Оказалось, что клубам нужно оцифровать каждого игрока, чтобы понимать его ценность, прогресс в тренировках, параметры (как в RPG) и возможности на поле. И на пути возник ряд интересных проблем. В статье высокоуровнево объясняется тракт работы комплекса, затем показываются проблемы реального мира, которые решены или предстоит решить. Ценность статьи именно в бизнесовом взгляде на проблемы. Есть такая беда, вот набор вариантов решения в совершенно разных плоскостях.

Интересно, что не удалось уйти от ручного допиливания статистики. Сказано, что на 5 минут игры приходится от 300 до 1500 спорных пересечений, которые оператор размечает от 3 до 10 секунд каждое. Итого выходит примерно полтора часа, если 1000 пересечений и 5 секунд на каждое.

Вообще Milfgard пишет о разном, наша подборка любопытных статей его авторства тут.

#edu

RESTful web API design

У Майкрософта есть годный гайд по проектированию RESTful веб-API. Там и фундаментальные вещи, и конкретные рекомендации:
— во главу угла ставить ресурс, а не действие. Не делать ручку create-order, вместо неё делать POST-запрос на orders/<id>. При этом подчёркивается, что внутреннее представление данных не должно просачиваться наружу. То есть за сущностью orders может быть несколько сущностей реальной базы данных

— стараться не усложнять ручку больше, чем двойная вложенность collection/item/collection, например, /customers/<id>/orders. При этом следует найти баланс. С одной стороны, запросы лучше экономить (много запросов = больше нагрузка на сервер и клиент), но при этом на каждый чих слать весь мир в ответе тоже не стоит

— приводятся типовые HTTP-методы. Нередко достаточно GET/POST/DELETE, можно добавить PUT и PATCH. К сожалению, часто семантика этих запросов понимается всеми по-разному. В этом гайде представлено довольно практичное описание. По каждому методу даны нюансы как по применению, так и по особенностям реализации в части возврата ошибок и асинхронным операциям. Важно не забывать про идемпотентность (пост о ней) некоторых методов

— не забыта постраничная навигация в запросе, HATEOAS и версионирование API

#systemdesign

Да, у нас есть тесты. А толку?

50-минутное закрытое видео про тесты с конференции PiterPy от Николая Хитрова. Начинается видео с лирики и мемов, а потом разгоняется и проходит по ключевым темам с кучей ссылок на полезные тулзы. Покрытые темы:

— Концепция AAA (Arrange-Act-Assert) и линтер flake8-aaa

— Переход к GWT (Given-When-Then) и интересный способ применения тест-классов для группировки пользовательских сценариев. Кстати, впервые я вижу понятное объяснение преимуществ GWT, потому что в большинстве источников ставят равенство между AAA и GWT

— Что должны проверять тесты и как dirty-equals вам может помочь. Тут же предлагаются библиотеки для декларативной проверки сложных структур

— Snapshot asserts для сложных данных с библиотеками syrupy и assertpy

— Фикстуры, их область применения и полезные инструменты вроде построения графа фикстур pytest-fixture-tools

— Инструменты для борьбы с нестабильными (flaky) тестами

— Инструменты для генерации данных в тестах, в том числе генерации тесты по контракту

— Обсуждение классической пирамиды тестов E2E, интеграционных и юнит-тестов

— Какие зависимости в тестах мокать, а какие запускать при тестах

— Плотно обсуждаются mock-и и stub-ы

— Тулзы для профилирования и ускорения тестов за счёт параллельного запуска или запуска только изменённого кода

#python #youtube

Пятничное развлекательное

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

В серии S13E03 Margaritaville стёбно описывается современное состояние инвестиций в мире. Годно подсвечена неадекватность рынка и финансовых институтов.

Посмотрите отрывок И... их нет (оригинал) про 100$, вложенных Стэном в банк. "Это очередь только для клиентов банка". А часть серии про определение стоимости актива в банке — это просто мем, пусть и жестковатый. Бедная курица.

Какая ваша любимая серия Южного парка?

#fun

Решил тут подтянуть базу и прочитать книгу по скрам от самого создателя этой методологии. Называется “Революционный метод управления проектами”, Джеф Сазерленд. Вроде много где используем скрам, но было интересно узнать, а как оно всё таки задумывалось? Чтожжжж. Пожалуй, книга будет иметь какую-то маломальскую пользу, если вы никогда не слышали о скрам методологии. В остальном абсолютно графоманское произведение.
Что хорошего читали по методологиям?

#edu

Redis меняет лицензию

Как-то мы пропустили новость момент, что redis очередной раз поменял лицензию (нужен VPN). Эта лицензия (RSALv2 и SSPLv1) делает редис, как говорит автор заметки, source available – звучит так себе. Основное ограничение – запрет на бесплатное использование redis для облачных сервисов, то есть борьба с SaaS от крупных компаний вроде Amazon.

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

Поэтому есть повод посмотреть на достойные форки редиса, которые стали уже ничуть не хуже. Об одном из них писали ранее – KeyDB, второй достойный вариант – DragonflyDB.

#tools

Вот так да! Любопытно будет посмотреть.

Backdoor длиною в два года

Для тех кто пропустил детективную новость – бекдор в пакете архиватора XZ Utils, который повсеместно используется в Linux. Уязвимость предоставляет возможность выполнить произвольный код по SSH, не оставляя следов в логах sshd.

Всё началось в октябре 2021, когда некто под ником JiaT75 начал активно участвовать в развитии XZ, делать пул реквесты. Разумеется, мейнтенером проекта он не был. Через некоторое время появилось ещё два персонажа Jigar Kumar и Dennis Ens, которые также начали контрибьютить в проект. Через какое-то время в переписках они начали аккуратно давить на мейнтейнера проекта, что как будто он не справляется с нагрузкой, не успевает вовремя ревьюить пулл реквесты и что хорошо бы сделать JiaT75 ещё одним мейнтейнером. Так оно и случилось, JiaT75 стал мейнтейнером проекта XZ, а через некоторое время внедрил в него бекдор.

Вот что значит играть вдолгую :) Причём после релиза библиотеки с бекдором злоумышленники с левых аккаунтов стали писать меинтейнерам программ и дистрибутивов, мол, обновляйтесь.

Вскрылось всё это случайно. Один ну очень внимательный разработчик заметил, что XZ стало поджирать больше cpu, чем обычно. Он начал разбираться и обнаружил вредоносный код.

Такая невероятная история. Обязательно почитайте. Страшно представить, сколько подобных бекдоров мы ещё не знаем…

Больше деталей на opennet, в том числе разбор логики бекдора. Интересные детали ещё в канале Авва.

#security

The ultimate docker compose cheat sheet

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

Из интересного:
– параметр, позволяющий рестартить сервис, если он завалился
– как одному сервису дождаться запуска другого сервиса с использованием определенных условий. Бывает полезно, когда веб-сервис дожидается старта базы данных
– как задавать healthcheck сервисов с различными параметрами
– также автор разжёвывает тему volumes и networks

У нас был отдельный пост с практическими советами по докеру.

#skills #docker

Ну это просто прекраснейшая аналогия, теперь всем буду так объяснять

Прекрасное из недавнего диалога:

— Наша архитектура — микросервисный монолит!

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

Зеркало Dockerhub

Сейчас пользователь из РФ при использовании докерхаба получает такое сообщение

403 Forbidden
Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria.

Это либо техническая ошибка, либо РФ добавят в список стран.

Самая простая инструкция по настройке прокси тут
https://huecker.io/

Нюанс в том, что прокси надо доверять. В противном случае вы можете получить совсем не тот образ, что планируете. Адекватно использовать крупную площадку вроде зеркала Гугла
https://mirror.gcr.io

#tools

Пятничное развлекательное

Нестареющая классика. Так и живем. Лишние телодвижения ни к чему😃

#fun

Настраиваем терминал "под себя"

В нашем бесплатном курсе cli-for-dev на степике вышло новое занятие. Переменные окружения, конфиги, дикие алиасы. Практика с настоящим терминатором! Удобный Ctrl+R и тонны хоткеев, всё как вы любите.

У нас 950 учащихся, 180 дошли до пятого занятия и оставили 30 отзывов. Теперь доступно шестое занятие. Будем рады вашим отзывам на степике.

#devfm #skills

Оценка сроков проекта для тимлида

Как узнать у разработчика сроки решения задачи? Ну, никак. Он вам будет врать.

Если вы всё ещё хотите узнать сроки, то придется попотеть:
1. Спрашиваете сроки. Вам говорят некую величину R.
2. Если R <= 16 рабочих часов, то реальное время выполнения проекта составит примерно R умножить на π, то есть ~3,14R. Почему умножаем на Пи? Во-первых, это красиво. Во-вторых, тройного запаса обычно хватает.
3. Если R > 16 часов, то задача слишком большая и разработчик дал рандомный срок. В этом случае срок можно рассчитать как R×π + 2 недели. Почему умножаем на Пи? Потому что это красиво. Почему добавляем 2 недели? Потому что за 2 недели можно сделать что угодно...

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

Ответ на пост Трудоемкость != сроки

#edu #teamwork

Подкаст DevFM: Кто такой тимлид тимлидов (yandex / youtube / podster)

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

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

Что изменилось на новой должности? Нюансы потери детализации над проектом. Нужны ли KPI?

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

Наш первый подкаст

#devfm #podcast #teamwork

Dozer

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

Давно пользуюсь такой простой утилиткой, как Dozer. Очень удобно, очень нативно можно скрыть все, что вам мешает.

#tools

Книга "Getting Real"

Долго откладывал эту книжку, а потом каааак прочел на одном дыхании.

Книга описывает философию и подходы к разработке и управлению проектами.

Основные идеи книги включают:
– Простота: Сосредоточьтесь на том, что действительно важно, и избегайте усложнения проекта ненужными функциями.
– Гибкость: Будьте готовы к изменениям и адаптации на ходу.
– Реализация идей: Начинайте с реализации основных функций и постоянно совершенствуйте продукт на основе обратной связи от пользователей.
– Минимализм: Создавайте минимально жизнеспособный продукт (MVP), чтобы быстрее получить обратную связь и внести необходимые улучшения.

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

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

#edu #books

Книга "Релевантный поиск"

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

И вот что он рассказал о книге:
Книга знакомит с понятиями релевантности, текстового анализа, ранжирования. Подробно рассказывает о разных хитрых особенностях.

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

Отдельно рассказали как эксплейнить запросы и какие механизмы есть под капотом, которые оценивают релевантность в соответствии с введенным запросом.

Дабы закрепить материал, в конце показывают вымышленное приложение и как авторы собирали поиск, учитывая желания и клиентов, и бизнеса, и геолокации.

Для нашего нового проекта книга оказалось полезной, удалось пересмотреть анализаторы и выкинуть в помойку лишнее.

#skills #books