Мне видится, что проблему можно декомпозировать на три вполне понятные и относительно простые задачи: 1. Закрепление авторского права: тут уже в комментариях предлагали решение с заказными письмами с работой самому себе, чтобы в случае споров на руках было юридически значимое доказательство. Можно ещё к юристу по авторскому праву обратиться за консультацией. 2. Перевод на английский - вы в комментах писали, что нужные вам журналы настаивают на переводе. Его, опять же, можно сделать с любой доступной LLM. То, что вы не имеете возможности проверить качество перевода - это опять же решается через консультацию специалиста. Не думаю, что у вас в окружении нет ни одного человека, кто бы владел английским ). Да и у редактора/секретаря профильного журнала можно попросить рекомендацию англоязычного редактора. 3. Поиск подходящей площадки для публикации: ну вот Перплексити для русскоязычных публикаций рекомендует Математический сборник, Известия РАН. Серия математическая и Успехи математических наук. В каждое издание можно обратиться с вопросом об условиях публикации. Если требуют ревизию статьи, а на работе люди нерелевантного профиля, то можно попробовать попросить редакцию порекомендовать конкретных экспертов, которым можно передать материал на рецензию. Редакторы обычно заинтересованы в качественных статьях и могут помочь с процессом. Про соблюдение авторских прав в этой схеме - обращаемся к пункту 1, его тогда нужно провернуть до пересылки материала куда-либо )
Ответ от Вадима: Всё верно, задача FLST трансформировать запрос, к примеру, вида "Внуково - Адлер для двух пассажиров на такое-то число" в многопоточный параллельный процесс поиска всех возможных вариантов в разных источниках. Формирование из этих потоков оптимальных результатов - задача для других наших сервисов, которыми занимается отдельная команда. Я думаю, если есть интерес, они могли бы оформить это тоже в отдельную статью.
Ответ от Вадима: Масштабирование сделано везде на основании CPU/MEM, и только на Search workers - через KEDA (https://keda.sh/) на основании количества поисковых горутин. Это количество на 1 под было выведено скорее экспериментальным путём, скейлинг включается чтобы не допустить более N поисковых горутин на 1 под. Остальные сервисы не такие прожорливые на ресурсы, и отлично себя показали со скейлингом чисто по CPU/MEM.
Из интересных плюшек наверное только то, что стало сильно проще распараллеливать процессы, масштабировать отдельные компоненты, а так же иметь на выходе скомпилированный бинарник который можно положить в docker image сильно меньшего размера.
MariaDb у нас стандарт в компании, эту часть не хотелось трогать. А KeyDb заменил Redis поскольку мультипоточна и производительнее Редиса.
На тот момент Weave Flux использовался минимально. Но согласны: пожалуй,нам стоило бы сказать, что для улучшения процессов нужно было форсировать переход на GitOps.
«Мы смогли успешно изолировать кровь неандертальцев и шерстистых мамонтов» — т.е. с ними шансов на воспроизводство больше, т.к. и более-менее подходящие «яйца» найти тоже проще, чем динозавровые? :)
«а выбраковывались ли аллергики, диабетики, которым мама сладкое запрещает по объективным причинам и те, кто тупо не любит сладкое или мармеладки»
— покажите мне хоть одного трёхлетнего ребёнка, который _не любит_ сладкое… оч вряд ли такой найдётся
Мне видится, что проблему можно декомпозировать на три вполне понятные и относительно простые задачи:
1. Закрепление авторского права: тут уже в комментариях предлагали решение с заказными письмами с работой самому себе, чтобы в случае споров на руках было юридически значимое доказательство. Можно ещё к юристу по авторскому праву обратиться за консультацией.
2. Перевод на английский - вы в комментах писали, что нужные вам журналы настаивают на переводе. Его, опять же, можно сделать с любой доступной LLM. То, что вы не имеете возможности проверить качество перевода - это опять же решается через консультацию специалиста. Не думаю, что у вас в окружении нет ни одного человека, кто бы владел английским ). Да и у редактора/секретаря профильного журнала можно попросить рекомендацию англоязычного редактора.
3. Поиск подходящей площадки для публикации: ну вот Перплексити для русскоязычных публикаций рекомендует Математический сборник, Известия РАН. Серия математическая и Успехи математических наук. В каждое издание можно обратиться с вопросом об условиях публикации. Если требуют ревизию статьи, а на работе люди нерелевантного профиля, то можно попробовать попросить редакцию порекомендовать конкретных экспертов, которым можно передать материал на рецензию. Редакторы обычно заинтересованы в качественных статьях и могут помочь с процессом. Про соблюдение авторских прав в этой схеме - обращаемся к пункту 1, его тогда нужно провернуть до пересылки материала куда-либо )
Да, пожалуй, Мамкин Айтишник уже ойвсё, это я ещё люблю слушать старьё )))
Удивилась, что нет Радио Т, Запуск Завтра, Мамкин Айтишник...
Ответ от Вадима:
Всё верно, задача FLST трансформировать запрос, к примеру, вида "Внуково - Адлер для двух пассажиров на такое-то число" в многопоточный параллельный процесс поиска всех возможных вариантов в разных источниках. Формирование из этих потоков оптимальных результатов - задача для других наших сервисов, которыми занимается отдельная команда. Я думаю, если есть интерес, они могли бы оформить это тоже в отдельную статью.
Ответ от Вадима:
Масштабирование сделано везде на основании CPU/MEM, и только на Search workers - через KEDA (https://keda.sh/) на основании количества поисковых горутин. Это количество на 1 под было выведено скорее экспериментальным путём, скейлинг включается чтобы не допустить более N поисковых горутин на 1 под. Остальные сервисы не такие прожорливые на ресурсы, и отлично себя показали со скейлингом чисто по CPU/MEM.
Из интересных плюшек наверное только то, что стало сильно проще распараллеливать процессы, масштабировать отдельные компоненты, а так же иметь на выходе скомпилированный бинарник который можно положить в docker image сильно меньшего размера.
MariaDb у нас стандарт в компании, эту часть не хотелось трогать. А KeyDb заменил Redis поскольку мультипоточна и производительнее Редиса.
На тот момент Weave Flux использовался минимально. Но согласны: пожалуй, нам стоило бы сказать, что для улучшения процессов нужно было форсировать переход на GitOps.
— покажите мне хоть одного трёхлетнего ребёнка, который _не любит_ сладкое… оч вряд ли такой найдётся