Вам, возможно, приглянется проект Rhasspy, возникший из похожих мотиваций, но не поддерживающий Windows напрямую (только через WSL) и пока не имеющий распространяемых пакетов команд. Есть ещё более "костлявая" его версия — voice2json, которая скорее набор конструкторных деталей для работы с голосом.
Проект ощутимо так разросся, хорошо распознаёт ограниченный корпус русского языка (формируется из описанной грамматики команд) и даже натренировал свою систему TTS Larynx. У которой с русским языком есть некоторые странности ("шесть" произносит как "шос"), но в остальном звучит неплохо.
То, что вы описали, больше на OV похоже, чем на EV. С другой стороны, вся эта система с DV/OV/EV держится на ЦСах, и если они косячат с жёсткостью проверок, то уровни всё равно не работают :\
Можно создать собственный ЦС и добавить как доверенный на свои устройства. Без каких-либо проверок третьими сторонами. Это уже сейчас несложно, и если спрос на этот приём будет расти, то будет становиться только проще.
Разве что Яндекс.Браузер может возмутиться, что сертификат указывает на неведомый ему ЦС; но он, я надеюсь, хотя бы спрашивает, что с этим делать. Лично не пользовался.
Возможно, с распространением повсеместной DV от Let's Encrypt сертификаты уровня OV выделят каким-то особым способом. Сейчас, чтобы отличить OV от DV, нужно залезть внутрь сертификата и посмотреть на поле «субъект» (subject).
А ярко выделяются только EV: в Chrome вместо слова «Защищено» отображается название фирмы, на которую выписан сертификат.
Это в основном касается уровней сертификатов, в порядке возрастания цен и надёжности: DV, OV и EV.
Отличаются они тем, сколько усилий центр сертификации вкладывает в проверку владельца домена:
для DV проверяет только контроль над доменом
для OV проверяет существование заявленной организации и связь владельца домена с ней по документам и "надёжным третьим сторонам"
для EV тоже проверяет фирму, но с максимальной строгостью, вплоть до навязывания своих требований по части безопасности
DV гарантируют только получение контента, условно, "от владельца домена, без порчи посредниками". OV и EV помимо гарантий DV уже свидетельствуют о связи с фирмой, возможно серьёзной — важно в местах, связанных с деньгами, например.
Let's Encrypt выдаёт только DV.
Для пользователей сертификаты DV от LE или любого другого провайдера с известным доверенным центром сертификации ведут себя совершенно одинаково.
Для администраторов — сертификаты от LE довольно краткосрочные и их обновление стоит автоматизировать, кроме этого никаких существенных ограничений.
Точно. То есть, да, отпилен лишь частично. Похоже, что только для случаев, когда в качестве контекста поиска явно указан класс (а для модулей это и так не работало). Тесткейс.
Никак не заставлю себя открыть "Ruby Under a Microscope", там наверняка про это есть :/
Лично сталкивался с ситуацией, когда банк узнал о смене владельца номера, при том что сим-карта и оператор остались прежние. Так что возможность определённо существует.
Я пробовал разок, рисовал для нового проектика схему с довольно плотными связями по составным ключам. Субъективно понравилось. Умеет довольно много постгресо-специфичных штук. Визуализация несколько громоздкая, элементы частенько перекрываются, но разложить до приличного вида возможно. Связи показывает прямо к столбцам, а не просто к табличкам.
Существуют уже собранные DEB-пакеты в репозиториях PGDG (официальных репах PostgreSQL). Я просто со скучающим лицом вбил в поиск pgmodeler по репозиториям, и когда результаты нашлись, насколько обалдел.
Я б сказал, что попробовать стоит. Если ну прям очень лень возиться со сборкой, можно попробовать на убунтовой виртуалке. И уже тогда решить, возиться со сборкой, или нет.
Бывает и «содержательная»: баг-репорты/фиксы движка, трактовка и исправление документации, разработка расширений/фич, и т. д. Её количество зависит от активности опытных участников в сообществе.
А откуда эти опытные участники появляются? Либо приходят уже со схожим опытом и привыкают, либо вырастают из неопытных.
1. Корректен только в объектах/мапах.
2. Является частью данных, при преобразовании будет полностью загружен в память (что нужно дополнительно обходить, если это проблема).
JSON — формат обмена данными, у которого есть множество реализаций для самых разных языков программирования. Он как раз примечателен тем, что он не исполняем, а потому относительно безвреден, а вычислительные ресурсы по его преобразованию обычно близки к О(strlen(message)).
Если нужно обрабатывать данные перед преобразованием в JSON — как раз существующие реализации покрывают эти нужды. Ведь если есть JSON, то где-то рядом работает и преобразователь между JSON и нативными типами (как правило). Добавлять ещё один язык в технологический стек нерационально или даже опасно.
Я вижу только один адекватный способ применения: преобразование структуры JSON-документов — когда у нас есть только исходный документ и приёмник, в который надо послать документ с этими же данными, но в другой структуре. Больше я не вижу ситуаций, когда не используется реализация JSON на другом языке и потому есть свобода выбора. Но лично я даже в этой ситуации выбрал бы Ruby, Python (основы которого изучал бы на ходу, поскольку его не знаю) или JS/производные.
Вам, возможно, приглянется проект Rhasspy, возникший из похожих мотиваций, но не поддерживающий Windows напрямую (только через WSL) и пока не имеющий распространяемых пакетов команд. Есть ещё более "костлявая" его версия — voice2json, которая скорее набор конструкторных деталей для работы с голосом.
Проект ощутимо так разросся, хорошо распознаёт ограниченный корпус русского языка (формируется из описанной грамматики команд) и даже натренировал свою систему TTS Larynx. У которой с русским языком есть некоторые странности ("шесть" произносит как "шос"), но в остальном звучит неплохо.
Подозреваю, что имелся в виду переход на исходно хромиумные WebExtensions.
Разве что Яндекс.Браузер может возмутиться, что сертификат указывает на неведомый ему ЦС; но он, я надеюсь, хотя бы спрашивает, что с этим делать. Лично не пользовался.
Возможно, с распространением повсеместной DV от Let's Encrypt сертификаты уровня OV выделят каким-то особым способом. Сейчас, чтобы отличить OV от DV, нужно залезть внутрь сертификата и посмотреть на поле «субъект» (subject).
А ярко выделяются только EV: в Chrome вместо слова «Защищено» отображается название фирмы, на которую выписан сертификат.
Это в основном касается уровней сертификатов, в порядке возрастания цен и надёжности: DV, OV и EV.
Отличаются они тем, сколько усилий центр сертификации вкладывает в проверку владельца домена:
DV гарантируют только получение контента, условно, "от владельца домена, без порчи посредниками". OV и EV помимо гарантий DV уже свидетельствуют о связи с фирмой, возможно серьёзной — важно в местах, связанных с деньгами, например.
Let's Encrypt выдаёт только DV.
Для пользователей сертификаты DV от LE или любого другого провайдера с известным доверенным центром сертификации ведут себя совершенно одинаково.
Для администраторов — сертификаты от LE довольно краткосрочные и их обновление стоит автоматизировать, кроме этого никаких существенных ограничений.
Точно. То есть, да, отпилен лишь частично. Похоже, что только для случаев, когда в качестве контекста поиска явно указан класс (а для модулей это и так не работало). Тесткейс.
Никак не заставлю себя открыть "Ruby Under a Microscope", там наверняка про это есть :/
Забавный факт: в недавно (месяц назад) выпущенном Ruby 2.5 кусок алгоритма, представленный вами в п. 3 ("проверяется верхний уровень") отпилен.
Лично сталкивался с ситуацией, когда банк узнал о смене владельца номера, при том что сим-карта и оператор остались прежние. Так что возможность определённо существует.
Вышеупомянутый PgModeler показывает связи у колонок.
Я пробовал разок, рисовал для нового проектика схему с довольно плотными связями по составным ключам. Субъективно понравилось. Умеет довольно много постгресо-специфичных штук. Визуализация несколько громоздкая, элементы частенько перекрываются, но разложить до приличного вида возможно. Связи показывает прямо к столбцам, а не просто к табличкам.
Существуют уже собранные DEB-пакеты в репозиториях PGDG (официальных репах PostgreSQL). Я просто со скучающим лицом вбил в поиск pgmodeler по репозиториям, и когда результаты нашлись, насколько обалдел.
Я б сказал, что попробовать стоит. Если ну прям очень лень возиться со сборкой, можно попробовать на убунтовой виртуалке. И уже тогда решить, возиться со сборкой, или нет.
Бывает и «содержательная»: баг-репорты/фиксы движка, трактовка и исправление документации, разработка расширений/фич, и т. д. Её количество зависит от активности опытных участников в сообществе.
А откуда эти опытные участники появляются? Либо приходят уже со схожим опытом и привыкают, либо вырастают из неопытных.
Второй кончается как-то продуктивнее.
2. Является частью данных, при преобразовании будет полностью загружен в память (что нужно дополнительно обходить, если это проблема).
О(strlen(message)).Если нужно обрабатывать данные перед преобразованием в JSON — как раз существующие реализации покрывают эти нужды. Ведь если есть JSON, то где-то рядом работает и преобразователь между JSON и нативными типами (как правило). Добавлять ещё один язык в технологический стек нерационально или даже опасно.
Я вижу только один адекватный способ применения: преобразование структуры JSON-документов — когда у нас есть только исходный документ и приёмник, в который надо послать документ с этими же данными, но в другой структуре. Больше я не вижу ситуаций, когда не используется реализация JSON на другом языке и потому есть свобода выбора. Но лично я даже в этой ситуации выбрал бы Ruby, Python (основы которого изучал бы на ходу, поскольку его не знаю) или JS/производные.