Разница во владельцах. Владельцем SelfKey является клиент и только он может определять значение ключа; в свою очередь владельцем AssignedKey является сервер. То есть клиент может представить себя как ему угодно, а сервер может идентифицировать клиента по-своему, скажем добавить поле verified или что-то в этом духе.
На счёт документации вы совершено правы. Базовые моменты я описал здесь в различных секциях. Но описание конкретных методов всё ещё является слабым место. Я думаю, что это будет embedded документация, то есть встроенная непосредственно в код. Раз уж код генерируется и будут безусловно обновления, то и документацию следуют генерировать тоже.
Всегда стараюсь отвечать максимально деликатно на подобные вашему комментарии. Или просто игнорирую их. Но, знаете, сегодня не буду… надоело, пусть и полетят в меня минусы роем. Для себя я называю такие вот комментарии - «булькающая бабушка».
Суть проста - ты сделаешь что-то, поэкперементируешь, поиграешь с идеями и опишешь это и вот на горизонте появляется она, «булькающая бабушка»… всегда с единственно верным суждением и решимостью его предъявить миру - «это всё г$_&о, не нужно делать х*!?ю»
Она не интересна. Когда становится интересно пора переходить на протобаф, а не думать как сделать джейсон быстрее.
Я учту о чём мне не думать, но все равно поясню: JSON в данной статье упоминается в качестве наиболее распространённого варианта формата данных, что характерно особенно для небольших web проектов. Никто не оспаривает существование прекрасных парсеров для него (взять хотя бы тот же serde на rust). А clibri так и вовсе не использует JSON вообще и раз так, то и не оптимизирует его. Статья вообще не про это.
На счёт таймаутов вы правы, они отлавливаются на всех болевых точках в rust имплементации и будут добавлены также в typescript совсем скоро. Собственно поэтому и есть плашка alpha, что бы подсветить - не все детали ещё учтены, есть базовое решение, но работа ещё ведётся.
Конечно, protobuf - это первое что приходит на ум, и я ждал подобного вопроса. Но не упоминал о protobuf в статье лишь потому, что clibri не является ни конкурентом (куда уж мне в одиночку), ни тем более альтернативой; не в чистом виде, не в связке с gRPC. Это немного о другом.
Я по большей части работаю с web проектами, поэтому и на протокол смотрю именно с этой стороны. Часто нужно сделать какой-то несложный front-end для какого-нибудь сервиса. И каждый раз «под капотом» практически одно и тоже: транспорт, валидатор, реализация клиента, реализация сервера. Наблюдая порой за коллегами я не раз замечал, как реализация какой-нибудь связки «клиент-сервер» кочует от проекта к проекту, с каждой новой итерацией copy/paster, обрастая незначительными изменениями, то есть коллеги просто брали подходящее решение, копировали и заменяли содержание обработчиков, практически не трогая все остальное (ну разве что состав данных менялся безусловно). Но идея clibri именно в этом — дать возможность разработчику вообще не думать о том, что там делает метод send_something_somewhere. И я подумал, возможно будет интересно, если:
не описывать в протоколе ничего кроме данных (может он в рамках того же проекта будет использоваться для чего-то иного, импорта/экспорта, например)
описывая логику коммуникации (workflow) не описывать никаких функций, а описывать только возвраты и последствия возвратов. Добиться от схемы workflow однозначного и единственного толкования.
сделать так, чтобы разработчик в большей части случаев мог бы просто добавить свой код в уже готовый обработчик. То есть сгенерированное решение должно компилироваться сразу же, ещё до того, как добавлено «мясо» в обработчики.
Я не сравнивал clibri по производительность с protobuf ни с точки зрения кодирования/декодирования, ни с точки зрения экономичности, хотя, наверное, это следует сделать, но быть может немного позднее, ибо сейчас это будет сравнение автомобиля с шаттлом челленджер.
Надеюсь ответил. Ещё раз спасибо за хороший вопрос.
Спасибо за ваш комментарий.
Текущая картина такая:
TS: ~74%
Rust: ~16%
HTML, LESS, CSS, Ruby — rest
На rust сейчас наиболее ресурсоёмкие операции: индексация, декодирование/кодирование и другие. Но сессии и поиск модерируются на nodejs. Миграция ядра на rust подразумевает модерацию сессий, включая поиск, на уровне rust; на nodejs останутся лишь какие-то общие задачи. И даже в версии 3.0, я уверен доля rust не вырастет выше 30-35% и это вполне ок, ибо на front-end довольно много кода.
Уточнить: rust не «сбоку», на нем уже сейчас лежит основополагающий функционал по подготовке контента к отображению (как было сказано выше: индексация, кодирование/декодирование). Ну а с версией 3 так и все ядро будет на нем.
Спасибо за Ваш вопрос. Из структурированных форматов, сейчас есть поддержка только для DLT формата. Иные форматы воспринимаются как plain text. Между тем, Вы можете создать feature requestздесь и описать своё видение, что очень важно. Например мне сложно представить, что именно Вы хотели бы видеть в качестве поддержки логов в формате JSON. Как должна отображаться строка логов? Как текст или, например, поименованными столбцами (а если JSON имеет вложенную структуру?). Или может вы хотели бы видеть на sidebar представление выделенной строки логов как JSON pretty print? Как видите вопросов возникает масса, поэтому мы призываем создавать feature request, где Вы и мы могли бы обсудить как именно должна быть реализован тот или иной функционал.
Ниже на скрине показано как выглядит DLT файл в chipmunk. Представление строк — столбцами; плюс на sidebar разбивка по полям.
Спасибо за Ваш отклик. Поддержка tail и возможность включения любых дополнительных кодировок появится в версии 3.x вместе с упомянутой мной оптимизацией производительности. Произойдёт это не раньше чем через 1-1.5 месяца.
К сожалению, такого рода временные метки не могут быть идентифицированы прямым путём. Я имею ввиду, что это не соответствует формату YYYY, MM, DD, hh, mm, ss etc. Как отличить «20200825223600050161» от простого числа логах? Полагаю, что никак.
Кроме того, в вашем случае нужно не только найти значение, но и преобразовать его, что несколько осложняет задачу.
Для решения подобных задач в следующих версиях мы хотим добавить определение формата, как регулярного выражения с поименованными группами. Что-то вроде.
Какого рода интеграцию вы имеете ввиду? Например, интеграция с DLT понятна — декодирование и разбиение на столбцы для удобства чтнения. С opentracing немного не ясно, что именно нужно интегрировать. Поясните пожалуйста.
Спасибо за разъяснения.
На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.
Спасибо за ваш комментарий.
Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?
Полностью с вами согласен, юзкейсов очень много. И далеко не всегда логи хранятся удалённо. У нас, например, довольно большая группа пользователей, работающих с embedded software. И там можно получать десятки гигобайт логов лишь за ночь или за одну сессию тестирования. При этом логи часто бывают от нескольких источников, что вовсе не облегчает жизнь. Ну и конечно, такие логи живут более ли менее локально.
Спасибо за ваш вопрос. Там были изменения в порядке подписания приложения. Мы «покрыли» тот порядок, который установлен на 10.15 и младше, и, честно, не стали заморачиваться над поддержкой процедуры подписания для более поздних версий. Дело только в подписи. Решили, что если появится issue на этот счёт, то обязательно добавим поддержку более ранних версий ОС, но пока запросов не поступало.
Спасибо за ваш комментарий.
Полагаю я уже ответил частично на ваш комментарий здесь. Могу добавить, что есть несколько идей по тому чтобы научить chipmunk цепляться по ssh, что во многом снимает вопрос удалённого доступа, но открывает проблемы другого характера. Пока думаем над этим. Но если у вас есть какие-то идеи или пожелания, будем очень рады увидеть их в качестве feature request.
Спасибо за ваш комментарий. Я отвечу сравнением, если позволите.
В каких-то повседневных задачах, не знаю, файл с настройками подправить, я вот не задумываясь прибегну к nano (или если настроение плохое, к vim). Но все же, для работы над проектом, я открою VSCode или что-нибудь от JetBrains. Я сделаю это не потому что не могу кодить в vim или nano, а просто потому, что удобнее это делать в IDE. Хотя, если задуматься, IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно. И вот эти вот мелочи делают работу удобнее и быстрее.
Как-то так и возник chipmunk. Блин, а как сохранить шаблоны поиска (скажем фильтров 5-10) и не терять их, а ещё по необходимости шарить с коллегами? А как усадить студента-тестировщика и не ввергать его в шок консольными командами, а сказать: «увидишь здесь красное — кричи!». А у нас в логах тут куча закодированных данных, которые было бы очень здорово не копи/пастить по окнам, а сразу читать. Ну и так далее. То есть базово вопрос не в том, что chipmunk умеет делать что-то что не умеют другие, нет, а в том, чтобы попытаться делать это проще. Хотя есть и DLT, которые с консоли декодировать та ещё проблема.
На счёт tail, то уже есть feature request по этому поводу. Думаю что в ближайших обновлениях это появится, то есть chipmunk будет открывать файл и обновлять по мере его изменений.
Разница во владельцах. Владельцем
SelfKeyявляется клиент и только он может определять значение ключа; в свою очередь владельцемAssignedKeyявляется сервер. То есть клиент может представить себя как ему угодно, а сервер может идентифицировать клиента по-своему, скажем добавить полеverifiedили что-то в этом духе.На счёт документации вы совершено правы. Базовые моменты я описал здесь в различных секциях. Но описание конкретных методов всё ещё является слабым место. Я думаю, что это будет embedded документация, то есть встроенная непосредственно в код. Раз уж код генерируется и будут безусловно обновления, то и документацию следуют генерировать тоже.
Спасибо за ваш комментарий.
Всегда стараюсь отвечать максимально деликатно на подобные вашему комментарии. Или просто игнорирую их. Но, знаете, сегодня не буду… надоело, пусть и полетят в меня минусы роем. Для себя я называю такие вот комментарии - «булькающая бабушка».
Суть проста - ты сделаешь что-то, поэкперементируешь, поиграешь с идеями и опишешь это и вот на горизонте появляется она, «булькающая бабушка»… всегда с единственно верным суждением и решимостью его предъявить миру - «это всё г$_&о, не нужно делать х*!?ю»
Я учту о чём мне не думать, но все равно поясню: JSON в данной статье упоминается в качестве наиболее распространённого варианта формата данных, что характерно особенно для небольших web проектов. Никто не оспаривает существование прекрасных парсеров для него (взять хотя бы тот же serde на rust). А clibri так и вовсе не использует JSON вообще и раз так, то и не оптимизирует его. Статья вообще не про это.
На счёт таймаутов вы правы, они отлавливаются на всех болевых точках в rust имплементации и будут добавлены также в typescript совсем скоро. Собственно поэтому и есть плашка alpha, что бы подсветить - не все детали ещё учтены, есть базовое решение, но работа ещё ведётся.
Спасибо. Добра вам и терпимости к инакомыслию.
Большое спасибо за хороший вопрос.
Конечно, protobuf - это первое что приходит на ум, и я ждал подобного вопроса. Но не упоминал о protobuf в статье лишь потому, что clibri не является ни конкурентом (куда уж мне в одиночку), ни тем более альтернативой; не в чистом виде, не в связке с gRPC. Это немного о другом.
Я по большей части работаю с web проектами, поэтому и на протокол смотрю именно с этой стороны. Часто нужно сделать какой-то несложный front-end для какого-нибудь сервиса. И каждый раз «под капотом» практически одно и тоже: транспорт, валидатор, реализация клиента, реализация сервера. Наблюдая порой за коллегами я не раз замечал, как реализация какой-нибудь связки «клиент-сервер» кочует от проекта к проекту, с каждой новой итерацией copy/paster, обрастая незначительными изменениями, то есть коллеги просто брали подходящее решение, копировали и заменяли содержание обработчиков, практически не трогая все остальное (ну разве что состав данных менялся безусловно). Но идея clibri именно в этом — дать возможность разработчику вообще не думать о том, что там делает метод send_something_somewhere. И я подумал, возможно будет интересно, если:
не описывать в протоколе ничего кроме данных (может он в рамках того же проекта будет использоваться для чего-то иного, импорта/экспорта, например)
описывая логику коммуникации (workflow) не описывать никаких функций, а описывать только возвраты и последствия возвратов. Добиться от схемы workflow однозначного и единственного толкования.
сделать так, чтобы разработчик в большей части случаев мог бы просто добавить свой код в уже готовый обработчик. То есть сгенерированное решение должно компилироваться сразу же, ещё до того, как добавлено «мясо» в обработчики.
Я не сравнивал clibri по производительность с protobuf ни с точки зрения кодирования/декодирования, ни с точки зрения экономичности, хотя, наверное, это следует сделать, но быть может немного позднее, ибо сейчас это будет сравнение автомобиля с шаттлом челленджер.
Надеюсь ответил. Ещё раз спасибо за хороший вопрос.
Текущая картина такая:
На rust сейчас наиболее ресурсоёмкие операции: индексация, декодирование/кодирование и другие. Но сессии и поиск модерируются на nodejs. Миграция ядра на rust подразумевает модерацию сессий, включая поиск, на уровне rust; на nodejs останутся лишь какие-то общие задачи. И даже в версии 3.0, я уверен доля rust не вырастет выше 30-35% и это вполне ок, ибо на front-end довольно много кода.
Уточнить: rust не «сбоку», на нем уже сейчас лежит основополагающий функционал по подготовке контента к отображению (как было сказано выше: индексация, кодирование/декодирование). Ну а с версией 3 так и все ядро будет на нем.
Ниже на скрине показано как выглядит DLT файл в chipmunk. Представление строк — столбцами; плюс на sidebar разбивка по полям.
Что касается горячих клавиш, создал issue.
Кроме того, в вашем случае нужно не только найти значение, но и преобразовать его, что несколько осложняет задачу.
Для решения подобных задач в следующих версиях мы хотим добавить определение формата, как регулярного выражения с поименованными группами. Что-то вроде.
(?<YYYY>\d{4})\s(?<MM>\d{2})(?<DD>\d{2})\s(?<hh>\d{2})(?<mm>\d{2})(?<ss>\d{2})Это должно будет работать и для вашего случая
На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.
Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?
Релиз увидите в
На борту надо иметь:
Полагаю я уже ответил частично на ваш комментарий здесь. Могу добавить, что есть несколько идей по тому чтобы научить chipmunk цепляться по ssh, что во многом снимает вопрос удалённого доступа, но открывает проблемы другого характера. Пока думаем над этим. Но если у вас есть какие-то идеи или пожелания, будем очень рады увидеть их в качестве feature request.
В каких-то повседневных задачах, не знаю, файл с настройками подправить, я вот не задумываясь прибегну к nano (или если настроение плохое, к vim). Но все же, для работы над проектом, я открою VSCode или что-нибудь от JetBrains. Я сделаю это не потому что не могу кодить в vim или nano, а просто потому, что удобнее это делать в IDE. Хотя, если задуматься, IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно. И вот эти вот мелочи делают работу удобнее и быстрее.
Как-то так и возник chipmunk. Блин, а как сохранить шаблоны поиска (скажем фильтров 5-10) и не терять их, а ещё по необходимости шарить с коллегами? А как усадить студента-тестировщика и не ввергать его в шок консольными командами, а сказать: «увидишь здесь красное — кричи!». А у нас в логах тут куча закодированных данных, которые было бы очень здорово не копи/пастить по окнам, а сразу читать. Ну и так далее. То есть базово вопрос не в том, что chipmunk умеет делать что-то что не умеют другие, нет, а в том, чтобы попытаться делать это проще. Хотя есть и DLT, которые с консоли декодировать та ещё проблема.
На счёт tail, то уже есть feature request по этому поводу. Думаю что в ближайших обновлениях это появится, то есть chipmunk будет открывать файл и обновлять по мере его изменений.
ЗЫ. Кстати ripgrep шустрее )