если бы у нас Собак пришёл с таким ПР, я бы пару дней токсифицировал его в комментах

кто-нибудь знает, как кросс-тестить scalajs код на jvm и js? я тут криптографию заимплементил и надо бы написать тесты на то, что что генерируется в js хавается в jvm и наоборот

Я думаю только в отдельном проекте

третий или четвёртый раз в жизни такую муру писал даже в воркшите

что было в воркщите - остается в воркщите

третий или четвёртый раз в жизни такую муру писал даже в воркшите

ну то есть опыт есть, код надёжен, техника отработана! :D

ну то есть опыт есть, код надёжен, техника отработана! :D

да, воркшиты надёжно покрыты тестами, на 200%

и выпущены как либа

в манатки!

я думал что рефлексия ненуждается в покрытии тестами она нуждается в токсификации

я думал что рефлексия ненуждается в покрытии тестами она нуждается в токсификации

в такой? https://www.youtube.com/watch?v=vsPBpcBGVgQ

нет, в такой https://www.youtube.com/watch?v=dQw4w9WgXcQ

вангую быстрый заработок

может дружный коллектив

может дружный коллектив

не знаком с этим штаммом

ааааа hr

hr бы среагировал на факт моего вангования

лидеры отрасли

https://djinni.co/r/16276-international-it-recruiter-at-devbuddies-io/

неловкий момент когда я угадал

>Developers connecting Developers with Startups in Berlin We are tech people from Berlin hacking traditional tech recruiting by connecting developers from all over the world directly with startup teams we know and we trust. Our advantage over recruiters is that we can give you real insights into the Berlin startup scene! <

ж^(

судя по фото на стене это наверное комбо

из вас двоих вышла бы отличная HR-команда

троих*

функциональный хантинг

hr кололись плакали, но продолжали искать скалистов

травились тогда уже

кьяроскуро подвело

скалу тут обсуждаем

нужен метастикер [говно] ГОВНО

понедельник, судя по всему, выдался у всех спокойный и ненапряжённый

? ГОВНО!

Чат, концептуальный вопрос. Есть некая модель данных, скажем - документ с каким то числом полей. И есть большое число бизнес правил (100+) по валидации данного документа, в том числе по данным, которые находятся в справчниках в БД. Что нужно, валидировать большое число таких документов (10-100k/sec) относительно этих бизнес правил, которые еще и часто меняются. Чего бы тут заиспользовать?

? ГОВНО!

это похоже на толковый словарь

Чат, концептуальный вопрос. Есть некая модель данных, скажем - документ с каким то числом полей. И есть большое число бизнес правил (100+) по валидации данного документа, в том числе по данным, которые находятся в справчниках в БД. Что нужно, валидировать большое число таких документов (10-100k/sec) относительно этих бизнес правил, которые еще и часто меняются. Чего бы тут заиспользовать?

rust

или clickhouse

нахерачил такой уберселект, а кликхаус подтянул все справочники в оперативку, разбил твои правила по колонкам, и пошёл чекать разные колонки в сто потоков

Чат, концептуальный вопрос. Есть некая модель данных, скажем - документ с каким то числом полей. И есть большое число бизнес правил (100+) по валидации данного документа, в том числе по данным, которые находятся в справчниках в БД. Что нужно, валидировать большое число таких документов (10-100k/sec) относительно этих бизнес правил, которые еще и часто меняются. Чего бы тут заиспользовать?

Зависит от сложности правил, и насколько часто они меняются. Взять что-нибудь потоковое, (flink, spark-streaming и т.п.) и вперёд, на выход плевать ключ документа -> результат проверки

или clickhouse

это новый универсальный ответ? типа как "акка+монга", теперь будет "rust+кликхаус"?

или можно нахреначить свои "стрелки" и оптимизировать их как в HXT

чтобы опять же можно было обходить документы, чекая все правила параллельно

это новый универсальный ответ? типа как "акка+монга", теперь будет "rust+кликхаус"?

но я же детализировал

чтобы опять же можно было обходить документы, чекая все правила параллельно

а если между правил есть зависимости и сложность выполнения правил отличается?

а если между правил есть зависимости и сложность выполнения правил отличается?

неприятность тогда

но "между правилами есть зависимость" выражается и в стрелках и в SQL

Да, проверки бывают связаны - не выполнилась одна, нет смысла выполнять цепочку дальше. Сложность проверок относительно невысокая, это проверить, что в справочнике такое значение есть, что даты в интервале, и тд.

Да, проверки бывают связаны - не выполнилась одна, нет смысла выполнять цепочку дальше. Сложность проверок относительно невысокая, это проверить, что в справочнике такое значение есть, что даты в интервале, и тд.

справочник в памяти держать можно ?

так что тут несложно

Еще нюанс что таких типов документов будет много 50+, у каждого свои наборы правил и каждый смотрит на свои справочники и источники данных.

Еще нюанс что таких типов документов будет много 50+, у каждого свои наборы правил и каждый смотрит на свои справочники и источники данных.

правил сотня для каждого типа?

справочник в памяти держать можно ?

Справочники переиспользуют разные сервисы, выглядит, что это не разумно - в каждом сервисе грузить все справочники. Хотя надо подумать

ну это просто отдельно фильтрануть и повторять untill win

правил сотня для каждого типа?

Да, у каждого из документов свои наборы правил

Справочники переиспользуют разные сервисы, выглядит, что это не разумно - в каждом сервисе грузить все справочники. Хотя надо подумать

я не предлагаю их хранить для использования другими сервисами. Я к тому можно ли все инфу касательно правил хранить в памяти ?

я не предлагаю их хранить для использования другими сервисами. Я к тому можно ли все инфу касательно правил хранить в памяти ?

ну кстати, да. Оба моих решения неявно предполагают тоже, что можно

Часть наверно можно, именно справочники всяких валют и прочее, что особо никогда не меняется. Но есть динамическая часть, например справочник счетов, и эти счета нон стоп обновляются.

В целом я понял посыл, надо обдумывать стриминговое решение, и пристальнее глянуть на кликхаус

Часть наверно можно, именно справочники всяких валют и прочее, что особо никогда не меняется. Но есть динамическая часть, например справочник счетов, и эти счета нон стоп обновляются.

вопрос, есть ли возможность на момент чека всосать их все в оперативку, позволяет ли их размер?

кликхаус имхо немного для другого заточен.

кликхаус имхо немного для другого заточен.

по-моему, такие штуки вполне в его компетенции

для динамической части скорее всего придется лепить отдельный сервис, который будет держать указанную нагрузку.

вопрос, есть ли возможность на момент чека всосать их все в оперативку, позволяет ли их размер?

Думаю, что как вариант это можно рассмотреть. По крайней мере протитипчик с загрузкой в память точно получится.

для динамической части скорее всего придется лепить отдельный сервис, который будет держать указанную нагрузку.

и соответствнно дергать сервис, если прошли все независимые статические проверки.

Вообще, это батчевый процесс - клиент отправляет в бек 10к документов и для них нужен примерно один и тот же набор инфы. Вот если 2й клиент загрузит - у него свой набор данных. Но это в принципе можно пошардить, что бы на одних и тех же нодах не скапливались. Например.

а правила через админку меняются или через релиз?

по-моему, такие штуки вполне в его компетенции

с уберселектом можно слегка попасть, учитывая, что у clickhouse весьма специфичный SQL. Но тут надо уже конкретно смотреть, что можно покрыть, а что нет.

Да, проверки бывают связаны - не выполнилась одна, нет смысла выполнять цепочку дальше. Сложность проверок относительно невысокая, это проверить, что в справочнике такое значение есть, что даты в интервале, и тд.

ну вот это вроде выглядит хорошо

SQL, конечно же нужно генерить

но я за стрелочный вариант

а правила через админку меняются или через релиз?

Тоже думал об этом - думаю, что через релиз -вполне себе норм решение. Что бы не городить огород с кастомизацией этих проверок

Вообще, это батчевый процесс - клиент отправляет в бек 10к документов и для них нужен примерно один и тот же набор инфы. Вот если 2й клиент загрузит - у него свой набор данных. Но это в принципе можно пошардить, что бы на одних и тех же нодах не скапливались. Например.

откуда тогда требование в 100 krps ?

Это примерные прикидки по нагрузке на данный момент

Но это, скажем так, идеальные цифры. Если там будет даже 1k / sec на одной ноде, это уже будет очень хороший результат.

В общем, в один момент времени нагрузка в пике может достигать 100к/sec, и ее хорошо бы размазать по нодам

Сейчас в легаси проекте это прям нон стоп запросами в Оракл улетает, 3000 документов обрабатываются несколько минут под нагрузкой. Прикидываю, как это все переписать

Чат, концептуальный вопрос. Есть некая модель данных, скажем - документ с каким то числом полей. И есть большое число бизнес правил (100+) по валидации данного документа, в том числе по данным, которые находятся в справчниках в БД. Что нужно, валидировать большое число таких документов (10-100k/sec) относительно этих бизнес правил, которые еще и часто меняются. Чего бы тут заиспользовать?

Можно написать гибкий DSL на Groovy ;)

Можно написать гибкий DSL на Groovy ;)

Гибкий ??? на груви ?

Гибкий ??? на груви ?

смешно

В общем, в один момент времени нагрузка в пике может достигать 100к/sec, и ее хорошо бы размазать по нодам

Это имеется ввиду что 100к документов в секунду должны все контроли проходить? Крепко

Хотя бы 10к.

Это вполне реально даже на простой имплементации параллельной валидации с кешированием данных из базы на момент валидации

Прототип пока такие показатели показывает

А сами контроли кодом или как-то гибко настраиваемо в конфигах?