Продолжаю разбирать тему продуктивности и наткнулся на классную статью, которая раскладывает "эффективность" на простую и понятную формулу.

Эффективность = Результат / Затраты

Казалось бы, очевидно. Но дьявол, как всегда, в деталях.

Что такое "Результат"?
Это не просто "сделанная задача". Это ценность и влияние, которое она принесла. Запилить фичу за час — круто. Но если этой фичей никто не воспользуется, ее ценность, а значит и ваш результат, равны нулю. Эффективность тоже.

Что такое "Затраты"?
И вот тут главный инсайт. Мы привыкли мерить затраты только временем. Но это лишь верхушка айсберга. На самом деле мы тратим:

🧠 Мыслетопливо (привет, Дорофеев!)
💪 Физические силы
🧘‍♂️ Эмоции (привет, выгорание!)
🎯 Внимание
💰 Деньги

Главная ошибка, на которой попадаются все: мы отчаянно пытаемся уменьшить знаменатель (в основном время), забывая про числитель. Мы учимся делать бесполезные вещи очень быстро, сжигая все свое мыслетопливо. Итог - выгорание и нулевой результат.

Как быть эффективным на самом деле?

1. Прокачать числитель (Результат):
- Спрашивать "Зачем?": Постоянно задавать себе вопрос, какую реальную ценность принесет эта задача. Это тот самый навык, который отличает синьора от джуна
- Бить в самое важное: Применять правило Парето. Находить те 20% действий, которые дадут 80% результата, и фокусироваться на них

2. Уменьшить знаменатель (Затраты):
- Автоматизировать рутину: Все, что можно автоматизировать, должно быть автоматизировано.
- Не делать лишнего: Самый эффективный способ сделать задачу - понять, что ее делать не нужно.
- Выгружать все из головы: Использовать внешние системы (календарь, таск-менеджер), чтобы не тратить драгоценное мыслетопливо на запоминание.

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

В общем, всячески рекомендую оригинал к прочтению: https://bryzgalova.ru/effectiveness

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

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

"Почему все тянут до последнего, чтобы сделать через жопу? Если сделать через жопу сразу, то останется время все улучшить"

Это просто квинтэссенция борьбы с перфекционизмом в нашей работе.

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

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

Да, это был бы неидеальный код. Возможно, с парой "тупых" решений.

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

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

Возможно, наш главный враг — это не технический долг, а страх создать его на время?

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

Сегодня совершенно неожиданно для меня вышли сразу два видоса по FastStream!🤯

От Никиты Соболева: https://www.youtube.com/watch?v=Qf4r8xV-YNk

От Сурена: https://youtu.be/GqC29YuuuGk?si=ZPip3SZbzQU2aYB5

С каждого обязательно по просмотру и лайку! И огромное спасибо самым народным ютуберам за интерес к проекту❤️

Наконец-то снова техническая тема. Переслушивал доклад про NATS – и это натолкнуло меня на размышления, которыми хочу поделиться с вами.

Back Pressure: почему упасть иногда важнее, чем работать

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

Чтобы этого не происходило, умные системы используют механизм обратного давления (back pressure). Это не просто ограничение, это встроенный в протокол или архитектуру способ для потребителя сказать производителю: "Эй, я не успеваю, притормози!".

Это фундаментальный принцип построения отказоустойчивых систем. Давайте посмотрим на два примера.

⚡️ Back Pressure в HTTP: паттерн Circuit Breaker

В мире синхронных HTTP-запросов для обеспечения back pressure принято использовать паттерн Circuit Breaker ("Автоматический выключатель").

Представьте, Сервис А вызывает Сервис Б по HTTP. Сервис Б начинает тормозить или отвечать ошибками из-за нагрузки или сбоя в базе данных.

Что сделает наивный Сервис А?
Он будет долбиться в Сервис Б снова и снова, возможно, с ретраями. Если экземпляров Сервиса А много, они создадут "грозовую толпу" (thundering herd), которая окончательно добьет больной Сервис Б, не давая ему ни шанса на восстановление.

Как работает Circuit Breaker?

На самом деле это очень простой переключатель с тремя состояниями:

- Closed (Замкнут): Все хорошо, запросы свободно уходят в Сервис Б.

- Open (Разомкнут): Счетчик ошибок превысил порог (например, 5 ошибок за 10 секунд). "Пробка вылетает". В течение следующих 30 секунд Сервис А даже не пытается отправить запрос в Сервис Б, а сразу возвращает ошибку. Это и есть back pressure! Мы даем Сервису Б время на восстановление, не заваливая его запросами.

- Half-Open (Полуоткрыт): Через 30 секунд выключатель переходит в это состояние и пропускает один-два "пробных" запроса. Если они проходят успешно — цепь замыкается (Closed). Если нет — снова размыкается (Open) еще на 30 секунд.

🌊 Back Pressure в брокерах: NATS JetStream

Представьте, у вас есть сервис, который генерирует события (например, клики пользователей), и второй сервис, который их обрабатывает (считает аналитику, отправляет в БД). Продюсер может генерировать 10 000 сообщений в секунду, а консьюмер — разгребать только 1000.

Что произойдет без back pressure?
Сообщения будут копиться в очереди брокера, потребитель не будет успевать их разгребать. Отставание в обработке будет накапливаться – минуты, час, дни. В итоге вся система будет выполнять уже не актуальную работу и приносить ровно 0 пользы. А потом и память брокера переполнится – и умрет совсем все

Как решает проблему NATS JetStream?
У стримов в NATS есть две важные опции: max_msgs (`max_bytes`) и DiscardPolicy. Используя эти настройки можно добиться разного поведения, но здесь нас интересует DiscardPolicy.NEW

from faststream.nats import DiscardPolicy, JStream

stream = JStream(
    "stream",
    discard=DiscardPolicy.NEW,
    max_msgs=1000,
    # max_bytes=1024 * 1024 * 1024,
)

Когда стрим заполняется до указанного предела, продюсер при попытке сделать publish() получит ошибку. Это и есть наш back pressure!

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

🛡️ Итог

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

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

#архитектура #распределенные_системы #backend #nats #devops

НАКОНЕЦ-ТО! Этой ночью мы смогли релизнуть FastStream 0.6.0 (пока как release candidate) – https://github.com/ag2ai/faststream/releases/tag/0.6.0rc0

Это была огромная работа и мой публичный позор как разработчика, мейнтейнера, руководителя😢

Вот этот PR: https://github.com/ag2ai/faststream/pull/1779

- 23 контрибьютора приняли участие в подготовке этого релиза
- было сделано 400+ коммитов (а это еще были сквоши при мерже)
- затронуто 2000+ файлов
- больше 60 000 изменений кодлайнов
- почти ГОД работы!

Мы переписали проект изнутри практически целиком (снова). Нет ни одной строчки кода, которую мы бы не затронули. Обновили документацию, тесты, CONTRIBUTING гайд, мигрировали на новые подходы к работе с репой как локально, так и в CI... Практически удвоили тестовое покрытие фреймворка.

Изменения не должны быть такими большими. Они не должны доставляться до потребителя ТАК ДОЛГО.

За это я прошу у вас прощения🙏

Но также это большая радость и облегчение для меня – теперь мы снова разблокируем добавление новых брокеров! На очереди поддержка MQTT и SQS! А еще новая структура проекта позволит нам добавить еще больше классных и нужных фич. Постараемся делать следующие релизы гораздо быстрее (попробую уложиться в сроки до 3ех месяцев на мажор). Но пока я хотел бы взять небольшую паузу и просто выдохнуть.

До 1.0.0 осталось совсем немного вещей, которые мне хотелось бы добавить во фреймворк. Теперь ломающий изменений почти не остается.

Также хочется сказать спасибо команде контрибуторов, которая активно помогала мне дотащить этого гиганта до вас. Ребята супер-красавчики, я буквально каждому обязан❤️ Большая часть из них уже имеет права в репозитории, так что процессы также будут трансформироваться.

А пока – я прошу вас установить

faststream==0.6.0rc0

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

А с обновленной документацией вы можете ознакомиться тут:

https://faststream.ag2.ai/0.6/

И в догонку – сегодня подошли результаты Kaicode. FastStream занял первое место и выиграл 2k$🥳

https://www.kaicode.org/2025.html

Это конкурс Open Source проектов, где оценивается качество проекта: код, работа с Issue, CI, документация и тд.

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

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

Наверное, подам на следующий год другой свой проект https://github.com/Lancetnik/FastDepends 😂

Ребят, последние дни я вспомнил, что я – автор (и мейнтейнер) крупного фреймворка.

FastStream, если кто не в курсе🌚

(А то все про продуктивность, да разработку говорили)

Для меня это уже норма жизни, но мб кому-то интересен именно этот аспект?

Что бы вы хотели спросить у меня:

- как продвигать проект? какие каналы работают, какие - нет?
- как вырабатывать идеи?
- как много времени у меня на это уходит?
- что я с этого имею?
- какие типовые задачи я решаю в Open Source'е в течении дня? Недели? Квартала?
- как вообще выглядит планирование в OSS?
- как помогает сообщество?

В общем, накидайте вопросов в комменты – обсудим. А что-то мб выльется и в отдельный пост / статью / доклад.

У меня есть идея подготовить доклад на следующий сезон "Люди и Open Source" – про поиск пользователей, поиск контрибуторов, их (и свою) мотивацию, виды задач в OSS и всякое такое.

Но мб идея тухлая и ваши вопросики направят меня в нужную сторону.

OpenSource не помогает найти работу!

А потом тебе пишут на почту с предложением работы в зарубежном стартапе на очень вкусные цифры...

Оказывается, появилась целая платформа для HR, где мониторится топ-перформеров на гите🤯

https://algora.io/profile/Lancetnik

UPD: оказывается, там есть еще и Issue-баунти. Компании назначают вознаграждение за PR'ы. Как вам 3.500$ за MCP?

В общем, бежим коммитить!

Btw, на неделе закину историю другого человека, кто нашел работу благодаря Open Source🌚 И нет, он не мейнтейнер / топ-перформер или что-то вроде

Документация для нейронок

Вот в этом посте я уже рассуждал о том, что современные инструменты должны быть адаптированы для использования нейросетями. А сегодня я узнал, что в 2024 году вышел новый формат документации сайта `llms.txt`. Его предложил Jeremy Howard (основатель Fast.ai и бывший CEO Kaggle)

Это такой аналог sitemap.xml, но для LLMs. Он позволит нейросетевым поисковикам эффективнее взаимодействовать с вашими сайтами, а также будет посадочной страницей для MCP типа Context7.

Для меня пока что звучит сомнительно, но многие крупные игроки уже поддержали стандарт:
- Cloudflare - https://developers.cloudflare.com/llms.txt
- Anthropic - https://docs.anthropic.com/llms.txt
- Docker - https://docs.docker.com/llms.txt
- Netlify - https://docs.netlify.com/llms.txt
- Stripe - https://docs.stripe.com/llms.txt
- Pydantic - https://docs.pydantic.dev/latest/llms.txt
- многие другие

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

Поэтому я хочу добавить llms.txt для документации FastStream. А вы можете помочь мне и законтрибутить это (все детали в Issue)

– https://github.com/ag2ai/faststream/issues/2417

Кстати, в репозитории FastStream уже лежит набор правил для Cursor. Он пока сыроват, но вы также можете в него коммитить!

#AI #FastStream

Прошла ровно неделя с моего начала работы над AG2, а я уже придумал, куда там затащить FastStream🌚

Похоже, нас ждет распределенный мультигентный меш на FastStream + NATS🤯

Попробуем накидать хайповые названия в комменты?

Зачем идти в Open Source джуну?

Я часто сталкиваюсь с убеждением, что OpenSource'ом занимаются какие-то странные разработчики из высших материй, кому уже слишком просто "перекладывать JSON'ы". И это так. Но только отчасти.

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

Хочу поделиться с вами вдохновляющей историей разработчика, который сейчас работает в команде FastAPI (вашего любимого / ненавистного фреймворка). А попал он туда очень просто – отвечал на вопросы по фреймворку на всех возможных площадках!

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

Я сменил сферу деятельности (из других областей ИТ), а без релевантного опыта сейчас найти работу очень сложно. Я решил идти этим путём вместо того чтобы откликаться на вакансии. И сработало) Всего 1.5 года до первой работы и ещё 8 месяцев до хорошей работы!

Времени тратил в разные периоды по-разному. Пока не было работы - часа по 4 в день, в остальное время учил что-нибудь. Когда начал работать - часов по 5-10 в неделю.

Я в основном отвечал на Stackoverflow, позже начал и на гитхаб. Брал вопрос который был интересен и начинал разбираться. Иногда сдавался. Смотрел как другие отвечают. Очень помогло пройтись по открытым пулл-реквестам с меткой BUG, часто ответом было просто 'да, это известный баг'

Даже если вы джун (или особенно), вы можете сделать очень много полезного для себя и мира в OpenSource. Работа над открытыми проектами позволит вам:

– получить опыт работы в команде, который вы не получите на своих петах
– познакомиться с "промышленным" пайплайном разработки. Что такое линтеры, тесты, CI, процессы ревью, релизный цикл, обратная совместимость и тд
– прокачать свое резюме. Участие в важных экосистемных проектах точно выделит ваше резюме из сотен других
– регулярно сталкиваться с проблемами реальных пользователей с продакшена (и помогать их решать). Умный ведь учится на чужих ошибках?
– получить публичное портфолио. По нему прекрасно видно, как вы коммуницируете, решаете проблемы, пишете код. Некоторые лиды не ленятся на это смотреть, это гораздо полезнее тестового задания
– получить полезные связи

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

В общем

OpenSource – это способ зайти в IT сбоку

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

Эффективность > Продуктивность. Как перестать бежать и начать двигаться к цели

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

Когда-то я запустил серию постов по Дорофееву, где говорил о продуктивности. Но самая главная тема осталась нераскрытой – как НЕ БЫТЬ НЕЭФФЕКТИВНЫМ.

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

🏃‍♂️ Продуктивность — это про "много сделал". Это чистые действия. Можно закрыть 20 мелких багов, ответить на 50 сообщений в Slack и остаться на том же месте. Голая продуктивность — это спринт на беговой дорожке, который выжимает все соки.

🎯 Эффективность — это про "насколько я приблизился к цели". Это ЦЕЛЬ + ДЕЙСТВИЯ. Можно закрыть всего одну, но самую важную задачу, и сделать гигантский шаг вперед.

Поэтому у эффективности всего 2 простых рецепта:

1. Понять, куда ты движешься (Какая у меня цель на этот месяц/квартал?)
2. Отсечь всё, что не двигает тебя в эту сторону

Предлагаю на этой неделе провести небольшой аудит своих действий. Не глобально, а в моменте:

- Пилишь пет-проект? – Какую цель он преследует: выучить технологию, попасть в портфолио или это просто прокрастинация от основной работы?
- Изучаешь новый модный фреймворк? – Как это поможет тебе в текущих или будущих задачах?
- Смотришь 5-ю серию сериала за вечер? – Это осознанный отдых, который тебя заряжает, или способ убежать от мыслей о важном?

Я не говорю, что так делать не нужно. Но немного осознанности никогда не помешает...

Завтра закину полный список рецептов, которые помогли мне выбраться из выгорания и начать перформить как в лучшие годы😅

#Дорофеев #эффективность #продуктивность

Тема с "документацией для нейронок" развивается... Встречайте – AGENTS.md🤯

Это как README, только для агентов. Ну вы поняли

Примеры:
- Airflow
- Codex
- Temporal
- Pluto

Интересно, что будет следующим? mkdocs-agents, который дублирует навигацию в llms.txt?

Моя система эффективности: как я выбрался из выгорания и начал перформить

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

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

🎯 Принцип №1: Искать 80% результата за 20% усилий.
Мой главный враг — перфекционизм. Я могу потратить кучу времени, чтобы довести задачу до 100% идеала. Но правда в том, что эти последние 20% улучшений часто не нужны никому, кроме меня. Научиться говорить себе "стоп, этого уже достаточно" — главный скилл для сохранения энергии.

А дальше — более тактические вещи, которые помогают этому принципу работать.

Генерация "мыслетоплива"
Нельзя быть эффективным на пустом баке. Поэтому сначала — заправка.

- Больше спорта. Особенно игрового (у меня это теннис), где мозг полностью переключается с работы на движение. Плюс немного ЛФК, чтобы спина не отвалилась.
- Холодный душ каждое утро. Звучит как пытка, но это лучший способ быстро "перезагрузить" систему и получить заряд бодрости на несколько часов.

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

- "Zero Inbox" как стиль жизни. Отписался от всех рассылок, настроил фильтры. Теперь почта всегда пустая, и я трачу на нее 2 минуты в день, а не живу с вечным чувством "там что-то важное".
- Цифровая гигиена в чатах. Вышел из десятков чатов, оставил самый минимум. Не вступаю в бессмысленные дискуссии — это прямое применение принципа 80/20 к общению.
- Информационная диета. Резко сократил количество мусорного контента: фоновая музыка, "видосики" на YouTube, бесконечные сериалы. Мозг тоже устает от переваривания информации.
- Правило бойскаута для рабочего (и жилого) места. Бардак высасывает энергию. Вместо того чтобы раз в месяц делать "героическую" уборку, я просто убираю за собой по мелочи сразу. "Оставь место чище, чем оно было до тебя".

Осознанный отдых
Эффективность — это не про работу 24/7, а про качественные спринты и качественный отдых.

- ОТДЫХ ВНЕСЕН В ПЛАН. Это ключевое. Я прямо в таск-менеджер вписываю: "12:00 - 12:45 - Прогулка" или "Почитать книгу 30 минут". Это легализует отдых и убирает чувство вины.
- "Помидорки" на отдых без самобичевания. Если у меня перерыв 5 минут, я честно отдыхаю, а не думаю о работе. Раньше я тратил эти 5 минут на то, чтобы корить себя за то, что я не работаю. Глупость несусветная.

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

Продолжать тренировать мышцу "80/20". Перфекционист во мне очень силен😅 Это постоянная борьба, но она того стоит.

Теперь жду ваших историй об эффективности, чтобы стащить пару "рецептов"🌚

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

Гайд по OpenSource

Как-то я совсем профукал, что у Github есть ГАЙДИЩЕ по OpenSource – https://github.com/github/opensource.guide

Там есть клевые статьи о том:
– как контрибутить
– как запустить свой OSS
– как мейнтейнерам не выгорать
– как искать пользователей

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

А еще на Github есть оч крутой список Community Standarts (прям в Insights проекта), который помогает превратить ваш репозиторий из "сделано на коленке" в "выглядит сурьезно".

В общем, мне нравится, насколько Github ориентирован на OpenSource. Надеюсь, вся эта движня с Microsoft не испортит мою любимую платформу😢

Кстати, если вам интересно, могу закинуть свой чеклист с правилами оформления репозитрия Github и конкретными тулами, чтобы вы могли за один вечер прокачать свои репозитории по всем требованиям GH и даже больше😎

Кажется, AGI будет не в этом году😅

Зарубежные блогеры тоже по чуть-чуть подтягиваются и начинают освещать 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 минут – очень интересно узнать себя таким вот способом)