Российский центр компетенций по импортозамещению отказался инвестировать в два проекта на базе Java

Ходить при каждом поиске? Эм, а у вас на проекте точно есть архитектор?

Конечно же есть. И вот как он принимает решение:

Я уже писал что нагрузка от 2000 до 8000 запросов в секунду. возьмем в среднем 5000 для рассчетов. Если бездумно ипользовать кеш, то есть вероятность показать протухшие данные около 5% клиентам (что очень хорошая цифра для кеша). Для этого количества запросов это 250 раз в секунду.

В среднем только 1% от количества поисков приводит к покупке билетов. Т.е. 2.5, отбросим пол-человека, пусть будет 2 попытки в секунду купить билеты с протухшими данными.

Теперь пересчитываем: в час это 7200, в сутки - 172800. Т.е. 170 тыс. человек в сутки которые уже достали кредитку и готовы оплатить билеты - мы им «говорим билетов нет» хотя вернули их в поиске. От этого они зляться и уходят на другой сайт.

Поэтому лучше сходить в авиалинию и вернуть актуальные данные.

Даже если всю эту логику получится запихнуть в PL/Sql или T-Sql то возникают вопросы:

• как над этим кодом организовать работу комманды в 5-8 человек?
• как сделать юнит-тестирование для этого кода при каждом коммите?
• как с этим кодом сделать release rollout когда обновление на прод уходит порциями на 10%-20% серверов раз в несколько часов? Чтобы была возможность откатить релиз без даунтайма если с ним что-то не так.
• как его интегрировать с остальными сервисами компании?

Нет, неправильно. Объем памяти такой, а вот поиск - сложный.

как сделать юнит-тестирование для этого кода при каждом коммите?

так «процедура в БД» и есть сама по себе юнит. Json на вход, json на выходе - в простейшем случае. Она отдаёт или правильно, или неправильно. В чём там тестирование-то? Подсовывай шаблонные входные - сравнивай с шаблонными выходными. Не понятно где тут может быть затык. И не надо питонистам/джавистам вообще думать о том, как БДшник распилит таблицы на секции и какие индексы повесит.

как над этим кодом организовать работу комманды в 5-8 человек?

Вот тут да, самому интересно было бы почитать, как люди это делают.

А чего ты решил, что в java проектах не будет ос-специфичного кода?

Если в проекте не используется JNI/JNA/Unsafe/SWT или библиотеки, их использующие, то по идее, обещание «write once run anywhere» будет истинным. Когда что-то из перечисленного набора может использоваться?

• JNI/JNA: Ну, например для десктопных приложений, если нужно подключить библиотеку для шифрования по ГОСТ от вендора, который предоставляет ее только для Windows.
• SWT: Тоже десктопные приложения. И если ее использовать, то приложение будет работать только на Win/Mac/Lin, а например на какой-нибудь Haiku или JNode не заведется.
• Unsafe: Вот это настоящая черная магия. Одноклассники активно используют ее в своих серверных приложениях, но их инженеры знают как и зачем они это делают.

Я сталкивался с первыми двумя вариантами. Но если пишется обычное корпоративное REST-приложение, то это все ненужно и то, что разработчики могут использовать для написания и отладки кода Win/Lin/Mac, а развертывать на сервере с Lin, что вполне красноречиво говорит, что кроссплатформенность есть.

как над этим кодом организовать работу комманды в 5-8 человек?

А в чем проблема?

как сделать юнит-тестирование для этого кода при каждом коммите?

$sqlplus dev/pwd@server my_unit_test.sql > result.txt

как с этим кодом сделать release rollout когда обновление на прод уходит порциями на 10%-20% серверов раз в несколько часов? Чтобы была возможность откатить релиз без даунтайма если с ним что-то не так.

Делаешь обновления достаточно маленьким без этих ваших 10%.

как его интегрировать с остальными сервисами компании?

В чем проблема?

Чтобы не обижались, объясню градацию, под детьми я имею ввиду программистов которые знают и используют в основном один основной ЯП не важно сколько лет, въюноши понимают до 5, половозрелые мужчины до 10, а деды могут говорить о 10+ языках используя свои знания и опыт их применения.

Вы даже не понимаете, что в рамках таргетов JVM/.NET/native язык программирования всё больше перестаёт играть какую-либо роль, если он хотя бы соответствует полноте конструкций VB.NET и обладает гибридной типизацией (статической и при желании динамической)?

RemObjects позволяет абстрагироваться от синтаксиса языка, задействовать либы любых других популярных JVM/.NET языков и таргетировать в нужную байткодовую VM.

Речь шла лишь о том, что синтаксис C# приятнее Java, что на .NET доступны намного более функциональные компоненты для разработки GUI. Я вообще больше любитель VB.NET и скриптов на Bash/Ansible/Terraform HCL, но могу писать на любом из следующих ЯП: tcsh, C#, Python, серверный JavaScript.

Свободно читаю Java (иногда заглядываю в оригинальные либы типа Hibernate), PHP и Perl (немного патчил CMS-ки), Ruby (немного писал на нём для Vagrant), C++ (немного писал на нём в юности).

VBA, VB6, классический ASP (концептуально похож на PHP кстати), VBScript, наверно, сейчас никому не интересны, но я их прекрасно знаю.

Ну вот уже не так все просто. JSON не используется. Во-первых он медленный, что ещё терпимо, а во-вторых он очень большие сообщения делает. С таким объемом коммуникаций трафик внутри даже одного региона очень дорого выходит. В Aws он очень дорогой. Поэтому используется или protobuf или avro. А ещё все трейсы надо хотя бы месяц хранить в Jaeger. Умеет pl/SQL работать с protobuf/avro?

Памяти от 8-16гб в каждом поде

Чёт орнул.

Умеет pl/SQL работать с protobuf/avro?

PG точно умеет в protobuf. Через расширение.

Да, огромные ответы - это проблема. У меня тут ребятишки вчера гигабайт JSONа вчера пытались вытащить из БД. Но это другой вопрос же. Не надо ребятишкам хотеть такое.

Маленький вход -> сложный расчет, за который ребятишкам и волноваться не надо, кроме формата ответа и времени исполнения -> маленький выход.

Я как вспомню WPF и managed c++, так потом 2 ночи не сплю. Ужос-ужос.

А надо было VB.NET + DevExpress WinForms, тогда бы смотрел во сне райские мультики.

Особо одарённые используют и вовсе ActiveX + C++, предлагаешь оплачивать им психиатра сбором средств со всего форума?

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

В яндексе многое написано на Python - с точки зрения клиента бекенд, но для джавы это фронт, причем там дриснявая джанга. Java там нужна для работы с очередями

Я сталкивался с первыми двумя вариантами. Но если пишется обычное корпоративное REST-приложение, то это все ненужно и то, что разработчики могут использовать для написания и отладки кода Win/Lin/Mac, а развертывать на сервере с Lin, что вполне красноречиво говорит, что кроссплатформенность есть.

Так понимаешь ли, возьми любое кроссплатформенное приложение на C++, так оно тоже запуститься под Win/Mac/Linux без изменений исходного кода, если не используется платформозависимый код. Только что соберется три раза. Однако товарищ доказывает, что мол он уверен, что jar будет вылизан и отлажен. - Но это не фишка java, любой код можно вылизать и отладить.

А если взять python, то и собирать предварительно не придется. Так и кому нужна эта фишка java - один раз собрал, запустил везде? При том, что не всегда и не везде, т.к. как и в любом приложении, здесь точно также может быть платформозависимый код.

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

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

Хахахахаха. Красавчек.

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

VB.NET

дайте мне банхаммер, я его забаню

По какой причине? Чем тебя не устраивает VB.NET ?

А чего ты решил, что в java проектах не будет ос-специфичного кода?

Это уже тонкие вопросы архитектуры проекта, а не платформы в целом.

И что тестирование на разных версиях ос в обязанности группы разработки не входит?

Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во многом предсказуем.

И исходя из этого чем оттестированное приложение на не-java-языке отличается по надежности от java?

Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер. Туда же, Rust под MSVC и GCC, Python/PyPy +/- Nuitka с батарейками на C... Кто знает, что там стрельнёт внутри без полноценного тестирования?

Формально входит, но в Java экосистеме с гораздо более низким приоритетом и более щадящем режиме, т.к. ожидаемый результат во много предсказуем.

java - результат предсказуем. Другие языки - нет? Это не фанатизм?

Как пример, приложение на ANSI C (кроссплатформенность на уровне сырцов), может быть собрано с GLIBC, а может с Musl, потому что кто-то вдруг захотел контейнер.

Я так понимаю, что ты имеешь ввиду то, что в одной реализации стандартной библиотеки будут баги, которых нет на той реализации, на который проводили тестирование. Под «оттестированное» я понимаю что под все целевые платформы.

С другой стороны на java конечно же нет платформо-спцецифичных багов, так по твоему? Которые могут проявиться только на той платформе, на которой не тестировали.

Т.е. получается, что java - вроде запускается везде, но не так удобно, как тот же python, потому что компилировать все же нужно.

Сейчас на Java пишут, в основном, REST и прочий веб/корпоратив, поэтому оно будет везде запускаться: собрал JAR/WAR-пакет, скормил любому серверу приложений и оно поехало, хватит писать ерунду про «перекомпиляцию». Она может быть, только в тех случаях, которые я описал выше и только, если в комплекте не идет платформо-зависимая библиотека.

И главные фишки скорее - за выделением памяти не надо следить и память не будет повреждаться при неправильных данных (как в C/C++). И все будет работать на приличной скорости (в отличие от Python).

хватит писать ерунду про «перекомпиляцию»

Так а после изменения исходного кода компилировать не нужно, чтобы jar получить? Я это имел ввиду. Т.е. по сравнению с php/python нужно еще и компилировать/собирать jar перед запуском.

И все будет работать на приличной скорости (в отличие от Python).

Именно, что в отличие от Python.

Если бездумно ипользовать кеш

А если не бездумно? :) Кеши региональные с местными аэропортами в радиусе + хабы пересадки с обновлением раз в минуту.

то есть вероятность показать протухшие данные около 5% клиентам (что очень хорошая цифра для кеша).

Нет, это если делать бездумный кеш как вы описали. Подавляющее большинство посетителей, буквально 99% смотрит на количество пересадок, цену билета, маршруты полёта и тд - все кроме наличия билета прямо сейчас тк они не будут покупать прямо сейчас. Задача кеша и дать им информацию на экране поиска.

А вот когда оставшийся 1% нажимает в выдаче поиска кнопку купить (оформить) вот тогда идёт проверка мимо кеша к тем апи авиакомпаний которые участвуют в этом конкретном маршруте. И это базовая логика, без деталей как учитывать в кеше, региональные особенности, популярные сезонные направления, акции от авиакомпаний и тд.

Боюсь, что вы только подтвердили что архитектора на вашем проекте - нет.

Эм, на все эти вопросы решения есть и там не нужно изобретать велосипед, судя по тому что вы спрашиваете - архитектора у вас реально нет, кек. Я думал вы своими сообщениями просто прикалываетесь, а теперь чёт даже и не уверен.

И главные фишки скорее - за выделением памяти не надо следить и память не будет повреждаться при неправильных данных

Так есть rust тот же.

Я не вас имел ввиду под термином «java дети».

буквально 99% смотрит на количество пересадок, цену билета, маршруты полёта и тд - все кроме наличия билета прямо сейчас тк они не будут покупать прямо сейчас.

да, я и написал - только 1% от поиска ведет к продажам билетов. И надо сделать все чтобы им было удобно покупать билеты. Если этому проценту раз за разом показывать что их рейс куда-то пропал при попытке оплаты - можно растерять всех клиентов которые приносят деньги.

Хороший у нас архитект, другого не надо.

Умеет pl/SQL работать с protobuf/avro?

Вы издеваетесь? Есть как готовые решения типа pg_protobuf так и всякие поделки на C++ которые обычно пилят под себя оптимизируя под свою задачу.

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

И сказано это было в ответ на заявления одного персонажа

А это, надеюсь, про тов. Брежнева ? ;)

Кажется я понял в чем у нас фундаметальное различие. Разница в подходе к построению системы. Ваша цель «Как сэкономить ресурсы (память/cpu/network)» против нашей «Как построить максимально удобную систему которой приятно пользоваться и которая приносит деньги». Да, она будет дороже, не такой «эффективной», но цель у нее другая.

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

Ну что же Вы такое пишите, Вас же дети здесь читают. И начнут пихать protobuf, да еще и в связке с gRPC в свой сервис который обслуживает 100 запросов в день. Json очень хорош для low-traffic систем. Для бинарных протоколов нужно обоснование, когда их стоит использовать.

Сначала хотел предложить вам внимательно перечитать сообщения чтобы понять где вы ошиблись, а потом подумал, а зачем? Мне за качество вашей архитектуры не платят, распинаться далее не буду.

тоже нет, я про детей с нагугленными списками и прочих.

мало того, они уже это делают. На Go. И кто мы такие чтобы их останавливать…

И все же, очень интересно, где ошибка?

Нет, основная моя цель обычно - увеличить скорость доставки информации, что на фронтенде выливается в уменьшение времени отклика.

Почему так? Мы живём в эру когда у широких слоев населения СДВГ разной степени тяжести. Покупателю сложно ролик больше 8 сек посмотреть, а уж форма поиска которая ищет 20 сек это форма результат работы которой никто не будет смотреть. Поинтересуйтесь на досуге последними исследованиями сколько ждёт отклика на сайте средний посетитель и сравните с предыдущими исследованиями.

Если 10 лет назад большая часть оптимизации сводилась к битве с TTFB (time to first byte), то сейчас борьба идёт уже за десятки миллисекунд во всех частях работы системы.

Другими словами, сейчас юзеров оч много и они все очень нетерпеливые. Из-за чего архитекторам сейчас приходится делать не только отказоустойчивый, масштабируемый, поддерживаемый и расширяемый вариант системы, но и ставить приоритетом возможность накормить всех с лопаты, кого блинами, кого - говном (инвалидация кеша). Это оч. большая и дискуссионная тема и баланс в каждом ecommerce проекте будет свой.

Ошибка в том что вы рассматриваете форму поиска как то что должно выдавать точный результат всем 100% пользователям, хотя 99% из них вас не интересуют. Попробуйте посмотреть на форму поиска как на сито, которое работает быстро и отделяет зерна от плевел. Зерна на следующем шаге получат уточненную верную информацию мимо кеша и если что-то не срастётся то второй поиск с альтернативный вариантами уже мимо кеша сделает свое дело. Подумайте над таким подход с ручкой и листиком.

Далее не вижу смысла углубляться, для этого есть нанятый архитектор.

Нет, основная моя цель обычно - увеличить скорость доставки информации, что на фронтенде выливается в уменьшение времени отклика.

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

Это оч. большая и дискуссионная тема и баланс в каждом ecommerce проекте будет свой.

Согласен на все 100%.

ну мы же не знаем кто этот 1% кто пришел за билетами, поэтому достоверную информацию стараемся показывать всем.

Еще раз повторюсь, это очень плохое поведение системы - показать пользователю варианты перелета и при попытке оплаты сказать что таких рейсов нет. И уж вишенка на торте - если при повторном поиске опять предложить этот же вариант маршрута и снова не дать его купить. Пользователь уйдет навсегда. Причем не тот который зашел на посмотреть кто куда летает, а тот которому действительно нужны билеты.

Поэтому и был выбран такой компромис - искать дольше, но точнее.

Если 10 лет назад большая часть оптимизации сводилась к битве с TTFB (time to first byte), то сейчас борьба идёт уже за десятки миллисекунд во всех частях работы системы.

Это конечно хорошее заявление. Но блин сайты многие сайты за счет избытка js, всяких анимаций, плавных меню, аналитики в каждой дырке по каждому клику, проявляют куда большую задумчивость ui на актуальном железе чем 10 лет назад на старом железе и памяти жрут больше.

Фронтенд на какой-то своей волне, да. Сидишь с бэкендщиками, высчитываешь миллисекунды и смотришь где-что ещё можно поджать/оптимизировать. Потом открываешь «главную» конторы... У меня натурально истерика была.

форма поиска которая ищет 20 сек это форма результат работы которой никто не будет смотреть

Недавно фиксил один баг. Если поиск работает дольше 4 часов, то юзера выкидывает из сессии. Поставил 20 часов. Юзеры довольны.

Поэтому лучше сходить в авиалинию

блин, GDSки же безумно долго думают

главная рекламная фишка java (компилируется один раз, запускается везде)

главная фишка явы -

это в целом удобный язык со статической типизацией, кучей батареек в том числе для вебни и развитой инфраструктурой

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

не при попытке оплаты, а на следующем шаге. Оплата - предпоследний шаг чекаута. Возможно, через пару лет, когда ваш проект разовьется, вы поймёте о чем я толкую. Пока что не в коня корм.

Поймите меня правильно, я не пытаюсь доказать что у вас все не так и не то. Вовсе нет. Скорее я предоставил информацию о bleeding edge так сказать, то с чем я сам сталкиваюсь. В вашем проекте совсем другие требования и по двум постам судить обо всей системе можно только в порядке кека. Я написал пару провокационных постов на тему вашего архитекта чтобы спровоцировать дискуссию. Это дало мне понимание уровеня развития вашего проекта и то что я со своими замечаниями бегу впереди паровоза. Вы ко всему этому придёте, сами, когда придёт время.

Пока что не в коня корм.

Лучше и не скажешь. На том и разойдемся.

это в целом удобный язык со статической типизацией, кучей батареек в том числе для вебни и развитой инфраструктурой

Точно также как и python/php.

со статической типизацией

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

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

Думаю, смотря какие задачи.