Одинарные скобки делают красивый триминг отступов когда можно сохранить целостность данных (в обратном конвертировании они значат, что отступы не нужны). Двойные - сохраняют строку как есть. Такой была цель.
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок. Проверил на самом остром случае - строка “\ttrue”: вместо блока сейчас пишется однострочное field1:: true, а при обратном чтении ведущий таб пропадает вообще, значение схлопывается в чистое “true”. То есть это не просто некрасивая форма записи, а реальная потеря байта.
Этот же класс бага @chappihappymeal нашёл и прислал с PR, независимо от вас:
Я прогнал ваш случай на ветке этого PR отдельно - чинит и его: та же строка с ведущим табом уходит в ((…)) и возвращается обратно байт в байт. Фикс идёт в ближайший патч-релиз 0.6.3, ничего не ломает - плейграунд подтянет его следующим обновлением вендоренного WASM.
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы, а не выкатываем по одному.
Это будет масштабной работой. Не уверен, что возмусь за это, но мне нравятся ваши слова. В любом случае, это будет либо ktavPlus - вторым форматом (как TS над JS), либо обвязкой.
Оригинальный ktav очень хочу сохранить в простом виде - мне он тоже нравится именно своей простотой.
Если вы готовы быть поставщиком идей (в случае, если возьмусь) - создайте issue (https://github.com/ktav-lang/spec/issues). Если в будущем возьмусь, то я отпишусь под ним.
Спасибо - точное и ценное замечание, круто, что вы сразу нашли реальуню вещь, которая стоит доработки!
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё. Отдельные кавычки не нужны - механизм для этого случая в формате уже есть, просто writer его не соблюдает.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок.
Этот же баг на этой неделе нашёл и прислал с PR @chappihappymeal - независимо от вас, через код.
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы
Очень ценные запросы, спасибо! И почти всё здесь я готов подписать.
Про валидацию соглашусь. В другом комментарии я предлагал ровно то, что вы отвергаете - взять JSON Schema и проверять ей уже разобранный конфиг. Но тогда проверка идёт по готовым данным, в которых уже не осталось привязки к строкам файла. Подсветить ошибку в редакторе нечем.
Про остальные четыре пункта скажу прямо: этого нет. Почему - мы этим просто не занимались и не планировали заниматься. Формат отвечает на вопрос, как выглядит файл, а окружения, include и merge - это уже про то, как конфигурация собирается из нескольких файлов. Другой слой.
JSON и TOML останавливаются там же. Вы сами это отмечаете - и ваш тезис именно в том, что между форматом и полноценным инструментом остаётся дыра. С этим спорить нечего, дыра есть.
Мне кажется правильным закрывать её не изменением формата, а отдельной необязательной спекой поверх него: include как соглашение над обычными Ktav-документами, семантика глубокого merge (включая удаление ключа, а не только замену), выбор окружения, соглашение о ссылках на внешние секреты. Тогда файл остаётся обычным Ktav для тех, кому обвязка не нужна.
Спасибо, мысль хорошая - keywords действительно про то же самое: ключ самоозначающий, кавычки ему не нужны.
Если продолжить её и поставить форматы рядом, то ближайшим соседом по внешнему виду окажется, наверное, всё-таки JSON5 - там тот же порядок “ключ двоеточие значение” и ключи тоже без кавычек:
{ host: 'a.example', port: 1080 }
В plist и EDN двоеточие переезжает влево и превращает сам ключ в keyword, а пары разделяются пробелами внутри s-выражения:
(:host "a.example" :port 1080)
Но любопытно, что plist и JSON5 при этом роднит ровно то же самое, что вы заметили: ключ не нуждается в кавычках. Похоже, до этой мысли рано или поздно доходит каждый, кто делает формат для чтения человеком, - просто доводят её по-разному.
Ktav дотянул её на шаг дальше и снял кавычки и со строковых значений тоже, а структуру оставил построчной, без объемлющих скобок:
host: a.example
port: 1080
Так что, да - “не совсем то, но семантически близко”)
Спасибо за подробный контр-аргумент - это полезнее общей критики, потому что чётко очерчивает границу применимости.
И да, вы правы: на 3-4 тысячах ключей с тремя окружениями и разделением секретов Ktav вам ничего не даст сверх того, что дают JSON/YAML/TOML. Формат этого не решает и не пытается. Он про другое - про конфиг, который человек пишет и читает руками: сервис, CLI, небольшое приложение. Там, где конфигурация становится системой со своим наследованием, оверлеями и секрет-менеджментом, нужен не формат, а инструмент: Helm/Kustomize, CUE, Consul, Vault. Выбор формата на таком масштабе - вопрос десятый.
Про include / interpolation / merge - это сознательно вне формата, а не недоделка. Как только внутрь синтаксиса заходит include или подстановка переменных, файл перестаёт читаться сам по себе, и появляется порядок вычисления, который надо описывать и реализовывать одинаково во всех семи биндингах. Мы решили, что этот слой живёт в приложении: конфиг из файла, env поверх, секреты инжектятся отдельно. Скучно, зато предсказуемо.
Про схемы вы попали в реальный пробел - своего языка описания схем у Ktav нет, и это честное ограничение.
Но одно уточнение: модель данных у Ktav ровно JSON-овская - те же скаляры, массивы, объекты, null, bool, без тегов и якорей. Поэтому JSON Schema применима к результату разбора: распарсили .ktav в структуру и валидируйте тем же валидатором, что и для JSON. Отдельная схема под формат не нужна - преимущество JSON здесь наследуется, а не теряется.
Про вкусовщину спорить не буду. Кавычки и запятые действительно вопрос привычки, и если они вам не мешают - формат вам не нужен, это нормальный исход. Он вырос из личного раздражения, а не из уверенности, что так лучше всем, и 20 лет за клавитурой накопили разражение в бесконечных танцах пальцев с шифтами)
Спасибо - и отдельное спасибо за ПР, это редкий жанр комментария.
Про кросс-языковые команды верно, цена именно такая, как вы описали: .so рядом и прочее. Платим её сознательно, ради одинакового поведения везде и производительности Rust.
Теперь про ::int / ::float. Идея понятна и ложится на существующий синтаксис, но в 0.5.0 мы убрали ровно такие маркеры - были :i и :f.
Главная причина - типизированные языки всё равно сами решают, какого типа получать значение. Целевой тип задаёт структура, в которую десериализуют, а не документ: serde в Rust, struct в Go, класс в C# приведут port к u16 независимо от того, как парсер классифицировал скаляр. Маркер в конфиге дублировал то, что уже объявлено в коде, и добавлял вопрос, что делать, когда он противоречит форме.
Плюс ощущение, что для конфигов небольшого ПО текущих возможностей хватает - формат задумывался именно для удобных конфигураций, а не для передачи данных.
Отчасти ту же боль закрывает как раз ваш parse_strict, только с другой стороны: он не даёт форме молча поехать.
Спасибо, что заглянули! Видимо в статье разница с JSONC не бросилась в глаза. Есть сравнительаня таблица на сайте - ktav-lang.github.io (в комментарий пока не разобрался как вставлять таблицы), опишу словами:
JSONC - это JSON плюс комментарии, и всё, остальное как в обычном JSON: кавычки на ключах и строках обязательны, запятые обязательны.
В Ktav иначе: кавычки на ключах и строках не нужны вообще (кроме ::, когда явно хочешь застолбить строку), запятые нужны только если пишешь массив или объект в одну строку, комментарии свои - ##, а для многострочного текста есть отдельный блок в скобках вместо \n внутри одной строки в кавычках.
На примере с приватным ключом. В JSON/JSONC он склеен в одну строку через \n:
{
// тестовый ключ, не для прода
"private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKC...\n-----END RSA PRIVATE KEY-----"
}
В Ktav - отдельный блок, построчно как есть:
## тестовый ключ, не для прода
private_key: (
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKC...
-----END RSA PRIVATE KEY-----
)
Include с файлом секрета и ENV(‘LOG_LEVEL’, ‘info’) внутри конфига - сознательно не входит в формат. Ktav - только слой данных, без include/expressions/interpolation, как и JSON с TOML: добавишь интерполяцию - формат превращается в мини-язык со своей семантикой выполнения.
Стремился к минимализму - “Ktav простой и хороший, он не совершенный, но лучший для конфигов”. Получилось сделать его таким или нет - покажет время.
Возможно параллельно будет какой-нибудь ktav_plus - со ссылками, переменными и прочим, но основной формат останется в минимализме, как json
По сути это уже встроено - только как метод тестирования, не как продукт. Тест-спека - это пары “вход на Ktav → ожидаемый JSON”: https://github.com/ktav-lang/spec/tree/main/versions/0.6/tests/valid Берёте любой .ktav - рядом его .json-эквивалент. Транслятор, покрытый тестами на все краевые случаи, - это и есть наш эталонный Rust-парсер.
Почему всё же выбрал FFI в 7 языков, а не “отдай JSON нативному парсеру” - довод один, про скорость. Цель была - парсинг вровень с serde_json; по факту медленнее раза в два, но это наносекунды, я считаю результат хорошим. А вот лишний проход через JSON-текст (сериализовать → распарсить второй раз) - уже отдельная стоимость поверх, которая на горячем пути (частые перечитывания, много мелких конфигов) будет заметна. На конфиге, который читается раз при старте, - без разницы.
И обычно: “транслятор + родной парсер” - ровно то, что делают на старте нового формата, и это хорошая стратегия при ограниченности ресурсов. Я сделал наоборот - вложился в 7 FFI-биндингов за полтора месяца, до первого внешнего пользователя. Риск, чего уж там.
Лёгкий транслятор в чистый JSON отдельно от биндингов - хорошая идея, завёл issue: https://github.com/ktav-lang/spec/issues/2. В следующих версиях рассмотрю подробнее как с сней быть.
И да: без всего, что Ktav даёт сверх модели JSON, формулировка была бы именно такой - не 15-й стандарт, а просто приятный способ печатать JSON руками)
Занимаюсь активной разработкой нескольких проектов - очень много temp артефактов плодит это, и всё складируется в папку профиля temp
+ Рабочий стол давно не приводил в впорядок, + загрузки.
Оказалось, что часть из этих артефактов сканируется антвирусом при старте и еще что-то их перебирало, если не ошибаюсь. Скорее всего не смогу уточнить, это было пару месяцев назад, а Клод подчистил старые сесиии.
Недавно пришла идея реализовать систему контролля версий, которая будет хранить дерево объектов на базре AST дерева кода (и их историю). Тогда на каждую деталь кода можно будет вести любую историю любых мета-данных. Это бы сильно улучшило работу с кодом, мне кажется.
Работа мастштабная, но хочется взяться в этой жизни
Сама шкала "нормальности"/здоровья зависит от общества и эпохи? Вопрос с подвохом. Это не отменяет реальной пользы лечения - цифры говорят за себя, но интересно, насколько критерии расстройств универсальны или, напротив, культурно обусловлены.
Одинарные скобки делают красивый триминг отступов когда можно сохранить целостность данных (в обратном конвертировании они значат, что отступы не нужны). Двойные - сохраняют строку как есть. Такой была цель.
Спасибо!
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок. Проверил на самом остром случае - строка “\ttrue”: вместо блока сейчас пишется однострочное field1:: true, а при обратном чтении ведущий таб пропадает вообще, значение схлопывается в чистое “true”. То есть это не просто некрасивая форма записи, а реальная потеря байта.
Этот же класс бага @chappihappymeal нашёл и прислал с PR, независимо от вас:
Issue: https://github.com/ktav-lang/rust/issues/3
PR: https://github.com/ktav-lang/rust/pull/4
Я прогнал ваш случай на ветке этого PR отдельно - чинит и его: та же строка с ведущим табом уходит в ((…)) и возвращается обратно байт в байт. Фикс идёт в ближайший патч-релиз 0.6.3, ничего не ломает - плейграунд подтянет его следующим обновлением вендоренного WASM.
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы, а не выкатываем по одному.
Это будет масштабной работой. Не уверен, что возмусь за это, но мне нравятся ваши слова. В любом случае, это будет либо ktavPlus - вторым форматом (как TS над JS), либо обвязкой.
Оригинальный ktav очень хочу сохранить в простом виде - мне он тоже нравится именно своей простотой.
Если вы готовы быть поставщиком идей (в случае, если возьмусь) - создайте issue (https://github.com/ktav-lang/spec/issues). Если в будущем возьмусь, то я отпишусь под ним.
Спасибо - точное и ценное замечание, круто, что вы сразу нашли реальуню вещь, которая стоит доработки!
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё. Отдельные кавычки не нужны - механизм для этого случая в формате уже есть, просто writer его не соблюдает.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок.
Этот же баг на этой неделе нашёл и прислал с PR @chappihappymeal - независимо от вас, через код.
Issue: https://github.com/ktav-lang/rust/issues/3
PR: https://github.com/ktav-lang/rust/pull/4
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы
Почти) Только запятые были довеском - по-настоящему меня довели кавычки.
В JSON5 голым можно написать ключ, а значение всё равно в кавычках:
В Ktav кавычек нет ни в ключе, ни в значении, и корень не обёрнут в скобки - файл читается построчно:
Запятые ушли уже за компанию: раз пары и так разделены переносом строки, разделять их ещё и запятой стало не нужно.
Очень ценные запросы, спасибо! И почти всё здесь я готов подписать.
Про валидацию соглашусь. В другом комментарии я предлагал ровно то, что вы отвергаете - взять JSON Schema и проверять ей уже разобранный конфиг. Но тогда проверка идёт по готовым данным, в которых уже не осталось привязки к строкам файла. Подсветить ошибку в редакторе нечем.
Про остальные четыре пункта скажу прямо: этого нет. Почему - мы этим просто не занимались и не планировали заниматься. Формат отвечает на вопрос, как выглядит файл, а окружения, include и merge - это уже про то, как конфигурация собирается из нескольких файлов. Другой слой.
JSON и TOML останавливаются там же. Вы сами это отмечаете - и ваш тезис именно в том, что между форматом и полноценным инструментом остаётся дыра. С этим спорить нечего, дыра есть.
Мне кажется правильным закрывать её не изменением формата, а отдельной необязательной спекой поверх него: include как соглашение над обычными Ktav-документами, семантика глубокого merge (включая удаление ключа, а не только замену), выбор окружения, соглашение о ссылках на внешние секреты. Тогда файл остаётся обычным Ktav для тех, кому обвязка не нужна.
Завёл под это issue, расписал ваши пять пунктов как отправную точку: https://github.com/ktav-lang/spec/issues/5
Там же вынес открытые вопросы: своя схема или привязка к JSON Schema, отдельный документ или репозиторий, и стоит ли браться до 1.0 самого формата.
Это корректная форма ktav, спарсится в объект, который эквивалентен JSON:
Это можно в живую проверить на сайте ktav-lang.github.io
(на сложные случаи есть экранирование, но в малом ПО для конфигов это скорее всего не понадобится)
Наверно, это очень дорого. Но в вопросах выживания государства вкладываются сильно больше, чем дорого.
В этом свете такой фейл выглядит как слишком большая вера в мирное будущее.
Верить в мирное будщее хорошо, но централизованные точки отказа строить не хорошо
Спасибо, мысль хорошая - keywords действительно про то же самое: ключ самоозначающий, кавычки ему не нужны.
Если продолжить её и поставить форматы рядом, то ближайшим соседом по внешнему виду окажется, наверное, всё-таки JSON5 - там тот же порядок “ключ двоеточие значение” и ключи тоже без кавычек:
В plist и EDN двоеточие переезжает влево и превращает сам ключ в keyword, а пары разделяются пробелами внутри s-выражения:
Но любопытно, что plist и JSON5 при этом роднит ровно то же самое, что вы заметили: ключ не нуждается в кавычках. Похоже, до этой мысли рано или поздно доходит каждый, кто делает формат для чтения человеком, - просто доводят её по-разному.
Ktav дотянул её на шаг дальше и снял кавычки и со строковых значений тоже, а структуру оставил построчной, без объемлющих скобок:
Так что, да - “не совсем то, но семантически близко”)
Спасибо за подробный контр-аргумент - это полезнее общей критики, потому что чётко очерчивает границу применимости.
И да, вы правы: на 3-4 тысячах ключей с тремя окружениями и разделением секретов Ktav вам ничего не даст сверх того, что дают JSON/YAML/TOML. Формат этого не решает и не пытается. Он про другое - про конфиг, который человек пишет и читает руками: сервис, CLI, небольшое приложение. Там, где конфигурация становится системой со своим наследованием, оверлеями и секрет-менеджментом, нужен не формат, а инструмент: Helm/Kustomize, CUE, Consul, Vault. Выбор формата на таком масштабе - вопрос десятый.
Про include / interpolation / merge - это сознательно вне формата, а не недоделка. Как только внутрь синтаксиса заходит include или подстановка переменных, файл перестаёт читаться сам по себе, и появляется порядок вычисления, который надо описывать и реализовывать одинаково во всех семи биндингах. Мы решили, что этот слой живёт в приложении: конфиг из файла, env поверх, секреты инжектятся отдельно. Скучно, зато предсказуемо.
Про схемы вы попали в реальный пробел - своего языка описания схем у Ktav нет, и это честное ограничение.
Но одно уточнение: модель данных у Ktav ровно JSON-овская - те же скаляры, массивы, объекты, null, bool, без тегов и якорей. Поэтому JSON Schema применима к результату разбора: распарсили .ktav в структуру и валидируйте тем же валидатором, что и для JSON. Отдельная схема под формат не нужна - преимущество JSON здесь наследуется, а не теряется.
Про вкусовщину спорить не буду. Кавычки и запятые действительно вопрос привычки, и если они вам не мешают - формат вам не нужен, это нормальный исход. Он вырос из личного раздражения, а не из уверенности, что так лучше всем, и 20 лет за клавитурой накопили разражение в бесконечных танцах пальцев с шифтами)
Спасибо - и отдельное спасибо за ПР, это редкий жанр комментария.
Про кросс-языковые команды верно, цена именно такая, как вы описали: .so рядом и прочее. Платим её сознательно, ради одинакового поведения везде и производительности Rust.
PR влит, релиз для Rust опубликован - 0.6.2: https://crates.io/crates/ktav
Теперь про ::int / ::float. Идея понятна и ложится на существующий синтаксис, но в 0.5.0 мы убрали ровно такие маркеры - были :i и :f.
Главная причина - типизированные языки всё равно сами решают, какого типа получать значение. Целевой тип задаёт структура, в которую десериализуют, а не документ: serde в Rust, struct в Go, класс в C# приведут port к u16 независимо от того, как парсер классифицировал скаляр. Маркер в конфиге дублировал то, что уже объявлено в коде, и добавлял вопрос, что делать, когда он противоречит форме.
Плюс ощущение, что для конфигов небольшого ПО текущих возможностей хватает - формат задумывался именно для удобных конфигураций, а не для передачи данных.
Отчасти ту же боль закрывает как раз ваш parse_strict, только с другой стороны: он не даёт форме молча поехать.
Благодраю за участие! Очень рад первому ПР.
Оказывается еще и баг в темной теме со списоком. Исправил. Спасибо!
По INI - не каждый конфиг может сконвертироваться в INI. Это не баг. Ниже на скрине показывается корректная ошибка об этом.
Спасибо, что заглянули! Видимо в статье разница с JSONC не бросилась в глаза. Есть сравнительаня таблица на сайте - ktav-lang.github.io (в комментарий пока не разобрался как вставлять таблицы), опишу словами:
JSONC - это JSON плюс комментарии, и всё, остальное как в обычном JSON: кавычки на ключах и строках обязательны, запятые обязательны.
В Ktav иначе: кавычки на ключах и строках не нужны вообще (кроме
::, когда явно хочешь застолбить строку), запятые нужны только если пишешь массив или объект в одну строку, комментарии свои -##, а для многострочного текста есть отдельный блок в скобках вместо\nвнутри одной строки в кавычках.На примере с приватным ключом. В JSON/JSONC он склеен в одну строку через
\n:В Ktav - отдельный блок, построчно как есть:
Include с файлом секрета и ENV(‘LOG_LEVEL’, ‘info’) внутри конфига - сознательно не входит в формат. Ktav - только слой данных, без include/expressions/interpolation, как и JSON с TOML: добавишь интерполяцию - формат превращается в мини-язык со своей семантикой выполнения.
Стремился к минимализму - “Ktav простой и хороший, он не совершенный, но лучший для конфигов”. Получилось сделать его таким или нет - покажет время.
Возможно параллельно будет какой-нибудь ktav_plus - со ссылками, переменными и прочим, но основной формат останется в минимализме, как json
Спасибо, приятно слышать!
По сути это уже встроено - только как метод тестирования, не как продукт. Тест-спека - это пары “вход на Ktav → ожидаемый JSON”: https://github.com/ktav-lang/spec/tree/main/versions/0.6/tests/valid Берёте любой .ktav - рядом его .json-эквивалент. Транслятор, покрытый тестами на все краевые случаи, - это и есть наш эталонный Rust-парсер.
Почему всё же выбрал FFI в 7 языков, а не “отдай JSON нативному парсеру” - довод один, про скорость. Цель была - парсинг вровень с serde_json; по факту медленнее раза в два, но это наносекунды, я считаю результат хорошим. А вот лишний проход через JSON-текст (сериализовать → распарсить второй раз) - уже отдельная стоимость поверх, которая на горячем пути (частые перечитывания, много мелких конфигов) будет заметна. На конфиге, который читается раз при старте, - без разницы.
И обычно: “транслятор + родной парсер” - ровно то, что делают на старте нового формата, и это хорошая стратегия при ограниченности ресурсов. Я сделал наоборот - вложился в 7 FFI-биндингов за полтора месяца, до первого внешнего пользователя. Риск, чего уж там.
Лёгкий транслятор в чистый JSON отдельно от биндингов - хорошая идея, завёл issue: https://github.com/ktav-lang/spec/issues/2. В следующих версиях рассмотрю подробнее как с сней быть.
И да: без всего, что Ktav даёт сверх модели JSON, формулировка была бы именно такой - не 15-й стандарт, а просто приятный способ печатать JSON руками)
в текущих реалиях их надо делать под каждой станцией метро и еще где-то глубоко под горами
Занимаюсь активной разработкой нескольких проектов - очень много temp артефактов плодит это, и всё складируется в папку профиля temp
+ Рабочий стол давно не приводил в впорядок, + загрузки.
Оказалось, что часть из этих артефактов сканируется антвирусом при старте и еще что-то их перебирало, если не ошибаюсь. Скорее всего не смогу уточнить, это было пару месяцев назад, а Клод подчистил старые сесиии.
Недавно пришла идея реализовать систему контролля версий, которая будет хранить дерево объектов на базре AST дерева кода (и их историю). Тогда на каждую деталь кода можно будет вести любую историю любых мета-данных. Это бы сильно улучшило работу с кодом, мне кажется.
Работа мастштабная, но хочется взяться в этой жизни
централизованные точки отказа - это то, чего пытались избежать при создании интернета. Хорошо бы всегда это помнить и следовать этому
знаю людей, у которых ощущения 1/10 не в пользу здоровых. Примечательно, что себя они при этом относят к 9 больным
Сама шкала "нормальности"/здоровья зависит от общества и эпохи? Вопрос с подвохом. Это не отменяет реальной пользы лечения - цифры говорят за себя, но интересно, насколько критерии расстройств универсальны или, напротив, культурно обусловлены.