Кодовой Барабанщик
112 subscribers
304 photos
103 videos
175 links
БлогеРОК программиста-барабанщика 👨‍💻🥁
Telegram: @GranSteL
YouTube: https://youtube.com/@granstel
ВКВидео: https://vkvideo.ru/@drummer_programmer
Download Telegram
#ИИшница раздаёт советы
🔥2😁1
Кажется, #ИИшница постепенно убирает естественные барьеры между работой и отдыхом 🚧

Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики🟥, кайфуешь. Пока ешь — не пишешь код. Чтобы программировать, нужно сесть за компьютер и сосредоточиться.

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

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

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

В результате появляется странный эффект😳

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

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

Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения⚡️

Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить
Please open Telegram to view this post
VIEW IN TELEGRAM
3❤1🔥1
Последние три дня был в Самаре, приехал по делам.
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑‍💻

Какие методы должны быть у такого интерфейса?
🔹 RehearsalBase() — должна быть репетиционная база, чтобы можно было подготовиться к выступлению.
🔹 Workspace() — место, где можно спокойно поработать: удобный стол, стабильный интернет (Wi-Fi или хороший мобильный): коворкинг или просто удачный номер в отеле.
🔹 Ну и базовые методы вроде Sleep() и Eat(). Без них тоже никуда.

Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома🏠

Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений✨
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4🫡11
Как менялось моё рабочее место в течение дня👆
👍2🔥11
#RunIT в этот раз проходит без меня 👟
Зато совсем скоро будет ещё #движ, жди подробностей🎉
❤2
Так вот, новость про #движ: в пятницу (10 июля) в 19:00 выступаю с #хитпоинт на Dio Birthday Party 🎂🎉🎸
Клуб Цеппелин N5, Слободской переулок д.6 с.4. Вход платный 🤑
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Декомпозировать всё 🧩

Это уже не столько про #поиск_работы, сколько в целом про полезный навык💪

Не знаю, как в других профессиях, но в разработке часто встречается понятие декомпозиции — разделения одной большой задачи на множество маленьких. Это про то, что можно съесть слона по кусочкам🖥
В идеале, эти кусочки должны представлять собой инкремент (прирост) функциональности и измеряться какими-нибудь метриками📈

Когда я готовился к смене работы, этот подход помог мне подступиться к такой большое задаче и разделить её на несколько более простых и понятных:
🧩 написать резюме (инкремент: артефакт в виде резюме, метрика: наполненность ключевыми навыками)
🧩 регулярно откликаться на вакансии (инкремент: отклик, метрика: кол-во моих откликов и ответов на них)
🧩 последовательно освежать знания (инкремент: знания, метрика: насколько подробно и уверенно отвечаю на вопросы по теме: субъективно, но всё-таки измеримо)

Последний пункт тоже надо было декомпозировать: тем для повторения было много, поэтому я отсортировал их по уровню работы, от низкоуровневых (ОС, проц, память) до верхнеуровневых (архитектурные паттерны) и проходил одну за другой. Не пытался охватить всё сразу - просто двигался шаг за шагом👣

Точно так же, кстати, учу новые песни на барабанах🥁

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

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

Иногда самый важный прогресс — это не сделать всю работу сразу, а правильно разделить её на части и составить план работы
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1
Forwarded from C# Short Posts 🔞
🗄Оперативное 2: Кэш ОС — ещё один уровень кэша, которым Postgres не управляет

Второй едок памяти из обзорного поста — кэш операционной системы. Именно с ним связана классическая паника «на сервере с базой вся оперативка занята, памагити, ААА!»😂

📚 Откуда он берётся
shared_buffers — это кэш самого Postgres. Но есть ещё один уровень кэша, который живёт своей жизнью. Когда любая программа читает файл с диска, операционная система запоминает прочитанные блоки в свободной оперативке. В следующий раз тот же файл прилетит уже из памяти, без похода на диск. Этот общесистемный кэш называется страничным кэшем (или же page cache) 📃

Postgres читает свои файлы — и кучу с данными, и файлы индексов — как все, через операционную систему. Значит, его страницы попадают ещё и в кэш ОС. Получается двойное кэширование: одна и та же страница может одновременно лежать и в shared_buffers, и в страничном кэше ОС 📄

🍽 Почему «вся память занята»
Операционная система не любит, когда оперативка простаивает впустую, поэтому забивает всё свободное место кэшем файлов. На Linux, например, при помощи утилиты free (которая показывает, как используется ОЗУ и пространство подкачки (swap) в системе) зачастую можно увидеть, что свободной памяти почти не осталось, а здоровенный кусок помечен как buff/cache (если, конечно, в системе активно происходит чтение файлов 🧠)

Пугаться этого не нужно. Память под кэшем ОС считается освобождаемой. То есть, правильно говорить не «память кончилась», а «сейчас память используется под кэш, но как только она понадобится другому приложению, система тут же готова уступить оперативку по первому требованию, чесслово 💯»

🔗 read ≠ чтение с диска
Напомню, что в посте про чтение страниц мы видели в плане запроса слово read — «страницы не было в shared_buffers, пришлось дочитывать». Там же мы выяснили, что read не обязательно означает поход на диск: страница вполне могла быть прочитана из кэша ОС. Поэтому read иногда оказывается почти таким же быстрым, как hit (чтение из shared_buffers, то есть, по сути, тоже из оперативки).

🅰️ Что унести с собой
🟢 Кроме кэша Postgres есть кэш операционной системы: он общий для всей машины, и Postgres им не управляет
🟢 Одна страница может лежать сразу в двух кэшах — это и есть двойное кэширование
🟢 Когда вся память используется под файловый кэш — это нормально: такая память освобождается по первому требованию других приложений
🟢 read в плане запроса значит «не нашлось в shared_buffers», а не обязательно прочитано с диска»

🧑‍💻dp🥁
#бд #postgresql #инженерныештучки #heavywednesday
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
This media is not supported in your browser
VIEW IN TELEGRAM
Продолжаю нерегулярную рубрику лайфхаков для барабанщиков 🥁
Рассказываю важный и полезный лайфхак про барабанный стул 🪑, смотри до конца👆
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4🔥1
#RocknMob в Москве состоится 22 августа!
Москва, Северный речной вокзал, 14:00

Сет-лист:
PINK FLOYD – Another Brick in the Wall
BLACK SABBATH – Paranoid
LINKIN PARK – The Emptiness Machine
БРАВО – Любите девушки

Для участия регистрируйся по ссылке:
https://rocknmob.com/rocknmob-moscow-12/

#движ
🔥1
Так выглядела моя "кухня" на выступлении с #хитпоинт, сейчас дома уже, делаю видосы 🎥
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Многие жалуются на то, что #ИИшница не телепат и не делает сразу хорошо. Но не многие знают, что ей, как и любому новому разработчику в проекте, надо дать немного общего контекста и правил, которые не всегда можно понять непосредственно из кода. Да, какие-то вещи есть и в коде, но если твой ИИ-помощник будет перед каждой задачей полностью сканировать кодовую базу проекта, у тебя не останется доступных лимитов на непосредственное выполнение задачи🧠
Так что сделай для него хотя бы базовые инструкции, чтобы вы были "на одной волне" 🌊

Ещё я для себя выработал такую формулу:

Не додумывай, перепроверяй, уточняй


Раньше я добавлял её ко всем запросам, а потом занёс в глобальные правила. Теперь мои ассистенты чуть меньше выдумывают, и чуть больше уточняют, что, во многом, экономит время на старте. Рекомендую к использованию👆

А так тут вот хорошо пишут о базовой подготовке проекта к работе с ИИ. Хоть и речь в основном про Claude😒, но некоторые другие инструменты тоже по умолчанию ориентируются на эти файлы, или можно явно попросить об этом. В общем, тоже рекомендую👇
Please open Telegram to view this post
VIEW IN TELEGRAM
День 2721. #ЗаметкиНаПолях #AI
Превращаем Claude из Автодополнителя в Коллегу. Начало
Claude не «плохо разбирается в .NET». Он слеп. Вы просите его «добавить конечную точку», а он уверенно:
- изобретает структуру папок, которая не соответствует вашему репозиторию;
- добавляет шаблоны, которые вы не используете;
- пропускает ваш рабочий процесс сборки/тестирования;
- нарушает соглашения и заставляет вас убирать за ним.
Это не проблема ИИ. Это проблема адаптации.


Решение — один файл, который становится системой оперирования вашим проектом для Claude: CLAUDE.md.

В Claude Code файлы памяти, такие как ./CLAUDE.md (и модульные правила в ./.claude/rules/*.md), автоматически загружаются в качестве контекста при запуске инструмента, поэтому Claude начинает каждую сессию с картой вашего проекта и правилами, вместо того чтобы гадать.

Что на самом деле делает CLAUDE.md
Представьте CLAUDE.md как вводные инструкции для нового старшего разработчика. Однако этот «разработчик» будет:
- последовательно следовать вашим инструкциям,
- запоминать их между сессиями,
- перестанет каждый раз заново изобретать вашу архитектуру.

В документации Claude Code файл CLAUDE.md описывается как файл конфигурации проекта, который находится в вашем репозитории и автоматически загружается в контекст.

И что важно: вам не нужно начинать с нуля. Claude Code поддерживает команду /init для генерации стартового файла CLAUDE.md путём сканирования вашего репозитория — затем вы его дорабатываете.

Правило: ваш CLAUDE.md должен предотвращать дорогостоящие ошибки
Если CLAUDE.md не предотвращает одну из следующих ошибок, он не выполняет свою работу:
- неправильные шаблоны (репозитории, AutoMapper, случайные абстракции, которые вы не используете);
- неправильный рабочий процесс (изменения без плана, отсутствие тестов, отсутствие валидации);
- неправильные значения по умолчанию (тайм-ауты, отмена, повторные попытки, фоновая работа, время жизни DI).

Поэтому не пишите его как документацию. Пишите его как: ограничители + карта + команды.

Структура памяти Claude Code
Claude Code поддерживает небольшую иерархию файлов памяти, включая:
- ./CLAUDE.md для общей памяти проекта,
- ./.claude/rules/*.md для модульных правил,
- ~/.claude/CLAUDE.md для ваших личных глобальных настроек,
- ./CLAUDE.local.md для ваших личных заметок по проекту (и он НЕ предназначен для того, чтобы его коммитили).
Это означает, что вы можете:
- держать краткий корневой файл CLAUDE.md,
- поместить подробные правила в .claude/rules/,
- хранить ваши личные данные в CLAUDE.local.md, не засоряя репозиторий.

Минимально необходимый CLAUDE.md для бэкенда на .NET 10
Создайте CLAUDE.md в корневом каталоге вашего репозитория:
## What this repo is
- .NET 10 backend API focused on scalability, p95/p99 latency, and production reliability.
- Prefer simple, copy/pasteable patterns over "clever architecture".

## Tech stack --> Зависит от ваших условий
- .NET 10 / C# (modern style)
- ASP.NET Core (Minimal APIs)
- Dapper (NOT EF Core)
- Redis (IDistributedCache / StackExchange.Redis depending on project)
- Azure hosting (App Service / Containers)
- Observability: Application Insights (logs + metrics)

## Repo map --> Измените, чтоб соответствовало вашим папкам
- src/Api/ → endpoints, DI, middleware, startup
- src/App/ → use-cases/services (business orchestration)
- src/Infra/ → DB, Redis, HTTP clients, external integrations
- tests/ → unit + integration tests

## Hard rules (do not violate)
- NEVER add new framework layers or "Clean Architecture cosplay".
- NEVER introduce patterns we don't use (AutoMapper, repositories, magic abstractions).
- Always pass CancellationToken through all async calls.
- No sync-over-async (no .Result/.Wait).
- No Task.Run inside request handlers.
- Outbound HTTP MUST have timeouts + cancellation.
- Caching MUST have: time budget, stampede protection strategy, and key versioning.

## Default workflow
1) Ask for missing requirements before changing code.
2) Propose a plan + list files to touch.
3) Implement smallest change that works.
4) Add/update tests when relevant.
5) Provide commands to verify (build/test/run).

## Commands --> Измените на нужные вам
- Build: `dotnet build`
- Test: `dotnet test`
- Run API: `dotnet run --project src/Api`
- Format: `dotnet format`

## Output format
- Prefer short sections, small code blocks, and explain trade-offs.
- When making changes: show diff-level guidance + why.


Этого достаточно, чтобы избежать 80% гаданий Claude.

Далее сделаем его жутко эффективным.

Окончание следует…

Источник:
https://medium.com/codetodeploy/claude-md-for-net-10-turn-claude-from-autocomplete-into-a-teammate-5ae9d5ad0b92
Эксперимент: что если скрестить две иишницы 🍳

💡 Немного мудрости:
Сложную задачу реши сам, а лёгкую отдай джуну👶

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

Если говорить про обычную работу, то здесь есть нюанс. Да, новичку можно давать задачи, соответствующие его опыту. Но если он будет заниматься только ими, то никогда не вырастет. Любой специалист развивается тогда, когда сталкивается с задачами чуть сложнее своего текущего уровня🤯

Но именно эта "мудрость"👆в данном случае является наставлением для ИИ-агента aka #ИИшница 🧠

Сейчас я исследую работу с несколькими AI-вендорами одновременно. Есть мощный агент (например, Claude😒), а есть более простые и дешёвые сторонние модели.
Если проводить аналогию с разработкой, то получается примерно так:

👨‍💻 я — сеньор, который понимает архитектуру и конечную цель 🧠
🧠 Claude — опытный мидл. Он способен самостоятельно решать сложные задачи, но иногда ему всё ещё нужны направление и проверка💪
🤖 Более дешёвые модели — очень инициативные джуны. Они готовы работать много и быстро, но результат далеко не всегда оказывается идеальным. Иногда они делают именно то, что попросили, а иногда — совсем не то, что имели в виду👶

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

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

НО

это всё в рамках одной подписки и одних лимитов❗️. Да, на более дешёвых моделях ресурсы расходуются меньше, но всё-таки расходуются, и для более долгой работы дорогой модели их может не хватить (если не раскошелился на боле дорогую подписку 🤑).
Мне же удалось настроить интеграцию сторонних моделей (Клавдий всё настроил, а я рядом стоял). То есть когда работает другая, более дешёвая модель, тратятся её лимиты, а не дорогой модели. Profit ↗️

В итоге дорогая модель не тратит своё время и токены на примитивную работу. Она занимается тем, где действительно нужна её квалификация, а всё остальное отдаёт тем, кто справится дешевле💰

Именно в этом контексте фраза начинает звучать совсем иначе:
Сложную задачу реши сам, а лёгкую отдай джуну

Не потому что джуна жалко или не хочется ему доверять сложное, а потому что ресурсы дорогого специалиста (или дорогой модели) лучше тратить там, где без него действительно не обойтись🧠

P.S. на самом деле, стоит ещё оценить, действительно ли так дешевле❓ Ведь тут может возникнуть та же ситуация, что была на ранних этапах вайбкодинга агентной разработки: более опытной модели (миддлу) надо проверять и, возможно, поправлять косяки за "джуном", то есть всё равно тратить ценные ресурсы. Не будет ли лучше сразу всё сделать силами дорогой модели🤔
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥11