#TS
Паттерн «Either» , используется в Go и Rust.
Избавляемся от лишней вложенности при работе с async await и try / catch .
Для себя в последнее время выбрал вариант написания обработчика когда, когда из «baseApi» мы получаем кортеж из двух результатов.
В нашем случае Either это сущность, значение которой может быть одного из двух типов, «левое» и «правое». Есть соглашение, по которому Right соответствует data соответствующего типа переданного в дженерик, а Left – ошибке.
Таким образом получается сделать плоским каскад вложенных try catch и осуществить ранний выход из функции где это необходимо.
Если вы когда-нибудь писали на try/catch, в map, вызов 6-7 асинхронных методов, то поймете о чем я :)
На первый взгляд, может показаться необычно, но по факту дело привычки. Актуальность возрастает с ростом сложности сервисных методов ( кол-ва обрабатываемых промисов)
Примеры на скринах:
1. паттерн Either в сервисном слое
2. Точно такой же метод , но на try catch
3. пример api handler из baseApi класса
Паттерн «Either» , используется в Go и Rust.
Избавляемся от лишней вложенности при работе с async await и try / catch .
Для себя в последнее время выбрал вариант написания обработчика когда, когда из «baseApi» мы получаем кортеж из двух результатов.
В нашем случае Either это сущность, значение которой может быть одного из двух типов, «левое» и «правое». Есть соглашение, по которому Right соответствует data соответствующего типа переданного в дженерик, а Left – ошибке.
Таким образом получается сделать плоским каскад вложенных try catch и осуществить ранний выход из функции где это необходимо.
Если вы когда-нибудь писали на try/catch, в map, вызов 6-7 асинхронных методов, то поймете о чем я :)
На первый взгляд, может показаться необычно, но по факту дело привычки. Актуальность возрастает с ростом сложности сервисных методов ( кол-ва обрабатываемых промисов)
Примеры на скринах:
1. паттерн Either в сервисном слое
2. Точно такой же метод , но на try catch
3. пример api handler из baseApi класса
🔥1
#Hire #ComputerScience
Пользователь ввел доменное имя сайта в адресную строку браузера - что было дальше ?)
1) Браузер проверяет свои кэши, чтобы можно было использовать сохраненный IP или кэш страницы, без дополнительных запросов. Если кэша нет, то делает DNS запрос, чтобы преобразовать доменное имя в IP адрес сервера.(DNS сервера опрашиваются рекурсивно, пока не найдется нужный IP)
Браузер получает соответствующий IP адрес.
2) Браузер устанавливает TCP-соединение с сервером, используя IP-адрес и порт (по умолчанию 80 для HTTP или 443 для HTTPS).
TCP Handshake: Браузер и сервер обмениваются пакетами для установки соединения(3х стороннее рукопожатие).
Если используется HTTPS, то происходит TLS Handshake - обмен ключами для шифрования :
- согласование криптографических протоколов
- аутентификация с помощью SSL-сертификата, проверка сертификатов
- генерация сеансового ключа, обмен ключами
В TLS 1.3 используется всего 3 шага рукопожатия (ранее 10 шагов). Происходит генерация симметричных сессионных ключей для шифрования данных.
3) Браузер отправляет HTTP запрос, заголовки (тело запроса)
4) Сервер обрабатывает запрос, формирует ответ (статус код/заголовки / тело ответа)
5) Браузер получает ответ и обрабатывает его, читает заголовки , например Content-type, чтобы определить тип данных.
6) Рендер страницы, что происходит :
- парсинг HTML, строится DOM дерево
- загружает CSS, строит CSSOM
- создается Render-Tree (объединение DOM и CSSOM)
- layout reflow, вычисление размеров и позиций элементов
- paint, отрисовка пикселей на экране
- выполняется JS код
7) Отображение страницы
Пользователь ввел доменное имя сайта в адресную строку браузера - что было дальше ?)
1) Браузер проверяет свои кэши, чтобы можно было использовать сохраненный IP или кэш страницы, без дополнительных запросов. Если кэша нет, то делает DNS запрос, чтобы преобразовать доменное имя в IP адрес сервера.(DNS сервера опрашиваются рекурсивно, пока не найдется нужный IP)
Браузер получает соответствующий IP адрес.
2) Браузер устанавливает TCP-соединение с сервером, используя IP-адрес и порт (по умолчанию 80 для HTTP или 443 для HTTPS).
TCP Handshake: Браузер и сервер обмениваются пакетами для установки соединения(3х стороннее рукопожатие).
Если используется HTTPS, то происходит TLS Handshake - обмен ключами для шифрования :
- согласование криптографических протоколов
- аутентификация с помощью SSL-сертификата, проверка сертификатов
- генерация сеансового ключа, обмен ключами
В TLS 1.3 используется всего 3 шага рукопожатия (ранее 10 шагов). Происходит генерация симметричных сессионных ключей для шифрования данных.
3) Браузер отправляет HTTP запрос, заголовки (тело запроса)
4) Сервер обрабатывает запрос, формирует ответ (статус код/заголовки / тело ответа)
5) Браузер получает ответ и обрабатывает его, читает заголовки , например Content-type, чтобы определить тип данных.
6) Рендер страницы, что происходит :
- парсинг HTML, строится DOM дерево
- загружает CSS, строит CSSOM
- создается Render-Tree (объединение DOM и CSSOM)
- layout reflow, вычисление размеров и позиций элементов
- paint, отрисовка пикселей на экране
- выполняется JS код
7) Отображение страницы
🔥2
#Архитектура #SOLID
Single Responsibility Principle
Многие разработчики некорректно понимают и трактуют данный принцип из SOLID.
Понимание того, что одна функция должна выполнять одну задачу - это низкоуровневая база и она не является сутью SRP.
Поэтому передаю фактическую краткую суть принципа :
- Программа изменяется по желанию определенной группы лиц, так называемый "актор"
- модуль (связный набор функций и структур данных) должен отвечать только за одного актора , например "отдел качества" ( отдел в компании X , для которой разрабатывается ПО)
- связность это сила, благодаря которой код объединяется в модуль , данный код ответственен только за этого актора, т.е отдел качества.
Любой вариант композиции бл (бизнес-логики) буду называть Unit ( Composition Unit).
Основные поинты для соблюдения принципа в коде :
- держать в одном unit только функции отвечающие за одного актора
- отделять данные от бл , т.к данные могут понадобиться различным акторам
Т.е основной подход соблюдения SRP - это правильная композиция бл , отсутствие смешения кода разных акторов, что приводит к багам при внесении изменений, а также регулярным конфликтам слияний git.
SRP касается Composion unit'ов.
Его проявления также идут выше : на уровень компонентов системы и на уровень архитектуры ( ось изменений, архитектурные границы).
Single Responsibility Principle
Многие разработчики некорректно понимают и трактуют данный принцип из SOLID.
Понимание того, что одна функция должна выполнять одну задачу - это низкоуровневая база и она не является сутью SRP.
Поэтому передаю фактическую краткую суть принципа :
- Программа изменяется по желанию определенной группы лиц, так называемый "актор"
- модуль (связный набор функций и структур данных) должен отвечать только за одного актора , например "отдел качества" ( отдел в компании X , для которой разрабатывается ПО)
- связность это сила, благодаря которой код объединяется в модуль , данный код ответственен только за этого актора, т.е отдел качества.
Любой вариант композиции бл (бизнес-логики) буду называть Unit ( Composition Unit).
Основные поинты для соблюдения принципа в коде :
- держать в одном unit только функции отвечающие за одного актора
- отделять данные от бл , т.к данные могут понадобиться различным акторам
Т.е основной подход соблюдения SRP - это правильная композиция бл , отсутствие смешения кода разных акторов, что приводит к багам при внесении изменений, а также регулярным конфликтам слияний git.
SRP касается Composion unit'ов.
Его проявления также идут выше : на уровень компонентов системы и на уровень архитектуры ( ось изменений, архитектурные границы).
🔥1
💥 Немного о наболевшем, или почему архитектура — это про выживание продукта.
Работая на том или ином проекте, можно подметить, что новая фича в проекте даётся всё тяжелее.
Каждое изменение ломает старый код, баги множатся, а “поправить мелочь” превращается в X-дневный квест.
И проблема тут не в людях, а в архитектуре, а также подходах и процессах, которые её формируют.
🏗 Что такое архитектура ?
Архитектура — это совокупность решений (комплекс) разного уровня детализации, управляющих стоимостью изменений во времени.
Цель архитектуры — сделать так, чтобы каждое новое изменение не становилось дороже предыдущего.
Если трудозатраты растут с каждой фичей — архитектура не работает (или её просто нет).
🪓 Как выглядит плохая архитектура
- Любое изменение ломает старое
- Баги возникают “на ровном месте”
- Команда устает и и теряет мотивацию
- Руководство злится: “Почему так медленно?”
- В проекте становится всё больше людей, но не скорости...
- Стоимость разработки растет экспоненциально
Проще говоря — растёт хаос.
🤡 Что мы часто слышим на таких проектах?
- Нужно выкатить релиз “вчера”
- “Потом наведём порядок” (никогда 💀)
- “Не вылизывай, просто сделай”
- “Успеть до конца срока!” — снова и снова
С каждым таким релизом проект становится всё более хрупким и запутанным.
Любое изменение вызывает цепочку багов.
💡 Почему так происходит ?
Главный враг архитектуры — спешка ⚠️.
Мы жертвуем качеством ради скорости.
Выигрываем время сегодня — теряем его завтра, причем кратно больше.
Нужно принять простую истину: скорость без качества — иллюзия.
🚑 Как лечить ?
Есть такое народное выражение: "Чем больше спешишь, тем меньше успеваешь"
Это и есть ответ - нужно замедлиться, чтобы ускориться.
В разработке, как и в спорте, важна периодизация и циклы восстановления.
В этих циклах восстановления, необходимо внедрять и применять следующее :
👉 Дизайн-ревью сложного функционала (перед выполнением)
👉 Проводить качественное кросс-ревью и внедрять соглашения.
👉 Разрабатывать функционал с применением устоявшихся паттернов проектирования
👉 Соблюдать принципы SOLID, отслеживать структуру проекта
👉 Формировать тех-долг и заниматься им на регулярной основе
👉 Понимать, что каждый MR либо улучшает систему, либо ухудшает
👉 Формировать культуру ответственности за внесенный хаос и баги
👉 Качественно планировать, оценивать реальные сроки :
- текущую сложность и хаос проекта
- коммуникацию с коллегами
- аналитику, коллизии, время на несколько итераций тестирования и баг-фиксов
Короче говоря не самонадеянно верить в свою супер-скорость - а закладывать риски.
"Потом" чаще всего никогда не наступает и после релиза будет следующая фича, а не рефакторинг.
Культура начинается снизу!
Разработчику следует сразу стараться писать код максимально чисто и обдуманно, обсуждать решения, благодарить коллег за ревью.
Помните, что хорошая архитектура - экономия, она удерживает стоимость изменений и позволяет развивать продукт стабильно.
А чтобы ее реализовать нужны как харды и ответственность разработчиков, так и осознание всего вышеперечисленного руководителями.
#Архитектура
Работая на том или ином проекте, можно подметить, что новая фича в проекте даётся всё тяжелее.
Каждое изменение ломает старый код, баги множатся, а “поправить мелочь” превращается в X-дневный квест.
И проблема тут не в людях, а в архитектуре, а также подходах и процессах, которые её формируют.
🏗 Что такое архитектура ?
Архитектура — это совокупность решений (комплекс) разного уровня детализации, управляющих стоимостью изменений во времени.
Цель архитектуры — сделать так, чтобы каждое новое изменение не становилось дороже предыдущего.
Если трудозатраты растут с каждой фичей — архитектура не работает (или её просто нет).
🪓 Как выглядит плохая архитектура
- Любое изменение ломает старое
- Баги возникают “на ровном месте”
- Команда устает и и теряет мотивацию
- Руководство злится: “Почему так медленно?”
- В проекте становится всё больше людей, но не скорости...
- Стоимость разработки растет экспоненциально
Проще говоря — растёт хаос.
🤡 Что мы часто слышим на таких проектах?
- Нужно выкатить релиз “вчера”
- “Потом наведём порядок” (никогда 💀)
- “Не вылизывай, просто сделай”
- “Успеть до конца срока!” — снова и снова
С каждым таким релизом проект становится всё более хрупким и запутанным.
Любое изменение вызывает цепочку багов.
💡 Почему так происходит ?
Главный враг архитектуры — спешка ⚠️.
Мы жертвуем качеством ради скорости.
Выигрываем время сегодня — теряем его завтра, причем кратно больше.
Нужно принять простую истину: скорость без качества — иллюзия.
🚑 Как лечить ?
Есть такое народное выражение: "Чем больше спешишь, тем меньше успеваешь"
Это и есть ответ - нужно замедлиться, чтобы ускориться.
В разработке, как и в спорте, важна периодизация и циклы восстановления.
В этих циклах восстановления, необходимо внедрять и применять следующее :
👉 Дизайн-ревью сложного функционала (перед выполнением)
👉 Проводить качественное кросс-ревью и внедрять соглашения.
👉 Разрабатывать функционал с применением устоявшихся паттернов проектирования
👉 Соблюдать принципы SOLID, отслеживать структуру проекта
👉 Формировать тех-долг и заниматься им на регулярной основе
👉 Понимать, что каждый MR либо улучшает систему, либо ухудшает
👉 Формировать культуру ответственности за внесенный хаос и баги
👉 Качественно планировать, оценивать реальные сроки :
- текущую сложность и хаос проекта
- коммуникацию с коллегами
- аналитику, коллизии, время на несколько итераций тестирования и баг-фиксов
Короче говоря не самонадеянно верить в свою супер-скорость - а закладывать риски.
"Потом" чаще всего никогда не наступает и после релиза будет следующая фича, а не рефакторинг.
Культура начинается снизу!
Разработчику следует сразу стараться писать код максимально чисто и обдуманно, обсуждать решения, благодарить коллег за ревью.
Помните, что хорошая архитектура - экономия, она удерживает стоимость изменений и позволяет развивать продукт стабильно.
А чтобы ее реализовать нужны как харды и ответственность разработчиков, так и осознание всего вышеперечисленного руководителями.
#Архитектура
👍1🔥1
Перед релизом прилетела задача, сделать небольшую доработку с изменением dto.
Так происходит на проекте, на котором нет архитектуры 🙈
Так происходит на проекте, на котором нет архитектуры 🙈
😁1
Самая важная мысль. Каждый программист во время разработки функционала должен думать об этом, чтобы писать поддерживаемый и расширяемый код.
#Архитектура
#Архитектура
#claudecode
Полезная инфа по работе с клодом от https://x.com/bcherny
https://howborisusesclaudecode.com/
Иногда нужно чекать, как далеко ты от прогресса )
btw в ближайшем будущем все больше и больше разработчиков уже не будут самостоятельно писать код, а работа сведётся к оркестрированию n терминалов claude (что и происходит уже в крупнейших компаниях за границей 🧐)
Вот только решает кто у руля, эксперт и знающий домен человек, сделает круто и кратно увеличит производительность.
А условный джун только добавит проблем.
Важно мыслить широко, так или иначе знать паттерны проектирования, владеть доменной информацией, чтобы грамотно строить планы с claude , а от плана зависит 90% результата
Думаю в скором времени в России тоже начнут (или уже начали) перенимать западные практики внедрения AI в проекты: skills/workflows/claude.md и прочие уникальные для проектов настройки будут оживать в git и активно редактироваться/дополняться командами.
Полезная инфа по работе с клодом от https://x.com/bcherny
https://howborisusesclaudecode.com/
Иногда нужно чекать, как далеко ты от прогресса )
btw в ближайшем будущем все больше и больше разработчиков уже не будут самостоятельно писать код, а работа сведётся к оркестрированию n терминалов claude (что и происходит уже в крупнейших компаниях за границей 🧐)
Вот только решает кто у руля, эксперт и знающий домен человек, сделает круто и кратно увеличит производительность.
А условный джун только добавит проблем.
Важно мыслить широко, так или иначе знать паттерны проектирования, владеть доменной информацией, чтобы грамотно строить планы с claude , а от плана зависит 90% результата
Думаю в скором времени в России тоже начнут (или уже начали) перенимать западные практики внедрения AI в проекты: skills/workflows/claude.md и прочие уникальные для проектов настройки будут оживать в git и активно редактироваться/дополняться командами.
🔥1
🔥 Не трать время на переход в отдельный терминал для обычных bash команд, пиши
#claudecode #daily
! в claude cli 🙈#claudecode #daily
🆒1
📰 Кто рано встаёт тому ... Claude Code даёт.
Суть: Anthropic меняет распределение лимитов сессий Claude в пиковые часы из-за жесткого хайпа и наплыва юзеров.
Что меняется:
В будни с 15:00 до 21:00 МСК, лимиты 5-часовых сессий будут «сгорать» быстрее
Затрагивает Free / Pro / Max подписки.
Общий недельный лимит не изменился, только перераспределение внутри недели.
~7% пользователей (особенно Pro) будут упираться в лимиты там, где раньше не упирались.
Вообщем встаем и работаем с..ранья, совы скажут спасибо 🙏
#news
Суть: Anthropic меняет распределение лимитов сессий Claude в пиковые часы из-за жесткого хайпа и наплыва юзеров.
Что меняется:
В будни с 15:00 до 21:00 МСК, лимиты 5-часовых сессий будут «сгорать» быстрее
Затрагивает Free / Pro / Max подписки.
Общий недельный лимит не изменился, только перераспределение внутри недели.
~7% пользователей (особенно Pro) будут упираться в лимиты там, где раньше не упирались.
Вообщем встаем и работаем с..ранья, совы скажут спасибо 🙏
#news
😁1
📖 context-rot (1/3)
AI чудит - забывает правки, повторяет отклонённое, галлюцинирует. Контекст забивается и модель теряет фокус.
Тут важно как мы с ней работаем. Мои рекомендаcы:
1. CLAUDE.md — худой
Соблазн запихать туда правила на 500 строк — понятен. Но claude md грузится при каждом старте и висит в контексте постоянно. Только нужное для сессии, остальное — в skills / rules / ... через рефы.
2. English
Кириллица дробится токенизатором сильнее латиницы — тот же смысл на русском занимает больше токенов, контекст забивается быстрее.
Скиллы, планы, описания агентов — в EN. Общение тоже, если комфортно. На длинных сессиях разница ощутима.
#claudecode #contextrot #configs
AI чудит - забывает правки, повторяет отклонённое, галлюцинирует. Контекст забивается и модель теряет фокус.
Тут важно как мы с ней работаем. Мои рекомендаcы:
1. CLAUDE.md — худой
Соблазн запихать туда правила на 500 строк — понятен. Но claude md грузится при каждом старте и висит в контексте постоянно. Только нужное для сессии, остальное — в skills / rules / ... через рефы.
2. English
Кириллица дробится токенизатором сильнее латиницы — тот же смысл на русском занимает больше токенов, контекст забивается быстрее.
Скиллы, планы, описания агентов — в EN. Общение тоже, если комфортно. На длинных сессиях разница ощутима.
#claudecode #contextrot #configs
🔥3
📖 context-rot (2/3)
Теперь инструменты:
3. RTK-AI
CLI-прокси на Rust. rtk перед командами (grep/bash/git/..etc) — позволяет фильтровать вывод до попадания в контекст.
Например
4. Context Mode
MCP-сервер с другим подходом — не фильтрует вывод, а вообще не пускает сырые данные в контекст.
Встраиваем в глобальные настройки.
Оба решают одну задачу разными способами, использую вместе.
#claudecode #contextrot #configs
Теперь инструменты:
3. RTK-AI
CLI-прокси на Rust. rtk перед командами (grep/bash/git/..etc) — позволяет фильтровать вывод до попадания в контекст.
Например
git diff на большом PR — 10k+ токенов, из которых модели нужна малая часть. RTK выкинет мусор и оставит важное. Встраиваем в глобальные настройки.4. Context Mode
MCP-сервер с другим подходом — не фильтрует вывод, а вообще не пускает сырые данные в контекст.
ctx_execute гоняет команды в изолированном процессе, отдаёт выжимку.ctx_search ищет по проиндексированному.Встраиваем в глобальные настройки.
Оба решают одну задачу разными способами, использую вместе.
#claudecode #contextrot #configs
👍1
📖 context-rot (3/3)
Теперь про подход.
5. CLI > MCP
Работайте через CLI в приоритете.
MCP-вызовы тянут схемы, метадату, обёртки — короче это дорого по токенам.
Поэтому если у тулза есть CLI - must have (gitlab, playwright и т.д)
6. Workflow как слайсы + агенты
Стройте свои процессы (скиллы) так, чтобы задача билась на куски.
Каждый кусок — агент со своим контекстом.
Отработают и вернут выжимку, в итоге не потратите 20к основного окна на ресёрч :)
В том числе анализ документации, фоновые задачи и т.п
Держу контекст сессии до 150к. Дальше — clear/compact, но с summary в кэше, чтобы стартовать с актуальной инфой.
Про workflow скиллы подробнее — в следующих постах :)
#claudecode #contextrot #configs
Теперь про подход.
5. CLI > MCP
Работайте через CLI в приоритете.
MCP-вызовы тянут схемы, метадату, обёртки — короче это дорого по токенам.
Поэтому если у тулза есть CLI - must have (gitlab, playwright и т.д)
6. Workflow как слайсы + агенты
Стройте свои процессы (скиллы) так, чтобы задача билась на куски.
Каждый кусок — агент со своим контекстом.
Отработают и вернут выжимку, в итоге не потратите 20к основного окна на ресёрч :)
В том числе анализ документации, фоновые задачи и т.п
Держу контекст сессии до 150к. Дальше — clear/compact, но с summary в кэше, чтобы стартовать с актуальной инфой.
Про workflow скиллы подробнее — в следующих постах :)
#claudecode #contextrot #configs
👍2
📖 LLM Wiki by Andrej Karpathy
Смотрите Gist
Новое веяние как можно подходить к работе с документацией, как личной так и для проектов разработки.
Разработка - при текущем активном росте кодовых баз более структурированно работать с информацией о проекте, обеспечивать быстрый поиск нужной информации, решений и т.п
Личная wiki - здоровье, отношения, развитие и т.д. , банально - взял краткую сводку по себе перед походом к врачу.
Суть: LLM берёт на себя поддержку wiki (наполнение, проверку, актуализацию)
Состоит из:
1. Сырые источники (неизменяемые)
2. Скомпилированная вики (markdown, которую создаёт и обновляет LLM)
3. Схема / конфиг — CLAUDE.md с правилами работы
Система накапливает синтезированное понимание, а не переоткрывает знания заного при каждом вопросе/сессии. Добавил новый Raw документ (источник) — LLM интегрирует его в wiki, обновляет перекрёстные ссылки, помечает противоречия.
Раньше было легко это все забросить, а сейчас благодаря LLM мы имеем возможность формировать такие вики, которые не ограничены вообще ничем.
В основном работа с raw через obsidian, удобно работать с документацией т.к множество плагинов для chrome, а также удобно смотреть графы.
Затем можно завернуть в скиллы Claude Code, масштабировать поиск и т.д
Как по мне - новый маст хэв. Подумайте о том, чтобы затащить такой подход в свои проекты и реализовать общекомандный подход по работе с readme / decisions и т.д с обеспечением быстрого и удобного поиска для любой LLM. А ещё можно и CLI забацать. Берите на заметку.
#claudecode #skills #workflows
Смотрите Gist
Новое веяние как можно подходить к работе с документацией, как личной так и для проектов разработки.
Разработка - при текущем активном росте кодовых баз более структурированно работать с информацией о проекте, обеспечивать быстрый поиск нужной информации, решений и т.п
Личная wiki - здоровье, отношения, развитие и т.д. , банально - взял краткую сводку по себе перед походом к врачу.
Суть: LLM берёт на себя поддержку wiki (наполнение, проверку, актуализацию)
Состоит из:
1. Сырые источники (неизменяемые)
2. Скомпилированная вики (markdown, которую создаёт и обновляет LLM)
3. Схема / конфиг — CLAUDE.md с правилами работы
Система накапливает синтезированное понимание, а не переоткрывает знания заного при каждом вопросе/сессии. Добавил новый Raw документ (источник) — LLM интегрирует его в wiki, обновляет перекрёстные ссылки, помечает противоречия.
Раньше было легко это все забросить, а сейчас благодаря LLM мы имеем возможность формировать такие вики, которые не ограничены вообще ничем.
В основном работа с raw через obsidian, удобно работать с документацией т.к множество плагинов для chrome, а также удобно смотреть графы.
Затем можно завернуть в скиллы Claude Code, масштабировать поиск и т.д
Как по мне - новый маст хэв. Подумайте о том, чтобы затащить такой подход в свои проекты и реализовать общекомандный подход по работе с readme / decisions и т.д с обеспечением быстрого и удобного поиска для любой LLM. А ещё можно и CLI забацать. Берите на заметку.
#claudecode #skills #workflows
Gist
llm-wiki
llm-wiki. GitHub Gist: instantly share code, notes, and snippets.
👏1
📰 Anthropic выпустила бесплатное 33-страничное руководство по созданию и тестированию скиллов.
Самый популярный язык программирования в 2026 ? Конечно же английский. Поэтому и руководство на нём же.
https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf
#claudecode #skills
Самый популярный язык программирования в 2026 ? Конечно же английский. Поэтому и руководство на нём же.
https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf
#claudecode #skills
👍1
📰 Обнова, Opus 4.7
Зовем: claude —update
Что интересно, по дефолту xHigh effort
https://www.anthropic.com/news/claude-opus-4-7
#claudecode #news
Зовем: claude —update
Что интересно, по дефолту xHigh effort
Opus 4.7 thinks more at higher effort levels, particularly on later turns in agentic settings. This improves its reliability on hard problems, but it does mean it produces more output tokens
https://www.anthropic.com/news/claude-opus-4-7
#claudecode #news
SKILL.md
5.1 KB
⚡️ Оптимизация расхода токенов Claude Code
Готовые и рабочие методы:
- /advisor режим , где opus - архитектор, sonnet исполнитель
- Сократить global/project/local CLAUDE.md через референсы. В теле должен быть только контекст, нужный всегда.
- Отключить не используемые MCP, каждый сервер засоряет контекст. Про замену на CLI уже писал.
- Отключить доступ на чтение dist, node_modules через permissions в settings.json
- уделяйте больше времени планированию, сократит лишние сообщения в процессе имплементации
- /clear это база , каждое новое сообщение тянет контекст предыдущих и потребляет все больше токенов
- На крайняк поиграться с env "BASH_MAX_OUTPUT_LENTH": "150000". По дефолту клод обрезает на 30-50к вывода, что приводит к потерям вывода.
Bonus: Skill для аудита контекста, добавляйте себе и проверяйте свои настройки
#claudecode #MCP #contextrot #configs #CLAUDE_MD
Готовые и рабочие методы:
- /advisor режим , где opus - архитектор, sonnet исполнитель
- Сократить global/project/local CLAUDE.md через референсы. В теле должен быть только контекст, нужный всегда.
- Отключить не используемые MCP, каждый сервер засоряет контекст. Про замену на CLI уже писал.
- Отключить доступ на чтение dist, node_modules через permissions в settings.json
- уделяйте больше времени планированию, сократит лишние сообщения в процессе имплементации
- /clear это база , каждое новое сообщение тянет контекст предыдущих и потребляет все больше токенов
- На крайняк поиграться с env "BASH_MAX_OUTPUT_LENTH": "150000". По дефолту клод обрезает на 30-50к вывода, что приводит к потерям вывода.
Bonus: Skill для аудита контекста, добавляйте себе и проверяйте свои настройки
#claudecode #MCP #contextrot #configs #CLAUDE_MD
⚡️ Лайфхак с рутинами для сдвига 5-часового окна сессии
Окно сессии в Claude Code начинает отсчет с первого сообщения (5 часовой отрезок).
Если начал в 9 утра — следующее обновление окна будет только в 14:00.
И зачастую бывает, что в самые удобные и активные часы может закончиться лимит по токенам.
Лайфхак: запустить рутину (в веб версии) на фиктивную мини-таску за 2-3 часа до начала рабочего дня.
Например в 6 утра запускаешь рутину, в 9 садишься за работу, при этом остается 2 часа окна с фулл лимитами по токенам.
#claudecode #workflows #contextrot
Окно сессии в Claude Code начинает отсчет с первого сообщения (5 часовой отрезок).
Если начал в 9 утра — следующее обновление окна будет только в 14:00.
И зачастую бывает, что в самые удобные и активные часы может закончиться лимит по токенам.
Лайфхак: запустить рутину (в веб версии) на фиктивную мини-таску за 2-3 часа до начала рабочего дня.
Например в 6 утра запускаешь рутину, в 9 садишься за работу, при этом остается 2 часа окна с фулл лимитами по токенам.
#claudecode #workflows #contextrot
🔥2
Итого сейчас имеем:
- 5ч лимит х2
- недельный лимит х2
- никаких ограничений по времени как раньше
Гуляем.
#claudecode #news
- 5ч лимит х2
- недельный лимит х2
- никаких ограничений по времени как раньше
Гуляем.
#claudecode #news
👏2