Зарубежные блогеры тоже по чуть-чуть подтягиваются и начинают освещать FastStream

Arjan включил FS в список "неизветные либы, которые вам стоит знать": https://youtu.be/F09EK4ztG34?si=zMi-wiKQhV9e_DET
Обидно, что не осветили вообще никакие фичи фреймворка. Кажется, он сам не особо вчитывался даже в README. Возможно, стоит пересмотреть README, чтобы подсвечивать все важное с первых строк.

А вот у Eduardo более вдумчивый подход – https://www.youtube.com/watch?v=_78VJCs-8DQ

Чувак пилит полноценные двухчасовые стримы, изучает все фичи, готовит примеры кода, делает слайды, разбавляет это своими примерыми и доп материалам, объясняет почему это важно и круто. Кажется, он даже в истрию "двух библиотек" залез. Но я все равно ничего не понял, т.к. стрим на португальском и перевести у меня не получилось😢 Но формат у него крутой

В общем, медленно, но верно растем. Глядишь, скоро 5к звезд наберем

Полный гайд по OpenSource на GitHub

Стартануть свой OSS может быть очень сложно. Не ясно, с чего начать, как он вообще должен выглядеть, как его продвигать. Тут очень помогает насмотренность – ходишь по крупным GitHub репозиториям и делаешь "как у них". Но я избавил вас от такой необходимости и подготовил чек-лист оформления репозитория для старта вашего проекта на GH😎

Основная цель всего этого оформления – сделать репозиторий максимально привлекательным для мимопроходящих людей (чтобы конвертить их в пользователей) и максимально гостеприимным для контрибуторов. Чем раньше вы позаботитесь о своем инструментарии - тем вероятнее в ваш проект будут коммитить другие люди.

1️⃣ README.md - папа и мама вашего проекта. Он должен быть даже раньше кода. Именно по нему юзеры принимают решение – юзать или не юзать. Там обязательно должны быть следующие секции:
– основная идея проекта. 1-3 предложения. Ильяхов в помощь
– основные фичи буллет-поинтами
– как проект установить
– базовый пример использования (код / скрины / что угодно в зависимости от проекта)
– как запускать
– подсветить другие важные фичи
– из прикольного можно добавить аватарки всех контрибуторов, людям будет приятно увидеть себя в списке (пример из репы FS)

2️⃣ Заполнить раздел "Описание" вашего проекта (правый верхний угол репозитория) - именно это описание будет отображаться на превью карточки репозитория по ссылке. Важно для SEO.

3️⃣ Правильно выбрать топики. Делается там же, где и описание. По таким топикам я нашел много OSS проектов – еще один бесплатный канал SEO для вас

4️⃣ LICENSE - ОБЯЗАТЕЛЬНО. Без лицензии ваш проект не более чем игрушка. Никто не будет рассматривать его использование на продакшене. Можете посмотреть шаблоны тут и сравнить их тут. Если у вас нет никаких особых планов - просто воткните MIT. Ну или пивную лицензию (хотя бы полезно)

5️⃣ лейблы (badges / shields) в README - это тоже очень важно. Эти лейблы быстро распознаются юзером и помогают понять, в каком состоянии проект. Почти все можно оформить тут. Там обязательно должно быть:
– последняя версия библиотеки, которую можно скачать (pypi / npm / etc)
– code test coverage - это оч важная цифра для нового проекта. Наличие coverage 95% показывает пользователям, что хотя у вас и не много звезд / скачиваний, вы все равно думаете о качестве. Это дает им какую-то уверенность, что ваш проект можно взять и не обжечься
– количество установок (в день / неделю / месяц) - можно добавить чуть позже, когда будет что показать. Но это тоже отличный способ показать "смотри, нас уже кто-то юзает. Ты тоже можешь".
– поддерживаемые версии языка (python в моем случае). Чтобы юзеры понимали сразу, подходит ли им проект. Или мб он уже устарел на 5 версий от хедлайн и проект скорее мертв, чем жив
– лицензия проекта
– другие пайплайны по вкусу - Sonar, Code Quality, Dependency Review и тд

6️⃣ ДОКУМЕНТАЦИЯ - без этого даже нет смысла запускаться. Сайтик на пару страниц делается на mkdocs с хостингом на GitHub Pages за вечер. Но он нужен. Причем сразу. Посадочной страницей имеет смысл продублировать README репозитория

7️⃣ examples/ примеры кода - пока проект маленький оч удобно держать такую мини-доку прям в коде. Люди смогут дергать куски кода для понимания работы каждой фичи. Они точно это оценят

8️⃣ Настроить CI - форматеры, линтеры, автоматический запуск тестов... OpenSource - это про качество и про контрибуторов. Без CI не будет ни того, ни другого
– также очень важно добавить запуск тестов по крону (раз в сутки / неделю), чтобы отлавливать несовместимости с релизом новых версий ваших зависимостей

9️⃣ CONTRIBUTING - небольшой (или огромный) гайд о том, как запустить ваш проект локально, вносить изменения, запускать линтеры, тесты и тд. Без этого людям тяжело приносить PR'ы. А вам нужна их помощь

Дополнительные советы закину в комменты. Обязательно отпишите свои рекомендации по оформлению репозитория и делитесь полезными ссылками для этого! Я сам постоянно ищу что-то прикольное, мб возьму и ваши советы на заметку🌚

Рабочая неделя заканчивается, а кому-то даже пора в отпуск🌚

Вестей от меня не ждите до 23го минимум, я буду далеко на природе обниматься с медведями. Ну, разве что где-нибудь сеть поймает😅

А пока оставлю вам прикольное занятие на выходные – позаниматься коучинговыми практиками. В принципе, чем я и сам планирую заняться на природе. Да, я знаю, что нарываюсь на клоунов😅 Но как вы поняли, я фанат темы про эффективность, самомотивацию и личное развитие. Поэтому в последнее время подзалип на канал вот этой дамы:

https://youtu.be/uRg8CiXABWs?si=StuNwPb3dZNqU1j9

Там не без треша, конечно (тема с эзотерикой мне вообще не близка), но в остальном мне нравятся ее идеи и советы.

Например, из видоса выше мне оч понравилось упражнение – расписать всю свою прошедшую жизнь отрезками по 7 лет. 0-7, 7-14, 14-21, 21-28 и тд. Что ты сделал за это время, что с тобой произошло важного, чего достиг, чем сам гордишься. Сначала я не понял, в чем прикол, но решил попробовать. А потом как понял🤯

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

Поэтому теперь я смотрю на следующий отрезок 28-35 не со страхом, а с уверенностью – впереди меня ждет еще одна "целая жизнь" и планы на нее можно строить грандиозные. Я же знаю теперь, сколько всего можно успеть😅 А еще я вижу "тренд", что помогало и мешало мне все эти годы.

На выходных обязательно потратьте 10 минут – очень интересно узнать себя таким вот способом)

Как не пилить фичи, которые никому не нужны? Модель Кано в разработке.

Вот и отпуск прошел, пора возвращаться к работе...

Сейчас я работаю над AG2 и пытаюсь make this project great again. В общем, составляем родмап для фич.

И в этом мне сильно помогает модель Кано, которую я изначально подсмотрел у Дорофеева. Максим в своей книге адаптировал 5 категорий "фич" под продуктивность. Но это только подтверждает состоятельность методолгии – ведь ее можно применять к любой области!

Итак, 5 категорий фич (задач) по Дорофееву (Кано):

🤩 1. Ублажители (Delighters)
Это те самые "вау-фичи". Их никто не ждет, но их минимальное наличие вызывает восторг.

- Пример: AI-ассистент в документации, который отвечает на вопросы. Или забавная анимация загрузки. FastStream, который сам генерирует документацию для сервиса.
- Суть: Пользователь не расстроится, если их нет (он их может даже не ожидать), но будет в восторге, если они есть. Хотя, может быть и сильным конкурентным преимуществом.

✅ 2. "Должно быть" (Must-be)
Это базовые, ожидаемые вещи. Если они работают хорошо, этого никто не замечает. Но если они сломаны — удовлетворенность пользователя падает до нуля.

- Пример: Кнопка "Сохранить" действительно сохраняет. pip install вашего пакета работает без ошибок. API отдает валидный JSON.
- Суть: Их наличие не радует, но их отсутствие или плохая работа — это катастрофа. Это фундамент, на котором все строится.

🚀 3. "Больше — лучше" (Performance)
Здесь все просто: чем лучше реализация, тем выше удовлетворенность.

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

🤷‍♂️ 4. Нейтральные (Indifferent)
Пользователям на них все равно. Вы можете потратить недели на их реализацию, но никто этого не оценит.

- Пример: 15-й способ кастомизации цвета кнопки в настройках, которым воспользуются 0.01% пользователей.
- Суть: Чистая трата ресурсов. Главная задача - научиться распознавать их до начала разработки.

🤬 5. Реверсивные (Reverse)
Фичи, наличие которых ухудшает пользовательский опыт. Да, и такое бывает.

- Пример: Обязательная регистрация для того, чтобы воспользоваться простейшей утилитой. Слишком сложный и запутанный UI там, где все могло быть просто.
- Суть: Это выстрел себе в ногу. Такие фичи не просто не приносят пользы — они вредят.

Как это применить на практике?

Эта модель — мощный инструмент для приоритизации и принятия решений. Прежде чем бросаться кодить очередную гениальную идею, спросите себя:

- Это "ублажитель", который можно сделать потом, или "должно быть", без которого все развалится?
- Мы сейчас улучшаем метрику "больше — лучше" или пилим "нейтральную" фичу, которая никому не нужна?
- А не создаем ли мы "реверсивную" фичу, которая только усложнит жизнь пользователю?

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

А теперь вопрос в зал: какая самая бесполезная или даже "реверсивная" фича, которую вам приходилось делать?🌚

#программирование #продуктивность #карьера #дорофеев

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

А еще - там есть ранкинг LLM тулов (IDE плагины, CLI утилиты, библиотеки и тд)🤯 А вот это уже прикольнее, т.к. там можно подсмотреть какие-нибудь прикольные тулы, о которых ты не знал.

Например, я увидел, что можно попробовать юзать Kilocode вместо Continue в качестве AI плагина для VSCode🚀 (continue безбожно лагает по моему опыту)

Как работает MCP

MCP - это очень простой протокол, который изменил мир. По сути, MCP - это RPC (Remote Procedure Call) для LLM, где "процедурами" выступают поставщики контекста. Весь обмен построен на стандартизированных JSON-сообщениях. ЭТО ПРОСТО HTTP РУЧКИ С ОПРЕДЕЛЕННЫМ ПОРЯДКОМ ВЫЗОВА

В протокол MCP вовлечены 3 действующих лица:

- MCP Server - HTTP (и не только) приложение, которое поддерживает обращения по протоколу MCP. Например, в IDE включены некоторые MCP-тулы по работе с файловой системой / историей коммитов / etc. Но вы можете поднять любые удаленные MCP серверы и просто указать их для работы.
- MCP Client - приложение, которое хочет работать с MCP сервером. Например, IDE-ассистент, CLI-утилита, или даже ChatGPT (ему тоже можно дать доступ к MCP)
- LLM провайдер - это "голова" вашего MCP клиента. Туда клиент передает вопросы и получает ответы (или команды на запуск MCP)

Основной флоу: Знакомство, Запрос, Ответ

Представим, что вы подключили к Chat GPT MCP сервер для арифметики. И задаете ему вопрос: "Сколько будет 2 + 2 * 2?" (я пропущу пару шагов, чтобы не усложнять)

Шаг 1: Tool Discovery (Знакомство)

Как только вы начинаете диалог, MCP Client (Chat GPT) опрашивает MCP Server'ы, чтобы узнать, что те вообще умеют. MCP Server отвечает сообщением типа ContextProvider.

Это как если бы сервер сказал клиенту: "Привет, я сервер. Вот мой Swagger / OpenAPI. Ты можешь вызывать вот такие эндпоинты".

// Сообщение от MCP Server -> MCP Client
{
  "jsonrpc": "2.0",
  "result": {
    "tools": [{
        "name": "calculator_arithmetic",
        "title": "Calculator",
        "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",
        "inputSchema": {
          "type": "object",
          "properties": {
            "expression": {
              "type": "string",
              "description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"
            }
          },
          "required": ["expression"]
        }
      },
  ]}
}

Что здесь происходит:

* name: calculator_arithmetic — уникальное имя операции.
* title + description: Человекопонятное описание, чтобы LLM поняла, что эта штука делает и когда ее стоит вызывать.
* inputSchema: А вот и "сигнатуры функций". Это, по сути, JSON Schema, описывающая, какие параметры принимают методы этого сервера.

Теперь LLM Client отправит это сообщение вместе с вашим вопросом прямо в GPT. И GPT уже знает, что он может вызвать операцию calculator_arithmetic, если понадобится что-то посчитать.

Шаг 2: Request (Запрос контекста)

Агент анализирует ваш вопрос и решает, что для ответа ему нужно вызвать операцию calculator_arithmetic с параметром expression равным 2 + 2 * 2.
Агент формирует и отправляет MCP Client сообщение ContextRequest. Client понимает, что LLM хочет вызвать MCP сервер и передает ему это сообщение.

// Сообщение от Агента (LLM) -> MCP Server
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "calculator_arithmetic",
    "arguments": { "expression": "2 + 2 * 2" }
  }
}

Это и есть тот самый "вызов функции".

Шаг 3: Response (Ответ)

MCP Server получает этот запрос (HTTP запрос), делает свое дело и возвращает результат MCP Client'у. А тот отправляет его обратно LLM.

// Сообщение от MCP Server -> MCP Client
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [{
        "type": "text",
        "text": "6"
    }]
  }
}

Теперь LLM "мозг" решает – готов ли он дать окончательный ответ или нужно вызвать еще парочку MCP

И вот так MCP Client менеджит команды LLM "мозга" на выполнение разных запросов к MCP серверам. Так мы приделали к "мозгу" "руки". С помощью MCP нейронки могут общаться с внешним миром - спрашивать данные, выполнять действия во внешних системах и тд.

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

#MCP #протоколы #LLM #AI

Кстати, чтобы написать свой простейший MCP сервер очень просто:

from fastmcp import FastMCP

mcp = FastMCP("Demo 🚀")

@mcp.tool
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b

FastMCP - это небольшая обертка над библиотекой Starlette, которая позволяет легко создавать MCP серверы - тут вы видите и title, и description, и inputSchema каждого метода.

#MCP #протоколы #LLM #AI

Спасибо dependanbot за такую "классную" поддержку uv

https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#package-ecosystem-

А я все думал, почему у меня локфайл не обновляется?😕

Вот скажите, почему pip - pip, pip-compile - pip, даже poetry - pip, но uv - uv!?🤬

Шок-контент - Django 6.0 (господи, я последний раз на третьей писал), которая выйдет в декабре, релизит built-in Celery🤯

https://docs.djangoproject.com/en/dev/topics/tasks/

Кажется, Celery убьют не с той стороны, с которой все ждали😂

Ладно, это не совсем Celery, но очень похоже.

А еще они планируют дропать python3.10 и 3.11 - кто-нибудь объясните мне, почему я поддерживаю все живые версии питона в FastStream?