Вот на скриншоте показаны несколько темных тем: Dracula, Solarized, Gruvbox, Monokai, Moonlight. В теории можно взять и инвертировать светлоту, получив тем самым светлую тему. В теории теория и практика не отличаются. На практике всё совсем наоборот 😀. Чтобы объяснить почему, полезно сначала посмотреть на то, как устроена работа с цветом в принципе.

В 2011 году Этан Шунуовер опубликовал Solarized — палитру из шестнадцати цветов для терминалов и редакторов. Она стала популярной потому что в основе проектирования цвета была конкретная методология.

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

Ключевое свойство Solarized в том, что монотонные цвета имеют симметричные разницы светлоты в CIELAB, поэтому переключение между тёмным и светлым режимами сохраняет одинаковую воспринимаемую контрастность между каждым значением. Это достигается точным зеркалированием Lab-координат: base03 и base3 симметричны относительно средней точки шкалы, как и все остальные пары.

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

Именно поэтому я считаю, что Solarized — очень хороший пример темы, хотя и сам ей не пользуюсь. В схему вложена хорошая идея и такая же хорошая реализация — оба режима (темный и светлый) должны восприниматься как части единой системы.

Разные цветовые модели

Когда мы говорим о цвете, мы часто думаем о HEX или HSL. HEX — это просто RGB в другой записи, а HSL хоть и интуитивен, но математически нечестен. Два цвета с одинаковым L в HSL воспринимаются глазом совершенно по-разному. Зелёный при hsl(120 100% 50%) — ослепительно яркий, синий при hsl(240 100% 50%) — значительно темнее, хотя формально у них одна «светлота».

Шунуовер работал в CIELAB именно потому, что это пространство перцептивно равномерное: одинаковое числовое расстояние между точками соответствует одинаковому воспринимаемому различию для глаза. Отсюда и возможность строить симметрию: если base03 имеет L=15, а base3 имеет L=97, то их среднее — L=56, и вся палитра строится как зеркало вокруг этой оси.

Современные системы дизайна, переходят на OKLCH. Это улучшенная версия того же принципа. В нём L (lightness) означает одно и то же для любого оттенка. Поэтому цвета с L = 0.55 воспринимаются одинаково яркими. Это позволяет строить палитры более системно, а не на глаз. В нашем случае темы хранятся именно в OKLCH, а в браузере они рендерятся как lab().

Проблема контраста

Solarized решал контраст вручную, через Lab-симметрию. В нашем же случае мы не можем всё выверять вручную. В текущей реализации есть лишь автоматическая генерации и нет симметрии. У нас есть только числа, которые нужно проверять.

Для проверки контрастности можно использовать относительную яркость (relative luminance). Она используется в WCAG. Но яркость относительна, поэтому мы не можем полагаться на нее полностью как на L в OKLCH. Синие и фиолетовые цвета при L ≈ 0.55 дают относительную яркость около 0.22–0.25, что обеспечивает контраст ~5:1 с белым текстом. Этого достаточно, для того, чтобы комфортно читать текст. Но жёлтый и оранжевый при той же OKLCH-светлоте имеют яркость 0.35–0.45, и контраст с белым падает до 2.5–3:1. А такого контраста уже недостаточно для читаемости.

Первая попытка генерации светлых тем для Gruvbox и Monokai дала золотистый primary с тёмным текстом поверх него. Визуально это выглядело плохо. У меня не сохранилось скриншотов, поверьте на слово, было так себе. Поэтому для последующей генерации я решил для тёплых хроматических primary-color (жёлтый, оранжевый, золотой) нужно опускать L до 0.45–0.50 и использовать белый foreground-color. Для холодных (синий, фиолетовый) можно оставлять L ≈ 0.50–0.58. Это нельзя вычислить автоматически без анализа конкретного цвета.

Проблема сохранения визуальной идентичности

Любая тема, которую мы генерируем в дополнение к уже существующей должна удовлетворять как минимум двум условиям: — иметь правильный контраст — быть узнаваемой

Solarized — это крайний случай. Тут идентичность задокументирована точными Lab-значениями. Но есть темы, у которых нет такой хорошей документации.

Например, Dracula узнаваемы по пурпурно-розовому оттенку из #bd93f9. Но этот цвет воспроизводится по-разному в разных редакторах. Более того, для многих тем существуют еще и различные вариации, то есть нет только темной или светлой темы. Есть наборы из нескольких темных и нескольких светлых вариантов.

Первая автоматически сгенерированная версия Dracula использовала --primary: oklch(0.550 0.178 295°). Цвет синевато-фиолетовый, контраст с белым нормальный. Вроде технически верно. Но полученный оттенок был скорее пурпурно-розовый. При 295° тема начинает напоминать Moonlight. В результате смещение на 10 градусов по оттенку разрушало идентичность.

Инвертированная логика акцентов

В качестве компонентов в проекте используются shadcn. Одна из неочевидных конвенций shadcn это то, как работает accent в светлых и тёмных темах. В тёмной теме accent — это насыщенный цвет. Он используется для подсветки активных элементов. В светлой теме accent — это очень бледная, почти белая поверхность для hover-состояний, а accent-foreground — тёмный текст поверх неё. При автоматической генерации мы копируем тёмные значения accent в светлые варианты. В результате получаются элементы с насыщенным фоном и светлым текстом. Все это можно описать некрасивым эмодзи, но не буду этого делать 😁.

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

Результат работы можно посмотреть ниже или открыть пулл реквест и исследовать код. Конечно, некоторые моменты еще можно докрутить и улучшить. Хотя у меня и нет года, как у Шунуовера, я считаю, что результат получился вполне достойным.

Вот что Claude делает очень хорошо, так это строит графики и выполняет рутинные задачи. Ну а еще льстит, конечно. Для эксперимента я попросил построить прогноз на сегодняшний забег. Я долго сомневался бежать 5км или 10км. По итогу бежал 10, потому что слоты на 5 просто закончились :)

Вот с такими данными я пришел к Claude и планировал бежать 28-го марта 10км.

Прогноз Garmin: 48:56. Реалистичная цель: 48–50 мин. Оптимистичная (при хорошем самочувствии): 47:30.

... Сказал Claude и дал раскладку на гонку: — Км 1–2: 5:05–5:10 Разгон — Км 3–8: 4:50–4:55 Основной блок — Км 9–10: 4:35–4:45 Финишное ускорение

Тут я посмеялся. Уверен, что мой тренер, читающий этот пост тоже посмеялся, зная меня. Для тех кто не знает, скажу: никакого финишного ускорения у меня быть не может. Я так не делаю. У меня или всё ровно, или финишное замедление :D Хотя последнее я стараюсь избегать. И вот, чтобы его избегать и не сбрасывать, мне очень важно бежать всю дистанцию ровно.

"Любой каприз за ваши токены". Claude скорректировал раскладку после уточнения.

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

А вот реальный результат. Он сильно отличается от прогноза Garmin и плана Claude. И это очень важно иметь в виду, когда и если вы захотите попробовать эти инструменты в работе.

Зачем вообще всё это? Использование ИИ сейчас повсеместно. Но надо быть очень аккуратными с тем, что мы получаем в результате его использования. Чтобы прогнозы были точными, любую модель нужно обучать, запросы должны быть точнее, ограничения в рамках которых модель мыслит должны быть жестче. Иначе результат будет далек от истины.

Но в чем ИИ точно хорош, так это в исполнении рутинных задач. Например, подключив к Claude коннектры Garmin и Calendar, можно делегировать ему планирование тренировок с учетом плана, списка дел в календаре и пожеланий. В результате за считанные секунды неделя будет распланирована, в Календаре и плане Garmin будут стоять тренировки с расписанными блоками. Вот это действительно классно.

Ниже опишу кратко шаги, необходимые для подключения Garmin MCP к Claude Code.

Требования

• macOS / Linux
• Python 3.10+
• uv — менеджер пакетов Python
• Аккаунт Garmin Connect

Шаг 1 — Установка uv

bash curl -LsSf https://astral.sh/uv/install.sh | sh

Проверка: bash uv --version

Шаг 2 — Клонирование репозитория

bash git clone https://github.com/Taxuspt/garmin_mcp ~/dev/garmin cd ~/dev/garmin uv sync

Шаг 3 — Аутентификация в Garmin Connect

Токены сохраняются в ~/.garminconnect и используются повторно — пароль вводится только один раз.

bash cd ~/dev/garmin GARMIN_EMAIL=your@email.com GARMIN_PASSWORD=your_password uv run garmin-mcp-auth

Если включена MFA — нужно ввести код при запросе.

Проверка токенов: bash uv run garmin-mcp-auth --verify

Принудительная повторная аутентификация (если токены устарели): bash uv run garmin-mcp-auth --force-reauth

Токены действительны ~6 месяцев.

Шаг 4 — Подключение к Claude Code

Добавить MCP-сервер глобально (для всех проектов):

bash claude mcp add -s user garmin -- /path/to/uv --directory ~/dev/garmin run garmin-mcp

Узнать полный путь к uv: bash which uv Например: /Users/denis/.local/bin/uv

Итоговая команда: bash claude mcp add -s user garmin -- /Users/denis/.local/bin/uv --directory /Users/denis/dev/garmin run garmin-mcp

Проверь подключение: bash claude mcp list

В случае успеха, должны увидеть что-то вроде garmin: ... - ✓ Connected

После этого MCP доступен в любом проекте без дополнительных настроек.

Шаг 5 — Подключение к Claude Desktop

Нужно открыть файл конфигурации:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Добавить секцию mcpServers:

json { "mcpServers": { "garmin": { "command": "/Users/denis/.local/bin/uv", "args": [ "--directory", "/Users/denis/dev/garmin", "run", "garmin-mcp" ] } } } Важно заменить /Users/denis на свой домашний каталог. Полный путь к uv важен — Claude Desktop не использует PATH из терминала.

Перезапустить Claude Desktop. В интерфейсе появится иконка с подключённым сервером garmin.

Использование

Тут все конечно зависит от фантазии. Можно начать с простого:

Покажи мою сегодняшнюю активность Проанализируй мою последнюю пробежку Сколько шагов я сделал вчера? Какой у меня был сон на этой неделе? Сравни тренировки за последние 7 дней

Доступно 96+ инструментов: активности, шаги, сон, пульс, стресс, вес, тренировки, устройства и др.

Обновление токенов

Токены Garmin истекают примерно раз в полгода. При ошибке подключения:

```bash cd ~/dev/garmin GARMINEMAIL=your@email.com GARMINPASSWORD=your_password uv run garmin-mcp-auth --force-reauth

```

Решение проблем

Failed to connect в claude mcp list. Токены не найдены или истекли — повтори Шаг 3.

429 Too Many Requests при аутентификации. Garmin временно заблокировал IP. Надо подождать 15–30 минут и попробуй снова.

Claude Desktop не видит MCP. Нужно убедиться, что в claude_desktop_config.json указан полный путь к uv (не просто uv). Проверь: which uv.

Логи Claude Desktop

• macOS: ~/Library/Logs/Claude/mcp-server-garmin.log
• Windows: %APPDATA%\Claude\logs\mcp-server-garmin.log

PS: Еще экспериментировал дополнительно с локальными моделями Ollama + qwen + openapi с гарминовскими ендпоинтами. Но в базовом варианте, это решение выглядит абсолютно нерабочим, если вы хотите просто общаться с ИИ через чат, не тратя время на настройку модели.

О чем вообще речь?

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

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

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

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

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

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

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

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

Работая над бесплатными (или условно бесплатными) проектами, я также стараюсь вести учёт задач и времени. Что-то в меньшей степени, что-то в большей. Но важно понимать объём проделанной работы, сколько сил и времени вложено.

Учтённое время можно конвертировать в деньги — заработанные или незаработанные. Можно прикинуть ценность дел, проектов, затраченных сил и времени. За всю свою жизнь я успел поработать во множестве проектов. И очень часто мне приходилось считать своё время и выставлять счета на основе фактических трудозатрат. Я пробовал разные инструменты. Был Toggl, Harvest, ещё что-то, о чём успел забыть. Но в результате я перенёс опыт использования этих инструментов на собственное решение, которое воплотилось в TrueNorth.

Для чего этот сервис? Чтобы осознанно подходить к ведению своих проектов. С помощью учёта времени вы можете видеть объём вложенных усилий. С помощью отслеживания расходов вы можете видеть ценность своей деятельности.

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

Что даёт система? Она позволит вам видеть затраченное время на работу, которой вы занимаетесь. Если вы работаете над несколькими проектами, вы увидите, где и откуда приходит больше денег, а где вы, наоборот, теряете. А ещё это простой способ увидеть, сколько времени вы действительно занимаетесь какой-то деятельностью. Сделает ли этот сервис вас продуктивнее? Однозначно нет. Ни один сервис не сделает вас продуктивным, пока вы сами этого не захотите. Но TrueNorth может показать вам те реальные цифры, которые побудят вас к размышлениям.

В общем, попробовать стоит. Возможно, статистика сделает вам больно. Но также возможно, что это поможет вам осознать те пробелы, которые вы можете закрыть. В этом и заключается осознанность, правда?

Как обычно, мне изначально казалось, что тут и говорить не о чем. Пока не начал разматывать клубок воспоминаний.

Про бег

В этом году я бегал. Не так много, как в прошлом, но всё же.

— Участвовал в благотворительном забеге в Паличе — Сбегал почти марафон в Иванице — Был на Дрине — Участвовал в ночном марафоне по городу — А ещё сбегал ночной трейл на Фрушке — Ещё была Белградская 10-ка — И ночной трейл на Авале, который мы скорее прошли, чем пробежали, с сыном.

Личные проекты

— Летом сделал календари.

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

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

— Осенью запустил syn-co.me, который помогает координировать работу команды в разных часовых поясах. Писал о нём вот тут — Координатор по часовым поясам.

— Почти запустил, но ещё не совсем, STRATA. Проект пока в бете. Всё работает, но домен я ещё не покупал, и мелкие огрехи вроде оформления страницы «О проекте» требуют полировки.

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

Приходите тестировать STRATA. Всё работает без регистрации и SMS. Но регистрация позволит хранить данные и пользоваться таймером с любого устройства.

Как обычно, много работал, а к концу года стал открыт к новым предложениям, возможностям и вызовам 😁.

Про увлечения

Много писал в блокнотик и иногда рисовал.

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

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

Ещё в этом году удалось перевезти гитару. Спасибо всем причастным — мы не виделись с этой крошкой почти три года.

Год снова получился насыщенным. Были и сложности, и радости, но главное — движение вперёд. Впереди новый сезон, новые старты и новые вызовы.

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

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

Я отказался от почты Gmail примерно четыре года назад. Переехал на Proton, в надежде, что сервис будет развиваться вглубь. Но спустя два года пришел к выводу, что использовать Proton все еще неудобно. Пришлось переехать на FastMail. В результате, вместо одного аккаунта Gmail у меня три почты, и мне все еще приходится периодически проверять их. Миграция с одного ящика на другой — это не про то, чтобы просто перетащить почтовые рассылки.

На почту завязано огромное количество сервисов. Даже если просто изменить доменное имя, то в старом аккаунте могут остаться важные данные. А может быть, и не останутся. Например, тот же Proton дает лишь 1 Гб бесплатного хранилища. Так что при переезде с него мне пришлось просто удалить 5 Гб данных. Как бы я ни старался все сохранить, я уже столкнулся с пробелами в истории переписки.

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

Почта сейчас как ID-карточка или номер телефона. Это настолько важная вещь, которую часто уже и не хочется менять, потому что затраты на переезд — очень высоки из-за риска потери данных (будь контакт, сохраненное или даже еще неполученное письмо).

Я так же искренне верю, что сейчас уже не нужна просто еще одна почта. Нужен удобный сервис, вмещающий много смежных функций. Одна из самых важных функций, которая должна быть интегрирована в почту — календарь. Планирование — неотъемлемая часть жизни. Именно поэтому календарь и почта должны идти рука об руку. Большинство сервисов поддерживают синхронизацию с Google-календарем. Но стоит вам использовать иное решение, то события начинают теряться. Иной раз, создавая событие на полгода вперед, я ловлю себя на мысли о том, что пытаюсь понять где лучше создать это событие, чтобы вот уже точно не пропустить: в календаре Google, на MacOS, в FastMail или планировщике Singularity? И знаете, для особо важных событий я создаю дубликаты. Это ужасно, но вот она реальность.

Теперь про письма. Когда-то давным-давно Google экспериментировал с Inbox. Я считаю, что это был один из очень успешных проектов, просто пользователи в то время не были готовы к такому подходу. Однако я считаю, что почтовые сообщения действительно стоит рассматривать как своего рода задачи. Их можно писать самому себе, формировать проекты. А если мы говорим о рабочих письмах, то в большинстве своем все письма можно рассматривать как сущности различных проектов.

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

Примечание: У этой заметки недоформулирована мысль, но я решил опубликовать ее как есть.