В новом Codex CLI v0.121.0 появилась команда /memories.
Она позволяет Codex запоминать рабочий контекст между сессиями и постепенно учитывать опыт прошлых взаимодействий.
Зачем он, если есть AGENTS.md, project rules и skills?
А изюминка в том, что это адаптивный механизм, который сам подстраивается и пишет для себя правила, исходя из истории переписки с вами.
Codex начинает собирать повторяющиеся паттерны и предпочтения по ходу работы.
Например:
- особенности вашего workflow
- детали проекта
- повторяющиеся требования
- вещи, которые раньше приходилось объяснять заново
В итоге меньше повторных объяснений и меньше ручного контекста в новых сессиях.
https://www.npmjs.com/package/@openai/codex/
Документация по /memories: https://developers.openai.com/codex/memories
Она позволяет Codex запоминать рабочий контекст между сессиями и постепенно учитывать опыт прошлых взаимодействий.
Зачем он, если есть AGENTS.md, project rules и skills?
А изюминка в том, что это адаптивный механизм, который сам подстраивается и пишет для себя правила, исходя из истории переписки с вами.
Codex начинает собирать повторяющиеся паттерны и предпочтения по ходу работы.
Например:
- особенности вашего workflow
- детали проекта
- повторяющиеся требования
- вещи, которые раньше приходилось объяснять заново
В итоге меньше повторных объяснений и меньше ручного контекста в новых сессиях.
https://www.npmjs.com/package/@openai/codex/
Документация по /memories: https://developers.openai.com/codex/memories
👍28🎉20😁19❤17🤩16🔥11
Краткий обзор ClickHouse 26.5 🚀
💻
Функция рекурсивно обходит директорию и возвращает метаданные файлов: путь, имя, размер, тип, права, время изменения. При необходимости можно читать и содержимое через колонку
🔄 Обратный порядок LIMIT BY
🔁
⚡ Оптимизация
Чтчерез
🎁 Бонус: Web Terminal
В браузере появился экспериментальный
Поддерживает:
✨ syntax highlighting
⌨️ autocomplete
📝 multiline-запросы
📜 историю команд
Разбор релиза:
🎥 https://www.youtube.com/live/P1IDAvsi7p8?si=n66k1CmeuoA7QIDU
💻
filesystem() — новый способ работать с файлами из SQL.Функция рекурсивно обходит директорию и возвращает метаданные файлов: путь, имя, размер, тип, права, время изменения. При необходимости можно читать и содержимое через колонку
content.SELECT path, name
FROM filesystem('logs')
WHERE type = 'regular'
AND content LIKE '%ERROR%';
🔄 Обратный порядок LIMIT BY
LlLIMIT -2 BY user_id
🔁
Материализованные представления теперь можно заменять атомарно:
CREATE OR REPLACE MATERIALIZED VIEW ...
⚡ Оптимизация
Чтчерез
JOIN
ClickHouse теперь может проталкивать ORDER BY ... LIMIT n через LEFT/RIGHT JOIN, если ключ сортировки относится только к сохраняемой стороне JOIN. Это уменьшает объём данных, который нужно протащить через join.🎁 Бонус: Web Terminal
В браузере появился экспериментальный
/webterminal: интерактивная сессияПоддерживает:
✨ syntax highlighting
⌨️ autocomplete
📝 multiline-запросы
📜 историю команд
Разбор релиза:
🎥 https://www.youtube.com/live/P1IDAvsi7p8?si=n66k1CmeuoA7QIDU
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥159🎉158👍154❤148❤🔥146🤩145💯135😍120🥰117😁17
Codex + PC + iPhone
⚡️ У Codex появилась невероятно полезная фича, хотя и банально простая: теперь компьютер можно подключить к смартфону и управлять задачами прямо с телефона.
Вы уже настраивали управление с телеграмма или использовали другие решения? Если так, то знаете о чем речь, но теперь это стало удобно как никогда раньше.
А также это работает нативно с вашей обычной подпиской, а значит вам не нужно дополнительно покупать API.
Это не про замену IDE и не про попытку писать код на маленьком экране. Телефон здесь нужен для другого: быстро дать команду, посмотреть результат и принять решение, пока Codex работает на компьютере.
Раньше часто приходилось ждать у монитора, пока агент закончит задачу. Он мог попросить подтверждение, предложить правку, остановиться на спорном месте или ждать уточнения. Теперь можно закрыть ноутбук, оставить компьютер включённым и продолжить уже с телефона.
Например, по дороге домой можно:
🎙 надиктовать уточнение
🔍 посмотреть diff
✅ принять финальные правки
📝 попросить Codex подготовить описание для merge request
⚡️ У Codex появилась невероятно полезная фича, хотя и банально простая: теперь компьютер можно подключить к смартфону и управлять задачами прямо с телефона.
Вы уже настраивали управление с телеграмма или использовали другие решения? Если так, то знаете о чем речь, но теперь это стало удобно как никогда раньше.
А также это работает нативно с вашей обычной подпиской, а значит вам не нужно дополнительно покупать API.
Это не про замену IDE и не про попытку писать код на маленьком экране. Телефон здесь нужен для другого: быстро дать команду, посмотреть результат и принять решение, пока Codex работает на компьютере.
Раньше часто приходилось ждать у монитора, пока агент закончит задачу. Он мог попросить подтверждение, предложить правку, остановиться на спорном месте или ждать уточнения. Теперь можно закрыть ноутбук, оставить компьютер включённым и продолжить уже с телефона.
Например, по дороге домой можно:
🎙 надиктовать уточнение
🔍 посмотреть diff
✅ принять финальные правки
📝 попросить Codex подготовить описание для merge request
🔥153❤151🥰144👍142🎉136🤩133❤🔥133💯129😍115😁27
Вышел новый Storybook 10.4
1. Automated setup ⚙️
Storybook теперь можно настраивать через AI-агента.
Он может сам создать конфиг, добавить моки, написать stories и interaction tests, проверить рендер компонентов и доработать настройку, пока проект не заведётся.
Главная польза: меньше ручной настройки на старте.
2. Change detection 👀
-В сайдбаре появились фильтры
Они показывают:
- новые stories;
- изменённые stories;
- stories, которые могли быть затронуты изменениями в коде.
Почему это удобно: для UI-ревью не нужно смотреть весь Storybook. Можно сразу открыть то, что реально изменилось или могло сломаться.
3. Quick sharing 🔗
Теперь можно быстро поделиться конкретной story, над которой работаешь.
Story — это отдельное состояние компонента: форма с ошибкой, открытая модалка, loading-состояние, кнопка в нужном варианте.
Главное: не нужен commit, PR или ожидание CI. Открыл нужную story, отправил ссылку, получил обратную связь.
4. TanStack React framework 🧩
Добавили поддержку React-проектов на TanStack через
TanStack — это набор инструментов для React: роутинг, работа с серверными данными, server functions и React Query.
Если проект использует TanStack Router, TanStack Start или React Query, Storybook теперь проще подключить и настроить.
5. React Native setup and isolation 📱
Этот пункт относится только к проектам на React Native.
В Storybook 10.4 улучшили изоляцию: Storybook проще запускать отдельно от основного приложения, не смешивая его код с обычной точкой входа.
6. React Component Meta for MCP 🚀
Добавили экспериментальный
Он анализирует React-компоненты: props, типы, описания и API компонента.
Главное преимущество: скорость. В примерах из статьи новый анализатор работает в десятки раз быстрее старого
За счёт этого Storybook быстрее понимает структуру компонентов, а AI-инструменты быстрее получают нужный контекст.
1. Automated setup ⚙️
Storybook теперь можно настраивать через AI-агента.
Он может сам создать конфиг, добавить моки, написать stories и interaction tests, проверить рендер компонентов и доработать настройку, пока проект не заведётся.
Главная польза: меньше ручной настройки на старте.
2. Change detection 👀
-В сайдбаре появились фильтры
New, Modified и Related.Они показывают:
- новые stories;
- изменённые stories;
- stories, которые могли быть затронуты изменениями в коде.
Почему это удобно: для UI-ревью не нужно смотреть весь Storybook. Можно сразу открыть то, что реально изменилось или могло сломаться.
3. Quick sharing 🔗
Теперь можно быстро поделиться конкретной story, над которой работаешь.
Story — это отдельное состояние компонента: форма с ошибкой, открытая модалка, loading-состояние, кнопка в нужном варианте.
Главное: не нужен commit, PR или ожидание CI. Открыл нужную story, отправил ссылку, получил обратную связь.
4. TanStack React framework 🧩
Добавили поддержку React-проектов на TanStack через
@storybook/tanstack-react.TanStack — это набор инструментов для React: роутинг, работа с серверными данными, server functions и React Query.
Если проект использует TanStack Router, TanStack Start или React Query, Storybook теперь проще подключить и настроить.
5. React Native setup and isolation 📱
Этот пункт относится только к проектам на React Native.
В Storybook 10.4 улучшили изоляцию: Storybook проще запускать отдельно от основного приложения, не смешивая его код с обычной точкой входа.
STORYBOOK_ENABLED=true — это технический переключатель именно для React Native-проектов. Для обычных web-проектов на React или Vue это не актуально.6. React Component Meta for MCP 🚀
Добавили экспериментальный
react-component-meta.Он анализирует React-компоненты: props, типы, описания и API компонента.
Главное преимущество: скорость. В примерах из статьи новый анализатор работает в десятки раз быстрее старого
react-docgen-typescript.За счёт этого Storybook быстрее понимает структуру компонентов, а AI-инструменты быстрее получают нужный контекст.
🎉157🤩153🔥149🥰139😍135💯135👍127❤123❤🔥112😁16
Сегодня в очередной раз сталкиваясь с проблемами Windows / Docker / WSL вернулся к теме настройки рабочего места.
Если у вас есть уже готовые конфигурации сервисов, то намного удобнее использовать именно их, и docker compose тут очень удобен.
Однако что делать, если вашему процессу Docker надо работать с файлами в файловой системы Windows?
Если вы давно пользуетесь WSL или вообще не являетесь пользователем Windows, то о такой проблеме вы даже не слышали.
Проблема проста: Docker работает в WSL, и если ваш проект находится в Windows (например на диске c:/), то процессы докер при работе с файлами будут тормозить.
Прыгать между окружениями Windows / WSL не удобно, и поэтому использовать WSL не хочется. Тем более, что IDE и другие программы хорошо работают с файловой системой Windows, а попытки их подружить с WSL очередной раз отвлекают от основных задач при работе с проектом.
Кроме этого синтаксис PowerShell я не знаю, переходить на него не хочется, и это для меня не удобно. Но и WSL со своими ограничениями не особ приятен.
Поэтому на Windows использую Git Bash, и этого почти всегда достаточно. Хотя это и менее удобно чем стандартные команды Ubuntu.
Вместе с этим продолжаю искать решения, как поднять необходимые сервисы с минимальными усилиями, которые уже настроены в Docker compose, но которые я не могу использовать с удобством в Windows.
Чтобы быстро тестировать различные варианты интеграций, я написал небольшой тест для проверки скорости работы в Windows / Docker / WSL. ⚙️
Ссылка на этот тест: https://github.com/Artemeey/bench-runtime-windows-vs-wsl/blob/main/README.ru.md#%D0%B1%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9-%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B9-%D1%82%D0%B5%D1%81%D1%82
Для запуска достаточно выполнить команду, указанную в документации, в нужной папке в Windows / Docker / WSL.
Результаты шокируют: чтение файлов из Docker в папке
Полный бенчмарк со сравнением работы с файлами в Windows / WSL: https://github.com/Artemeey/bench-runtime-windows-vs-wsl
Если у вас есть уже готовые конфигурации сервисов, то намного удобнее использовать именно их, и docker compose тут очень удобен.
Однако что делать, если вашему процессу Docker надо работать с файлами в файловой системы Windows?
Если вы давно пользуетесь WSL или вообще не являетесь пользователем Windows, то о такой проблеме вы даже не слышали.
Проблема проста: Docker работает в WSL, и если ваш проект находится в Windows (например на диске c:/), то процессы докер при работе с файлами будут тормозить.
Прыгать между окружениями Windows / WSL не удобно, и поэтому использовать WSL не хочется. Тем более, что IDE и другие программы хорошо работают с файловой системой Windows, а попытки их подружить с WSL очередной раз отвлекают от основных задач при работе с проектом.
Кроме этого синтаксис PowerShell я не знаю, переходить на него не хочется, и это для меня не удобно. Но и WSL со своими ограничениями не особ приятен.
Поэтому на Windows использую Git Bash, и этого почти всегда достаточно. Хотя это и менее удобно чем стандартные команды Ubuntu.
Вместе с этим продолжаю искать решения, как поднять необходимые сервисы с минимальными усилиями, которые уже настроены в Docker compose, но которые я не могу использовать с удобством в Windows.
Чтобы быстро тестировать различные варианты интеграций, я написал небольшой тест для проверки скорости работы в Windows / Docker / WSL. ⚙️
Ссылка на этот тест: https://github.com/Artemeey/bench-runtime-windows-vs-wsl/blob/main/README.ru.md#%D0%B1%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9-%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B9-%D1%82%D0%B5%D1%81%D1%82
Для запуска достаточно выполнить команду, указанную в документации, в нужной папке в Windows / Docker / WSL.
Результаты шокируют: чтение файлов из Docker в папке
C:/ медленнее в 40 раз, а механизм кеширования файловой системы ext4 в WSL при повторных обращениях к файлам приводит к ускорению в 10 раз по сравнению с обычной работой в файловой системе Windows. ⚡️Полный бенчмарк со сравнением работы с файлами в Windows / WSL: https://github.com/Artemeey/bench-runtime-windows-vs-wsl
🎉154🔥153🤩146👍142💯141❤136❤🔥128😍127🥰121😁25
💡Полезные советы: исправляем Unicode в Windows Git Bash
По умолчанию в Git Bash обычно используется UTF-8, и Unicode работает корректно. Однако переменная окружения
Пример:
* пишем
* стираем
* пишем
* в выводе получаем:
Для решения проверьте локаль:
Если значение
Повторите проверку. Если помогло, сохраните настройку в
Проверить содержимое пользовательских настроек Git Bash можно так:
По умолчанию в Git Bash обычно используется UTF-8, и Unicode работает корректно. Однако переменная окружения
LANG может быть не задана. Из-за этого после ввода текста на кириллице в консоли может ломаться последующий ввод.Пример:
* пишем
ды* стираем
ды* пишем
ls* в выводе получаем:
bash: □□ls: command not foundДля решения проверьте локаль:
locale
Если значение
LANG не задано, установите его вручную:export LANG=C.UTF-8
Повторите проверку. Если помогло, сохраните настройку в
~/.bashrc:printf 'export LANG=C.UTF-8\n' >> ~/.bashrc
Проверить содержимое пользовательских настроек Git Bash можно так:
cat ~/.bashrc
😍137🎉135❤🔥132👍127🔥127💯127🥰126🤩124❤107