Мои коллеги недавно решили внедрять Spark OCR плагин от John Snow Labs. Если кто-нибудь пробовал, поделитесь пожалуйста опытом - как оно?
Раньше использовали FineReader Server (14), но по результатам тестирования на реальных документах Spark плагин выдавал более качественные результаты (меньше и менее критические ошибки) при схожей производительности и заметно более выгодном ценнике на больших объёмах данных.
Если я правильно понял, то вы «сервис» разбиваете на несколько функций? Если так то очень интересны 2 момента, если конечно не секрет:
Как вы решаете вопрос с общей логикой (бизнес- и инфрастуктурной) при разделении приложения на несколько функций? Это какой-то общий модуль который есть в каждой функции и все функции деплоятся одновременно по каждому коммиту или как-то иначе?
По каким критериям вы решаете что нужно разбивать сервис/приложение на несколько функций вместо одной?
Судя по тому что написано на их сайте letsencrypt.org/certificates/#cross-signing — у них есть одна пара ключей (приватный+публичный) для их intermediate CA (в данном случае он называется R3) и от этой пары они выпустили 2 сертификата (CSR; полагаю что примерно так это можно сделать), один из которых подписал новый центр сертификации ISRG Root X1 (истекает в 2035), а другой был подписан старым DST Root CA X3 (истекает в Сентябре 2021). Обе цепочки пока что валидны, но сертификаты сами по себе разные (такой и такой), пусть и с одинаковым публичным (а значит и приватным) ключом, т.е. грубо говоря перекрёстная подпись это не про конкретный RSA сертификат, а скорее про пару ключей, которые были использованы для формирования CSR; имхо формулировка с «сертификатами» не очень удачная в целом, т.к. совсем непонятно когда речь про ключи, а когда про конкретные RSA сертификаты которые можно пощупать в der/pem формате.
Что интересно всё на той же странице они рекоммендуют использовать сертификат и цепочку от истекающего в Сентябре DST Root CA X3, полагаю что как раз для совместимости с теми самыми старыми Android девайсами, но мне совершенно непонятно как это всё будет работать на остальных девайсах начиная с Ноября (окей старая java будет вечно доверять этой цепочке, но та же винда и десктопные браузеры я полагаю должны проверять NotAfter у всей цепочки?) — неужели веб серверы должны будут как-то динамически выбирать сертификат (и цепочку) для SSL исходя из «client hello»?
Добрый день, как раз искал подобный виджет, но для несколько иной задачи, не связанной со здоровьем, и наткнулся на эту статью, хотелось бы узнать, можно ли найти пакет в npm и какая лицензия на исходный код (в гитлабе лицензия не указана) и политика контрибутинга?
Занятно, что подобную методологию десериализации/обработки данных с минимальными издержками по памяти уже давно придумали использовать для XML и имя ей SAX.
Как говорится: Всё новое — хорошо забытое старое.
за 3-10 секунд делают запись в блокчейне доступной любому желающему
Возможно для тех, кому приватность действительно важна, вроде тех, кто сейчас использует TOR, это подойдёт, но для массового пользователя выглядит жутко неудобно (особенно в реалиях нестабильного/мобильного интернета).
В целом у меня возникают некоторые сомнения в возможности масштабирования подобного решения. Ведь в мире каждую секунду создаются миллионы сессий со всех концов света, а нам при всём этом нужно, чтобы в блокчейне при этом не случалось конфликтов или был автоматический механизм их разрешения в кратчайшие сроки.
Так же при массовом использовании вызывает опасение объём трафика, летающий между нодами в целях синхронизации. Тут, наверное, можно было бы сделать шардирование на более мелкие цепочки (может даже динамическое), но в этом случае, на мой взгляд, куда более вероятны атаки.
Первый — как и сейчас в https — прошитый в браузер адресс публичного «удостоверяющего центра» (по сути одна из нод, которую например крупный поисковик решил сделать публичной для удобства). Этот способ сопоставим по безопасности с текущей реализацией https.
Получается что в этом случае мы получаем примерно те же векторы атак, что и с https, только с повышенной централизацией, т.к. почти наверняка получим примерно ту же ситуацию, что и с DNS сервисами, где 2-3 крупных игрока обслуживают большую часть пользовательского трафика — на мой взгляд это может быть даже хуже того, что мы сейчас имеем с публичными CA.
Возможно я что-то не понимаю, так что буду рад почитать подробнее, когда будет отдельная статья.
Второй — скачать себе на железо блокчеин и верифицировать поступающие обновления через встроенный в код механизм соблюдения консенсуса. Это для тех, кто подходит к вопросу безопасности со всей серьезностью. Проще говоря, если собственная нода «приняла» поступившую запись, то все с ней нормально.
В этом случае мы получаем все минусы хостинга блокчейна на своей машине, например, при медленной сети локальная нода практически наверняка не сможет угнаться за цепочкой и выписать новый блок; а так же повышенные минимальные требования к железу (хотя возможно это не самая большая проблема, если не использовать PoW).
Первое что пришло мне в голову после прочтения данной статьи:
Сколько нужно будет ждать, пока пройдёт «регистрация» сессионного ключа и вызываемая сторона начнёт мне доверять (блок с моим ключём попадёт в блокчейн и синхронизируется между нодами)? Сможет ли он хоть как-то конкурировать с HTTPS по скорости работы и удобству?
Как будет осуществляться безопасное взаимодействие до blockchain-нод? Как будет осуществляться первичный поиск хостов и т.д.?
Если блокчейн будет использоваться в том числе и для хранения отпечатков сессионных ключей, то не окажется ли что при активном использовании, сопоставимым с текущими объёмами https трафика, размер блокчейна начнёт превышать возможности его хранения на каждой из машин, участников блокчейна?
Кто будет оплачивать содержание всей этой инфрастуктуры, разработки ПО, рекламу
и т.д.? По крайней мере до момента достижения критической массы пользователей, когда на данный протокол обратят внимание крупные компании.
Хотелось бы добавить на тему последнего пункта про «await в однострочном методе», что при возврате task'а напрямую (без использования async-await), вызов такого метода не будет виден в callstack'е при возниковении exception'а где-то в процессе работы «проброшенного» таким образом task'а. В некоторых случаях это может привести к серьёзным проблемам при расследовании подобных ошибок, особенно если в коде довольно много ветвлений, которые в конечном итоге заканчиваются вызовом одного и того же метода (например, вызова API).
А не могли бы вы объяснить, чем обусловлен выбор именно Golang, а не используемых у вас в компании Java и PHP, для данной задачи?
Ещё очень интересно было бы понять, почему вы решили делать доработку именно в формате микросервиса, а не правки в существующий сервис, что по сути было бы просто расширением ограничения с 10к до 300к строк?
2) Забудьте про ConfigureAwait. Это костыль и мусор который захламляет код и не пригодится при выполнении пункта 1
Ну это весьма даже опасный совет, особенно если придётся много Task-based задач выполнять параллельно — контекст будет форсировать не более 1 задачи за раз, в итоге производительность будет в разы хуже, нежели при выполнении задач на ThreadPool'е.
А можно чуть подробнее про «предусмотрена возможность «переписать историю» — в случае, если некто (т.н. узел-«рыбак») докажет, что один из блоков был подписан некорректно»?
В частности, интересно, кому и как «некто» будет доказывать, что блок подписан некорректно?
Мои коллеги недавно решили внедрять Spark OCR плагин от John Snow Labs. Если кто-нибудь пробовал, поделитесь пожалуйста опытом - как оно?
Раньше использовали FineReader Server (14), но по результатам тестирования на реальных документах Spark плагин выдавал более качественные результаты (меньше и менее критические ошибки) при схожей производительности и заметно более выгодном ценнике на больших объёмах данных.
FineReader вроде тоже нейросети использует в свежих версиях для некоторых языков, по крайней мере так они писали в release notes.
Судя по тому что написано на их сайте letsencrypt.org/certificates/#cross-signing — у них есть одна пара ключей (приватный+публичный) для их intermediate CA (в данном случае он называется R3) и от этой пары они выпустили 2 сертификата (CSR; полагаю что примерно так это можно сделать), один из которых подписал новый центр сертификации ISRG Root X1 (истекает в 2035), а другой был подписан старым DST Root CA X3 (истекает в Сентябре 2021). Обе цепочки пока что валидны, но сертификаты сами по себе разные (такой и такой), пусть и с одинаковым публичным (а значит и приватным) ключом, т.е. грубо говоря перекрёстная подпись это не про конкретный RSA сертификат, а скорее про пару ключей, которые были использованы для формирования CSR; имхо формулировка с «сертификатами» не очень удачная в целом, т.к. совсем непонятно когда речь про ключи, а когда про конкретные RSA сертификаты которые можно пощупать в der/pem формате.
Что интересно всё на той же странице они рекоммендуют использовать сертификат и цепочку от истекающего в Сентябре DST Root CA X3, полагаю что как раз для совместимости с теми самыми старыми Android девайсами, но мне совершенно непонятно как это всё будет работать на остальных девайсах начиная с Ноября (окей старая java будет вечно доверять этой цепочке, но та же винда и десктопные браузеры я полагаю должны проверять NotAfter у всей цепочки?) — неужели веб серверы должны будут как-то динамически выбирать сертификат (и цепочку) для SSL исходя из «client hello»?
Как говорится: Всё новое — хорошо забытое старое.
Возможно для тех, кому приватность действительно важна, вроде тех, кто сейчас использует TOR, это подойдёт, но для массового пользователя выглядит жутко неудобно (особенно в реалиях нестабильного/мобильного интернета).
В целом у меня возникают некоторые сомнения в возможности масштабирования подобного решения. Ведь в мире каждую секунду создаются миллионы сессий со всех концов света, а нам при всём этом нужно, чтобы в блокчейне при этом не случалось конфликтов или был автоматический механизм их разрешения в кратчайшие сроки.
Так же при массовом использовании вызывает опасение объём трафика, летающий между нодами в целях синхронизации. Тут, наверное, можно было бы сделать шардирование на более мелкие цепочки (может даже динамическое), но в этом случае, на мой взгляд, куда более вероятны атаки.
Получается что в этом случае мы получаем примерно те же векторы атак, что и с https, только с повышенной централизацией, т.к. почти наверняка получим примерно ту же ситуацию, что и с DNS сервисами, где 2-3 крупных игрока обслуживают большую часть пользовательского трафика — на мой взгляд это может быть даже хуже того, что мы сейчас имеем с публичными CA.
Возможно я что-то не понимаю, так что буду рад почитать подробнее, когда будет отдельная статья.
В этом случае мы получаем все минусы хостинга блокчейна на своей машине, например, при медленной сети локальная нода практически наверняка не сможет угнаться за цепочкой и выписать новый блок; а так же повышенные минимальные требования к железу (хотя возможно это не самая большая проблема, если не использовать PoW).
и т.д.? По крайней мере до момента достижения критической массы пользователей, когда на данный протокол обратят внимание крупные компании.
Ещё очень интересно было бы понять, почему вы решили делать доработку именно в формате микросервиса, а не правки в существующий сервис, что по сути было бы просто расширением ограничения с 10к до 300к строк?
blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html
Ну это весьма даже опасный совет, особенно если придётся много Task-based задач выполнять параллельно — контекст будет форсировать не более 1 задачи за раз, в итоге производительность будет в разы хуже, нежели при выполнении задач на ThreadPool'е.
В частности, интересно, кому и как «некто» будет доказывать, что блок подписан некорректно?