G>Реактивщина съест твой мозг сложностью отладки и составления программы. Сами интерфейсы Reactive Streams простые, но составить из них программу тяжело, а отлаживать ещё труднее. Плюс навешиваются АПИ самой реактивной библиотеки, которую ты выберешь, это тоже усложняет понимание.

Понимаю, что ты наверное явист, но вдруг сможешь что-то сказать о
https://github.com/IgorBuchelnikov/ObservableComputations
В этой библиотеке реактивность основана на дотнетовских интерфейсах INotifyPropertyChanged and INotifyCollectionChanged
но может оборачивать интерфейсы из Reactive Extensions (дотнетовкий аналог Reactive Streams)
Делал эту библиотеку в основном для UI, но как ты думаешь,
можно ли её в бэкэнде как то применить (в enterprise архитектуре)?

Здравствуйте, igor-booch, Вы писали:

G>>Реактивщина съест твой мозг сложностью отладки и составления программы. Сами интерфейсы Reactive Streams простые, но составить из них программу тяжело, а отлаживать ещё труднее. Плюс навешиваются АПИ самой реактивной библиотеки, которую ты выберешь, это тоже усложняет понимание.

IB>Понимаю, что ты наверное явист, но вдруг сможешь что-то сказать о
IB>https://github.com/IgorBuchelnikov/ObservableComputations
IB>В этой библиотеке реактивность основана на дотнетовских интерфейсах INotifyPropertyChanged and INotifyCollectionChanged
IB>но может оборачивать интерфейсы из Reactive Extensions (дотнетовкий аналог Reactive Streams)
IB>Делал эту библиотеку в основном для UI, но как ты думаешь,
IB>можно ли её в бэкэнде как то применить (в enterprise архитектуре)?

Вот это поворот))
Вообще, для реактивщины есть определенные контракты, и есть библиотека для их верификации на соответствие этим контрактам — TCK (Technology Compatibility Kit), для дот-нета в том числе.
Так что в первую очередь тебе нужно, чтобы твоя либа проходила все эти тесты. Это по поводу реактивных контрактов. А по поводу применимости в энтерпрайзе, завтра внимательнее погляжу на твое творение в этом разрезе, с позиций энтерпрайзного джава-разработчика.

vsb>А я бы не советовал изучать реактивщину в Java. В Java в обозримом будущем появятся легковесные потоки, что сделает всю реактивщину бесполезным расходом ментальной энергии.

Многопоточность и асинхронность, на базе которой основана реактивность, совсем разные вещи.

vsb>Не знаю, что надо изучать, но лично моё имхо, Фаулера, "дядю Боба" в особенности, паттерны — изучать НЕ надо. А применять тем более.

Ну ты то, вижу, точно ничего не читал

Здравствуйте, igor-booch, Вы писали:

G>>Реактивщина съест твой мозг сложностью отладки и составления программы. Сами интерфейсы Reactive Streams простые, но составить из них программу тяжело, а отлаживать ещё труднее. Плюс навешиваются АПИ самой реактивной библиотеки, которую ты выберешь, это тоже усложняет понимание.

IB>Понимаю, что ты наверное явист, но вдруг сможешь что-то сказать о
IB>https://github.com/IgorBuchelnikov/ObservableComputations
IB>В этой библиотеке реактивность основана на дотнетовских интерфейсах INotifyPropertyChanged and INotifyCollectionChanged
IB>но может оборачивать интерфейсы из Reactive Extensions (дотнетовкий аналог Reactive Streams)
IB>Делал эту библиотеку в основном для UI, но как ты думаешь,
IB>можно ли её в бэкэнде как то применить (в enterprise архитектуре)?

Посмотрел, документация в readme неплохая. Но бросается в глаза, что в коде нет комментариев, а также коммиты все идут в одной ветке и с плохими коммит-мессаджами — это не создает ощущения продукта для энтерпрайза, коммьюнити у продукта тоже нет судя по всему? Еще бы не помешало написать, это как-то связано с Reactive Streams и проч. реактивными стандартами?
В текущем виде библиотеку вряд ли кто-то всерьез будет рассматривать для энтерпрайза. Нужно коммьюнити, ссылки на реально используемые проекты, также непонятно как дела уязвимостями и CVE.

G>Но бросается в глаза, что в коде нет комментариев
С комментариями проблема. Документирующие комментарии для пользователей,
либо очевидны из названия члена (тупые комментарии писать не хочется),
либо требуют развернутого объяснения, которое приведено в readme.
Но некоторые комментарии, согласен, не мешало бы добавить.

G>, а также коммиты все идут в одной ветке и с плохими коммит-мессаджами
Да, я с ними не заморачивался,
так как был и остаюсь единственным разработчиком.
Если появится ещё разработчики, тогда месседжи конечно будут нужны,
ещё можно сделать документацию для разработчика,
коммит месседжи старых комитов вряд ли помогут

G> коммьюнити у продукта тоже нет судя по всему?
А где его взять? Вот думаю выступить на какой-нибудь встрече с докладом.


G> Еще бы не помешало написать, это как-то связано с Reactive Streams и проч. реактивными стандартами?
Отсюда как бы очевидно (если предыдущие главы почитать). System.Reactive это пространство имен для реализации реактивного стандарта dotnet

G>Нужно коммьюнити, ссылки на реально используемые проекты,
Opensource проекты?

G>также непонятно как дела уязвимостями и CVE.
Уязвимости, наверное, такие же как для библиотек dotnet, на которые ссылается ObservableComputations. А ссылок мало и только на базовые библиотеки

Здравствуйте, igor-booch, Вы писали:

G>>Но бросается в глаза, что в коде нет комментариев
IB>С комментариями проблема. Документирующие комментарии для пользователей,
IB>либо очевидны из названия члена (тупые комментарии писать не хочется),
IB>либо требуют развернутого объяснения, которое приведено в readme.
IB>Но некоторые комментарии, согласен, не мешало бы добавить.

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

G>>, а также коммиты все идут в одной ветке и с плохими коммит-мессаджами
IB>Да, я с ними не заморачивался,
IB>так как был и остаюсь единственным разработчиком.
IB>Если появится ещё разработчики, тогда месседжи конечно будут нужны,
IB>ещё можно сделать документацию для разработчика,
IB>коммит месседжи старых комитов вряд ли помогут

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

G>> коммьюнити у продукта тоже нет судя по всему?
IB>А где его взять? Вот думаю выступить на какой-нибудь встрече с докладом.

Конечно, нужен доклад, нужна статья в блоге с литературным описанием (завязка-интрига-развязка) какие проблемы эта библиотека решает, почему разработчики должны выбрать именно её?


G>> Еще бы не помешало написать, это как-то связано с Reactive Streams и проч. реактивными стандартами?
IB>Отсюда как бы очевидно (если предыдущие главы почитать). System.Reactive это пространство имен для реализации реактивного стандарта dotnet

G>>Нужно коммьюнити, ссылки на реально используемые проекты,
IB>Opensource проекты?

Для начала да. Чтобы посмотреть реальные кейсы применения твоей либы.

G>>также непонятно как дела уязвимостями и CVE.
IB>Уязвимости, наверное, такие же как для библиотек dotnet, на которые ссылается ObservableComputations. А ссылок мало и только на базовые библиотеки

Без этой инфы либа тоже не вкатится в энтерпрайз. Там же все либы постоянно чекаются на секьюрити. Если у либы нет этой инфы, либо если инфа есть и есть дыры в безопасности, то такая либа просто поступает на карантин и энтерпрайз-проекты, зависящие от неё, не собираются devsecops-пайплайном системы сборки.

И еще нужна четкая инфа по лицении продукта.

Здравствуйте, gyraboo, Вы писали:

G>Здравствуйте, kaa.python, Вы писали:

IB>>>Посоветуйте книги (или блоги) по enterprise архитектуре,

KP>>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

G>Это построение сложной надежной системы с возможностью масштабирования, распределенности, высокой нагруженности, транзакционности, обмена сообщениями по разным протоколам, безопасности, логирования, интеграций, кэширования, управления развертыванием и службами имен, и т.д. Полный список можно загуглить по "JEE спецификациям" — они неплохо описывают возможности корпоративного ПО и архитектуры, из списка возможностей можно построить и саму дефиницию этого термина, почему бы и нет. Так что в общем ты прав, это о том, как запилить сложный монолит или микросервисы без изобретения велосипедов и не помереть.

Всё это нужно для корпорации с каким количеством сотрудников? Просто если в конторе софтиной пользуются полтора человека один раз в месяц, то зачем заморачиваться?

Здравствуйте, Vladek, Вы писали:

KP>>>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

G>>Это построение сложной надежной системы с возможностью масштабирования, распределенности, высокой нагруженности, транзакционности, обмена сообщениями по разным протоколам, безопасности, логирования, интеграций, кэширования, управления развертыванием и службами имен, и т.д. Полный список можно загуглить по "JEE спецификациям" — они неплохо описывают возможности корпоративного ПО и архитектуры, из списка возможностей можно построить и саму дефиницию этого термина, почему бы и нет. Так что в общем ты прав, это о том, как запилить сложный монолит или микросервисы без изобретения велосипедов и не помереть.

V>Всё это нужно для корпорации с каким количеством сотрудников? Просто если в конторе софтиной пользуются полтора человека один раз в месяц, то зачем заморачиваться?

Практика показывает, что даже мелкий заказчик часто хочет и авторизацию по токену, и логирование, и сбор метрик, и полнотекстовый поиск, и секьюрность с блэкджэком и https. К счастью, в джаве есть проекты типа JHipster, которые позволяют буквально за 5 минут сгенерировать полноценный проект с бэком и фронтом на основе предоставленной доменной модели данных, и включающий в себя большинство энтерпрайзных практик, а сгенеренный код будет соответствовать общепринятым парадигмам. Потом просто допиливаешь этот код под нужные детали.

Здравствуйте, Vladek, Вы писали:

IB>>>>Посоветуйте книги (или блоги) по enterprise архитектуре,

KP>>>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

G>>Это построение сложной надежной системы с возможностью масштабирования, распределенности, высокой нагруженности, транзакционности, обмена сообщениями по разным протоколам, безопасности, логирования, интеграций, кэширования, управления развертыванием и службами имен, и т.д. Полный список можно загуглить по "JEE спецификациям" — они неплохо описывают возможности корпоративного ПО и архитектуры, из списка возможностей можно построить и саму дефиницию этого термина, почему бы и нет. Так что в общем ты прав, это о том, как запилить сложный монолит или микросервисы без изобретения велосипедов и не помереть.

V>Всё это нужно для корпорации с каким количеством сотрудников? Просто если в конторе софтиной пользуются полтора человека один раз в месяц, то зачем заморачиваться?

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

Здравствуйте, gyraboo, Вы писали:

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

В случае с багами Log4J, что привело к проблемам? Каких экспертных знаний и кому не хватило?

Здравствуйте, Vladek, Вы писали:

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

V>В случае с багами Log4J, что привело к проблемам? Каких экспертных знаний и кому не хватило?

Инфосек вообще не так давно стал широко внедряться в энтерпрайз, с появлением девсекопса. Но территория все равно ещё для большинства энтерпрайзных разрабов дикая и мало освоенная. Так что предположу, что это проявление общей проблемы плохого внедрения инфосека в энтерпрайз. Хорошие спецы по нему есть, но это параллельный мир, который мало пересекается с миром разрабов. Пересечение происходит разве что в точках девсекопса — например в пайплайнах, проверяющих уязвимости в коде, или репозиториев типа нексуса, которые умеют переводить библиотеки на карантин, или в эпизодических проверках системы пентестерами. Но девсекопс сам еще не созрел и не везде внедрен, а где внедрен, то не полностью (например, используются не все виды проверок).
Возможно, авторы этой библиотеки вообще не обращали внимание на отчеты по уязвимостям, а может даже сами и не проводили их, т.к. хорошие инструменты стоят очень дорого (чекмаркс например стоит десятки тысяч долларов в год для небольшой команды).
Надежда тут скорее всего только на то, что сами репы, типа гитхаба, будут бесплатно внедрять инструменты девсекопса, и либа просто не будет собираться там если имеет уязвимости. Потому что ждать от самих энтерпрайзных разрабов повышения квалификации в инфосеке слишком оптимистично, им бы фуллстэк, ddd и реактивщину освоить, не до инфосека, если только какие-то базовые правила, типа не логировать сессию и не хранить пароли в открытом виде в стринге.

Здравствуйте, Vladek, Вы писали:
V>В случае с багами Log4J, что привело к проблемам? Каких экспертных знаний и кому не хватило?
Я так понимаю, что в основном не хватило фантазии придумать контрпример.
То есть вроде как сама по себе идея лукапов в чём-то здравая. По крайней мере, сложно сразу же придумать равномощное решение.
Тем более, что она придумана вовсе не в log4j, а далеко за его пределами. К примеру, при разрешении конфигурационных параметров почти везде принято раскрывать $-ссылки, причём рекурсивным образом. Нуачо, прикольно же — когда у тебя префикс имени переменной задаётся в другой переменной. Типа ${${context}path}\${${context}_filename} — и вот, можно одной строкой переключаться между ${staging_path}, ${staging_filename} и ${production_path}, ${production_filename}.
Офигенно же удобно.
Ну, вот и решили, что раз такая пьянка возможна в конфигурации, то почему бы не сделать её и в логгировании.
А вот дотумкать, что если в конфигурацию доступ посторонним запрещён, и можно полагаться на отсутствие в ней неожиданных jndi:ldap:... обращений, то в логгирование попадает произвольная порнография, приходящая из недоверенных источников, не вышло.
Я даже не знаю, есть ли способ отследить подобные вещи каким-нибудь статическим анализатором.