Можно по архитектуре вопрос? В языках Go, Kotlin и Java соответственно есть Goroutines, Coroutines и Virtual Threads (с Java 21). Во всем ли они лучше реактивных технологий? Или у них, в сравнении с реактивными, разные области эффективного применения?
Верю, вы продумали какие функции должны быть у библиотеки такого класса и как сделать ее компактной и быстрой.
Но забыли продумать, как сделать, чтобы разработчику было удобно. Синтаксис и стиль кода противоестественные, местами ставящие в тупик. Раскрыл бы мысль, но еще ни разу не сталкивался, чтобы такую критику воспринимали конструктивно. Да и формировать реестр видимых недостатков эргономики, это времени требует.
"Чукча хитрый однако"(с) Сначала описание проблем соискателей - поставил лайк. Потом проблемы галер представлены, как универсальные для рынка - лайк уже не отзовешь.
p.s. Советовать IBM BPM не буду. Дорогой и с 2006 года не развивается.
Что поражает - за 5 лет разработки, 20 лет назад, могли создать более качественное и функциональное приложение, чем за 15 лет на "современных технологиях" (Camunda и остальные современные аналоги, выродившиеся в распил инвесторских денег).
Полгода писал на Camunda, скрипя зубами от мусорного качества встроенного функционала.
Опыт банка Тиньков, описанный у вас, подтвердил догадки — 98% функционала Camunda лучше не использовать и программировать на других языках. Получится быстрее, читабельней и надежней.
Общая беда всех BPMS - если в модели отразить бизнесовый уровень логики, а технологический скрыть в контексте и скриптах, получается абсолютно неподдерживаемое приложение. Как организована работа с данными, видно в формате мелких фрагментов в "задачах", которые невозможно смоделировать полностью в голове, а в среде разработки физически не видно.
Решений этой проблемы есть три:
В IBM BPM, например, внутри сервис-тасков, юзер-тасков и т.п. может быть еще одна модель. На верхнем уровне пишется бизнесовая логика, на вложенном - технологическая.
В нашей компании была утверждена политика - вытягивать в Camunda технологическую логику на верхний уровень модели, при минимуме скрипт-тасков. На бизнес-процесс эта модель уже переставала подходить даже близко, но баги на тестировании можно было исправлять за разумное время и не плодя новых.
Ваш подход — не использовать встроенный функционал Camunda, пожалуй лучший. Такая вот каша из топора.
С начала статьи смежные концепции описываются в разном стиле, без подглядывания в справочник, непонятно что автор хочет донести. Есть FetchType (EAGER, LAZY) Есть FetchMode (JOIN, SELECT, SUBSELECT) Есть @BatchSize - необязательная аннотация полей с FetchMode.SELECT
"Hibernate маппинг, формирует глобальный план выборки." Непонятно, что подразумевается под Hibernate маппингом и под глобальным планом выборки. Осилил несколько абзацев. Чем дальше, тем больше текст запутывает.
Есть такое слово - семантика - смысловое наполнение используемых слов и выражений. В общем случае, под "продай себя" подразумевается "убеди заплатить за твои услуги больше".
Спортсмены и актеры получают миллионы, летают по миру и чувствуют себя гораздо меньшими рабами, чем живущие от зарплаты до зарплаты.
Отождествлять высокооплачиваемую работу с "быть скотом" придумали коммунисты.
Статья приписывает недостатки JDBI всем Transaction Script решениям. И выдает спорные решения в Hibernate за преимущества.
DynamicUpdate, например, в Hibernate отключен по умолчанию, так как в обмен на уменьшение данных, передаваемых по сети, он не использует кэш запросов, чем повышает нагрузку на сервер.
"Spring Data JDBC" позволяет код из первого примера сделать втрое короче и в разы читабельнее. С ним удобно работать и с SQL-запросами в репозитории, и с Entity-классами через привычные методы CrudRepository.
При этом он не имеет недостатков Hibernate:
Проблемы N+1 и N+M+1 даже в Eager-режиме.
Проблемы перегрузки соединениями БД из-за неудачно реализованного Lazy-режима и попытки это исправить, используя OSIV.
Проблемы метода save/persist не выполняемого в момент вызова, не позволяющего сразу получить id записи в базе. Это вынуждает прописывать транзакции, где они не требуются по бизнес-логике, с высоким риском замедлить базу избыточными блокировками.
Бизнес-логика сконцентрирована в одном месте, в доменных объектах.
А как-же SpeakerService? В нем тоже фрагмент бизнес-логики.
Когда передадут в реализацию еще 10 API, использующих эту таблицу базы, все методы с их бизнес-логикой будут перемешаны в Entity-классех? Вот уж спагетти, так спагетти.
За это отвечают архитекторы. Состав подсистем в организации, их функциональность (API), хранимые данные, способы сетевого обмена. А вот менеджер подразделения x знать об этом не может и не должен.
Статья бэкендера - "как я проходил собеседование в 8 этапов, с жонглированием на моноколесе". Статья фронтендера - "меня взяли на работу, а я ничего не могу, и никто не помогает". p.s. Не в обиду фронтендерам, знаю там есть профессионалы.
Проблемы по результатам нескольких дней попыток использования. Если кратко, невозможно пользоваться заявленными функциями.
Функция перевода страницы целиком завязана на "интеллектуально" исчезающую кнопку. Кнопка исчезает ровно тогда, когда открываешь страницу с иностранным текстом. Воспроизводится в Twitter. Уж прибили бы ее гвоздями что-ли? Гора ненужных кнопок есть, устанешь отключать, а нужная - исчезает.
Не нашел, как попасть в магазин расширений и активировать-дезактивировать их. Пришлось искать расширения в Хром-браузере и копипастить ссылки в Вивальди.
Так-же, невозможно скрыть значки расширений, чтобы не отвлекали бегающие цифры "сколько порезано рекламы". У Хрома прекрасное выпадающее меню есть для этой цели, справа от адресной строки, скопировали бы что-ли.
Резалка рекламы не позволяет вручную блокировать рекламу и отвлекающие блоки интерфейса. Не понятно, зачем она нужна, если uBlock все равно придется ставить.
Чтобы сообщить разработчикам о проблеме, есть система регистрации багов, есть англоязычный форум. При их использовании, нужно изучить удобный формат взаимодействия для разработчиков, иначе не примут. Оно мне что-ли нужно? Мне проще снести и поставить что-то другое.
Мне Vivaldi именно из-за UI зашел. Компактные по вертикали панели вкладок, адресной строки и закладок, без "пустых пространств". Лучше читаемый и контрастный шрифт этих панелей. Чувствуется, что делалось с уважением к людям, к их рабочему пространству.
Bravo в этом плане - выглядят похабно, в их панелях еще и надписи криво отцентрированы. Адресная строка - по нижнему краю, панель вкладок - по верхнему. При том, что выпадающая панель настроек эргономически выверена идеально. Но в настройки мы ходим редко, а панели перед глазами всегда.
У Хрома шрифт панели закладок еще мельче, а пустое пространство больше. Мода на бело-серый микрошрифт и огромные пустые пространства просто выводит из себя.
Можно по архитектуре вопрос? В языках Go, Kotlin и Java соответственно есть Goroutines, Coroutines и Virtual Threads (с Java 21).
Во всем ли они лучше реактивных технологий? Или у них, в сравнении с реактивными, разные области эффективного применения?
Техническое развитие у Intel остановилось в 2012. Неужели раньше Intel была в разы меньше?
Израильтянам передали развитие. А те заменили разработку "челночной дипломатией".
Ок, как будет время, перечитаю все, подготовлюсь и свяжусь в течение 1-2 недель.
Верю, вы продумали какие функции должны быть у библиотеки такого класса и как сделать ее компактной и быстрой.
Но забыли продумать, как сделать, чтобы разработчику было удобно. Синтаксис и стиль кода противоестественные, местами ставящие в тупик. Раскрыл бы мысль, но еще ни разу не сталкивался, чтобы такую критику воспринимали конструктивно. Да и формировать реестр видимых недостатков эргономики, это времени требует.
"Чукча хитрый однако"(с)
Сначала описание проблем соискателей - поставил лайк.
Потом проблемы галер представлены, как универсальные для рынка - лайк уже не отзовешь.
p.s.
Советовать IBM BPM не буду. Дорогой и с 2006 года не развивается.
Что поражает - за 5 лет разработки, 20 лет назад, могли создать более качественное и функциональное приложение, чем за 15 лет на "современных технологиях" (Camunda и остальные современные аналоги, выродившиеся в распил инвесторских денег).
Полгода писал на Camunda, скрипя зубами от мусорного качества встроенного функционала.
Опыт банка Тиньков, описанный у вас, подтвердил догадки — 98% функционала Camunda лучше не использовать и программировать на других языках. Получится быстрее, читабельней и надежней.
Общая беда всех BPMS - если в модели отразить бизнесовый уровень логики, а технологический скрыть в контексте и скриптах, получается абсолютно неподдерживаемое приложение. Как организована работа с данными, видно в формате мелких фрагментов в "задачах", которые невозможно смоделировать полностью в голове, а в среде разработки физически не видно.
Решений этой проблемы есть три:
В IBM BPM, например, внутри сервис-тасков, юзер-тасков и т.п. может быть еще одна модель. На верхнем уровне пишется бизнесовая логика, на вложенном - технологическая.
В нашей компании была утверждена политика - вытягивать в Camunda технологическую логику на верхний уровень модели, при минимуме скрипт-тасков.
На бизнес-процесс эта модель уже переставала подходить даже близко, но баги на тестировании можно было исправлять за разумное время и не плодя новых.
Ваш подход — не использовать встроенный функционал Camunda, пожалуй лучший. Такая вот каша из топора.
С начала статьи смежные концепции описываются в разном стиле, без подглядывания в справочник, непонятно что автор хочет донести.
Есть FetchType (EAGER, LAZY)
Есть FetchMode (JOIN, SELECT, SUBSELECT)
Есть @BatchSize - необязательная аннотация полей с FetchMode.SELECT
"Hibernate маппинг, формирует глобальный план выборки."
Непонятно, что подразумевается под Hibernate маппингом и под глобальным планом выборки.
Осилил несколько абзацев. Чем дальше, тем больше текст запутывает.
Есть такое слово - семантика - смысловое наполнение используемых слов и выражений. В общем случае, под "продай себя" подразумевается "убеди заплатить за твои услуги больше".
Спортсмены и актеры получают миллионы, летают по миру и чувствуют себя гораздо меньшими рабами, чем живущие от зарплаты до зарплаты.
Отождествлять высокооплачиваемую работу с "быть скотом" придумали коммунисты.
Прочитать пару статей? Сейчас как-раз на Baeldung статьи по Hibernate вычитываю.
250 статей, в среднем по 10 страниц = 2500 страниц. В день усваивается текст с новой информацией и конспектированием - по 60 страниц.
Итого, информации на 40 дней ежедневного изучения, вместо работы. С выходными - 2 месяца.
Не понял за что минусы. Неделю назад была статья, что во всем виноваты капиталисты и их нужно обманывать - 150 плюсов за сутки собрала.
В вашу классификацию не вписываются банки, маркетплейсы и еще многие большие IT и не-IT компании.
Статья приписывает недостатки JDBI всем Transaction Script решениям. И выдает спорные решения в Hibernate за преимущества.
DynamicUpdate, например, в Hibernate отключен по умолчанию, так как в обмен на уменьшение данных, передаваемых по сети, он не использует кэш запросов, чем повышает нагрузку на сервер.
"Spring Data JDBC" позволяет код из первого примера сделать втрое короче и в разы читабельнее. С ним удобно работать и с SQL-запросами в репозитории, и с Entity-классами через привычные методы CrudRepository.
При этом он не имеет недостатков Hibernate:
Проблемы N+1 и N+M+1 даже в Eager-режиме.
Проблемы перегрузки соединениями БД из-за неудачно реализованного Lazy-режима и попытки это исправить, используя OSIV.
Проблемы метода save/persist не выполняемого в момент вызова, не позволяющего сразу получить id записи в базе. Это вынуждает прописывать транзакции, где они не требуются по бизнес-логике, с высоким риском замедлить базу избыточными блокировками.
А как-же SpeakerService? В нем тоже фрагмент бизнес-логики.
Когда передадут в реализацию еще 10 API, использующих эту таблицу базы, все методы с их бизнес-логикой будут перемешаны в Entity-классех? Вот уж спагетти, так спагетти.
За это отвечают архитекторы. Состав подсистем в организации, их функциональность (API), хранимые данные, способы сетевого обмена.
А вот менеджер подразделения x знать об этом не может и не должен.
В статье написано - сократят 100 из 400 руководителей.
На Windows 7 я бы сбежал.
Статья бэкендера - "как я проходил собеседование в 8 этапов, с жонглированием на моноколесе".
Статья фронтендера - "меня взяли на работу, а я ничего не могу, и никто не помогает".
p.s.
Не в обиду фронтендерам, знаю там есть профессионалы.
Проблемы по результатам нескольких дней попыток использования.
Если кратко, невозможно пользоваться заявленными функциями.
Функция перевода страницы целиком завязана на "интеллектуально" исчезающую кнопку. Кнопка исчезает ровно тогда, когда открываешь страницу с иностранным текстом. Воспроизводится в Twitter. Уж прибили бы ее гвоздями что-ли? Гора ненужных кнопок есть, устанешь отключать, а нужная - исчезает.
Не нашел, как попасть в магазин расширений и активировать-дезактивировать их. Пришлось искать расширения в Хром-браузере и копипастить ссылки в Вивальди.
Так-же, невозможно скрыть значки расширений, чтобы не отвлекали бегающие цифры "сколько порезано рекламы". У Хрома прекрасное выпадающее меню есть для этой цели, справа от адресной строки, скопировали бы что-ли.
Резалка рекламы не позволяет вручную блокировать рекламу и отвлекающие блоки интерфейса. Не понятно, зачем она нужна, если uBlock все равно придется ставить.
Чтобы сообщить разработчикам о проблеме, есть система регистрации багов, есть англоязычный форум. При их использовании, нужно изучить удобный формат взаимодействия для разработчиков, иначе не примут. Оно мне что-ли нужно? Мне проще снести и поставить что-то другое.
Мне Vivaldi именно из-за UI зашел. Компактные по вертикали панели вкладок, адресной строки и закладок, без "пустых пространств". Лучше читаемый и контрастный шрифт этих панелей.
Чувствуется, что делалось с уважением к людям, к их рабочему пространству.
Bravo в этом плане - выглядят похабно, в их панелях еще и надписи криво отцентрированы. Адресная строка - по нижнему краю, панель вкладок - по верхнему. При том, что выпадающая панель настроек эргономически выверена идеально. Но в настройки мы ходим редко, а панели перед глазами всегда.
У Хрома шрифт панели закладок еще мельче, а пустое пространство больше. Мода на бело-серый микрошрифт и огромные пустые пространства просто выводит из себя.