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

Что такое opencode и чем он отличается #

opencode — это интерактивный CLI-агент для помощи в программистских задачах. В отличие от Codex, он построен вокруг концепции скиллов — специализированных инструкций для конкретных типов задач — и MCP-серверов, которые дают агенту доступ к внешним инструментам без необходимости вручную выполнять команды.

В моём случае это не просто «чат с ИИ». Это инструмент, который:

• знает контекст моих проектов через Obsidian Volt;
• умеет работать с Hugo-блогом напрямую через MCP-сервер hugo;
• может искать информацию через SearXNG;
• умеет управлять заметками, тегами и структурой хранилища.

Главное отличие от Codex: опencode — это не привязка к одной модели, а оболочка, которая может работать с разными бэкендами и расширениями через скиллы и MCP 🔌

Модель под капотом: Qwen3.6-35B-A3B-MLX-6bit #

За опencode в текущей сессии отвечает модель Qwen3.6-35B-A3B-MLX-6bit. Разберём, что это значит на практике.

Qwen3.6 — это семейство моделей от Alibaba Group, третье поколение архитектуры Qwen. Модель позиционируется как одна из лучших в классе open-weight моделей с 35 миллиардами параметров.

35B-A3B — интересная архитектура. 35 миллиардов параметров, из которых активными при каждом проходе используется только ~3 миллиарда. Это Mixture-of-Experts (MoE) подход: модель активирует только нужные «экспертные» подсети для каждой задачи, что даёт скорость приближенную к гораздо меньшим моделям при качестве, сопоставимом с моделями в несколько раз большего размера.

MLX — это фреймворк от Apple для запуска LLM на чипах Apple Silicon. MLX оптимизирует загрузку и выполнение моделей на M-сериях процессоров, обеспечивая эффективное использование unified memory.

6bit — модель квантована до 6-битной точности. Это компромисс: при значительном уменьшении размера модели (примерно в 4 раза по сравнению с FP16) потери качества минимальны для большинства задач. Для написания текстов и работы с кодом 6-битная квантованная модель работает практически неотличимо от полной.

Почему это важно для написания постов. Модель достаточно ёмкая (35B total, 3B active), чтобы работать с длинными контекстами и сохранять логическую связность текста. Но при этом она runs locally на моей Mac-машине — никаких API-лимитов, задержек сети или отправки данных на сторону.

Инструменты и MCP-серверы #

Вот что подключено к opencode в ходе работы над этим постом:

Hugo MCP-сервер #

Позволяет агенту работать с Hugo-сайтом напрямую: проверять установку, список контента, собирать сайт, запускать локальный сервер. Это избавляет от необходимости вручную выполнять hugo list, hugo --minify — агент делает это через инструмент.

Obsidian MCP-сервер #

Дает доступ к моему Vault (~/temp/git.evgn.ru/obsidian/vault/) — это хранилище всех заметок, проектов и знаний. Через него агент:

• читает профиль проекта Projects/Блог (Hugo).md;
• смотрит правила написания постов;
• проверяет структуру и форматирование существующих статей.

SearXNG MCP-сервер #

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

Скиллы #

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

• impeccable — аудит и улучшение frontend-интерфейсов;
• infra-audit — аудит self-hosted сервисов;
• himalaya-inbox-cleaner — чистка почтового ящика;
• memory-consolidate и memory-patcher — управление долгосрочной памятью;
• unified-search — универсальный поиск по всем источникам;
• obsidian-vault-mcp — работа с Obsidian.

Рабочий процесс: как создаётся пост #

Процесс создания этого поста прошёл через несколько этапов, каждый из которых агент выполнял автономно:

1. Изучение контекста #

Первое, что сделал opencode — загрузил профиль проекта из Obsidian. Это заняло пару секунд: чтение Projects/Блог (Hugo).md и References/Управление блогом через MCP Hugo.md. Модель получила полную картину: структуру репозитория, правила постов, CI/CD-процесс, технический стек.

2. Анализ существующих постов #

Агент прочитал несколько предыдущих статей, чтобы понять стиль и формат. Особенно важен пост «Пишем посты с Codex» — он задаёт тон для материалов об автоматизации. Также был изучён релизный пост про Hugo 0.164.0 — это референс для технической глубины и структуры.

3. Проверка актуальности #

Агент определил текущее время (МСК, 12:19) и сгенерировал дату поста 2026-07-21T12:14:00+03:00 — на 5 минут в прошлом, как требуют правила. Это важно: пост не должен оказаться в future, иначе CI его не опубликует.

4. Написание текста #

Самая сложная часть. Агент сгенерировал текст, опираясь на:

• правила из AGENTS.md (русский язык, минимум 2 эмодзи, структура с разделами);
• знание модели (Qwen3.6-35B-A3B-MLX-6bit, MoE, MLX, 6bit);
• контекст из Obsidian (правила фронтматтера, теги, toc);
• личный опыт автора (реальные инструменты, репозитории, инфраструктура).

Текст разделён на смысловые блоки: введение, описание модели, инструменты, рабочий процесс. Каждый раздел содержит конкретные детали, а не общие фразы.

5. Техническая валидация #

После написания текста агент проверил фронтматтер: формат даты, tags (взял из существующих постов), toc/readTime enabled. Summary и description — разные, без дублирования.

6. Публикация #

Финальный шаг — git commit и git push в ветку main. После этого CI/CD через Forgejo Actions автоматически соберёт сайт, проиндексирует поиск Pagefind и деплоит через rsync на сервер.

Что работает хорошо, а что — нет #

Сильные стороны #

• Контекстная осведомлённость. Агент читает Obsidian и знает о проекте больше, чем «чистый» LLM-чат.
• Автоматизация рутины. Фронтматтер, дата, теги, проверка future-дат — всё это агент делает сам.
• Локальность. Модель работает на Mac, данные не покидают машину. Это важно для приватности и скорости.
• Скиллы. Специализированные инструкции позволяют агенту быстро переключаться между задачами: сегодня пишет пост, завтра чистит почту.

Слабые места #

• Стиль. Текст агента иногда слишком «структурирован» — разделы идут как по шаблону, без естественных отклонений. Авторская редактура важна не для «исправления ошибок», а для добавления живости.
• Глубина технических деталей. Агент знает, что модель называется Qwen3.6-35B-A3B-MLX-6bit, но может ошибиться в архитектурных нюансах. MoE — это Mixture of Experts, а не какая-то абстрактная физика: агент описывает её на основе общих паттернов, а не реального опыта.
• Эмоциональная тональность. Агент хорошо справляется с информационным содержанием, но тон текста часто остаётся «нейтрально-аналитическим». Авторская правка добавляет иронию, личные наблюдения, интонацию.

Почему это вообще имеет смысл #

Главный вопрос: зачем писать пост об ИИ, который пишет посты?

Потому что это не новый способ «генерации контента». Это новый способ разделения труда.

Автор остаётся там, где он уникально полезен:

• формулирует идею и позицию;
• добавляет личный опыт и фактуру;
• контролирует логику аргументации;
• решает, что стоит рассказать, а что — нет.

Агент берёт на себя:

• поиск и структурирование контекста;
• черновую сборку текста из тезисов;
• техническое оформление (фронтматтер, теги, форматирование);
• валидацию перед публикацией.

Результат — не «ИИ написал статью», а «автор написал статью быстрее и увереннее, потому что инструмент снял операционную нагрузку».

Сравнение с Codex: два инструмента, разные роли #

Codex и opencode — это не конкуренты, а взаимодополняющие инструменты. Вот как они отличаются в моём рабочем процессе:

Codex лучше подходит для сложных задач, где нужна максимальная «интеллигентность» — анализ архитектуры, написание кода, глубокие рассуждения. opencode — для задач, где важна скорость, локальность и работа с известным контекстом.

Для блога opencode сейчас работает лучше: он знает правила, структуру и стиль проекта через Obsidian, и не требует API-доступа.

Итог 🧠 #

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

1. Идея — от автора.
2. Контекст — агент собирает из Obsidian и репозитория.
3. Черновик — агент собирает из тезисов и контекста.
4. Редактура — автор добавляет фактуру, иронию, личный опыт.
5. Техника — агент оформляет фронтматтер, проверяет дату, делает commit/push.
6. Деплой — CI/CD собирает и публикует.

Модель Qwen3.6-35B-A3B-MLX-6bit — хороший выбор для этого: достаточно ёмкая для понимания контекста, достаточно быстрая для итеративной работы, достаточно локальная для приватности.

А opencode — это не просто «ещё один ИИ-ассистент». Это инструмент, который объединяет модель, скиллы и MCP-серверы в единый рабочий процесс. И для блога на Hugo это сейчас оптимальная комбинация: быстро, локально, с полным знанием контекста.

Источники #

• Qwen3.6: Alibaba Group — Qwen
• MLX: Apple MLX
• opencode: opencode.ai

С прошлого разбора прошёл ровно месяц: 0.163.3 вышел 18 июня, 0.164.0 — 6 июля. После «квартала инфраструктурного взросления» с AVIF и хардненингом этот релиз выглядит скромнее: одна минорная версия, никаких громких фич.

Но два пункта в нём заслуживают внимания:

1. Стили Chroma получили dark/light-пары. Подсветка кода наконец умеет жить в двух темах штатно, а не через самодельные костыли.
2. Починена регрессия производительности, тянувшаяся с 0.128.0. Это не новая фича, а возврат утраченного — но на больших сайтах разница заметна.

Остальное — приятные мелочи в шаблонных функциях и один депрекейт. Breaking changes как таковых нет, обновление спокойное.

Главное за один взгляд #

Фичи:

• Dark/light-пары в стилях Chroma — подсветка синтаксиса умеет два режима; у команды hugo gen chromastyles появились новые флаги.
• Новые шаблонные функции: crypto.Hash, encoding.HexEncode, encoding.HexDecode.
• Опция markup.rst.syntaxHighlight — подсветка для reStructuredText.
• Поддержка цитат в Pandoc — для тех, кто держит библиографию.
• Вложенные пути в layouts для Page.Render.
• Фикс регрессии производительности из 0.128.0 — обсуждение на Discourse тянулось долго.

Депрекейт:

• resources.PostProcess объявлен устаревшим в пользу templates.Defer (issue #15086).

Мелочи, которые могут задеть:

• Поиск имени шаблона стал регистронезависимым (#15057).
• .Render теперь возвращает ошибку, если шаблон не найден (#15052) — раньше молча отдавал пустоту.
• IsSet включает ключ в предупреждение о неподдерживаемом типе.

Dark/light в Chroma 🌗 #

Главная фича релиза — и, пожалуй, самая недооценённая.

Раньше стиль подсветки в Hugo был один на весь сайт: в hugo.toml задавался markup.highlight.style, и всё. Если сайт умеет переключаться между светлой и тёмной темой, приходилось выкручиваться: генерировать два CSS-файла через hugo gen chromastyles, руками оборачивать их в медиа-запросы или классы, следить за синхронизацией.

Теперь Chroma внутри Hugo знает про парные режимы, а у hugo gen chromastyles появились флаги для генерации нужного варианта. Смысл простой: светлая и тёмная схемы подсветки — это не два несвязанных стиля, а пара, и Hugo теперь так к ним и относится.

Что это значит для нашего блога. Прямое попадание. Переключатель дня и ночи здесь работает на JS с сохранением выбора в localStorage — то есть тема меняется без перезагрузки, и подсветка кода должна меняться вместе с ней. Сейчас в конфиге один [markup.highlight] на оба режима, и в тёмной теме блоки кода выглядят компромиссно. Это следующий пункт в списке доработок: сгенерировать пару стилей и подцепить их к тому же переключателю. В этот заход не делаю — обновление и так вышло насыщенным, — но фича переехала из «знать» в «внедрять».

Регрессия производительности: возврат утраченного ⚡ #

Незаметная, но приятная часть. В 0.128.0 (это июль 2024-го) в сборку просочилась регрессия, из-за которой большие сайты собирались медленнее. Симптом обсуждали на Discourse больше года, и вот в 0.164.0 его закрыли.

Ремарка из release notes честная: эффект заметен в первую очередь на крупных сайтах. Наш блог — около сотни страниц, и на таком объёме разница в пределах шума. Но сама история поучительна: регрессия прожила полтора года и полтора десятка релизов, потому что на маленьких сайтах её просто не видно.

Новые функции: crypto.Hash и hex 🔧 #

Три новые шаблонные функции:

{{ crypto.Hash "sha256" "текст" }}
{{ encoding.HexEncode "привет" }}
{{ encoding.HexDecode "d0bfd180d0b8d0b2d0b5d182" }}

crypto.Hash принимает алгоритм явным параметром — удобнее, чем существующие md5/sha1/sha256 по отдельности. Практический сценарий — стабильные идентификаторы: захешировать путь или содержимое и получить детерминированный ключ для кэша, якоря или имени файла.

Hex-функции закрывают давнюю мелочь: base64 в шаблонах был, а hex приходилось изображать вручную.

Для нашего блога — пока в копилку. Ни одного места, где это было бы нужно прямо сейчас, нет.

Депрекейт resources.PostProcess ⚠️ #

Единственное, за чем стоит следить.

resources.PostProcess использовался для отложенной обработки ресурсов — классический сценарий — PurgeCSS/Tailwind, когда нужно узнать финальный HTML, чтобы вычистить неиспользуемые классы. Теперь рекомендуется templates.Defer, механизм более общий и предсказуемый.

Нас не задевает: проверил layouts/ и themes/ — resources.PostProcess не используется нигде. CSS через Hugo Pipes с Tailwind мы не собираем, а Pagefind живёт отдельным npm-инструментом и к ресурсной цепочке отношения не имеет.

Если у вас Tailwind в Pipes — это первое, что нужно проверить перед обновлением: депрекейт пока не ломает, но направление задано.

Осторожно: .Render теперь возвращает ошибку #

Мелочь из списка изменений, которая может неприятно удивить. Раньше .Render с несуществующим шаблоном молча отдавал пустую строку — и сайт собирался, просто без куска контента. Теперь он возвращает ошибку, то есть сборка упадёт.

Формально это исправление, а не breaking change: молчаливая пустота — плохое поведение. Но если у вас в шаблонах есть вызов .Render с опечаткой в имени, который «работал» годами, — обновление его вскроет. Заодно поиск имени шаблона стал регистронезависимым, так что часть таких опечаток теперь, наоборот, начнёт находиться.

Инфраструктура: заодно поменяли базу образа 🐳 #

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

Блог собирается в собственном Docker-образе, куда запечены Hugo Extended, Node и Pagefind. Пошёл поднимать версию Hugo — и обнаружил, что база образа node:20-bookworm-slim достигла EOL 30 апреля 2026. То есть почти три месяца образ жил без обновлений безопасности базового слоя.

Node здесь нужен ровно для одного — установить Pagefind. Поэтому смена мажора малорискованная, и база переехала сразу на Node 24 (LTS, поддержка до апреля 2028). Итоговый образ:

hugo v0.164.0+extended linux/amd64
node v24.18.0
pagefind 1.5.2

Мораль простая и не новая: следите не только за приложением, но и за базовым слоем. Версию Hugo видно в каждом релизном посте, а FROM node:20 тихо стареет в первой строке Dockerfile, пока про него не вспомнишь.

Отдельная заметка на будущее — образ до сих пор собирался руками, поэтому и отстал. Правильный путь: собирать его в CI при изменении Dockerfile. У сборки на нашем раннере есть нюанс — он живёт в LXC-контейнере, где docker build не может применить AppArmor к промежуточным RUN-контейнерам и падает. Обходится это kaniko: он собирает образ в userspace, без демона Docker и вложенных контейнеров. Тот же приём уже используется для других наших образов.

Что это значит для нашего блога #

• Chroma dark/light — самая полезная фича релиза именно для нас, ложится на существующий переключатель темы. В работу.
• Фикс производительности — приятно, но на сотне страниц незаметно.
• Депрекейт PostProcess — не задевает, проверено.
• .Render с ошибкой — не задевает, но стоит держать в голове.
• Обновление базы образа с Node 20 на Node 24 — по факту важнее самого апдейта Hugo.

Чек-лист обновления ✅ #

1. Обновление спокойное. С 0.163.x на 0.164.0 идти можно без подготовки: breaking changes нет, депрекейт один.

2. Если используете resources.PostProcess (обычно это Tailwind/PurgeCSS в Pipes) — запланируйте переход на templates.Defer:

   grep -rn 'resources.PostProcess' layouts/ themes/

   copy

3. Если в шаблонах есть .Render — проверьте имена шаблонов: теперь несуществующий шаблон роняет сборку, а не молчит.

4. Если у сайта есть тёмная тема — посмотрите на парные стили Chroma, это заметное упрощение по сравнению с самодельными решениями.

5. Проверьте базовый слой сборочного образа, а не только версию Hugo. Node 20 в EOL с 30 апреля 2026:

   grep -n '^FROM' Docker/Dockerfile

   copy

6. Стандартный прогон и сверка предупреждений до и после:

   hugo --minify --gc

   copy

Итог 🧠 #

0.164.0 — релиз-передышка после насыщенного квартала. Одна по-настоящему полезная фича (парные стили Chroma), одно давно ожидавшееся исправление (регрессия скорости из 0.128.0), горсть новых шаблонных функций и один аккуратный депрекейт.

Обновляться стоит: рисков практически нет, а dark/light-подсветка снимает целый класс костылей для сайтов с переключателем темы.

Но главный вывод этого обновления оказался не про Hugo. Версию генератора видно в каждом релизном посте, а базовый слой образа стареет молча — и именно он оказался просроченным на три месяца, а не Hugo, отставший на одну минорную версию.

Источники #

• Релиз 0.164.0: gohugoio/hugo v0.164.0
• Режимы стилей подсветки: gohugo.io/quick-reference/syntax-highlighting-styles/#modes
• crypto.Hash: gohugo.io/functions/crypto/hash/
• encoding.HexEncode: gohugo.io/functions/encoding/hexencode/
• Обсуждение регрессии производительности: discourse.gohugo.io
• График поддержки Node.js: endoflife.date/nodejs

С прошлого разбора (v0.160.1, 8 апреля) накопилось пять релизов: 0.161.0, 0.161.1, 0.162.0, 0.163.0 и патчи до 0.163.3 (18 июня). Это не один минор, а целый квартал развития — поэтому разбор догоняющий.

Если сжать до двух заголовков, их два:

1. AVIF — Hugo научился кодировать и декодировать AVIF прямо в image pipeline. Третий формат рядом с JPEG и WebP, и для фото-блога это самое интересное.
2. Хардненинг безопасности — Node-инструменты теперь запускаются с --permission, text/html-контент запрещён по умолчанию, ужесточены security.http.urls, плюс транзитом приехали XSS-фиксы из Go 1.26.3.

Остальное — приятные улучшения конфигурации (slice-based permalinks, гибкие идентификаторы в именах файлов, вложенные vars в css.Build) и порция депрекейтов. Breaking changes есть, но точечные — разберём, кого они задевают.

Главное за один взгляд #

v0.161.0 / 0.161.1 (28–29 апреля) — фичи + первый хардненинг:

• Node-инструменты (PostCSS, Babel, TailwindCSS) запускаются с флагом --permission. Нужен Node ≥ 22, а Tailwind теперь только как npm-пакет (standalone-бинарь больше не поддерживается).
• Ужесточены дефолты security.http.urls; добавлен security.node.permissions (включая AllowChildProcess).
• Slice-based permalinks — конфигурация permalinks с target-матчерами (как в cascade).
• Гибкая схема идентификаторов в именах файлов: _language_en_, _role_, _version_.
• Вложенные vars в css.Build / css.Sass: @import "hugo:vars/dark".

v0.162.0 / 0.162.1 (26–28 мая) — AVIF + security:

• 🎯 Поддержка AVIF (encoder + decoder) в image pipeline.
• text/html-контент запрещён по умолчанию — новая политика security.allowContent.
• Go 1.26.3: фиксы XSS в html/template (CVE-2026-39826, CVE-2026-39823).
• Проверка security.http.urls на каждом редирект-хопе resources.GetRemote; отказ от symlink-записей в resources.Get.

v0.163.0 (8 июня) — тюнинг AVIF + депрекейты:

• AVIF по умолчанию quality = 60 (≈ JPEG/WebP q75), content-aware chroma subsampling через hint, качество настраивается per-format.
• Депрекейт глобального imaging.quality и Imaging.Compression (переезжают в per-format конфиги).
• Добавлен .IsBranch, депрекейт .IsNode; депрекейт baseUrl в jsconfig.

v0.163.1 / 0.163.2 / 0.163.3 (11–18 июня) — патчи:

• Security: bump golang.org/x/image, нормализация integer-IPv4 в http.urls, отказ от symlink в os.ReadDir/ReadFile/Stat/FileExists.
• Escape lang в дефолтном рендере код-блоков; сохранение non-ASCII пробела после summary-разделителя; поддержка вариантов конфигов babel/postcss; фикс регрессии коллизии имён page/section.

Дальше — что это значит на практике.

AVIF: третий формат в pipeline 🖼️ #

Главная фича квартала. В 0.162.0 Hugo получил полноценную обработку AVIF — и кодер, и декодер (issue #7837, висел с 2020 года). AVIF при том же визуальном качестве заметно легче JPEG и обычно легче WebP, плюс умеет HDR (у Hugo есть демо-сайт, который имеет смысл смотреть на HDR-экране вроде Retina).

В 0.163.0 фичу довели до ума:

• Дефолтный quality для AVIF опустили до 60 — оказалось, JPEG/WebP с q75 сопоставимы с AVIF q60. Не гоните качество вверх по привычке.
• Появился hint (как у WEBP): для lossy фото по умолчанию используется YUV420 chroma subsampling, а для текста/иконок/схем — 444. Это резко снижает память на кодирование больших картинок.
• Качество можно задавать на формат:

[imaging]
  # глобальный quality теперь deprecated
[imaging.webp]
  quality = 80
[imaging.avif]
  quality = 60
  hint    = "photo"

В шаблоне AVIF получается так же, как WebP — через .Process / метод ресайза:

{{ $img := resources.Get "img/cover.jpg" }}
{{ $avif := $img.Process "resize 1600x avif" }}
<picture>
  <source srcset="{{ $avif.RelPermalink }}" type="image/avif">
  <source srcset="{{ ($img.Process "resize 1600x webp").RelPermalink }}" type="image/webp">
  <img src="{{ ($img.Resize "1600x").RelPermalink }}" alt="…">
</picture>

Что это значит для нашего блога. Раздел /photos уже генерит 800/1600/2400 px в JPEG + WebP и отдаёт через <picture>/srcset. Добавить AVIF — это правка шаблона, который собирает <source>-ы (плюс per-format quality в hugo.toml): первым <source type="image/avif">, дальше WebP, в конце JPEG-фолбэк. Браузеры берут первый поддерживаемый. На фотографиях с retina это даст ощутимую экономию трафика при том же качестве. В этот заход не делаю — но это очевидный следующий шаг для фото-ленты.

Хардненинг безопасности 🔒 #

Самая «breaking» часть. Изменения копились через все релизы:

Node-инструменты под --permission (0.161.0). PostCSS, Babel и TailwindCSS теперь запускаются с Node permission-флагом и правами из security.node.permissions. Следствия:

• нужен Node ≥ 22;
• css.TailwindCSS требует Tailwind CLI как npm-пакет — standalone-бинарь больше не годится.

Если вы собираете CSS через Hugo Pipes с Tailwind/PostCSS — это первое, что стоит проверить перед обновлением.

Запрет text/html-контента по умолчанию (0.162.0). Новая политика security.allowContent гейтит, какие media-типы допустимы для страниц в /content. text/html теперь запрещён по умолчанию. Сайты, где есть руками написанные .html-файлы в content/ (или их эмитит content adapter), вернут доступ явно:

[security]
  allowContent = ['.*']

Прочее (0.162.0 → 0.163.3):

• security.http.urls перепроверяется на каждом редирект-хопе в resources.GetRemote — мимо валидации больше не проскочить через 30x.
• Symlink-записи отклоняются в resources.Get, а в 0.163.1 — ещё и в os.ReadDir/ReadFile/Stat/FileExists.
• Go подняли до 1.26.3 с фиксами XSS в html/template (CVE-2026-39826, CVE-2026-39823) — это касается любого сайта, рендерящего недоверенный ввод в шаблонах.

Любопытная ремарка от мейнтейнера в release notes 0.163.1: всплеск security-репортов в последнее время — это не «Hugo стал менее безопасным», а работа новых AI-инструментов, которые берут security-модель Hugo за baseline и методично её простукивают.

Slice-based permalinks 🔗 #

В 0.161.0 конфигурация permalinks стала гибче (старая map-форма продолжает работать). Теперь это список с теми же target-матчерами, что и в cascade:

permalinks:
  - target:
      kind: page
      path: "/books/**"
    pattern: /books/:year/:slug/
  - target:
      kind: page
    pattern: /other/:slug/

Удобно, когда для разных секций нужны разные схемы URL без дублирования настроек. Нашему блогу с плоской структурой posts/ это пока избыточно, но знать про механизм полезно — особенно если когда-нибудь заведём разделы со своими правилами URL.

Гибкие идентификаторы в именах файлов 🏷️ #

Тоже из 0.161.0. Раньше язык кодировался как mypost.en.md. Теперь доступна расширяемая схема префиксов в имени файла:

content/mypost._language_en_.md эквивалентно content/mypost.en.md, но открывает дорогу к версиям и ролям контента. Для одноязычного блога — мимо, для документации с версиями — заметное упрощение.

css.Build: вложенные vars 🎨 #

Развитие фичи из 0.160. К @import "hugo:vars" добавились вложенные наборы — @import "hugo:vars/<name>". Классический сценарий — палитры под prefers-color-scheme:

[params.style]
  primary    = "#000000"
  background = "#ffffff"
  [params.style.dark]
    primary    = "#ffffff"
    background = "#000000"

@import "hugo:vars";
@import "hugo:vars/dark" (prefers-color-scheme: dark);

Аккуратно, но не для нас: переключатель дня/ночи на блоге работает через JS и localStorage (явный выбор пользователя, без авто), а не через prefers-color-scheme. Палитра живёт в :root. Так что фича в копилку «знать», но не «внедрять».

Депрекейты и мелочи #

• .IsNode → .IsBranch (0.163.0): если в шаблонах есть .IsNode, мигрируйте на .IsBranch (issue #11574).
• Глобальный imaging.quality (0.163.0): помечен deprecated в пользу per-format ([imaging.webp], [imaging.avif], …). Старая форма пока работает и даже не всегда ругается — но направление задано.
• jsconfig baseUrl убран (был deprecated).
• Сохранение non-ASCII пробела после summary-разделителя (0.163.3) — мелочь, но именно для кириллических текстов с `

` это правильное поведение.

• Фикс коллизии имён page/section (0.163.3, #15046) — регрессия, всплывшая в 0.163.x; ещё одна причина брать самый свежий патч, а не 0.163.0.

Что это значит для нашего блога #

Прогнал блог на 0.163.3 — собирается чисто, 90 страниц, 0 ошибок, 52 изображения обработаны без проблем. Конкретика:

• Запрет text/html нас не задел — в content/ нет руками-сверстанных .html, всё в Markdown. security.allowContent трогать не нужно.
• Node-permission мимо — Tailwind/PostCSS через Pipes не используем, Pagefind живёт отдельным npm-инструментом.
• languageCode → locale: попутно почистил deprecation в hugo.toml (languageCode = 'ru-RU' → locale = 'ru-RU'). Этот warning ушёл. Оставшиеся три (.Site.LanguageCode, .Language.LanguageCode, .Language.Direction) приходят из шаблонов темы typo — уйдут, когда обновится тема.
• AVIF — главная зацепка на будущее: добавить третий <source> в фото-pipeline и срезать вес ленты /photos.

Чек-лист обновления ✅ #

1. Прыгайте сразу на 0.163.3, а не на 0.163.0 — патчи .1/.2/.3 закрывают security-дыры и регрессию коллизии имён.

2. Если собираете CSS через Tailwind/PostCSS/Babel в Pipes — поставьте Node ≥ 22 и Tailwind как npm-пакет; проверьте security.node.permissions.

3. Если в content/ есть .html-файлы — добавьте security.allowContent = ['.*'], иначе страницы выпадут из сборки.

4. Почистите депрекейты:

   # languageCode → locale в конфиге
   # .IsNode → .IsBranch в шаблонах
   grep -rn '\.IsNode' layouts/ themes/

   copy

5. Если работаете с изображениями — присмотритесь к AVIF и per-format quality; глобальный imaging.quality уводите в [imaging.<format>].

6. Стандартный прогон и сверка warning’ов до/после:

   hugo --minify --gc

   copy

Итог 🧠 #

0.161–0.163 — это квартал «инфраструктурного взросления» Hugo: новый формат изображений (AVIF), методичный security-хардненинг и более гибкая конфигурация (permalinks, идентификаторы файлов, вложенные CSS-vars). Громкая фича ровно одна — AVIF; всё остальное либо про безопасность, либо про удобство.

Breaking changes реальны, но адресные: они бьют по сайтам с Tailwind-в-Pipes и с HTML-контентом в content/. Если вы (как наш блог) пишете на чистом Markdown и не гоняете Node-сборку CSS — переход бесшовный, достаточно поднять версию и пробежаться по депрекейтам.

Если сидите на 0.160 или раньше — есть смысл прыгать сразу на 0.163.3, мимо промежуточных: так вы заодно получите все security-фиксы одним движением.

Источники #

• Релиз 0.161.0: gohugoio/hugo v0.161.0
• Релиз 0.162.0: gohugoio/hugo v0.162.0
• Релиз 0.163.0: gohugoio/hugo v0.163.0
• Релиз 0.163.3: gohugoio/hugo v0.163.3
• Конфигурация AVIF: gohugo.io/configuration/imaging/#avif
• Security-модель Hugo: gohugo.io/about/security/

Если ты когда-нибудь просил AI-помощника (Claude, ChatGPT, Cursor) сделать тебе сайт, ты замечал одно и то же: получается вроде неплохо, но подозрительно «как у всех». Тёмно-синий фон, фиолетовый градиент в заголовке, карточки с лёгкой тенью, шрифт Inter. Узнаваемый «AI-look».

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

Impeccable от Paul Bakaus решает именно эту задачу. Сам автор позиционирует его как «дизайн-словарь для AI-помощников по коду»: набор из одного навыка и 23 команд, которые дают AI и человеку общий понятийный аппарат. Каждая команда отвечает за свою дизайн-дисциплину: типографика, цвет, ритм пространства, взаимодействия, копирайтинг, элевация (тени и слои), анти-паттерны. Плюс отдельный список из 25 типичных «AI-ляпов», которые детектор ловит автоматически.

Что важно: impeccable — не библиотека CSS-токенов и не редактор макетов. Он живёт в твоём боевом коде, читает существующие исходники, рендеренный HTML, дизайн-документы, и вместе с AI правит то, что уже есть. Не «нарисуй мне сайт с нуля», а «доведи существующий до состояния, в котором он перестанет быть похожим на любой другой блог».

Я взялся применить это к собственному Hugo-блогу. Hugo — статический генератор сайтов: ты пишешь посты в Markdown, конфиг и HTML-шаблоны, он собирает готовые HTML-файлы. Дизайн жил в одном CSS-файле плюс тема typo как git submodule. К апрелю накопилось ощущение «работает, но как-то не так». Тёмная тема жила в одной палитре, светлая — местами в другой. Страница «Обо мне» выглядела как кусочек чужого SaaS-сайта, попавший в блог по ошибке.

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

Фундамент: PRODUCT.md и DESIGN.md #

Первая команда — /teach. Это не «настройки», а короткое интервью: кому пишешь, каким голосом, чем не должен быть сайт, какие требования к доступности. На выходе два файла в корне проекта:

• PRODUCT.md — стратегический документ. Регистр (бренд или продукт), целевая аудитория, голос, анти-референсы, дизайн-принципы, планка доступности.
• DESIGN.md — визуальная спецификация. Цвета, шрифты, шкала пространства, шкала радиусов, компоненты.

Эти два файла потом читает каждая последующая команда. Без них любой /audit или /polish даёт ответы вообще, не привязанные к конкретному проекту.

Главное открытие здесь — раздел анти-референсов. PRODUCT.md заставляет ответить, чем сайт не должен быть. Я выписал четыре конкретных образца, которые не хочу повторять:

• Habr и VC.ru с их боковыми панелями, бейджами и блоками «читайте также» на пять экранов;
• Medium и Substack: безликий шаблон платформы, попап «подпишись», где ощущение «это любой блог»;
• современный SaaS с градиентами и стеклянными карточками;
• Dev.to и обычные GitHub Pages: стандартный markdown без типографики, синие ссылки, sans-serif, ноль характера.

Анти-референсы оказались полезнее обычных «делай как Stripe». «Как Stripe» — растяжимое: можно повторить любой кусок и сказать «вот видишь, похоже». «Не как Habr» — конкретный отказ. Каждое следующее дизайн-решение проверялось по этому списку и часто не проходило: «а не повторяю ли я сейчас Habr-ленту одинаковых превью?»

Дальше команда /document отсканировала существующий CSS и собрала DESIGN.md. Здесь я первый раз ошибся — но об этом дальше.

Аудит: 11 из 20 на старте 📊 #

/audit — техническая проверка по пяти направлениям, каждое от 0 до 4 баллов: доступность, производительность, согласованность дизайн-токенов, адаптивность, отсутствие шаблонных AI-ляпов.

Финальная оценка моего блога — 11 из 20. Между «нормально, но работы много» и «плохо». От «плохо» вытащило только производительность (Hugo и так быстрый, картинки грузятся лениво, шрифты с правильной стратегией загрузки).

Что нашлось:

Контраст вторичного текста проваливал стандарт WCAG AA в обеих темах. Цвет #6272a4 на светлом фоне #f8f8f2 давал соотношение контраста 3.92:1, на тёмном #282a36 — 3.33:1. Стандарт WCAG AA требует минимум 4.5:1 для основного текста. Эта переменная использовалась одновременно как цвет вторичного текста, как цвет ссылок в светлой теме и как мета-информация. Поражено больше 40% не-основного контента сайта.

Страница поиска в светлой теме выдавала белый текст на белом фоне. В моём CSS заголовки результатов поиска имели цвет #f8f8f2 (захардкожен под тёмную тему). На светлой теме фон тоже #f8f8f2 — белый на белом. Я этого не замечал, потому что почти всегда сижу в тёмной теме. Половина посетителей видела пустые результаты поиска полтора года.

Страница «Обо мне» — типичный SaaS-клон. Шрифт Inter (один из самых заезженных AI-выборов), фон с линейным градиентом, тяжёлая тень под аватаром. Все четыре анти-референса из PRODUCT.md в одном экране.

Кликабельные элементы меньше 44 на 44 пикселей. Кнопка переключения темы — 32–35 пикселей. У ссылок в навигации не было внутренних отступов, кликабельная зона = площадь самого текста. Стандарт WCAG 2.1 рекомендует минимум 44×44 для тача и моторной доступности.

У цитат border-left в 2 пикселя. Эта самая полоска слева у «цитаты». В философии impeccable любая боковая полоска шире 1 пикселя — отдельный анти-паттерн (типичный «callout-style» из старых книг по веб-дизайну).

Семь крупных проблем плюс несколько помельче. Чинилось всё в одном проходе: подняли цвет вторичного текста до читаемого, переписали страницу «Обо мне» с нуля без шрифта Inter и градиентов, сделали все статусы reading-секции чувствительными к теме, расширили кликабельные зоны. После — оценка поднялась до 18 из 20.

Без /audit я бы половину этих проблем не нашёл. Особенно поиск в светлой теме: я не садился в светлую тему вживую неделями.

UX-ревью и кейс с фиктивным компонентом #

Дальше — /critique. Это уже не технический аудит, а ревью на уровне дизайн-решений: правильно ли устроена главная как точка входа, не теряется ли пост в ленте, нужен ли архив-по-годам, есть ли узкие места в навигации.

Команда устроена так, что запускает два независимых ревью одновременно. Один — отдельный AI-агент с фокусом на пользовательский опыт; читает исходники и рендеренный HTML. Второй — программный детектор npx impeccable --json, проверяющий 25 конкретных шаблонных AI-ляпов автоматически. И ключевое: они не видят выводы друг друга. Это сделано специально — чтобы один не подтверждал догадки другого.

Я к этому отнёсся скептически. Думал, что изоляция «для красоты».

Оказался неправ.

Отдельный AI-агент за пять минут нашёл вот что: в моей же DESIGN.md, которую я сам написал часом ранее, описан боковой sticky-блок «Содержание» как одна из ключевых деталей сайта. Подробно: фиксированное позиционирование, ширина 260 пикселей, рамка, скругление, размеры ссылок, активное состояние. И сразу следом: «один из главных компонентов сайта; обслуживает чтение длинных постов вторым по важности после самого текста».

А в layouts/_default/single.html (мой собственный шаблон страницы поста) этого блока нет. Поиск по проекту: ноль вхождений toc-sidebar, toc-sticky, TableOfContents. Только 190 строк CSS-стилей, который никем не используется, потому что HTML-разметку никто не выводит. Документация описывала то, чего на сайте не было.

Что произошло: при первом проходе /document я смотрел в CSS, увидел проработанный sticky-блок и описал его в DESIGN.md как рабочий компонент. Не проверил, что в шаблонах кто-то этот класс выводит. CSS живёт, разметки нет — а я этого не заметил, потому что неудобно увидеть, что я только что подробно описал то, чего не существует.

Это та самая «слепая зона», когда видишь в собственной работе только то, что её подтверждает. Я писал код, я писал документацию по этому коду. Свою же работу мне «удобно» считать согласованной.

Отдельный AI-агент в /critique не видел ни моих рассуждений по команде /document, ни моей DESIGN.md как авторитетного источника. Он читал её как один из файлов проекта. И тут же подсветил расхождение: «sticky TOC задокументирован как ключевой элемент, не рендерится ни на одной странице».

Этот один пункт окупил весь подход с двумя независимыми ревью. Я зашил это в персональную память Claude Code как правило: прежде чем называть компонент ключевым в DESIGN.md, надо проверить, что он действительно рендерится в шаблонах, а не только в стилях. Стилевой блок без HTML-разметки — мёртвый код, не «компонент».

После этого /critique нашёл ещё несколько пунктов помельче:

• листинг прочитанных книг сделан карточной сеткой — это прямой анти-референс из моей же PRODUCT.md;
• три параллельных шаблона шапки и подвала на разных страницах с чуть разным поведением;
• текст страницы «Обо мне» написан в типичном LinkedIn-стиле: «Я исследую пересечения технологий, мышления и практики», «Автор · Инженер · Исследователь» — строго против моего же голоса;
• в публичной копии сайта засветилось имя поискового движка («Pagefind»), хотя пользователю это знать не нужно.

Всё, кроме текста «Обо мне», починили в этом же сеансе. Текст — это переписывание личного голоса, я сделал черновик, но коммитить не стал.

Полировка деталей 🎨 #

После /critique оставшиеся три команды — это работа другого характера. Не «найди и почини», а «доведи до состояния, в котором детали перестают раздражать».

Команда /harden («закалка») закрыла прямой пробел: на месте английской заглушки темы «typo? Click here» теперь нормальная страница 404 на русском с тремя осмысленными путями. Локализовал раздел тегов: хлебные крошки теперь говорят «Главная / Теги», а не «Tags». Расширил поддержку настройки «уменьшить движение» в операционной системе — теперь обнуляются все плавные переходы, не только прокрутка. Защитился от очень длинных заголовков (если в название поста попадёт длинная ссылка без пробелов, сетка не поедет).

Команда /polish («полировка») добавила состояния «при наведении» и «при фокусе с клавиатуры» там, где их не было: теги статьи, ссылки на соцсети в шапке главной, навигация пагинации, ссылки между постами, кнопка копирования кода. Каждая ссылка теперь визуально откликается на наведение через смену цвета — без сдвига, без тени, по принципу «никакой фальшивой глубины» из моей же DESIGN.md.

Команда /typeset (типографика) — самая «невидимая» работа. Включил кернинг (профессиональная регулировка расстояний между парами букв) и лигатуры (где две буквы соединяются в один знак — fi, fl). Включил табличные цифры на датах в ленте: цифры теперь одной ширины и в столбце выстраиваются штамп-в-штамп. Добавил мягкие переносы русских слов внутри статьи (без них длинные слова рвали строку абзаца на узкой колонке). Тонко уплотнил трекинг (межбуквенный интервал) на крупных заголовках 28-44 пикселя — Literata в больших размерах без лёгкого негативного трекинга «дребезжит» как кубики, с ним читается как один жест.

Каждая из тройки — 30-60 минут работы. Вместе они подняли качество с «работает» до «приятно читать».

Что я понял про инструмент #

Импеккейбл работает с локальными файлами, не с задеплоенным сайтом. Команды читают исходники в репозитории, рендеренный HTML после локальной сборки Hugo, и оба дизайн-документа. Прода нет ни в одной команде, кроме /live (интерактивный режим в браузере), которую я не использовал. То есть весь дизайн-цикл идёт у меня на ноутбуке, и выкладка в боевой репозиторий — финальный шаг, не источник истины.

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

Анти-референсы выстреливают сильнее, чем референсы. «Не как Habr» — конкретный отказ, проверяемый автоматически. «Как Stripe» — растяжимое, можно подогнать любой результат. PRODUCT.md заставляет выписать четыре-пять анти-референсов, и каждое решение проверяется против них.

Метрики важнее ощущений. /audit дал 11 из 20. Это конкретное число. После правок — 19. Я знаю, на сколько лучше. Бессчётный «прогресс» — самообман: правишь, правишь, чувствуешь, что лучше. С оценкой видно, что иногда нет.

Убывающая отдача наступает быстро. После пяти проходов половина команд impeccable стали неуместными для моего блога. /animate, /delight, /bolder, /overdrive — прямо конфликтуют с принципом «без подкупа» из PRODUCT.md. /quieter, /distill — сайт уже плоский и сдержанный, дальше пустая страница. /colorize — палитра закрыта на 13 цветах. /optimize — Hugo уже выжат до предела.

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

Где AI ошибся, а где я #

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

Первый случай. Один сборочный билд занял 9 минут вместо обычных 40-50 секунд. Я уверенно сказал: причина — что я только что добавил в подвал отметку реального времени сборки. Каждая страница теперь содержит уникальный текст в подвале, значит, утилита синхронизации (rsync) с проверкой по контрольной сумме перезаливает все 227 страниц целиком. Технически красивое объяснение, инженерно стройное. И неверное.

Следующий билд с той же отметкой времени занял 40 секунд. То есть 9-минутный билд был случайным выбросом — холодный старт исполнителя, сетевой сбой, что-то сторонне. Я экстраполировал из одной точки и готов был «починить» проблему, которой нет.

Второй случай. Я случайно удалил пустой файл content/posts/.md (артефакт от прошлой попытки автоматического создания поста с битым именем) после того, как назвал его «пустой стуб». Не прочитал содержимое перед удалением. Файл был не пустой — 101 байт. После удаления выяснилось, что в нём всё-таки лежал какой-то фронтматтер (служебный заголовок поста с метаданными), которого я не увидел до действия.

Оба случая зашиты в персональную память:

• Перед удалением читать каждый файл. Не отслеживается ли git — не значит «можно выкинуть».
• Прежде чем уверенно объявлять причину явления — собрать минимум две сравнимых точки. Один выброс ≠ закономерность.

Особенно полезно для вопросов производительности, где «фикс несуществующей проблемы» — это напрасные телодвижения и потеря доверия к собственным выводам.

Когда импеккейбл не нужен #

• На бренде, который требует «как у всех»: внутренний инструмент, служебная панель, прототип без идентичности.
• Когда нет 30-60 минут на интервью /teach и сборку DESIGN.md. Без фундамента остальные команды дают ответы вообще, не для тебя.
• На короткой одностраничной странице — обычная ручная работа быстрее.
• Когда дизайн уже отлажен и работает — повторное прохождение часто стоит дороже того, что находит.

Конкретные числа #

Итог #

Импеккейбл не делает дизайн за тебя. Он даёт инструмент, через который вы вместе с AI доводите дизайн до состояния, в котором вы оба перестаёте делать стандартные ошибки. Аудиторская часть (/audit, /critique) ловит сразу видимое. Доводочная часть (/harden, /polish, /typeset) делает то, что в одиночку лень довести до конца.

Стоимость: один вечер плюс умение зафиксировать собственный голос в PRODUCT.md и DESIGN.md. Срок отдачи: пока продолжаешь редактировать сайт. Каждое следующее обращение к AI («поправь шапку», «добавь страницу архива», «перепиши блок») идёт на фоне этих двух файлов, и шансы получить очередной AI-look уменьшаются.

Скрытая ценность инструмента в том, что он заставляет писать честно о собственном проекте. Анти-референсы зашиты в PRODUCT.md и зачитываются перед каждой правкой. Это ровно та дисциплина, которую я никогда не наводил руками.

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

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

В этом посте разбираемся с Qwen3-Coder-Next-MLX-4bit: квантованной версией кодовой модели от Alibaba, оптимизированной под Apple Silicon. Что это такое, как поставить, как подключить к Codex CLI и когда честно лучше остаться в облаке.

Что это такое и почему именно эта сборка #

Qwen3-Coder — линейка моделей от Alibaba, специально натренированных на коде. Базовая модель — около 8 млрд параметров. Это не GPT-4-class, но для большинства повседневных задач (понять код, написать функцию, сгенерить тесты, отрефакторить) — более чем достаточно.

MLX — относительно новый ML-фреймворк от Apple. Создан с нуля под Apple Silicon: использует unified memory (CPU и GPU делят одну RAM), zero-copy между ними, lazy evaluation. Для пользователя это значит, что модель работает заметно быстрее, чем тот же файл, запущенный через PyTorch с MPS-бэкендом.

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

Важно не путать форматы: MLX хранит модели в собственном формате (.safetensors обёрнутый в MLX-структуру), а не в .gguf (это формат llama.cpp). При выборе модели в LM Studio это нужно учитывать: «MLX»-вариант и «GGUF»-вариант — это разные файлы для разных движков, не одно и то же.

Для Qwen3-Coder-Next-MLX-4bit характеристики такие:

• Параметры: ~8B (тот же что и у не-квантованной версии).
• Формат: MLX (.safetensors).
• Размер на диске: ~5.5 GB.
• Контекст: 32 768 токенов.
• Минимум RAM: 16 GB (модель + накладные).
• Комфортный минимум: 24-32 GB (если ещё нужна работа с IDE и браузером параллельно).

Установка через LM Studio 📦 #

LM Studio — desktop-приложение для работы с локальными LLM. Поддерживает и MLX, и GGUF, плюс встроенный OpenAI-совместимый сервер на localhost.

Шаги:

1. Поставить LM Studio с официального сайта.
2. Открыть Discover (вкладка с моделями).
3. В фильтре указать «MLX» (важно — без этого подсунет GGUF-вариант).
4. Найти Qwen3-Coder-Next или подобную сборку.
5. Скачать (~5.5 GB).
6. Загрузить в My Models, потом Load.

После загрузки в правом sidebar’е будут параметры:

• Context length: 8 192 для большинства задач хватает; 32 768 если нужен большой prompt с длинным куском кода.
• GPU offload: «Max» — отдать всё на Metal-ядра.
• Threads: оставить дефолт (LM Studio сам подберёт).

LM Studio автоматически поднимет OpenAI-compatible endpoint на http://localhost:1234/v1/. Дальше с моделью работают любые клиенты, понимающие OpenAI API.

Подключение к Codex CLI через MCP 🔌 #

Если вы используете Codex CLI (агентский интерфейс на базе LLM), к нему можно подключить локальную модель через MCP-сервер для LM Studio.

В ~/.codex/config.toml:

[[mcpServers]]
name = "lmstudio"
command = "npx"
args = ["-y", "@mlaboard/lmstudio-mcp"]

После перезапуска Codex увидит локальную модель как один из доступных провайдеров. Smoke-тест: попросить простую задачу типа «напиши функцию Фибоначчи на Python» — должен ответить за 0.5–1 секунду.

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

Замеры на M2 Max 📊 #

На моём железе (M2 Max, 32 GB unified memory) получились такие цифры:

Это медленнее облачного GPT-4 (там 50-80 ток/с в среднем), но быстрее, чем кажется по первому впечатлению. Для итеративной работы (написал → попросил → поправил руками → попросил снова) разница в latency почти неощутима, потому что много времени всё равно уходит на чтение и редактирование результата.

Если поднять контекст до 32k и закинуть в prompt большой кусок кода (типа целого файла на 1000 строк), скорость падает примерно вдвое: 9-12 ток/с при first-token latency около 2 секунд. Ничего страшного, но уже заметно.

Сравнение с облаком #

Когда честно лучше облако #

Локальная модель не серебряная пуля. Есть классы задач, где она объективно проигрывает:

Большой контекст. 128k+ контекст-окно у топовых облачных моделей позволяет закидывать в prompt целые модули кода. У 32k Qwen банально не хватит места.

Сложные многошаговые задачи. Спроектировать архитектуру модуля, отрефакторить взаимосвязанные классы, написать миграцию с несколькими шагами — здесь топовые модели заметно качественнее.

Мультимодальность. Анализ скриншотов UI, генерация по чертежу, чтение PDF — Qwen3-Coder-Next специализирован под код, картинки не обрабатывает.

Редкие языки/фреймворки. На массовом Python, JS, Go качество приемлемое. На нишевых вещах (Elixir, Crystal, какой-нибудь специфичный DSL) облачная модель тренировалась на большем корпусе и даёт более уверенные ответы.

Когда локалка точно полезна #

И обратная сторона:

Чувствительные репозитории. Закрытый клиентский код, медицинские/финансовые данные, что-то под NDA — локально единственный вариант, который не нарушает соглашений.

Работа в дороге без сети. Поезд, самолёт, кафе с глюкавым WiFi — локальная модель отвечает одинаково ровно.

Высокочастотные задачи. Если модель используется десятки раз в час (autocomplete, объяснение fragment’ов кода в IDE), даже маленькая абонентская плата быстро накапливается. Локалка после железа бесплатна.

Эксперименты с агентами. Запускать тестовый цикл, где LLM крутится в фоне без лимитов, проще на собственном железе. Лимиты по rate limit / стоимости в облаке быстро становятся узким местом.

Размышления после месяца использования #

Для меня сложилась гибридная схема: 70% повседневной работы (объяснить функцию, написать regex, сгенерить unit-тест, набросать структуру модуля) — Qwen локально. Остальные 30% (сложная архитектура, разбор большого PR, работа со скриншотом) — облако.

Это не «локальная победила облачную». Это разделение по типу задач: где важна privacy и скорость отклика — локально, где важно качество и контекст — облако.

Установка занимает максимум полчаса (LM Studio + скачать файл + подключить через MCP). Дисковое пространство в 5.5 GB не критично даже на 256 GB Mac. Если вы давно думали попробовать локальные LLM, но откладывали из-за «сложно настроить» — Qwen3-Coder-Next-MLX-4bit как раз тот случай, когда барьер входа честно низкий. ✅

Источники #

• Документация MLX: github.com/ml-explore/mlx
• LM Studio: lmstudio.ai
• Qwen models на HuggingFace: huggingface.co/Qwen
• Model Context Protocol: modelcontextprotocol.io

8 апреля 2026 вышел Hugo v0.160.1 — патч-релиз, который чинит несколько неприятных panic-сценариев из v0.160.0 (вышедшего четырьмя днями раньше). Вместе они формируют один логический шаг для проектов: 0.160.0 даёт две новые возможности, 0.160.1 закрывает баги, всплывшие сразу после релиза.

Если коротко: одну фичу (CSS-переменные в css.Build) ждали давно те, кто строит CSS через Hugo Pipes; остальные изменения — улучшения для авторов render hooks и фиксы редких краевых случаев. Никаких breaking changes, никаких депрекейтов.

Но фиксы в 0.160.1 — это именно тот случай, когда «пропустил минор и поймал panic в проде». Поэтому пробежать стоит.

Главное за один взгляд #

v0.160.0 (4 апреля 2026) — фичевый минор:

• CSS-переменные можно инжектить в стили при сборке через css.Build (например, прокинуть значения из конфига).
• Метод .Position теперь доступен на всех render hooks и стал точнее.
• Несколько прицельных багфиксов (Position, escape ampersand’ов в link URL, stray quotes в partial-декораторе script-контекста).

v0.160.1 (8 апреля 2026) — patch:

• Fix: panic при passthrough-элементах в заголовках.
• Fix: panic при редактировании legacy template names, которые одновременно валидные пути в новой схеме.
• Fix: RenderShortcodes утекал context markers при отступах.
• Fix: standalone RenderShortcodes теперь снимает nested page context markers.
• Fix: автосоздание root sections в мультиязычных сайтах.
• Чистка: cascade._target → cascade.target (в тестах; deprecation осталось в коде).
• README: чинены ссылки.

Дальше — что это значит на практике.

CSS-переменные в css.Build 🎨 #

Это главная фича релиза. Если вы используете Hugo Pipes для сборки CSS (а не просто статически копируете файлы из static/), теперь можно прокидывать значения из Hugo-контекста прямо в CSS на этапе сборки.

Раньше для подобного приходилось городить пайплайн через переменные окружения, sed-замены или генерировать .css через Hugo template (что ломает синтаксис LSP-плагинов).

Теперь это выглядит ближе к декларативно:

{{ $opts := dict
    "vars" (dict
        "primary"   site.Params.brand.primary
        "max-width" "1200px"
    )
}}
{{ $css := resources.Get "css/main.css" | css.Build $opts }}
<link rel="stylesheet" href="{{ $css.RelPermalink }}">

В CSS можно ссылаться на эти переменные через специальный hook (@import 'hugo:vars' или подобный, точный синтаксис — в документации css.Build).

Когда полезно: сайтам с темой, где accent-цвет задаётся в hugo.toml и должен применяться к компонентам через CSS переменные; сборкам, где max-width или breakpoint-значения управляются из конфига; multi-tenant билдам.

Нашему блогу это не нужно — у нас ровно один theme и палитра жёстко зафиксирована в :root блоке. Но если вы строите тему-конструктор или multi-сайт — стоит изучить.

Точная позиция в render hooks 📍 #

Вторая фича — расширение .Position на все render hooks (image, link, heading, code-block) с одновременным улучшением точности.

.Position возвращает позицию исходного Markdown-токена в файле. Для отладки и понимания «откуда пришла эта ссылка» — критично.

Сценарий использования:

{{/* render-link.html */}}
{{ $url := .Destination | safeURL }}
{{ if not (urls.Parse $url).IsAbs }}
  {{/* Внутренняя ссылка — проверяем что target существует */}}
  {{ if not (.Page.GetPage (string $url)) }}
    {{ warnf "Битая внутренняя ссылка %q в %s" $url .Position }}
  {{ end }}
{{ end }}
<a href="{{ $url }}">{{ .Text | safeHTML }}</a>

В warning’е теперь будет точное файл:строка исходника поста, а не нечто приблизительное. Проще ловить регрессии после рефакторингов контента.

Багфиксы 0.160.1 🔧 #

Пять патчей, каждый закрывает свой панический сценарий или утечку.

Panic при passthrough в заголовках #

Hugo Goldmark поддерживает passthrough — режим, когда определённые символьные блоки (например, LaTeX-формулы $...$) пропускаются как есть и обрабатываются на клиенте через MathJax/KaTeX.

В 0.160.0 если passthrough-элемент попадал прямо внутрь заголовка (например, ## Формула $E=mc^2$), Hugo падал с panic при сборке. 0.160.1 чинит этот случай: теперь рендерится корректный HTML без падения.

Если вы пишете научный/математический контент с inline-формулами в заголовках — обновление обязательно.

Panic на legacy template names #

Если в проекте есть старая схема именования шаблонов (_default/single.html.html и подобные legacy-варианты), которая одновременно является валидным путём в новой схеме именования Hugo, при редактировании файла Hugo мог падать. 0.160.1 разводит эти кейсы.

RenderShortcodes и context markers #

RenderShortcodes — функция для обработки всех шорткодов внутри переданного контента. Она использует внутренние «context markers» для отслеживания вложенности.

В 0.160.0 эти маркеры могли:

1. Утекать в финальный HTML, если контент с шорткодами был с отступами (например, внутри списка или blockquote).
2. Не очищаться при standalone-вызове .RenderShortcodes через .Page.Content после nested-рендеринга.

Оба случая дают видимый «мусор» в выводе (артефакты вида __hugo_ctx0__ и подобные). 0.160.1 чистит маркеры в обеих ситуациях.

Если вы используете шорткоды внутри списков или blockquote’ов — обновляйтесь.

Auto-creation root sections в мультиязычных сайтах #

В мультиязычных сайтах Hugo автоматически создаёт «виртуальные» root section страницы для каждого языка. В 0.160.0 эта логика могла давать сбой (root section не создавалась, или создавалась только для default-языка), что ломало навигацию по неосновным языкам.

Если у вас один язык — пункт мимо. Если несколько — обновление лечит.

cascade.target вместо cascade._target #

Мелкий, но симптоматичный пункт: ключ _target в cascade-конфигурации переименован в target (без подчёркивания). Старая форма помечена как deprecated в коде, всё ещё работает.

Если у вас есть cascade-блоки в front matter:

cascade:
  - _target:                 # ← старая форма
      kind: page
    params:
      foo: bar

Замените на:

cascade:
  - target:                  # ← новая форма
      kind: page
    params:
      foo: bar

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

Чек-лист обновления ✅ #

1. Поднять версию Hugo до 0.160.1 в Dockerfile / CI-образе или локальном binary. Если вы уже на v0.161.0+ — пропускаем, это пройденная развилка.

2. Если используете passthrough для математики или специальных Markdown-блоков, и они появляются в заголовках — обновление закрывает panic. Без обновления заголовки-формулы могут быть рассадником сюрпризов.

3. Если используете cascade._target в front matter, переименовать в cascade.target:

   grep -rln '_target:' content/ | xargs sed -i '' 's/_target:/target:/g'

   copy

4. Если строите CSS через Hugo Pipes, посмотреть документацию css.Build с CSS variables — возможно, сможете заменить sed-замены или env-обвязку на встроенный механизм.

5. Если пишете кастомные render hooks, проверить, можно ли использовать .Position для лучшей диагностики битых ссылок/изображений в постах.

6. Стандартный прогон:

   hugo --minify --gc

   copy

   Сравнить количество warning’ов до и после. Если новых не появилось — мигрировано чисто.

Итог 🧠 #

Hugo 0.160.x — это не громкий feature drop, а методичное улучшение инфраструктуры: новый удобный механизм для CSS-сборки, более точная диагностика в render hooks, набор фиксов под краевые случаи (passthrough в заголовках, RenderShortcodes с отступами, multilingual sections).

Главная причина обновляться — патч 0.160.1 закрывает несколько panic-сценариев. Если вас они никогда не цепляли, повезло; но «не цепляли» — это не «не зацепят». На статичных сайтах panic при сборке проявляется как сломанный CI и красный билд, что рассинхронизирует прод и репозиторий.

Если уже сидите на 0.161.0 (как мой блог сейчас), всё это вы уже получили транзитом. Если на 0.159 или раньше — есть смысл прыгать сразу на самую свежую stable, минуя промежуточные.

Источники #

• Релиз 0.160.0: gohugoio/hugo v0.160.0
• Релиз 0.160.1: gohugoio/hugo v0.160.1
• Документация css.Build: gohugo.io/functions/css/build/
• Документация passthrough: gohugo.io/configuration/markup/#passthrough
• Документация cascade: gohugo.io/content-management/front-matter/#cascade

Именно такой формат, на мой взгляд, лучше всего показывает ценность автоматизации: не в красивых обещаниях, а в повторяемом результате. 🔧

Исходный контекст #

На старте у нас уже был рабочий блог на Hugo с темой typo, CI/CD через Forgejo Actions и поиском на Pagefind.

Дальше в рамках одной непрерывной сессии мы сделали:

1. Написали и опубликовали новый пост про Hugo 0.157.0.
2. Поймали проблему с невидимостью поста из-за времени публикации.
3. Добавили правила в AGENTS.md, чтобы больше не ловить future-ошибки.
4. Настроили и протестировали подсветку кода (в итоге перешли на dracula).
5. Привели к dracula цвета выдачи поиска.
6. Исправили некорректные заголовки в Pagefind (вместо названия поста показывалось имя сайта).
7. Структурировали README.md и AGENTS.md как рабочую документацию процесса.

То есть это уже не «написать один пост», а полноценный операционный цикл контентного проекта.

Как выглядел рабочий цикл с Codex CLI #

Самый полезный паттерн из этой сессии:

1. Чёткая постановка задачи #

Каждый шаг формулировался как конкретный результат:

• «Напиши новую статью про релиз».
• «Почему статья не видна? Исправь».
• «Сделай правило, чтобы проблема не повторялась».
• «Сделай тему поиска в dracula».

Чем конкретнее цель, тем меньше «творческого шума» и выше скорость прохождения задачи.

2. Локальная диагностика перед правкой #

Перед изменением файлов Codex проходил короткий аудит:

• чтение текущих шаблонов/конфигов;
• проверка фактического рендера;
• сверка с реальным поведением сайта;
• поиск причинно-следственной связи, а не симптомов.

Пример мышления: если цвета не применились, сначала проверить порядок подключения CSS, а не сразу «добавить ещё !important».

3. Точечная правка + обязательная валидация #

После каждого изменения шёл одинаковый технический минимум:

hugo list future
hugo --minify
git status --short

Это сильно снижает вероятность того, что в main улетит «логически верно, но технически сыро».

4. Фиксация в git маленькими коммитами #

Вместо одного гигантского коммита по итогам сессии:

• каждый смысловой шаг фиксировался отдельно;
• сообщения коммитов были предметными;
• любой этап можно быстро отследить и откатить локально при необходимости.

Для блога это особенно удобно: контент, стили, шаблоны и правила не смешиваются в «одно большое изменение».

Реальные проблемы, которые мы поймали и закрыли #

Проблема 1: пост «не видно на сайте» #

Симптом: статья есть в репозитории, но не отображается в списке публикаций.

Причина: date в фронтматтере оказался в будущем относительно московского времени на момент деплоя.

Решение:

• сдвиг даты в прошлое;
• проверка hugo list future;
• фиксация правила в AGENTS.md: новые посты ставить на 5-10 минут в прошлое и всегда проверять future-список перед коммитом.

Ключевой эффект: проблема устранена один раз на уровне процесса, а не «подкручена вручную» только для одного поста.

Проблема 2: подсветка кода «всё одним цветом» #

Симптом: HTML уже содержит chroma-классы, но визуально код почти монохромный.

Причина: базовый файл подсветки темы был близок к bw-палитре.

Решение:

1. Включили работу через CSS-классы (noClasses = false).
2. Добавили собственный assets/css/syntax-highlighting.css.
3. Сначала проверили monokai, затем переключили на dracula.

Итог: читаемая цветная подсветка с контролируемой темой в репозитории.

Проблема 3: выдача поиска не в стиле сайта #

Симптом: поле и результаты поиска выпадали из общей цветовой схемы.

Причина: стили Pagefind подключались после custom.css, и часть переопределений не применялась.

Решение:

• сначала добавили CSS-переменные Pagefind в custom.css;
• затем сделали гарантированное переопределение после pagefind-ui.css прямо в шаблоне layouts/search/single.html.

Это важный вывод: иногда нужно исправлять не «цвета», а точку и порядок их применения.

Проблема 4: у результатов поиска заголовок «Evgeny Kushnarenko» #

Симптом: каждая найденная строка в выдаче имела одинаковый title (имя сайта).

Причина: Pagefind подхватывал h1 из шапки страницы.

Решение:

• вынесли локальный layouts/partials/header.html и пометили шапку data-pagefind-ignore;
• добавили data-pagefind-meta="title" на h1 поста в layouts/_default/single.html.

Итог: выдача начала показывать реальные заголовки материалов.

Что это даёт в ежедневной работе #

После такого цикла становится заметно:

1. Время между идеей и публикацией сокращается.
2. Ошибки переходят из категории «случайные и повторяющиеся» в «редкие и диагностируемые».
3. Репозиторий становится документацией процесса, а не просто папкой с контентом.
4. Снижается когнитивная нагрузка на автора: меньше ручной рутины, больше фокуса на смысле.

На длинной дистанции это важнее, чем «сэкономить 5 минут на одной статье».

Что точно не нужно автоматизировать #

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

Тональность и личный голос. Codex может собрать структурный черновик, но финальный тон — авторская вещь. Если читатель чувствует «это писал не человек», доверие к материалу падает мгновенно. Заменять автора на этом этапе — значит потерять то, ради чего блог вообще существует.

Спорные технические решения. Когда в дизайне есть выбор между двумя одинаково обоснованными подходами (положить компонент в layouts/_default/ или в layouts/posts/, использовать ли Hugo Pipes для CSS или статичную копию), Codex даст «средний разумный вариант». Это не плохо, но это не вы. На длинной дистанции архитектурные решения, принятые «средним способом», накапливают трение, которое в одиночку не разглядеть.

Решения про контент. Что писать, что не писать, какие посты убирать, какие оставлять, как переименовать раздел — это редакционные решения. Они должны проходить через автора. Инструмент здесь полезен только как «помощник по реализации», когда решение уже принято.

Размышления после сессии #

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

Это типичная история про инфраструктуру: когда она работает плохо, она занимает 60% мысленного бюджета на каждое действие. Когда хорошо — становится незаметной, и весь бюджет уходит на смысл.

Практический шаблон автоматизации под Hugo #

Если хотите повторить подход, можно взять такой минимум:

1. Для каждой задачи: цель в 1-2 предложениях.
2. Перед правкой: чтение текущего состояния (rg, sed, шаблоны, конфиги).
3. После правки: hugo list future + hugo --minify.
4. Фиксация: один смысл = один коммит.
5. Публикация: git push сразу после проверки.
6. Если баг повторяемый: правило в AGENTS.md, а не «устная договорённость».

Набор команд, который реально работал в этой сессии #

# Проверки контента и даты
hugo list future
hugo --minify

# Диагностика
rg -n "pagefind|highlight|chroma" -S .
sed -n '1,220p' layouts/search/single.html

# Публикация
git add <файлы>
git commit -m "Осмысленный коммит по одной задаче"
git push

Никакой экзотики: сила не в сложных командах, а в дисциплине последовательности.

Практические выводы #

Автоматизация блога через Codex CLI работает лучше всего, когда вы относитесь к ней как к инженерному процессу:

1. Чёткая постановка задач.
2. Наблюдаемость и проверки после каждого шага.
3. Маленькие коммиты с понятной ответственностью.
4. Фиксация правил в репозитории.

Тогда Codex становится не «генератором текста», а операционным партнёром, который помогает держать качество и темп публикаций одновременно. ✅

В этой статье разберём, что именно изменилось, где может быть практический эффект, и как пройти обновление без сюрпризов. 🚀

Кому это релевантно сразу: командам, ведущим контент через Hugo Modules; авторам тем, использующим внешние API в шаблонах; всем, у кого билд иногда «висит» из-за медленного источника. Кому можно отложить: одиночный блог без модулей и без внешних запросов получит апгрейд почти прозрачно — обновляйтесь как часть обычной уборки технического долга.

Почему релиз 0.157.0 важен #

Главная идея релиза: Hugo становится устойчивее в «боевых» сценариях, где проект не ограничивается одной папкой content и парой шаблонов.

Ключевые точки:

1. Page.GitInfo теперь полноценно поддерживает контент из Git-модулей (через mounts).
2. В resources.GetRemote появился перезапросный timeout, который можно задавать прямо в шаблоне.
3. Добавлена частичная поддержка AVIF/HEIF/HEIC (пока только метаданные).
4. Улучшены дефолты обработки WebP.
5. Исправлены ошибки, влияющие на меню, section pages и стабильность сборок.

Если коротко: меньше «магии», больше управляемости. 🎯

GitInfo для Hugo Modules: что реально изменилось 🧩 #

Проблема до 0.157.0 #

Если вы подключали контент через module.imports.mounts (например, общий набор статей или документацию из отдельного репозитория), GitInfo мог работать неполно или нестабильно для таких страниц.

Это мешало:

• корректно выводить «последнее обновление» для импортированного контента;
• строить списки изменений по коммитам;
• делать единый шаблон мета-блока для локального и модульного контента.

Что даёт 0.157.0 #

В релизе добавлена и доработана поддержка Page.GitInfo для контента из Git-модулей. То есть страницы, примонтированные из модулей, теперь могут корректно отдавать данные о коммите: автора, дату, хеш, subject и т.д.

Это особенно полезно для:

• docs-порталов из нескольких репозиториев;
• мультисайтов, где контентные команды работают независимо;
• архитектуры «ядро темы + контент как модуль».

Практический шаблон #

{{ with .GitInfo }}
  <p class="meta">
    Обновлено: {{ .AuthorDate.Format "2006-01-02 15:04" }} ·
    Автор: {{ .AuthorName }} ·
    Коммит: <code>{{ .AbbreviatedHash }}</code>
  </p>
{{ end }}

Важный operational-момент: в CI должен быть не shallow clone, иначе Git-данные могут быть неточными.

resources.GetRemote получил timeout: контроль вместо зависаний ⏱️ #

Что болело раньше #

Когда вы тянете внешние данные (RSS/JSON/изображения), один медленный источник мог подвесить сборку. На небольшом сайте это раздражает, а на большом CI-пайплайне превращается в регулярную проблему.

Что появилось в 0.157.0 #

Теперь в resources.GetRemote есть опция timeout (строка длительности, например "10s"). Её можно задавать для каждого запроса отдельно.

{{ $url := "https://example.org/feed.rss" }}
{{ $opts := dict "timeout" "10s" }}

{{ with try (resources.GetRemote $url $opts) }}
  {{ with .Err }}
    {{ warnf "Не удалось получить feed %q: %s" $url . }}
  {{ else with .Value }}
    {{ $data := . | transform.Unmarshal }}
    {{/* дальнейшая работа с данными */}}
    {{ $data }}
  {{ else }}
    {{ warnf "Ресурс %q не найден" $url }}
  {{ end }}
{{ end }}

Практический эффект:

• можно задавать строгий timeout для нестабильных источников;
• сборка перестаёт «висеть» из-за одного внешнего API;
• проще разделить критичные и некритичные источники (где-то errorf, где-то warnf).

Изображения: что важно понимать про AVIF/HEIF/HEIC и WebP #

В 0.157.0 добавили частичную поддержку AVIF/HEIF/HEIC: на текущем этапе это поддержка метаданных, а не полноценный новый pipeline обработки.

Что это значит на практике:

• Hugo лучше распознаёт такие файлы;
• можно безопаснее работать с метаданными;
• но не стоит ожидать полной parity с привычной обработкой JPEG/PNG/WebP прямо «из коробки».

Также в релизе скорректированы настройки обработки WebP. Если вы строите агрессивный image pipeline, стоит прогнать визуальные regression-проверки на ключевых страницах.

Дополнительные исправления, которые могут «всплыть» в проде #

В релизе есть не самые заметные, но полезные улучшения:

• фикс menu pageRef в multidimensional-настройках;
• корректировки в логике section pages;
• улучшенные сообщения об ошибках модулей (go mod download);
• пропуск пустых taxonomy-ключей/значений в конфиге.

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

Сценарий, который раньше ломался: контент в нескольких модулях #

Чтобы понять ценность изменений вокруг GitInfo и section pages, представьте типичную mid-size-конфигурацию: основной репозиторий с темой, плюс два модуля с контентом — docs/ и blog/, каждый в своём Git-репо. Их подмонтировали в основной сайт через module.imports.mounts.

До 0.157.0 в этой конфигурации возникали мелкие неприятности: даты в footer’е импортированных постов отдавали поведение «default-на-momento-сборки» вместо «коммит-автор-дата»; menu иногда теряла pageRef для импортированных страниц при определённых вариантах языковой настройки; ошибки go mod download приходили без контекста, и приходилось вручную перебирать модули, чтобы найти проблемный.

В 0.157.0 каждый из этих краевых случаев починен. Если вы держите такой setup, после обновления заметна разница: меньше ручных правок шаблонов под «странности» modular-контента, прозрачнее ошибки при сетевых проблемах с одним из модулей.

Когда обновляться можно отложить #

Если у вас одиночный сайт без модулей, без resources.GetRemote в шаблонах, без AVIF/HEIF в pipeline и без активных кастомных меню с pageRef — этот релиз вас почти не коснётся. Обновитесь в плановом окне (вместе с пересборкой Docker-образа, например), но срочности нет.

Срочно обновляться стоит, если: используете resources.GetRemote и хотя бы раз попадали на медленный source; ведёте мультимодульный контент; пишете кастомные шаблоны с .GitInfo для импортированных страниц.

Чек-лист обновления до Hugo 0.157.0 ✅ #

1. Обновите бинарь/образ Hugo до 0.157.0.
2. Если используете GitInfo, проверьте enableGitInfo: true в конфигурации.
3. Убедитесь, что CI делает глубокий клон репозитория (fetch-depth: 0 в GitHub Actions или эквивалент).
4. Для всех resources.GetRemote проставьте осмысленный timeout и единообразный try-обработчик.
5. Прогоните smoke-тесты меню, section pages и страниц с импортированным модульным контентом.
6. Проверьте image pipeline (особенно WebP) на визуальные отличия.
7. Сравните длительность сборки до/после обновления.

Мини-план миграции на 30 минут #

Если проект уже в хорошем состоянии, переход можно сделать быстро:

1. 10 минут: поднять версию и собрать сайт локально без warning/error.
2. 10 минут: проверить шаблоны с .GitInfo и блоки с resources.GetRemote.
3. 10 минут: прогнать CI и открыть несколько критичных страниц руками.

Обычно этого достаточно, чтобы перейти на релиз без ночных откатов.

Итог 🧠 #

Hugo 0.157.0 не про «громкие фичи ради фич», а про зрелость платформы: лучшее поведение в модульных проектах, более предсказуемая работа с внешними запросами и аккуратные улучшения инфраструктурного уровня.

Если у вас контент разбит на модули, а сборка зависит от внешних данных, обновление стоит делать в ближайшем цикле.

Источники #

• Официальный релиз: gohugoio/hugo v0.157.0
• Документация Page.GitInfo: gohugo.io/methods/page/gitinfo
• Документация resources.GetRemote: gohugo.io/functions/resources/getremote

18 февраля 2026 вышел Hugo v0.156.0. Если поверхностно прочитать changelog, это очередной минор: пара новых методов, несколько депрекейтов, опция конфига. Звучит как «обновлюсь когда руки дойдут».

Но именно из таких минорных релизов и копится технический долг. Депрекейт API сегодня — это broken-build через год, когда вы решите перейти на крупную версию. Минута, потраченная сейчас, чтобы привести шаблоны в соответствие, экономит вечер разбирательств позже.

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

Главное за один взгляд #

Релиз 0.156.0 содержит шесть значимых изменений:

1. Добавлены новые API: hugo.Data и hugo.Sites.
2. Устаревшими объявлены site.Data и site.Sites (пока работают для обратной совместимости).
3. В контекст link render hooks добавлены методы IsBlock и Ordinal.
4. Добавлен новый метод site.Home.Translations; site.Home.AllTranslations помечен как deprecated.
5. Появилась опция конфигурации disableSetLocale.
6. Помечен как deprecated путь _vendor/github.com/gohugoio/locales.

Дальше — по каждому пункту, что это значит на практике и что менять.

Переезд site.Data → hugo.Data 🧱 #

Самое заметное смысловое изменение — переезд глобальных коллекций данных и сайтов с пространства имён site.* на hugo.*.

Сейчас в шаблонах вы могли писать:

{{ range site.Data.authors }}
  ...
{{ end }}

После 0.156 рекомендуется:

{{ range hugo.Data.authors }}
  ...
{{ end }}

Версия со старым site.Data пока работает — ради совместимости. Но в release notes явно сказано: новые методы предпочтительнее, старые помечены как deprecated. Когда придёт следующая major-версия (Hugo любит чистить депрекейты), site.Data могут совсем убрать.

Аналогичная история с site.Sites → hugo.Sites. Используется реже, в основном на мультисайтах с подмножеством общих ресурсов.

Что делать: массовый поиск-замена в шаблонах темы и проекта:

grep -rn 'site\.Data\|site\.Sites' layouts/ themes/*/layouts/ 2>/dev/null

Если хитов нет — вы никак не зависите от этого изменения. Если есть — заменить на hugo.Data и hugo.Sites.

Render hooks: IsBlock и Ordinal 🔗 #

Если у вас есть кастомные link render hooks (файл layouts/_default/_markup/render-link.html или подобный), в их контексте теперь доступны два новых метода:

• IsBlock — true, если ссылка стоит как самостоятельный блок (например, <p>[link](url)</p> где это единственный элемент абзаца), а не inline внутри текста.
• Ordinal — порядковый номер ссылки в документе, начиная с 0.

Зачем это нужно:

{{/* render-link.html */}}
{{ if .IsBlock }}
  {{/* Самостоятельная ссылка — рендерим как карточку */}}
  <a class="link-card" href="{{ .Destination | safeURL }}">
    <span class="link-card__num">№{{ add .Ordinal 1 }}</span>
    <span class="link-card__text">{{ .Text | safeHTML }}</span>
  </a>
{{ else }}
  {{/* Inline-ссылка — обычный <a> */}}
  <a href="{{ .Destination | safeURL }}">{{ .Text | safeHTML }}</a>
{{ end }}

Это удобно для блогов с активным использованием ссылок: можно по-разному оформлять «отдельные ссылки на источники» и «inline-упоминания».

Ordinal помогает строить нумерованные списки источников или footnote-style references без ручной разметки.

Мультиязычность: site.Home.Translations 🌐 #

Метод site.Home.AllTranslations помечен как deprecated. Заменяет его более узкий site.Home.Translations.

Разница:

• AllTranslations возвращает все языковые версии главной страницы, включая текущую.
• Translations возвращает только другие языки, без текущей версии.

Старый код:

{{ range site.Home.AllTranslations }}
  {{ if ne .Lang $.Lang }}
    <a href="{{ .Permalink }}">{{ .Language.LanguageName }}</a>
  {{ end }}
{{ end }}

После 0.156 ту же логику можно записать прямее:

{{ range site.Home.Translations }}
  <a href="{{ .Permalink }}">{{ .Language.LanguageName }}</a>
{{ end }}

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

Опция disableSetLocale ⚙️ #

В конфиге появилась новая опция:

disableSetLocale = true

По умолчанию Hugo пытается установить системную локаль операционной системы согласно языку текущего сайта. Это влияет на форматирование дат, чисел, сортировку строк (strings.Sort).

Иногда это поведение нежелательно. Например, в CI-контейнере может не быть нужной локали, и Hugo молча падает на дефолт. Или вы хотите, чтобы поведение было одинаковым на всех машинах сборки независимо от языка контента.

disableSetLocale = true отключает эту попытку. Hugo использует значения из конфига и встроенные форматтеры без обращения к OS-уровню setlocale().

Когда нужно: CI-сборки на минимальных образах (alpine, debian-slim), где локали могут отсутствовать; репозитории с воспроизводимой сборкой; ситуации, когда вы заметили различия в форматах между локальной сборкой и CI.

Депрекейт пути _vendor/github.com/gohugoio/locales #

Путь _vendor/github.com/gohugoio/locales помечен как устаревший. Если вы его явно использовали (например, импортировали как submodule в проект), стоит начать миграцию на встроенные локали Hugo — релиз поддерживает их через стандартный механизм.

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

Чек-лист обновления за 30 минут ✅ #

Чтобы пройти миграцию без сюрпризов:

1. Поднять версию Hugo до 0.161.0 (если ещё на старой) или 0.156.0 как промежуточный шаг. Если работаете в Docker, обновить ARG HUGO_VERSION и пересобрать образ.

2. Поиск устаревших API в шаблонах:

   grep -rn 'site\.Data\|site\.Sites\|AllTranslations' layouts/ themes/*/layouts/

   copy

   Если хиты есть — заменить на hugo.Data, hugo.Sites, Translations.

3. Проверить кастомные render hooks, если они есть. Можно ли получить пользу от новых IsBlock и Ordinal?

4. Решить про disableSetLocale. Если CI-сборки иногда дают разные форматы дат в зависимости от хоста, добавить опцию в конфиг.

5. Прогнать сборку:

   hugo --minify --gc

   copy

   Не должно быть warning’ов. Если появились — каждый из них чем-то да полезен, не игнорировать.

6. Открыть несколько критичных страниц локально, проверить, что меню, переводы, render hooks работают.

7. Закоммитить и задеплоить. На статичном Hugo-сайте откат — это git revert плюс пересборка, минут 5.

Итог 🧠 #

Hugo 0.156.0 — не «громкий релиз ради хайпа». Это пакет аккуратных архитектурных изменений: переезд на новые API, расширение возможностей для тех, кто пишет render hooks, чистка мультиязычной части.

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

Если у вас минимальный шаблонный код (стандартная тема без кастомных hook’ов и без мультиязычности), переход почти прозрачен. Если у вас активные render hooks или мультиязык — стоит выделить полчаса на ревизию.

И да: каждый минор-релиз стоит читать. Не как обязательное домашнее задание, но как короткую инвестицию в собственный код.

Источники #

• Официальный релиз: gohugoio/hugo v0.156.0
• Документация по новым API: hugo.Data, hugo.Sites
• Документация по переводам: site.Home.Translations
• Документация link render hooks: Render hooks: links

Магазинная колбаса — продукт, который терпит много претензий: непрозрачный состав, переизбыток фосфатов, переменное качество от партии к партии, дискомфорт от того, что «там вообще мясо или нет». Домашняя — наоборот: ты сам решаешь, какое мясо, сколько соли, какие специи, как готовить, что положить в оболочку.

Это не «дешевле магазинной» (по факту — нет, особенно с учётом времени). Это «честнее и вкуснее, если потратить время на освоение базовых пропорций». А пропорции — самое важное в колбасе. Если соль/специи/влага в норме, даже простой кусок мяса превращается в нормальный продукт.

Этот пост — рабочая памятка с пропорциями, которые я использую как отправную точку, плюс короткое объяснение, зачем там каждый ингредиент. Без претензий на «единственно верный рецепт».

Соль и добавки на 1 кг 🧂 #

Базовый набор:

• Соль: 18-20 г.
• Оптимальный вариант: 16 г обычной соли + 2-3 г нитритной соли.
• Сахар: 5 г (примерно 1 ч. л.).
• Чёрный перец: 1 ч. л.
• Чеснок: 2 зубчика (около 8-10 г).
• Мускатный орех: щепотка.
• Лёд или ледяная вода: 80-100 мл.

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

Зачем каждое из этого #

Чтобы рецепт не казался магической формулой, коротко по каждому пункту:

Соль — 18-20 г на 1 кг. Это не «по вкусу». Это пороговая концентрация: меньше — фарш плохо «связывается» (соль вытягивает миофибриллярные белки, которые удерживают воду), больше — переедено и опасно. Норма для большинства колбас 1.8-2%.

Нитритная соль — 2-3 г. Главный вопрос. Нитрит даёт характерный розовый цвет, узнаваемый «колбасный» вкус и — главное — подавляет рост ботулинических бактерий. Без него любая колбаса с длительной выдержкой или копчением рискует превратиться в источник опасных токсинов. Не «химия, которую нужно избегать», а функциональный консервант, который существует не зря. Концентрация 2-3 г нитритной соли (а не чистого нитрита) — безопасный диапазон, давно стандартизированный.

Сахар — 5 г. Не для сладости. Для микробиоты — она «съедает» сахар и даёт лёгкое подкисление, плюс смягчает солёность.

Чёрный перец, чеснок, мускат. Базовая «колбасная» ароматическая основа. Каждый компонент можно менять под вкус (паприка, горчица в зёрнах, кориандр, тмин), но эта тройка — спокойная отправная точка.

Ледяная вода — 80-100 мл. Самое неочевидное для новичков. Вода не «разбавляет», а наоборот — вместе с белками образует эмульсию, которая держит структуру колбасы при нагреве. Если воду не добавить, колбаса получится сухой и зернистой. Если добавить тёплую — белки свернутся раньше времени, эмульсия не сложится. Лёд гарантирует, что фарш во время вымешивания остаётся холодным.

Технология процесса #

Кратко, без излишних деталей, чтобы держать целое в голове:

1. Подготовка мяса. Охладить до 1-3°C (не замораживать). Срезать жёсткие плёнки и хрящи, нарезать кусками удобного размера.
2. Помол. Через мясорубку с решёткой 4-6 мм. Чем мельче, тем «нежнее» структура; чем крупнее — тем «деревенская» подача.
3. Внесение соли и нитрита. На холодный фарш, тщательно перемешать.
4. Специи и сахар. Добавить, перемешать снова.
5. Лёд/ледяная вода. Добавлять постепенно, продолжая вымешивать. Цель — получить однородную массу, в которой видна вязкость («тянется» при отрыве).
6. Холодная пауза. 1-3 часа в холодильнике, чтобы соль распределилась и фарш «созрел».
7. Набивка. В оболочку (натуральную или коллагеновую), без воздушных пузырей.
8. Термообработка. Зависит от типа: варка при 75-80°C до внутренней температуры 70-72°C, копчение, запекание.

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

Типичные ошибки начинающих 🪤 #

Самые частые сбои, которые легко избежать, если знать заранее:

Слишком тёплый фарш. Если на любом этапе фарш нагрелся выше 12-15°C, эмульсия не сложится. Жир «вытопится» при варке, в продукте появятся жирные карманы. Лёд обязателен.

Переизбыток соли. «Я люблю солёное» не работает. Превысил 25 г на кг — продукт не съесть, а ребалансировать сложно: соль из готовой колбасы не уберёшь.

Недомес. Если фарш не дошёл до состояния «вязкий, тянется» — структура развалится. Вымешивание — главное, что делает колбасу колбасой, а не «фарш в кишке».

Воздух в оболочке. Пузыри = места, где может развиваться нежелательная микрофлора. Прокалывать иголкой при набивке — нормальная практика.

Резкий перегрев при варке. Внутри колбасы должно быть 70-72°C, не больше. Перегрев = выплавление жира + сухость. Для контроля — кулинарный термометр; «на глаз» в этом деле подводит.

Спешка с дегустацией. Колбасе нужно «созреть» в холодильнике хотя бы 12-24 часа после варки. Свежевыкипяченная — это не финальный вкус.

Варианты по виду мяса #

Базовый рецепт работает для свинины и для смесей. Несколько типичных вариаций:

• Свинина (60% мякоти + 40% жирной части). Классика, сбалансированный вкус, хороший для новичков.
• Свинина + говядина (70/30). Более «мясной» характер, плотнее структура, чуть жёстче.
• Только говядина. Суше, требует больше воды и аккуратности с эмульсией; вкус интенсивнее.
• Птица (грудка + бедро). Нежнее, ниже жирность; нужно поднять долю воды и тщательнее вымешивать.

Соль и нитрит — те же. Воды иногда нужно немного больше для постного мяса.

Безопасность ⚠️ #

Несколько моментов, о которых стоит знать обязательно:

• Нитритная соль ≠ чистый нитрит. Это уже разбавленная смесь (обычно 0.5-0.6% NaNO₂ в обычной соли). Использовать строго по дозировке для нитритной соли, не для чистого вещества.
• Ботулизм. Главная причина существования нитрита в колбасном деле. При длительной выдержке без нитрита риск реален; не «древняя страшилка».
• Контроль температуры. Внутренняя температура готового продукта 70-72°C — это не «совет», это безопасность.
• Сроки хранения. Домашняя колбаса без консервантов хранится в холодильнике значительно меньше магазинной. Замораживание — ок, но текстура немного меняется.

Если делаете колбасу впервые — стоит прочитать пару проверенных источников по технологии (например, Stanley Marianski «Home Production of Quality Meats and Sausages» или книги по колбасному делу на русском). Это не та область, где «методом тыка» — оптимальный путь обучения.

Куда дальше, если втянулся #

Если базовый цикл стал привычным, есть много направлений для развития:

• Сухое созревание (колбаса как salami). Долгий процесс, требует контроля температуры и влажности.
• Копчение (горячее или холодное). Меняет вкус и продлевает хранение.
• Свои смеси специй. Эксперименты с паприкой, фенхелем, кориандром, перцем чили — ровно по чайной ложке, чтобы не «перегрузить».
• Натуральные оболочки. Свиная черева, говяжьи синюги, бараньи кишки — каждая дает свою текстуру.

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

Итоги #

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

Этот рецепт — мой рабочий минимум. Точные пропорции вы со временем подгоните под себя, но 18-20 г соли, 80-100 мл ледяной воды, обязательная нитритная составляющая и аккуратное вымешивание — фундамент, на котором всё остальное держится. 🍴

Мы с моим другом Андреем давно обсуждали идею «разобраться, как это работает на самом деле». Самогоноварение показалось подходящим испытанием: техническая часть, химия, дисциплина, плюс шанс сделать что-то необычное своими руками. Не для того, чтобы «гнать в промышленных масштабах», а чтобы пройти процесс целиком и понять, где спрятаны нюансы, о которых снаружи не догадаешься.

Так в нашей жизни появилась ректификационная колонна «Дом Спирт 2» и дерзкая цель — попробовать сделать абсент. Через несколько подходов мы получили результат, который можно назвать «похожим на абсент», и значительно больше — наблюдений о самом процессе.

Что такое ректификационная колонна (упрощённо) #

Колонна — это вертикальная труба, в которой пары спиртосодержащей жидкости поднимаются вверх, проходят через насадку (мелкие металлические или керамические элементы), частично конденсируются и стекают обратно. Это «ректификация» — многоступенчатая дистилляция в одном устройстве.

Эффект: получается высокая степень очистки, спирт-ректификат может быть крепче 90%, без значительной части примесей, которые делают «обычный самогон» неприятным.

«Дом Спирт 2» — российская модель домашней ректификационной колонны. Она не самая мощная и не самая компактная, но достаточно «честная»: достать, освоить базовый цикл, понять, как ведёт себя пар, давление, температура — реально для технически грамотного человека за несколько вечеров.

Первые впечатления: техника — это не половина дела, а почти всё #

Оказалось, что в этом хобби важна не только «железка», но и терпение. Ожидания были простыми: собрал, запустил, получил результат. Реальность — другая: время, аккуратность, много мелких нюансов и постоянное чувство, что упускаешь какую-то деталь.

Несколько вещей, которых мы не ожидали:

• Длительность процесса. Полный цикл от загрузки до получения готового продукта — это много часов, иногда вся суббота.
• Чувствительность к деталям. Изменение скорости отбора, температуры, охлаждения дефлегматора — каждое влияет на результат сильнее, чем казалось из видеообзоров.
• Гигиена. «Чисто» в обычном смысле и «чисто» для процесса — разные понятия.
• Дисциплина протокола. Если делать «на глаз» — результаты непредсказуемы. Если фиксировать каждый шаг — повторяемость растёт.

Чем абсент сложнее «обычного дистиллята» #

Классический спирт-ректификат — это, грубо, очищенный этанол с водой. Абсент сложнее устроен:

1. Мацерация. Травы (полынь, анис, фенхель и менее афишированные растения) настаиваются на готовом спирте.
2. Перегонка с травами. Полученный настой перегоняется заново — часть ароматических компонентов переходит в дистиллят, часть остаётся в кубе.
3. Финальное окрашивание. Дополнительная мацерация на свежих травах даёт характерный зелёный или жёлтый оттенок.

Каждый из этих шагов имеет свои переменные: какие травы, в какой пропорции, при какой температуре, как долго. Мелкая ошибка на любом шаге даёт ощутимое отклонение в финальном вкусе. И если «обычный самогон» прощает многое, абсент прощает мало.

Дополнительно — травы дают так называемые «термолабильные» компоненты, которые легко разрушаются при перегреве. Это даёт парадоксальную ситуацию: вы технически умеете гнать спирт, но при попытке сделать абсент получаете либо «горький эликсир», либо «спиртовая вода с лёгким намёком на полынь» — без середины.

Что получилось #

• Мы разобрались с базовой логикой процесса и перестали «бояться» оборудования.
• Получили результат, который можно оценивать — не идеально, но уже похоже на задуманное.
• Поняли, какие этапы требуют больше контроля, чем казалось на старте.
• Научились читать поведение колонны: давление, температура, скорость капельного отбора.
• Сформировали собственный «лог сессии», который помогает повторять удачные попытки.

Что не получилось #

• Стабильность. Один и тот же подход давал разный результат от подхода к подходу.
• Предсказуемость вкуса и аромата. Это тонкая, почти ювелирная работа.
• Терпение. Иногда проще поставить эксперимент на паузу, чем пытаться «додавить» его усталостью.
• Точная имитация классического абсента. До «как в Швейцарии» далеко; пока ближе к «дегустационному образцу собственного производства».

Главный вывод #

Самогоноварение — это не «про напиток», а про процесс и дисциплину. Это про внимание к деталям и честность с самим собой: если хочешь качественный результат, придётся уважать все этапы, а не только финал.

Любая часть, которую попытаешься «срезать», даст видимый результат: либо во вкусе, либо в стабильности, либо в безопасности. Это, наверное, и есть главная ценность таких хобби: они напоминают, что качественный результат складывается из мелочей, которые поодиночке кажутся незначительными.

Безопасность (важное) #

Несколько вещей, которые нужно проговорить отдельно:

• Голов и хвостов нельзя пить. Первые и последние фракции содержат метанол, сивушные масла и другие соединения, потенциально опасные. Их отделяют по проверенной методике.
• Высокая концентрация спирта = высокая огнеопасность. Колонна греется, пары горючи, помещение должно быть вентилируемым.
• Лицензирование и закон. В разных странах правила производства алкоголя для личного потребления отличаются. Ответственность всегда на изготовителе.
• Дегустация. Не «глотнуть и надеяться». Малая проба, оценка по органолептике, никаких больших порций неотлежавшегося продукта.

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

Зачем писать об этом #

Потому что это хороший пример живого эксперимента: мы не профессионалы, а просто люди, которым интересно разобраться. И именно в таких историях — ценность. Не в том, чтобы «повторить», а в том, чтобы увидеть путь, ошибки и выводы.

Любое сложное хобби работает по похожей траектории: первые попытки выглядят неуклюже, потом приходит понимание базовых механик, дальше — наблюдение за деталями, и только потом становится возможным «сознательно делать вкус», а не «случайно получать что-то близкое».

Что дальше #

Мы продолжаем экспериментировать. Возможно, через пару месяцев будет вторая часть — с более стабильным результатом и ясными выводами. Пока же — фиксируем этап и идём дальше.

Если резюмировать одной фразой: самое важное, что я понял за эти подходы — терпение в этом хобби стоит больше, чем оборудование. Хорошая колонна не сделает за тебя дисциплину. А плохая дисциплина не оправдается дорогой колонной. 🧪

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

Важно уточнить позицию сразу: Codex не заменяет автора и редактора. Он ускоряет производство черновика, стабилизирует техническую часть и снимает «операционную усталость», чтобы энергия оставалась на смыслы.

Где именно теряется время при выпуске поста #

До автоматизации у меня стабильно проседали одни и те же этапы:

1. Переход от идеи к первому цельному черновику.
2. Ручное оформление фронтматтера без ошибок.
3. Поддержание одинакового уровня качества для summary и description.
4. Повторяемые технические действия перед публикацией.

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

Какую роль я отдаю Codex, а какую оставляю себе #

Чтобы автоматизация была полезной, роли должны быть разделены жёстко.

За мной остаётся:

• тезис и позиция статьи;
• финальная логика аргументации;
• личный опыт, выводы и тональность.

Codex получает:

• сборку структурированного черновика из тезисов;
• технически корректный фронтматтер;
• контроль повторяющихся формальностей;
• подготовку git-части к публикации.

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

Рабочий конвейер: от идеи до публикации #

Ниже процесс, который у меня реально работает в блоге на Hugo.

1. Формулирую цель поста в двух фразах #

Перед стартом фиксирую:

• для кого материал;
• какое практическое действие читатель сможет сделать после прочтения.

Если это не ясно на старте, статья почти всегда расползается.

2. Даю Codex каркас будущего текста #

Минимальный вход:

• рабочий заголовок;
• 5-8 смысловых пунктов;
• 2-3 конкретных примера;
• желаемая глубина (коротко / подробно / разбор).

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

3. Собираю длинный черновик и сразу проверяю логические провалы #

Обычно я смотрю:

• нет ли повторов между разделами;
• есть ли причинно-следственная связка между блоками;
• не превращаются ли выводы в общие фразы.

Если провалы есть, лучше исправить их до стилистической шлифовки.

4. Редактирую смысл вручную #

Это самый важный шаг. Здесь я:

• вырезаю «воду»;
• добавляю реальные наблюдения;
• уточняю формулировки, где можно понять двояко;
• усиливаю практическую часть (чек-листы, сценарии, ограничения).

Именно здесь текст перестаёт быть «генерированным» и становится авторским.

5. Передаю Codex техническое оформление #

После смысловой правки Codex приводит материал к правилам блога:

• корректный фронтматтер;
• осмысленные summary и description без дублирования;
• релевантные теги;
• структура с оглавлением и читабельными секциями;
• уместные эмодзи для акцентов.

6. Финальная техническая валидация #

Перед публикацией использую обязательный минимум:

hugo list future
hugo --minify

Если пост попал в future, дата сдвигается назад (МСК, +03:00), затем повторная проверка.

7. Публикация #

После проверки Codex помогает зафиксировать изменения:

git add .
git commit -m "Осмысленный коммит на русском по теме поста"
git push

На этом этапе уже не нужно держать в голове «не забыть бы пуш» или «как назвать коммит».

Что реально улучшилось после внедрения #

Я получил не «магическое ускорение», а более важную вещь: предсказуемость процесса.

Практические эффекты:

• меньше технических ошибок во фронтматтере;
• стабильнее качество мета-описаний;
• ниже время между идеей и публикацией;
• меньше усталости от повторяющихся операций.

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

Типовые ошибки при работе с Codex (и как их избежать) #

Ошибка 1: просить «сразу финальный пост» #

Так почти всегда получается текст без авторской позиции. Лучше идти через этапы: каркас → черновик → ручная редактура → техническая сборка.

Ошибка 2: не задавать ограничения #

Если не проговорить глубину, аудиторию и формат, модель заполняет пробелы усреднёнными формулировками. Чем точнее входные параметры, тем полезнее выход.

Ошибка 3: пропускать финальный ручной проход #

Без авторской правки текст может быть «правильным», но без нервов и фактуры. Читатель это считывает мгновенно.

Мини-шаблон запроса, который у меня работает #

Я обычно даю Codex примерно такую рамку:

Нужен пост для Hugo-блога на русском.
Формат: длинная статья, глубокая проработка, практические выводы.
Структура: вступление, 6-8 разделов, финальный чек-лист.
Обязательно: осмысленные summary/description, корректный фронтматтер, уместные эмодзи.
После текста: проверить техническую часть публикации (hugo list future, hugo --minify, commit, push).

Этого достаточно, чтобы стартовый результат был рабочим, а не «общей заготовкой».

Когда Codex точно не помогает #

После пары месяцев работы в этом режиме можно честно перечислить ситуации, где автоматизация скорее мешает:

Когда тема ещё не оформилась. Если у вас в голове только смутное «хочется написать про X», Codex выдаст структуру вокруг этой смутности — формально стройную, по сути пустую. Лучше потратить полчаса на бумажный набросок, выписать 3-5 ключевых тезисов, и только потом включать инструмент. Код первым приходит туда, где есть запрос; в текстах этот запрос — авторская позиция.

Личные посты. Эссе про опыт, наблюдение, ошибку — Codex здесь не нужен. Структуру эссе диктует не методическая разбивка на h2-разделы, а внутренняя логика рассказа. Прогон через шаблон «вступление → 6 разделов → чек-лист» убивает живость текста. Технические руководства — да; рефлексия — нет.

Когда ответ нужно проверить руками. Если вы пишете про инструмент, который сами не запускали (например, обзор библиотеки по чужим текстам), Codex усилит риски: соберёт правдоподобный текст с фактическими ошибками. Точность здесь обеспечивает только личное прохождение сценария, до буквы команд.

Что меняется в процессе через 3-6 месяцев #

Любой workflow эволюционирует. Если поначалу Codex заметно ускоряет каждую публикацию, дальше эффект становится тише и переезжает в другую плоскость:

• Вы начинаете писать чаще, потому что нет «трения старта».
• Качество публикаций становится ровным — нет «слабых» постов из-за усталости от рутины.
• Появляется привычка фиксировать правила процесса (AGENTS.md, шаблоны, чек-листы) сразу, а не «когда-нибудь».
• Перестаёте откладывать посты из-за мелких технических придирок (формат даты, длина summary, теги).

Это не «магия ИИ». Это просто разделение труда между «чем я уникально полезен» и «что можно поручить инструменту».

Практические выводы #

Если коротко, рабочая модель такая:

1. Смысл и позиция остаются у автора.
2. Codex берёт структуру и операционную рутину.
3. Качество растёт там, где есть дисциплина процесса, а не просто «сильный промпт». ✅

Автоматизация в блоге полезна не потому, что «пишет быстрее», а потому что защищает внимание автора. А внимание, в долгую, важнее любой единичной публикации.

Тема здоровья легко превращается в гонку гаджетов, протоколов и баночек. Зашёл в любой телеграм-канал «про биохак», полистал — и через неделю на полке стоят семь новых БАДов, на руке трекер сна, на диване книга про митохондрии. А базовые вещи — режим сна, ежедневное движение, нормальный завтрак — продолжают проседать.

Я хочу держать тему в более приземлённом поле: сначала базовые привычки, потом аккуратные эксперименты, и только затем — добавки, если есть для этого основания. Этот пост — не медицинская рекомендация и не «топ-10 must-have БАДов». Это попытка нарисовать карту, по которой можно ориентироваться, не теряя голову.

База, без которой не работает ничего 🛏 #

Самые надёжные улучшения лежат в простых вещах, и они банальны до зевоты:

• Сон по расписанию. Одинаковое время отбоя и подъёма (включая выходные), темнота в спальне, ограничение экранов за час до сна. Не «8 часов любой ценой», а ровные 7-8 часов в одни и те же часы.
• Движение каждый день. Прогулки, силовые, растяжка — не важно что именно, важно регулярно. Дневная норма шагов даже без зала уже даёт большой кусок пользы.
• Рацион с адекватным белком, клетчаткой и достаточной калорийностью. Не «суперфуды», не «чистое питание» в религиозном смысле, а понятный рацион без хронического дефицита.
• Управление стрессом. Простые ритуалы (вечерняя прогулка, регулярные паузы), ограничение перегруза, цифровая гигиена. Не «медитация 1 час в день», а «не работать вечером».

Если эти пункты не закрыты, «биохакинг» превращается в красивую упаковку поверх системных дыр. Купить адаптоген, чтобы компенсировать хронический недосып — это не про здоровье, это про прокрастинацию здоровья.

Биохакинг как дисциплина, а не как шоу #

Для меня биохакинг — это не про сверхчеловеческие цели типа «жить до 120 лет», а про наблюдение и микро-настройку под собственные особенности. Три принципа, без которых тема превращается в магазин:

1. Измерять только то, что будет влиять на решения. Если данные не меняют поведение, это не данные, это шум.
2. Менять по одному фактору за раз. Иначе невозможно понять, что именно сработало (и сработало ли). Ввели магний, омегу и витамин D одновременно — улучшение есть, но причина неизвестна.
3. Держать горизонт не в днях, а в месяцах. Большинство значимых изменений в самочувствии копится медленно. «Через неделю стало лучше» — обычно эффект новизны, а не реальный сдвиг.

Эти три правила сами по себе отсекают 80% эзотерических протоколов из соцсетей. Если автор предлагает «попробуй и сразу почувствуешь разницу» — он не про дисциплину, он про маркетинг.

Анализы и данные: когда они действительно нужны 📊 #

Слепая сдача десятков анализов «потому что в соседнем чате посоветовали» редко помогает. Полезнее идти от вопросов:

• Что именно я хочу улучшить или понять?
• Есть ли симптомы или жалобы?
• Что из результатов повлияет на конкретные действия?

Если ответов нет — анализы становятся способом успокоиться, а не инструментом управления.

Несколько маркеров, которые часто имеют смысл проверять (без претензии на исчерпывающий список):

• Витамин D (25-OH). В умеренных широтах хронический дефицит у большинства, особенно зимой.
• Ферритин. Маркер запасов железа; низкий часто объясняет «беспричинную» усталость.
• B12 и фолат. Особенно важно для тех, кто ограничивает мясо.
• Магний. Анализ малоинформативен (магний в основном внутри клеток), но если есть симптомы (судороги, аритмии) — стоит обсудить с врачом.
• ТТГ + Т4 свободный. Базовая щитовидка, влияет на энергию, вес, настроение.

Это не «обязательная панель», это набор «если есть жалобы — есть смысл начать отсюда».

БАДы: инструмент, а не спасение #

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

Принципы, которых я стараюсь придерживаться:

• Сначала проверка базовых привычек.
• Затем чёткая цель и ожидаемый эффект.
• И только после этого — минимальная дозировка и наблюдение за эффектом.

Если БАД нельзя описать в формате «принимаю X для Y, эффект жду через Z недель» — лучше не принимать. Это правило отсеивает «модные новинки», которые завозят все блогеры разом.

Как выбирать добавки разумно #

Простая схема, которая работает:

1. Определить цель. Сон, энергия, восстановление, дефицит по анализу. Что-то одно, не «всё сразу».
2. Проверить безопасность и совместимость. С текущими лекарствами, состояниями, образом жизни. Это отдельная работа, не пропускать.
3. Начать с одной добавки и фиксировать изменения. Дневник в три строки в день: сон, энергия, настроение. Этого достаточно.
4. Отменить, если эффекта нет или он сомнителен. Через 4-8 недель, не раньше.

И да: это не медицинская рекомендация. При сомнениях, симптомах или сложных состояниях — обсуждать с врачом, не с интернетом.

Типичные ловушки 🪤 #

Самые частые ошибки, в которые попадаются почти все, кто заходит в тему:

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

Надеяться на «волшебную таблетку». Если есть проблема со сном — никакая добавка не починит то, что чинится за неделю гигиены сна.

Забывать про доказательную базу. Многие популярные добавки имеют слабые или противоречивые исследования. «Все вокруг пьют» — не критерий.

Игнорировать побочки. Любой БАД может давать эффект, который вы спишете на «обычный день». Дневник помогает поймать.

Доверять ярким инфлюенсерам. Биохакинг — благодатная почва для красивых историй и плохих советов. Чем громче «у меня всё работает», тем выше вероятность маркетинга или selection bias.

Минимальный подход #

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

Если совсем коротко: спать в одно время, гулять каждый день, есть не «правильно», а сбалансированно, и не пить больше двух-трёх БАДов одновременно. Этого хватит большинству людей в большинстве периодов жизни.

Итоги 🧠 #

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

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

Самый честный «биохакинг» — это лечь спать на час раньше. Бесплатно, без побочек, эффект через неделю.

Терминал - это не просто интерфейс, это мощный инструмент разработчика.

🌟 Tmux: Мультиплексор Терминала #

Основы Tmux #

• Создание сессий
• Разделение окон
• Персистентность

Продвинутая Конфигурация #

# Пример .tmux.conf
set -g prefix C-a
bind-key C-a send-prefix

🐚 Современные Shell: Zsh и Fish #

Zsh #

• Автодополнение
• Темы и плагины
• Oh My Zsh

Fish Shell #

• Интуитивный синтаксис
• Встроенные подсказки
• Автодополнение

🤖 Продвинутые Скрипты #

Bash Scripting #

• Функции
• Условные операторы
• Обработка ошибок

Python в Терминале #

• Click для CLI
• Argparse
• Asyncio в скриптах

🎨 Кастомизация Рабочего Окружения #

Dotfiles #

• Управление конфигурациями
• Переносимость настроек
• Система контроля версий

Продвинутые Алиасы #

# Примеры алиасов
alias gs='git status'
alias dc='docker-compose'

Автоматизация Задач #

🛠️ Инструменты Повышения Продуктивности #

• fzf: нечеткий поиск
• ripgrep: быстрый поиск
• bat: улучшенный cat
• fd: современная замена find

🌈 Эстетика Терминала #

• Powerline шрифты
• Цветовые схемы
• Иконки и prompt

🎓 Заключение #

Терминал - это искусство. Чем больше вы практикуетесь, тем он становится мощнее!

Hugo представил версию 0.141.0, которая включает в себя важные улучшения в работе с изображениями, исправления ошибок и общие улучшения производительности. Это обновление делает работу с медиа-контентом более надёжной и эффективной.

📸 Улучшения в работе с изображениями #

В этом релизе были внесены значительные улучшения в обработку изображений:

• Добавлена поддержка для изображений с прозрачностью в формате JPEG XL
• Улучшена обработка EXIF-данных для различных форматов изображений
• Оптимизирована работа с цветовыми профилями

🛠️ Исправления ошибок #

Релиз включает несколько важных исправлений:

• Исправлена ошибка в обработке путей к изображениям в Windows
• Улучшена обработка ошибок при работе с поврежденными изображениями
• Исправлены проблемы с кэшированием при обработке изображений

⚡ Оптимизация производительности #

Были внесены улучшения в производительность:

• Оптимизирована обработка больших наборов изображений
• Улучшена эффективность использования памяти при обработке изображений
• Ускорена работа с кэшем изображений

🔄 Как обновиться #

Для обновления Hugo до версии 0.141.0 используйте следующие команды:

# Для пользователей Homebrew (macOS)
brew upgrade hugo

# Для пользователей Windows (с использованием Chocolatey)
choco upgrade hugo

# Для пользователей Linux
sudo apt update && sudo apt upgrade hugo  # Debian/Ubuntu
sudo dnf upgrade hugo                     # Fedora

📝 Заключение #

Hugo v0.141.0 представляет собой важное обновление, особенно для проектов, активно использующих работу с изображениями. Улучшения в обработке изображений и оптимизация производительности делают эту версию рекомендованной к установке для всех пользователей Hugo.

Полный список изменений доступен в официальном релизе на GitHub.

Tmux (Terminal Multiplexer) — это мощный инструмент для работы с терминалом, который позволяет создавать несколько виртуальных терминалов внутри одного окна, управлять сессиями и сохранять рабочее окружение даже после отключения. В этой статье мы рассмотрим основные возможности tmux и научимся эффективно использовать его в повседневной работе.

🚀 Основные возможности tmux #

Ключевые преимущества #

• 📌 Сохранение сессий между подключениями
• 📌 Разделение окна на панели
• 📌 Создание нескольких окон в одной сессии
• 📌 Копирование и вставка текста между панелями
• 📌 Настраиваемые горячие клавиши
• 📌 Поддержка скриптов и автоматизации

🛠️ Установка и настройка #

Установка tmux #

На macOS с помощью Homebrew:

brew install tmux

На Ubuntu/Debian:

sudo apt install tmux

Базовая конфигурация #

Создайте файл ~/.tmux.conf с базовыми настройками:

# Изменение префикса на Ctrl+a
set -g prefix C-a
unbind C-b
bind C-a send-prefix

# Включение поддержки мыши
set -g mouse on

# Начинать нумерацию окон с 1
set -g base-index 1
setw -g pane-base-index 1

# Улучшение цветопередачи
set -g default-terminal "screen-256color"

📚 Основные команды #

Управление сессиями #

• 🔷 Создание новой сессии: tmux new -s имя_сессии
• 🔷 Подключение к существующей сессии: tmux attach -t имя_сессии
• 🔷 Список сессий: tmux ls
• 🔷 Отключение от сессии: Prefix + d
• 🔷 Переименование сессии: Prefix + $

Работа с окнами #

• 🔷 Создание нового окна: Prefix + c
• 🔷 Переключение между окнами: Prefix + номер_окна
• 🔷 Переименование окна: Prefix + ,
• 🔷 Закрытие окна: Prefix + &

Управление панелями #

• 🔷 Разделить горизонтально: Prefix + "
• 🔷 Разделить вертикально: Prefix + %
• 🔷 Переключение между панелями: Prefix + стрелки
• 🔷 Изменение размера панели: Prefix + Alt + стрелки
• 🔷 Закрытие панели: Prefix + x

🎯 Продвинутые техники #

Копирование и вставка #

1. Вход в режим копирования: Prefix + [
2. Перемещение курсора к началу текста
3. Начало выделения: Space
4. Выделение текста
5. Копирование в буфер: Enter
6. Вставка: Prefix + ]

Синхронизация панелей #

# Включение синхронного ввода во все панели
:setw synchronize-panes on

# Выключение синхронного ввода
:setw synchronize-panes off

Сохранение и восстановление сессий #

Используйте плагин tmux-resurrect для сохранения состояния сессий:

# Установка через tpm (Tmux Plugin Manager)
set -g @plugin 'tmux-plugins/tmux-resurrect'

# Сохранение сессии: Prefix + Ctrl-s
# Восстановление сессии: Prefix + Ctrl-r

💡 Полезные советы #

Эффективная работа #

1. Используйте осмысленные имена для сессий и окон
2. Создавайте отдельные сессии для разных проектов
3. Используйте скрипты для автоматического создания рабочего окружения
4. Настройте статусную строку для отображения важной информации

Пример скрипта для создания рабочего окружения #

#!/bin/bash
# Создание новой сессии
tmux new-session -d -s dev

# Разделение окна
tmux split-window -h
tmux split-window -v

# Запуск команд в панелях
tmux send-keys -t 0 'vim' C-m
tmux send-keys -t 1 'git status' C-m
tmux send-keys -t 2 'htop' C-m

# Подключение к сессии
tmux attach-session -d -t dev

📝 Заключение #

Tmux — это мощный инструмент, который значительно повышает эффективность работы в терминале. Начните с базовых команд и постепенно добавляйте новые возможности в свой рабочий процесс. С практикой вы сможете создавать сложные рабочие окружения и эффективно управлять множеством терминальных сессий.

Рекомендуется:

1. Создать собственный конфигурационный файл
2. Изучить и настроить горячие клавиши под свои нужды
3. Использовать плагины для расширения функциональности
4. Регулярно практиковаться в использовании новых команд

Hugo выпустил версию 0.140.2, в которой основное внимание уделено важному исправлению безопасности. Обновление затрагивает функцию html.Parse из пакета golang.org/x/net, которая используется в двух ключевых компонентах Hugo: при извлечении оглавления из вывода Asciidoctor и при сборе HTML-классов во время включенной статистики сборки.

🔒 Исправление безопасности #

Хотя вероятность эксплуатации уязвимости в контексте Hugo оценивается как невысокая, это обновление:

• Устраняет потенциальные риски безопасности
• Обеспечивает более чистый отчет безопасности
• Поддерживает высокие стандарты безопасности проекта

🔧 Технические улучшения #

Обновления зависимостей #

• ✨ Пакет golang.org/x/net обновлен с версии 0.32.0 до 0.33.0
• ✨ Улучшена стабильность и безопасность системы

Исправления ошибок #

• 🐛 Устранена проблема с конфигурацией языковых настроек
• 🐛 Исправлена ошибка многократной публикации одного ресурса
• 🐛 Добавлена проверка определения формата вывода

Улучшения функциональности #

• 📝 Добавлена документация по использованию hugo gen chromastyles с CSS
• 🎨 В подсветку синтаксиса добавлена опция wrapperClass
• 🔍 Улучшена обработка ошибок и информативность сообщений

📚 Рекомендации по обновлению #

Рекомендуется обновить Hugo до версии 0.140.2 по следующим причинам:

1. Повышение уровня безопасности системы
2. Улучшенная обработка ошибок
3. Новые возможности подсветки синтаксиса
4. Исправления в работе с ресурсами

🔍 Заключение #

Hugo v0.140.2 представляет собой важное обновление безопасности, которое также включает ряд полезных улучшений и исправлений. Хотя риск эксплуатации уязвимости в существующих установках Hugo минимален, обновление рекомендуется для поддержания высокого уровня безопасности и стабильности вашего сайта.

23 декабря 2024 года команда Hugo выпустила версию 0.140.1, которая, вероятно, станет последним обновлением в уходящем году. Этот релиз фокусируется на улучшении стабильности и исправлении ошибок в различных компонентах системы.

🔧 Основные улучшения #

Улучшенная поддержка облачных хранилищ #

• ✨ Обновлена интеграция с gocloud
• ✨ Улучшена документация для S3-совместимых конечных точек
• ✨ Расширена поддержка различных S3-совместимых сервисов хранения

JavaScript и сборка #

• 🔍 Оптимизирована работа js/esbuild
• 🔍 Исключены лишние попытки разрешения пакетов в /assets
• 🔍 Повышена стабильность процесса сборки

Работа с ресурсами #

• 📦 Исправлены функции для временных ресурсов:
  • Объединение
  • Дополнение
  • Симметричная разность
  • Пересечение

Улучшения в развертывании #

• 🚀 Добавлены расширенные deb-архивы
• 🚀 Улучшена поддержка деплоя
• 🚀 Расширены возможности для развертывания

🛠 Технические улучшения #

Система логирования #

• 📝 Изменен вывод PrintTimerIfDelayed
• 📝 Логи теперь направляются в stderr
• 📝 Улучшена общая обработка логов

Обновления зависимостей #

• 📚 Обновлена библиотека github.com/spf13/cast
• 📚 Версия обновлена с 1.7.0 до 1.7.1
• 📚 Включены последние исправления и улучшения

Система меню #

• 🔄 Исправлена обработка резервных значений
• 🔄 Улучшена работа с полями Name и Title
• 🔄 Добавлена корректная обработка отсутствующих значений

🔨 Изменения в инструментах разработки #

Важное изменение коснулось инструмента hugoreleaser:

• 🔄 Переход с TOML на YAML для конфигурации релизов
• 🔄 Упрощение процесса настройки
• 🔄 Улучшение читаемости конфигурационных файлов

📝 Заключение #

Hugo v0.140.1 завершает 2024 год набором важных улучшений, направленных на повышение стабильности и удобства использования фреймворка. Особое внимание было уделено работе с облачными хранилищами, системе сборки JavaScript и улучшению процесса развертывания.

Рекомендуется обновиться до этой версии, особенно если вы используете S3-совместимые хранилища или активно работаете с JavaScript в своих проектах. Новые deb-архивы с поддержкой деплоя также могут быть полезны для оптимизации процесса развертывания.

Gitea предоставляет мощный API, который позволяет автоматизировать различные задачи и интегрировать Gitea с другими системами. Это делает Gitea гибким инструментом для DevOps и разработки.

Почему использовать API Gitea? #

• Автоматизация: Позволяет автоматизировать рутинные задачи.
• Интеграция: Легко интегрируется с другими инструментами и сервисами.
• Гибкость: Позволяет создавать кастомные решения.

🔧 Основы работы с API #

Аутентификация #

Для работы с API Gitea требуется аутентификация с использованием токена доступа. Создайте токен в настройках вашего профиля Gitea.

Пример использования API #

Получение списка репозиториев #

curl -H "Authorization: token YOUR_TOKEN" \
    https://gitea.example.com/api/v1/user/repos

Создание нового репозитория #

curl -X POST -H "Authorization: token YOUR_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"name": "new-repo"}' \
    https://gitea.example.com/api/v1/user/repos

🛠️ Автоматизация с использованием API #

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

Пример скрипта на Python для автоматизации создания репозитория:

import requests

# Настройки
api_url: "https://gitea.example.com/api/v1/user/repos"
token: "YOUR_TOKEN"
headers: {
    "Authorization": f"token {token}",
    "Content-Type": "application/json"
}
data: {
    "name": "automated-repo"
}

# Создание репозитория
response: requests.post(api_url, headers=headers, json=data)

if response.status_code == 201:
    print("Репозиторий успешно создан!")
else:
    print("Ошибка при создании репозитория:", response.json())

📚 Заключение #

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

Hugo продолжает развиваться и совершенствоваться. В новой версии v0.140.0 разработчики представили важное нововведение для работы с JavaScript, а также внесли множество улучшений и исправлений. Давайте подробно рассмотрим, что нового появилось в этом релизе.

🔥 Главное нововведение: js.Batch #

Ключевым обновлением в Hugo v0.140.0 стала функция js.Batch. Это мощный инструмент для организации JavaScript-кода, который предоставляет следующие возможности:

• Создание групп JavaScript-файлов для разных разделов сайта
• Глобальное разделение кода между группами
• Гибкая настройка хуков и порядка выполнения
• Эффективное управление зависимостями

Эта функция особенно полезна при разработке сложных сайтов, где требуется четкая организация JavaScript-кода и оптимизация его загрузки.

🛠 Исправления ошибок #

В этом релизе было исправлено несколько важных ошибок:

Стабильность и производительность #

• ✅ Устранена паника при перестроении сервера при использовании базовых шаблонов с template.Defer
• ✅ Улучшена работа js.Batch в конфигурациях с несколькими сайтами
• ✅ Исправлены проблемы с перестроением при переименовании ресурсов

Форматирование и парсинг #

• ✅ Корректная работа разделителя аннотаций в Org Mode
• ✅ Исправлен атрибут title в шорткоде details
• ✅ Улучшен парсинг текста в хуке рендеринга цитат

Работа с ресурсами #

• ✅ Правильная обработка импортов Sass для файлов формата index.{scss,sass}

💡 Улучшения и новые возможности #

Обновления esbuild #

• 🆕 Добавлена поддержка цели es2024
• 🆕 Возможность запуска после выполнения скриптов
• 🆕 Оптимизированное построение групп в порядке идентификаторов

Улучшения шорткодов и функций #

• 📦 Обновлены шорткоды youtube и details
• 📦 В функцию querify добавлена поддержка аргумента типа map
• 📦 Добавлен новый шорткод details в tpl/tplimpl

Оптимизация js.Batch #

• 🔧 Предотвращение создания пустого среза Instances
• 🔧 Улучшенная интеграция с многосайтовыми конфигурациями

📝 Заключение #

Hugo v0.140.0 представляет собой важное обновление, которое значительно улучшает работу с JavaScript и исправляет множество ошибок. Новая функция js.Batch открывает дополнительные возможности для организации и оптимизации JavaScript-кода на сайтах, построенных с помощью Hugo.

Рекомендуется обновиться до новой версии, особенно если вы активно используете JavaScript в своих проектах или сталкивались с какими-либо из исправленных ошибок.

Для получения более подробной информации и загрузки новой версии посетите официальную страницу релиза на GitHub.

🚀 Версия 0.144.0 #

Это крупное обновление Hugo, выпущенное незадолго до 19 февраля 2025 года, принесло ряд важных изменений и улучшений:

🎯 Новые возможности #

• Добавлены новые токены для постоянных ссылок: :contentbasename и :slugorcontentbasename (заменяют устаревшие :filename и :slugorfilename)
• Введена настройка parser.autoDefinitionTermID для автоматического добавления атрибутов id к элементам dt в списках определений
• Добавлена поддержка меню в виде карт (maps) в адаптерах контента
• Реализована опция drop для js.esbuild
• Добавлена поддержка GOAUTH в конфигурации модулей

🐛 Исправления ошибок #

• Исправлена паника при обработке пустых заголовков Markdown
• Устранена проблема с позиционированием для проходных хуков
• Исправлена ошибка, когда server.redirects.fromRe игнорировался, если не был установлен server.redirects.from
• Улучшено сообщение об ошибке для самозакрывающихся шорткодов без .Inner

⚡ Улучшения #

• Обновлен Go до версии 1.24
• Улучшена обработка автоматически генерируемых ID заголовков
• Добавлена поддержка autoID для терминов определений
• Включено расширение KaTeX mhchem
• Добавлены новые опции сервера

⚠️ Устаревания #

• Объявлены устаревшими kind, lang и path во фронтматтере

🔧 Версия 0.144.1 #

Это небольшое обновление, выпущенное вскоре после 0.144.0, фокусируется на исправлении критической ошибки:

🐛 Исправление ошибки #

• Устранена паника при обработке пустых заголовков Markdown

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

WezTerm - это мощный, современный терминальный эмулятор с открытым исходным кодом, написанный на Rust. Благодаря использованию GPU-ускорения и оптимизированному коду, он обеспечивает молниеносную производительность и плавную работу даже с большими объемами данных.

✨ Ключевые особенности #

📑 Мультиплексирование и вкладки #

• Встроенная поддержка вкладок и разделения окон
• Мультиплексирование без необходимости использования tmux
• Удобное переключение между сессиями с помощью горячих клавиш
• Сохранение и восстановление рабочих сессий

🚄 Поддержка GPU #

• Аппаратное ускорение рендеринга текста
• Плавная прокрутка и анимации без задержек
• Эффективная работа с большими объемами текста
• Поддержка OpenGL и DirectX

🎨 Кастомизация #

• Гибкая конфигурация на Lua
• Поддержка пользовательских цветовых схем
• Настраиваемые горячие клавиши и команды
• Расширенные возможности стилизации

🌍 Кроссплатформенность #

• Нативная поддержка macOS, Linux и Windows
• Единообразный опыт на всех платформах
• Поддержка различных shell’ов
• Интеграция с системными возможностями

🛠️ Установка #

macOS #

brew install --cask wezterm

Linux #

curl -LO https://github.com/wez/wezterm/releases/download/nightly/wezterm-nightly.Ubuntu20.04.deb
sudo apt install ./wezterm-nightly.Ubuntu20.04.deb

Windows #

winget install wez.wezterm

⚙️ Базовая настройка #

1. Создайте файл конфигурации:

mkdir -p ~/.config/wezterm
touch ~/.config/wezterm/wezterm.lua

1. Добавьте базовую конфигурацию:

local wezterm = require 'wezterm'

return {
  -- Шрифт и размер
  font = wezterm.font("JetBrains Mono"),
  font_size = 14.0,
  
  -- Цветовая схема
  color_scheme = "Catppuccin Mocha",
  
  -- Настройки интерфейса
  enable_tab_bar = true,
  use_fancy_tab_bar = false,
  window_padding = {
    left = 2,
    right = 2,
    top = 0,
    bottom = 0,
  },
  
  -- Производительность
  animation_fps = 60,
  enable_wayland = true,
  webgpu_preferred_adapter = wezterm.gpu_adapters.discrete,
}

⌨️ Горячие клавиши #

Буфер обмена #

Управление окнами #

Управление вкладками #

Разделение панелей #

Размер панелей #

Шрифт и отображение #

Навигация и поиск #

Дополнительные функции #

💡 Примечание: Все горячие клавиши можно настроить в конфигурационном файле. На macOS доступны комбинации с ⌘, на других системах используйте ⌃⇧.

🏆 Преимущества #

1. Производительность #

• 🚀 GPU-ускорение для плавной работы
• ⚡ Минимальная задержка ввода
• 📊 Эффективное использование ресурсов
• 🔄 Оптимизированный рендеринг

2. Функциональность #

• 📑 Встроенное мультиплексирование
• 🖼️ Поддержка изображений в терминале
• 🔤 Лигатуры и эмодзи
• 🔍 Встроенный поиск

3. Настраиваемость #

• ⚙️ Мощный конфигурационный язык
• 🎨 Широкие возможности кастомизации
• 🔌 Поддержка плагинов
• 🎯 Гибкие правила

4. Стабильность #

• 🛡️ Написан на безопасном Rust
• 📈 Активная разработка
• 👥 Большое сообщество
• 🔒 Регулярные обновления

📝 Заключение #

WezTerm представляет собой современное решение для разработчиков, системных администраторов и power-users, которым важна производительность, гибкость и удобство работы в терминале. Благодаря GPU-ускорению, мощной системе конфигурации на Lua и активному развитию, WezTerm становится все более популярным выбором среди профессионалов.

Попробуйте WezTerm, если вы ищете:

• 🚀 Максимальную производительность
• 🎨 Гибкую настройку
• 📑 Встроенное мультиплексирование
• 🌍 Кроссплатформенность
• 🛡️ Надежность и стабильность

В мире разработки программного обеспечения появился новый игрок - Windsurf IDE. Это не просто еще одна среда разработки, а революционный инструмент, который интегрирует в себя мощного AI-ассистента Cascade. В этой статье мы рассмотрим основные особенности Windsurf и то, как он может изменить процесс разработки.

🤖 Что такое Windsurf IDE #

Windsurf - это первая в мире агентная среда разработки (IDE), созданная с фокусом на взаимодействие с искусственным интеллектом. Главная особенность Windsurf - это встроенный AI-ассистент Cascade, разработанный командой Codeium, который работает на основе революционной парадигмы AI Flow.

💡 Ключевые особенности #

AI-ассистент Cascade #

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

Интеграция с проектом #

• Глубокое понимание структуры проекта
• Автоматический анализ зависимостей
• Умное автодополнение кода
• Рефакторинг с учетом всего контекста

Пользовательский опыт #

• Современный и интуитивный интерфейс
• Быстрый отклик системы
• Удобная навигация по проекту
• Встроенные инструменты для работы с git

🔧 Как работает AI Flow #

AI Flow - это новая парадигма взаимодействия с искусственным интеллектом в процессе разработки. Она позволяет:

• Вести естественный диалог с AI-ассистентом
• Получать контекстно-зависимые предложения
• Автоматизировать рутинные задачи
• Получать объяснения предлагаемых решений

💪 Преимущества использования #

Для разработчиков #

• Ускорение процесса разработки
• Уменьшение количества ошибок
• Автоматизация рутинных задач
• Обучение лучшим практикам

Для команд #

• Улучшение качества кода
• Единый стиль кодирования
• Быстрая адаптация новых членов команды
• Эффективное решение сложных задач

🎓 Примеры использования #

Создание нового проекта #

Windsurf может помочь с:

• Генерацией базовой структуры проекта
• Настройкой зависимостей
• Созданием конфигурационных файлов
• Написанием базовой документации

Рефакторинг существующего кода #

AI-ассистент способен:

• Анализировать качество кода
• Предлагать улучшения
• Находить потенциальные проблемы
• Оптимизировать производительность

📈 Будущее развития #

Windsurf IDE находится в активной разработке, и команда постоянно работает над:

• Улучшением возможностей AI-ассистента
• Добавлением новых функций
• Оптимизацией производительности
• Расширением поддержки языков и фреймворков

🎯 Заключение #

Windsurf IDE представляет собой значительный шаг вперед в развитии инструментов разработки. Интеграция AI-ассистента Cascade и использование парадигмы AI Flow создают уникальный опыт разработки, который может существенно повысить продуктивность программистов и качество создаваемого кода.

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

🔤 Введение в Markdown Typography #

Markdown - это легкий язык разметки, который позволяет форматировать текст с минимальными усилиями. Этот гайд покажет все возможности типографики.

📝 Основы форматирования текста #

Синтаксис Заголовков #

Markdown поддерживает 6 уровней заголовков:

Пример Синтаксиса #

## Заголовок второго уровня
### Заголовок третьего уровня
#### Заголовок четвертого уровня
##### Заголовок пятого уровня
###### Заголовок шестого уровня

Визуальное Представление Заголовков #

Заголовок второго уровня #

Заголовок третьего уровня #

Заголовок четвертого уровня #

Заголовок пятого уровня #

Заголовок шестого уровня #

Стили Текста #

Демонстрация Стилей Текста #

**Жирный текст**
*Курсивный текст*
***Жирный курсив***
~~Зачеркнутый текст~~

Результат Применения Стилей #

Жирный текст Курсивный текст Жирный курсив Зачеркнутый текст

📋 Типы Списков #

Нумерованные Списки #

Пример Нумерованного Списка #

1. Первый элемент
2. Второй элемент
3. Третий элемент

Визуализация Нумерованного Списка #

1. Первый элемент
2. Второй элемент
3. Третий элемент

Ненумерованные Списки #

Пример Ненумерованного Списка #

- Первый элемент
- Второй элемент
  - Подэлемент
- Третий элемент

Визуализация Ненумерованного Списка #

• Первый элемент
• Второй элемент
  • Подэлемент
• Третий элемент

🖋️ Дополнительные Элементы Разметки #

Цитаты #

Пример Цитаты #

> Это основная цитата
> 
> С несколькими строками

Визуализация Цитаты #

Это основная цитата

С несколькими строками

Код #

Встроенный Код #

Синтаксис Встроенного Кода #

`Встроенный код в тексте`

Результат Встроенного Кода #

Встроенный код в тексте

Блоки Кода #

Пример Блока Кода #

```python
def hello_world():
    print("Привет, мир!")

##### Визуализация Блока Кода

```python
def hello_world():
    print("Привет, мир!")

Сноски #

Синтаксис Сносок #

Текст с первой сноской[^1]. 
Текст со второй сноской[^2].

[^1]: Первая сноска
[^2]: Вторая сноска

Результат Сносок #

Текст с первой сноской1. Текст со второй сноской2.

Горизонтальная Линия #

Синтаксис Линии #

---

🔗 Ссылки и Изображения #

Гиперссылки #

Примеры Ссылок #

[Ссылка на сайт](https://example.com)
[Ссылка с title](https://example.com "Описание сайта")

Визуализация Ссылок #

Ссылка на сайт Ссылка с title

Изображения #

Синтаксис Изображений #

![Логотип Markdown](https://upload.wikimedia.org/wikipedia/commons/4/48/Markdown-mark.svg)
![GitHub логотип](https://github.githubassets.com/images/modules/logos_page/GitHub-Mark.png)

Галерея Изображений #

🌟 Расширенный синтаксис #

Таблицы #

Пример Таблицы #

| Колонка 1 | Колонка 2 | Колонка 3 |
|-----------|-----------|-----------|
| Строка 1  | Данные    | Инфо      |
| Строка 2  | Значение  | Данные    |

Визуализация Таблицы #

Задачи #

Пример Задач #

- [x] Выполненная задача
- [ ] Невыполненная задача
- [x] Еще одна выполненная

Визуализация Задач #

• Выполненная задача
• Невыполненная задача
• Еще одна выполненная

💡 Советы и best practices #

1. Используйте консистентный стиль
2. Не перегружайте текст
3. Помните о читаемости
4. Экспериментируйте

📚 Полезные ресурсы #

• Официальное руководство Markdown
• GitHub Markdown Guide

🤔 Заключение #

Markdown - мощный и простой инструмент для форматирования текста. Практикуйтесь и открывайте для себя новые возможности!

123412341234123412341234

CCJo+al+vu,amWsnecbr1,i,ApCstos,leCumSmbSnl,yH2T,MCLolumn3

1. Первая сноска ↩︎
2. Вторая сноска ↩︎

Tea - это мощный инструмент для разработчиков, который позволяет управлять репозиториями, issue и pull request прямо из терминала. Он особенно полезен для DevOps-инженеров и разработчиков, которые предпочитают работать с командной строкой. Используя Tea, вы можете автоматизировать многие рутинные задачи и интегрировать его в свои рабочие процессы.

Зачем использовать Tea? #

• Ускорение рабочих процессов: Tea позволяет быстро выполнять команды, не переключаясь между интерфейсами.
• Автоматизация задач: Используйте скрипты для автоматизации рутинных операций.
• Интеграция с CI/CD: Легко интегрируйте Tea в ваши процессы непрерывной интеграции и доставки.

Установка #

macOS #

Для установки Tea на macOS используйте Homebrew:

brew install tea

После установки проверьте, что Tea установлен корректно, выполнив:

tea --version

Linux #

Для установки на Linux выполните следующие шаги:

1. Загрузите бинарный файл:

wget https://dl.gitea.com/tea/latest/tea-amd64

1. Сделайте файл исполняемым:

chmod +x tea-amd64

1. Переместите файл в директорию, доступную в PATH:

sudo mv tea-amd64 /usr/local/bin/tea

1. Проверьте установку:

tea --version

🔐 Аутентификация #

Создание токена в Gitea #

1. Перейдите в настройки профиля на вашем Gitea-сервере.
2. Выберите “Настройки приложений” и создайте новый токен доступа.
3. Сохраните токен в безопасном месте.

Настройка Tea #

Для настройки Tea выполните команду:

tea login add

Следуйте интерактивным инструкциям для ввода вашего токена и настройки соединения.

🗂️ Работа с Репозиториями #

Список репозиториев #

Чтобы получить список всех ваших репозиториев, используйте:

tea repos

Вы можете фильтровать и сортировать список по различным критериям.

Клонирование репозитория #

Клонируйте репозиторий с помощью команды:

tea clone username/repository

Эта команда создаст локальную копию указанного репозитория.

Создание нового репозитория #

Создайте новый репозиторий с помощью:

tea create repo --name my-new-project

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

🐞 Управление Issue #

Список Issue #

Получите список всех issue, связанных с вашим аккаунтом:

tea issues

Используйте фильтры для отображения только открытых или закрытых issue.

Создание Issue #

Создайте новое issue с подробным описанием:

tea create issue \
    --title "Новая задача" \
    --description "Подробное описание" \
    --repo username/repository

Закрытие Issue #

Закройте issue по его номеру:

tea close issue 42

🔀 Работа с Pull Request #

Список Pull Request #

Получите список всех pull request:

tea pulls

Создание Pull Request #

Создайте новый pull request для слияния изменений:

tea create pr \
    --base main \
    --head feature-branch \
    --title "Новый функционал" \
    --description "Детали изменений"

Слияние Pull Request #

Слейте pull request, указав его номер:

tea merge pr 10

🌐 Дополнительные Команды #

Просмотр веток #

Просмотрите все ветки в репозитории:

tea branches

Просмотр релизов #

Получите информацию о всех релизах:

tea releases

🛠️ Полезные Советы #

• Используйте флаг -r для указания репозитория при выполнении команд.
• Настройте автодополнение команд в вашем shell для ускорения работы.
• Регулярно обновляйте Tea, чтобы использовать последние функции и исправления.

📚 Заключение #

Tea значительно упрощает работу с Gitea, предоставляя мощный инструмент для управления репозиториями прямо из терминала. Он помогает автоматизировать рабочие процессы и интегрируется с различными инструментами DevOps, делая вашу работу более эффективной.

Obsidian - это powerful markdown-редактор и менеджер знаний нового поколения, который позволяет создавать связанную базу знаний на основе локальных markdown-файлов.

Ключевые преимущества #

1. Локальное хранение: Все ваши заметки хранятся локально на устройстве
2. Markdown-совместимость: Полная поддержка markdown
3. Связывание заметок: Возможность создавать wiki-links между документами
4. Расширяемость: Большое количество плагинов
5. Приватность: Никаких облачных синхронизаций по умолчанию

Установка #

macOS #

1. Скачать с официального сайта obsidian.md
2. Перетащить в папку Applications
3. Первый запуск - создание хранилища (Vault)

Windows/Linux #

1. Скачать дистрибутив с официального сайта
2. Установить через стандартный установщик
3. Запустить и создать первое хранилище

Базовая настройка #

Создание хранилища #

1. Нажать “New vault”
2. Выбрать директорию
3. Дать название хранилищу

Основные настройки #

• Темы: Настройка внешнего вида
• Плагины: Включение/отключение функционала
• Горячие клавиши: Кастомизация

Продвинутые техники #

Связывание заметок #

[[Название другой заметки]]  # Внутренняя ссылка

Теги #

#productivity #programming

Daily Notes #

Что такое Daily Notes? #

Daily Notes - это автоматически создаваемые ежедневные заметки, которые служат персональным дневником, трекером задач и инструментом рефлексии.

Настройка Daily Notes #

1. Базовая конфигурация #

В настройках Obsidian:

• Включить “Daily Notes” в Core Plugins
• Выбрать папку для хранения
• Настроить формат имени файла

Формат: YYYY-MM-DD.md
Пример: 2024-01-13.md

2. Шаблонизация #

Создайте шаблон для ежедневных заметок:

# {{date:YYYY-MM-DD}} - День {{date:dddd}}

## Утренние намерения
- [ ] Основная цель дня
- [ ] Приоритетные задачи

## Задачи
### Критично
- [ ] 

### Важно
- [ ] 

### Второстепенно
- [ ] 

## Трекинг
- Сон: 
- Вода: 
- Физическая активность: 

## Рефлексия
### Что прошло хорошо
- 

### Что можно улучшить
- 

## Заметки
- 

## Связанные заметки

3. Плагины для расширения функционала #

1. Templater

   • Динамическая генерация шаблонов
   • Поддержка скриптов JavaScript
   • Автоматическое заполнение метаданных

2. Calendar

   • Визуальный календарь
   • Быстрый переход между Daily Notes
   • Индикация заполненных дней

4. Автоматизация с Templater #

Пример скрипта для автоматизации:

// Получение списка незавершенных задач из предыдущего дня
async function getPreviousDayTasks() {
    const previousDate = moment().subtract(1, 'days').format('YYYY-MM-DD');
    const previousFile = await app.vault.getMarkdownFiles()
        .find(file => file.name === `${previousDate}.md`);
    
    if (previousFile) {
        const content = await app.vault.read(previousFile);
        // Логика извлечения незавершенных задач
    }
}

5. Стратегии использования #

• Утренний ritual: Заполнение намерений
• Вечерний review: Рефлексия и анализ дня
• Еженедельный и ежемесячный обзор

6. Продвинутые техники #

• Создание персональной системы треков
• Интеграция с проектным планированием
• Анализ продуктивности через Dataview

7. Приватность и безопасность #

• Использование .gitignore для исключения Daily Notes
• Настройка шифрования для личных заметок
• Регулярное резервное копирование

Best Practices #

1. Будьте последовательны
2. Не перегружайте заметки
3. Экспериментируйте с форматом
4. Используйте теги для категоризации
5. Связывайте заметки с проектами

Примеры использования #

#daily/productive 
#daily/learning
#daily/health

Интеграции #

• Todoist: Синхронизация задач
• Notion: Импорт/экспорт данных
• Apple Health: Трекинг активности

Ограничения и советы #

• Не привязывайтесь слишком сильно к шаблону
• Адаптируйте под свои нужды
• Экспериментируйте

Синхронизация #

1. Obsidian Sync: Платная официальная синхронизация
2. Git: Бесплатная синхронизация через Git-репозиторий
3. Dropbox/iCloud: Альтернативные варианты

Полезные плагины #

• Dataview: Создание динамических представлений заметок
• Templater: Продвинутые шаблоны
• Advanced Tables: Улучшенная работа с таблицами
• Kanban: Доски в стиле Trello

Безопасность #

• Шифрование хранилища
• Использование приватных репозиториев
• Регулярное резервное копирование

Заключение #

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

Полезные ресурсы #

• Официальная документация
• Форум сообщества
• Reddit-сообщество

Совет: Начните с малого, постепенно изучайте возможности и создавайте свою систему знаний!

🚀 Введение в Power User Markdown #

Если вы уже знакомы с базовым Markdown, эта статья откроет вам новые горизонты использования этого мощного инструмента разметки.

🔧 Расширенные синтаксические трюки #

Кастомные ID для заголовков #

Markdown #

### Мой заголовок {#custom-anchor}

[Ссылка на кастомный заголовок](#custom-anchor)

Результат #

Мой заголовок #

Ссылка на кастомный заголовок

Применение #

• Создание уникальных якорей
• Возможность прямой навигации
• Улучшение структуры документа

Аббревиатуры #

Markdown

*[HTML]: Hyper Text Markup Language
*[W3C]: World Wide Web Consortium

HTML - язык разметки, стандартизированный W3C.

Результат

*[HTML]: Hyper Text Markup Language *[W3C]: World Wide Web Consortium

HTML - язык разметки, стандартизированный W3C.

Преимущества

• Встроенные расшифровки терминов
• Всплывающие подсказки
• Улучшение читаемости технических текстов

💡 Продвинутое форматирование #

Математические формулы #

Markdown

\int_{a}^{b} f(x) dx = F(b) - F(a)

Результат

\int_{a}^{b} f(x) dx = F(b) - F(a)

Применение

• Научные публикации
• Технические документы
• Академические записки

Диаграммы и блок-схемы #

В современных системах документации существует множество способов визуализации алгоритмов и процессов:

• PlantUML
• Graphviz
• Mermaid
• Draw.io
• Excalidraw

Каждый из этих инструментов имеет свои преимущества:

1. PlantUML: Текстовое описание диаграмм
2. Graphviz: Генерация графов
3. Mermaid: Встраиваемые диаграммы в Markdown
4. Draw.io: Визуальный редактор
5. Excalidraw: Рукописные схемы

Возможности #

• Визуализация алгоритмов
• Построение схем процессов
• Наглядное представление логики

🎨 Расширенное форматирование #

Сноски с метками #

Markdown

Текст с расширенной сноской[^detailed].

[^detailed]: 
    Подробная сноска может содержать:
    - Многострочный текст
    - Список
    - Даже код
    
    ```python
    def example():
        return "Мощь сносок!"
    ```

Результат

Текст с расширенной сноской1.

• Многострочный текст

• Список

• Даже код

  def example():
      return "Мощь сносок!"

  copy

Преимущества #

• Многострочные сноски
• Возможность добавления кода
• Улучшенная информативность

Задачи с приоритетами #

Markdown

- [x] Высокий приоритет ⚡
- [ ] Средний приоритет 🔶
- [ ] Низкий приоритет 🕰️

Результат

• Высокий приоритет ⚡
• Средний приоритет 🔶
• Низкий приоритет 🕰️

🔬 Продвинутые техники #

Условный рендеринг #

Markdown

{% if user.is_admin %}
## Административная панель

- Управление пользователями
- Настройки системы
{% endif %}

Применение

• Динамические документы
• Контекстные руководства
• Персонализированный контент

Переменные и шаблоны #

Markdown

{%raw%}
{{ variable_name }}
{{ for item in list }}
    - {{ item }}
{{ endfor }}
{%endraw%}

Сценарии использования #

• Генерация документации
• Автоматизация контента
• Шаблонизация записей

🛠️ Полезные расширения #

1. Pandoc: Конвертация между форматами
2. Markdeep: Расширенная визуализация
3. Obsidian: Продвинутая работа с Markdown
4. VS Code: Плагины для Markdown

💪 Советы Power User #

1. Используйте линтеры для Markdown
2. Автоматизируйте форматирование
3. Создавайте собственные шаблоны
4. Экспериментируйте с расширениями

🤔 Заключение #

Markdown - это не просто разметка, это мощный инструмент для создания и структурирования контента. Постоянно изучайте новые техники!

📚 Дополнительные ресурсы #

• CommonMark Spec
• GitHub Flavored Markdown
• Markdown Guide

1. Подробная сноска может содержать: ↩︎

Если вы установили Gitea как бинарник в Linux и хотите настроить собственный Docker Registry, этот гайд для вас! 🐳 Мы рассмотрим все шаги от настройки до практического использования.

Предварительные требования 📋 #

• Установленная Gitea в виде бинарника ✅
• Установленный Docker 🐳
• Доступ к серверу с правами администратора 🔑
• Базовые навыки работы в Linux 🖥️

Шаг 1: Проверка текущей конфигурации Gitea 🕵️ #

Найдите конфигурационный файл Gitea. Обычно он расположен по пути:

/etc/gitea/app.ini

Откройте его:

nano /etc/gitea/app.ini

Шаг 2: Включение Docker Registry 🚢 #

Добавьте в app.ini следующие настройки:

[docker]
ENABLED = true
REGISTRY_HOST = registry.kushnaren.co

Шаг 3: Настройка прав доступа 🔐 #

Убедитесь, что пользователь Gitea имеет необходимые права:

# Проверьте текущего пользователя Gitea
grep User /etc/systemd/system/gitea.service

# При необходимости измените права
chown -R git:git /path/to/docker/registry

Шаг 4: Конфигурация Docker Registry 🔧 #

Создайте директорию для хранения образов:

mkdir -p /var/lib/gitea/docker-registry
chown -R git:git /var/lib/gitea/docker-registry

Шаг 5: Перезапуск Gitea 🔄 #

systemctl restart gitea

Проверка работоспособности 🕹️ #

# Проверьте статус Gitea
systemctl status gitea

# Проверьте порты
netstat -tulpn | grep gitea

Аутентификация и использование 🔑 #

# Логин в локальный Docker Registry
docker login registry.kushnaren.co

# Создание и пуш образа
docker build -t registry.kushnaren.co/username/repo/image:tag .
docker push registry.kushnaren.co/username/repo/image:tag

Безопасность 🚨 #

🔒 Дополнительные рекомендации:

• Используйте HTTPS 🔐
• Настройте fail2ban
• Регулярно обновляйте Gitea
• Используйте строгие правила паролей 🛡️

Troubleshooting 🔍 #

Частые проблемы 🛠️ #

1. Ошибки доступа 🚫

   • Проверьте права пользователя
   • Убедитесь в корректности путей

2. Проблемы с портами 🌐

   • Проверьте firewall
   • Убедитесь, что порты не заняты

Заключение 🏁 #

Docker Registry в Gitea - отличный способ иметь приватное хранилище образов прямо на вашем сервере. Следуя этой инструкции, вы легко настроите registry для вашей инфраструктуры. 🐳🚢

Полезные ссылки 🔗 #

• Официальная документация Gitea 📖
• Docker Registry Documentation 🐳

Что такое Git? #

Git - распределенная система контроля версий (DVCS), созданная Линусом Торвальдсом в 2005 году. Ключевые особенности:

• Распределенность: Каждый разработчик имеет полную копию репозитория
• Целостность: Невозможно изменить файл без ведома системы
• Производительность: Молниеносные операции
• Ветвление: Легкое создание и слияние веток

Преимущества Распределенной Системы Контроля Версий #

Распределенная природа Git предоставляет ряд существенных преимуществ:

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

   • Независимость от центрального сервера
   • Возможность работы оффлайн
   • Быстрые операции без необходимости постоянного подключения к удаленному репозиторию

2. Отказоустойчивость:

   • Каждая копия репозитория является полным бэкапом
   • Потеря одного репозитория не приводит к потере всей истории проекта

3. Гибкость рабочего процесса:

   • Легкое создание веток и экспериментирование
   • Простое совместное развитие проекта
   • Возможность работы с различными моделями разработки

Почему Git? #

1. Совместная разработка
2. Отслеживание изменений
3. Возможность отката
4. Параллельная работа

🔧 Установка и Настройка #

Установка на разных платформах #

macOS #

# Предпочтительный метод через Homebrew для простоты обновлений
brew install git

# Альтернативный способ через официальный установщик
https://git-scm.com/download/mac

Linux (Ubuntu/Debian) #

sudo apt update
sudo apt install git

Windows #

# Рекомендуется использовать Git Bash для унифицированного интерфейса
# Скачать с официального сайта: https://git-scm.com/download/win

Первичная Конфигурация #

Настройка идентификационных данных #

# Установка имени пользователя
git config --global user.name "Ваше Имя"

# Установка электронной почты
git config --global user.email "your.email@example.com"

Настройка редактора по умолчанию #

# Для Vim
git config --global core.editor "vim"

# Для Nano
git config --global core.editor "nano"

# Для VS Code
git config --global core.editor "code --wait"

Проверка конфигурации #

# Просмотр текущей конфигурации
git config --list

🏗️ Основы Работы с Репозиторием #

Создание Репозитория #

# Создание нового репозитория
mkdir my_project
cd my_project
git init

# Клонирование существующего
git clone https://github.com/username/repository.git

# Клонирование с указанием ветки
git clone -b develop https://github.com/username/repository.git

Состояния Файлов #

1. Untracked: Новый файл
2. Unmodified: Файл не изменен
3. Modified: Файл изменен
4. Staged: Файл подготовлен к коммиту

Базовые Операции #

# Проверка статуса
git status

# Добавление файлов
git add file.txt       # Один файл
git add .              # Все файлы
git add *.txt          # Все txt-файлы

# Коммит
git commit -m "Описание изменений"
git commit -am "Коммит с добавлением"

# История коммитов
git log
git log --oneline      # Краткий вид
git log -p             # С изменениями

🗂️ Основы Работы с Репозиторием #

Использование .gitignore #

Файл .gitignore позволяет исключить определенные файлы и директории из системы контроля версий:

# Игнорирование временных файлов
*.tmp
*.log

# Игнорирование директорий
node_modules/
build/
dist/

# Исключение конфиденциальных файлов
.env
*.secret

# Исключение файлов IDE
.vscode/
.idea/

Сравнение изменений с помощью git diff #

# Показать изменения в незакоммиченных файлах
git diff

# Сравнить staged изменения
git diff --staged

# Сравнение между ветками
git diff main feature-branch

🌿 Работа с Ветками #

Основы Ветвления #

# Создание ветки
git branch feature/login

# Переключение между ветками
git checkout feature/login

# Создание и переключение
git checkout -b feature/registration

# Список веток
git branch
git branch -a           # Включая удаленные

Продвинутое Ветвление #

# Переименование ветки
git branch -m old_name new_name

# Удаление ветки
git branch -d feature/login
git branch -D feature/login  # Принудительно

# Слияние веток
git merge feature/login
git merge --no-ff feature/login  # Без fast-forward

Стратегии Ветвления #

Git Flow #

Популярная модель ветвления для крупных проектов:

• main: Стабильная версия
• develop: Ветка разработки
• feature/*: Ветки новых функций
• release/*: Подготовка релизов
• hotfix/*: Критические исправления

# Создание новой ветки
git checkout -b feature/new-authentication

# Переключение между ветками
git checkout main
git checkout feature/new-authentication

# Слияние веток
git checkout main
git merge feature/new-authentication

Разрешение Конфликтов при Слиянии #

# При возникновении конфликтов
git merge feature-branch

# Открытие конфликтных файлов
# Ручное редактирование конфликтующих участков
# Удаление маркеров конфликтов (<<<<<<<, =======, >>>>>>>)

# После разрешения конфликтов
git add .
git commit

Практические Рекомендации по Работе с Ветками #

1. Создавайте отдельную ветку для каждой логически завершенной задачи
2. Используйте осмысленные названия веток
3. Регулярно синхронизируйте свою ветку с основной веткой
4. Удаляйте ветки после их слияния

🌍 Работа с Удалёнными Репозиториями #

Основы Работы с Удаленными Репозиториями #

# Добавление удаленного репозитория
git remote add origin https://github.com/username/repository.git

# Список удаленных репозиториев
git remote -v

# Загрузка изменений без слияния
git fetch origin

# Загрузка и слияние изменений
git pull origin main

Различия между git fetch и git pull #

• git fetch: Загружает изменения из удаленного репозитория БЕЗ автоматического слияния
• git pull: Загружает и СРАЗУ СЛИВАЕТ изменения с текущей веткой

Работа с Несколькими Удаленными Репозиториями #

# Добавление нескольких удаленных источников
git remote add upstream https://github.com/original/repository.git
git remote add fork https://github.com/myusername/repository.git

🧩 Дополнительные Возможности Git #

Работа с Подмодулями #

# Добавление подмодуля
git submodule add https://github.com/example/library.git libs/library

# Инициализация подмодулей
git submodule init
git submodule update

# Клонирование репозитория с подмодулями
git clone --recursive https://github.com/example/project.git

Использование Тегов #

# Создание легковесного тега
git tag v1.0.0

# Создание аннотированного тега
git tag -a v1.1.0 -m "Релиз версии 1.1.0"

# Просмотр тегов
git tag

# Отправка тегов на удаленный репозиторий
git push origin v1.0.0
git push origin --tags

🔄 Обновление Терминологии #

Переименование Основной Ветки #

# В локальном репозитории
git branch -m master main

# На удаленном репозитории (GitHub)
# 1. Изменить настройки репозитория в веб-интерфейсе
# 2. Обновить локальный репозиторий
git branch -m master main
git fetch origin
git branch -u origin/main main

💡 Лучшие Практики #

Рекомендации по Коммитам #

1. Частота коммитов:

   • Коммитьте после завершения логически законченных изменений
   • Один коммит = одна задача

2. Сообщения коммитов:

   # Шаблон сообщения коммита
   <тип>: <краткое описание>
   
   <развернутое описание (необязательно)>
   
   Примеры:
   feat: добавить аутентификацию пользователей
   fix: исправить утечку памяти в модуле кэширования
   docs: обновить README с инструкциями по установке

   copy

Рекомендуемые Ресурсы #

• Официальная документация Git
• GitHub Learning Lab
• Atlassian Git Tutorial

📚 Дополнительные Ресурсы #

• Pro Git Book
• GitHub Learning Lab
• Atlassian Git Tutorials

🎓 Заключение #

Git - это не просто инструмент, это философия совместной разработки. Чем больше вы практикуетесь, тем легче становится работать.

Практика - ключ к совершенству!

Visual Studio Code (VSCode) - это современный, легковесный, но при этом мощный редактор кода от Microsoft. В этой статье мы рассмотрим основные возможности, которые делают его одним из самых популярных IDE среди разработчиков.

История и развитие #

Visual Studio Code был впервые представлен Microsoft в 2015 году. Проект быстро завоевал популярность благодаря:

• Открытому исходному коду
• Кроссплатформенности (Windows, macOS, Linux)
• Регулярным обновлениям
• Активному сообществу разработчиков
• Высокой производительности

За годы развития VSCode превратился из простого редактора кода в полноценную среду разработки, сохранив при этом свою легковесность и скорость работы.

🚀 Основные возможности #

Интеллектуальное автодополнение #

VSCode предлагает умное автодополнение кода (IntelliSense) для множества языков программирования. Это включает:

• Подсказки по синтаксису с контекстной информацией
• Автодополнение функций и переменных с документацией
• Информацию о параметрах методов и их типах
• Быстрый доступ к документации и определениям
• Рефакторинг кода и быстрые исправления
• Анализ типов и проверку ошибок на лету
• Поддержку пользовательских определений

Встроенный терминал #

Встроенный терминал предоставляет множество возможностей:

• Выполнение команд без переключения окон
• Работа с несколькими терминалами одновременно
• Интеграция с различными оболочками:
  • bash
  • PowerShell
  • cmd
  • zsh
  • fish
• Настройка внешнего вида и поведения:
  • Выбор шрифта и размера текста
  • Настройка цветовой схемы
  • Конфигурация курсора
  • Горячие клавиши
• Поддержка разделения терминала
• История команд и автодополнение
• Интеграция с системным буфером обмена

Отладка кода #

Мощные возможности отладки включают:

• Точки останова:
  • Обычные точки останова
  • Условные точки останова
  • Логические точки останова
  • Точки останова с подсчетом попаданий
• Пошаговое выполнение:
  • Шаг с заходом
  • Шаг с обходом
  • Шаг с выходом
  • Продолжение выполнения
• Просмотр переменных:
  • Локальные переменные
  • Глобальные переменные
  • Выражения наблюдения
  • Стек вызовов
• Консоль отладки:
  • Выполнение произвольного кода
  • Просмотр значений выражений
  • Логирование отладочной информации
• Расширенные возможности:
  • Отладка нескольких процессов
  • Удаленная отладка
  • Отладка в контейнерах
  • Интеграция с отладчиками языков

Поиск и навигация #

VSCode предоставляет мощные инструменты для работы с кодом:

• Глобальный поиск по проекту:
  • Поиск по регулярным выражениям
  • Поиск с учетом регистра
  • Поиск целых слов
  • Замена с предпросмотром
• Навигация по коду:
  • Переход к определению
  • Поиск всех ссылок
  • Просмотр иерархии вызовов
  • Просмотр структуры файла
• Быстрый переход:
  • Между файлами
  • К определенной строке
  • К символу в файле
  • К символу в проекте

🔧 Расширения #

Экосистема расширений #

VSCode обладает богатой экосистемой расширений:

• Более 30,000 доступных расширений
• Простой процесс установки и обновления
• Возможность создания собственных расширений
• Рейтинг и отзывы пользователей
• Категоризация и поиск

Популярные расширения #

1. GitLens

   • Улучшенная интеграция с Git:
     • История изменений файла
     • Авторство каждой строки
     • Сравнение версий
   • Визуализация веток:
     • Графическое представление
     • Интерактивная история
     • Поиск по коммитам
   • Дополнительные функции:
     • Встроенный просмотр изменений
     • Интеграция с GitHub/GitLab
     • Расширенные настройки

2. Prettier

   • Автоматическое форматирование кода:
     • Настраиваемые правила
     • Поддержка множества языков
     • Интеграция с ESLint
   • Возможности конфигурации:
     • Отступы и переносы строк
     • Максимальная длина строки
     • Кавычки и точки с запятой
   • Интеграция с редактором:
     • Форматирование при сохранении
     • Форматирование выделенного кода
     • Горячие клавиши

3. ESLint

   • Проверка качества кода:
     • Поиск потенциальных ошибок
     • Проверка стиля кода
     • Соблюдение лучших практик
   • Настройка правил:
     • Использование готовых конфигураций
     • Создание собственных правил
     • Отключение правил
   • Автоматическое исправление:
     • Исправление при сохранении
     • Пакетное исправление файлов
     • Предпросмотр изменений

4. Live Share

   • Совместная разработка в реальном времени:
     • Совместное редактирование
     • Общий терминал
     • Общая отладка
   • Функции для команд:
     • Аудио-чат
     • Следование за участником
     • Права доступа
   • Безопасность:
     • Шифрование данных
     • Аутентификация
     • Контроль доступа

⚙️ Настройка и оптимизация #

Пользовательские настройки #

VSCode предлагает гибкие возможности настройки:

• Настройка интерфейса:
  • Темы оформления
  • Иконки файлов
  • Размер и тип шрифта
  • Расположение панелей
• Поведение редактора:
  • Автосохранение
  • Форматирование
  • Автодополнение
  • Проверка орфографии
• Горячие клавиши:
  • Настройка существующих
  • Создание новых
  • Импорт/экспорт
• Настройка языков:
  • Специфичные настройки
  • Форматтеры
  • Линтеры
  • Отладчики

Синхронизация настроек #

Встроенная система синхронизации позволяет:

• Синхронизировать между устройствами:
  • Настройки редактора
  • Установленные расширения
  • Пользовательские сниппеты
  • Горячие клавиши
• Управлять синхронизацией:
  • Выбор элементов для синхронизации
  • Разрешение конфликтов
  • История изменений
• Безопасность:
  • Шифрование данных
  • Привязка к аккаунту
  • Управление устройствами

🎯 Продвинутые функции #

Встроенный Git #

VSCode предоставляет мощную интеграцию с Git:

• Визуализация изменений:
  • Подсветка измененных строк
  • Сравнение версий
  • История изменений
• Управление ветками:
  • Создание и удаление
  • Переключение
  • Слияние
• Работа с коммитами:
  • Создание коммитов
  • Просмотр истории
  • Отмена изменений
• Интеграция с удаленными репозиториями:
  • Push/Pull операции
  • Работа с PR/MR
  • Просмотр удаленных веток

Remote Development #

Возможности удаленной разработки включают:

• Работа с контейнерами:
  • Docker интеграция
  • Devcontainer конфигурация
  • Отладка в контейнерах
• SSH подключения:
  • Безопасное подключение
  • Сохранение хостов
  • Проброс портов
• WSL интеграция:
  • Прозрачная работа
  • Доступ к файловой системе
  • Терминал WSL

Workspace Trust #

Система безопасности рабочего пространства:

• Изолированное выполнение кода
• Контроль доступа расширений
• Предупреждения о потенциальных рисках
• Настройка уровней доверия

💡 Советы по производительности #

🎮 Комбинации клавиш #

Эффективное использование горячих клавиш значительно ускоряет работу в VSCode. Вот основные комбинации по категориям:

🔍 Навигация и поиск #

• Файлы и поиск:

  • Ctrl+P - быстрый поиск файлов
  • Ctrl+Shift+P - командная палитра
  • Ctrl+Tab - переключение между файлами
  • Ctrl+G - переход к строке
  • Ctrl+T - поиск символа в проекте
  • Ctrl+Shift+O - поиск символа в текущем файле
  • Ctrl+Shift+F - поиск по всем файлам

• Панели и интерфейс:

  • Ctrl+B - скрыть/показать боковую панель
  • Ctrl+J - скрыть/показать панель терминала
  • Ctrl+Shift+E - открыть проводник
  • Ctrl+Shift+G - открыть панель Git
  • Ctrl+Shift+D - открыть панель отладки
  • Ctrl+Shift+X - открыть панель расширений
  • Alt+Z - перенос длинных строк
  • F11 - полноэкранный режим
  • Ctrl+K Z - режим Zen Mode

⌨️ Базовые операции редактирования #

• Базовое редактирование:
  • Alt+↑/↓ - перемещение строк вверх/вниз
  • Shift+Alt+↑/↓ - копирование строк вверх/вниз
  • Ctrl+Shift+K - удаление строки
  • Ctrl+Enter - вставить строку снизу
  • Ctrl+Shift+Enter - вставить строку сверху
  • Ctrl+Shift+\ - перейти к парной скобке
  • Ctrl+] - увеличить отступ
  • Ctrl+[ - уменьшить отступ

👥 Мультикурсор и выделение #

• Многокурсорное редактирование:
  • Alt+Click - добавить курсор
  • Ctrl+Alt+↑/↓ - добавить курсор сверху/снизу
  • Ctrl+D - выделить следующее вхождение
  • Ctrl+Shift+L - выделить все вхождения
  • Ctrl+F2 - выделить все вхождения текущего слова

📝 Манипуляции с текстом #

• Работа с текстом:
  • Ctrl+/ - закомментировать/раскомментировать
  • Alt+Shift+A - блочный комментарий
  • Ctrl+H - замена
  • Ctrl+Shift+V - вставить с сохранением форматирования
  • Ctrl+Space - вызвать автодополнение
  • Ctrl+K Ctrl+X - удалить лишние пробелы

🔄 Рефакторинг и навигация по коду #

• Рефакторинг:
  • F2 - переименовать символ
  • Ctrl+. - быстрые исправления
  • Shift+Alt+F - форматировать документ
  • Ctrl+K Ctrl+F - форматировать выделенный код
  • F12 - перейти к определению
  • Alt+F12 - показать определение
  • Shift+F12 - показать все ссылки

🐞 Отладка и тестирование #

• Отладка:
  • F5 - начать/продолжить отладку
  • F9 - поставить/убрать точку останова
  • F10 - шаг с обходом
  • F11 - шаг с заходом
  • Shift+F11 - шаг с выходом
  • Ctrl+Shift+F5 - перезапустить отладку
  • Shift+F5 - остановить отладку

📦 Управление Git #

• Основные операции:
  • Ctrl+Shift+G G - открыть панель Git
  • Ctrl+Enter - зафиксировать изменения (в панели Git)
  • Ctrl+Shift+P затем >git - доступ ко всем командам Git
  • Alt+←/→ - навигация по истории изменений файла

💻 Работа с терминалом #

• Управление терминалом:
  • `Ctrl+`` - открыть/закрыть терминал
  • `Ctrl+Shift+`` - создать новый терминал
  • Ctrl+Alt+←/→ - переключение между терминалами
  • Ctrl+Shift+C - копировать выделенное
  • Ctrl+Shift+V - вставить в терминал

⚙️ Персонализация редактора #

• Настройка редактора:
  • Ctrl+, - открыть настройки
  • Ctrl+K Ctrl+S - открыть горячие клавиши
  • Ctrl+K Ctrl+T - изменить тему оформления

💡 Рекомендации по использованию #

• Создайте свои собственные сочетания клавиш для часто используемых операций
• Используйте командную палитру (Ctrl+Shift+P) для поиска команд, которые вы не помните
• Постепенно добавляйте новые горячие клавиши в свой рабочий процесс
• Распечатайте или сохраните шпаргалку с самыми важными комбинациями

Сниппеты #

Работа со сниппетами кода:

• Создание сниппетов:
  • Определение триггеров
  • Использование плейсхолдеров
  • Табуляция между полями
• Использование:
  • Автодополнение
  • Вставка через командную палитру
  • Импорт готовых сниппетов
• Организация:
  • По языкам
  • По проектам
  • Глобальные сниппеты

Профили #

Работа с профилями VSCode:

• Создание профилей для разных задач
• Переключение между профилями
• Экспорт и импорт профилей
• Синхронизация профилей

📚 Заключение #

Visual Studio Code предоставляет отличный баланс между простотой использования и мощными функциями разработки. Благодаря:

• Обширной экосистеме расширений
• Активному сообществу
• Регулярным обновлениям
• Открытому исходному коду

VSCode продолжает развиваться и адаптироваться под нужды современной разработки. Это делает его надежным выбором для:

• Веб-разработчиков
• Системных программистов
• Data Scientists
• DevOps инженеров
• И многих других специалистов

Будущее развития #

Microsoft активно развивает VSCode, добавляя новые возможности:

• Улучшенная поддержка AI и ML
• Расширенные возможности удаленной работы
• Оптимизация производительности
• Новые инструменты для совместной разработки

Это делает VSCode не просто редактором кода, а полноценной платформой для разработки программного обеспечения.

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

🎯 Преимущества использования чат-бота #

• Автоматизация рутинных задач: генерация кода, документации, тестов
• Быстрые ответы на вопросы: поиск по документации и кодовой базе
• Помощь в отладке: анализ ошибок и предложение решений
• Улучшение процессов: рекомендации по оптимизации кода и архитектуры

🛠️ Пошаговое руководство по настройке #

📋 Подготовительный этап #

• Выбор задач для автоматизации
• Определение необходимых интеграций
• Оценка требований к безопасности

🔍 Выбор оптимальной платформы #

• Анализ доступных решений
• Оценка возможностей API
• Проверка совместимости с инструментами разработки

🔄 Процесс интеграции #

• Настройка окружения
• Подключение к системе контроля версий
• Настройка прав доступа

📚 Документирование системы #

• Документирование команд и возможностей
• Описание процесса взаимодействия
• Примеры использования

⚙️ Ключевые аспекты настройки #

🔒 Настройка безопасности системы #

• Контроль доступа к конфиденциальной информации
• Аутентификация и авторизация
• Логирование действий

🎨 Конфигурация рабочего контекста #

• Определение области знаний
• Настройка специфичных для проекта команд
• Создание пользовательских сценариев

📊 Система мониторинга и улучшений #

• Отслеживание использования
• Сбор обратной связи
• Регулярное обновление возможностей

📋 Организация файла инструкций #

📝 Базовая структура документации #

# Инструкции для AI Chat Bots

## Цель
- Описание основной цели использования бота
- Ключевые задачи и ограничения

## Ключевые моменты
- Используемый фреймворк и его версия
- Формат конфигурации
- Основной язык проекта
- Структура контента
- Расположение файлов

🔧 Рекомендации по ведению документации #

• Храните файл инструкций в корне проекта
• Регулярно обновляйте при изменении требований
• Используйте понятную структуру и форматирование
• Добавляйте примеры для сложных случаев
• Версионируйте файл вместе с кодом проекта

📝 Заключение #

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

🔗 Полезные ресурсы #

• Официальная документация OpenAI
• GitHub Copilot Documentation
• Hugging Face Documentation