Я ничего не говорил про патриотизм — русский или какой-то ещё. Я говорю про рациональное мышление. Ну чё, разве не было Сноудена? А Байден чё, победил на выборах честно?
Серьёзные уязвимости бывают — я это не отрицаю — и много есть примеров этого. Но это не умоляет того, факта, что у Intel есть возможность добавлять бэкдоры в свои процессоры (Чё разве нет такой возможности?). А если есть возможность, то почему ей не пользуются? Пользуются! Просто не говорят об этом.
Мы все знаем Сноудена, который вскрыл существование Prism (это надеюсь не бред сумасшедьшего). Эта Prism до сих пор существует, и до сих пор функционирует, наплевав на все законы морали, чести и права.
Вообще-то был инцидент с Ираном — об этом говорил сам Касперский, — когда центрифуги вышли из строя, в результате воздействия вредоносного ПО, которое проникло через бэкдор. А переход на личности, кстати, — это констатация своей слабости.
Согласен, но проблему бэкдоров тоже не надо списывать со счетов — плохо, если вдруг упали 10 самолётов, потому что в них вырубились главные компьютеры с иностранными процессорами, после отказа России на высшем уровне выполнять какие-то требования наших «партнёров» — хотелось бы избежать такой зависимости.
Абсолютно согласен. Но самое главное нужно собственное железо, чтобы точно знать, что нет бэкдоров, а то вдруг у США есть возможность выключить все компы в России.
Да, наверное нам повезло. Если имеются куча разных баз данных, и они ещё к тому-же со временем прибывают, да и у каждой по своему настраиваемый пул коннектов, то да — там будут общие вещи и наследование конфигом станет уместным.
У нас много «retryCount и timeout с batchSize», но мы их не пытались объединять — порознь с ними работать удобнее, как нам кажется. Хотя может у Вас другое мнение. И я согласен — библиотека должна позволять это делать.
Хочу обратиться ко всем комментаторам — спасибо Вам большое за Ваши комментарии — они оказались для нас очень полезными, хотя я совру, если скажу, что моё самолюбие не было задето.
Огромная благодарность команде habr-а за то, что Вы есть — мы намерены продолжать печататься здесь (у нас есть ещё пару «велосипедиков»!)
Хочу ещё сказать пару слов про пресловутый «Фатальный недостаток». Я никогда не стремался создавать свои велосипеды — излишне злоупотреблять этим конечно нельзя — очень вредно для производства. Но в истории очень много новых велосипедов, которые оказались лучше оригиналов, самый яркий пример — Chrome Browser. Я конечно не претендую, что greetgo conf — станет лидером конфигурации Java систем во всём мире; но тот опыт, который уже получен в этом, думаю, стоит свеч.
Из-за одного параметра делать абстрактный базовый класс — я не вижу рациональности в этом. Из опыта получается, что общие параметры встречаются редко — у нас ни разу не возникало желание наследовать конфигурационные интерфейсы друг-от-друга.
Спасибо Вам за Ваш конструктивный ответ, и в частности за эти ссылки — мы реально не знали, что они есть — нужно было изобрести свой велосипед, потом его несколько лет интенсивно эксплуатировать — потом написать статью про него в хабре (моя первая в жизни статья на хабре) — и только после этого получить ссылку на cfg4j и aeonbits. Только вот теперь дилемма — что использовать дальше в качестве конфигурации?
По поводу четырёх пунктов — часть из них уже есть, а части нету. И если будет принято решение развивать эту библиотеку, то они будут реализованы. По поводу разных типов параметров — я давно хотел сделать какой-нибудь кастомный конвертер, но всё руки не доходили.
Я благодарен за Вашу критику. Да мы заранее параметры конфигов и их сами не проектируем — они произвольно появляются на этапе разработки, но чаще на этапе сопровождения — в принципе проблем это у нас не вызывало. Рулит аннотация Description.
Мы бины никогда не пересоздаём — полностью с Вами согласен — это та ещё проблема. Мы просто используем Supplier-ы для чтения параметров, и тогда ничего пересоздавать не нужно, и всё меняется на горячую.
Вы будете смеяться, но у нас есть реализация чтения из гита — просто мы её не вынесли в библиотеку. По поводу configMap в kubernetes-е — мы им пользуемся, но только для сторонних программ, а свои по привычке через zookeeper — просто все наши распределённые проекты имеют Apache Kafka — поэтому zookeeper у нас на халяву есть — к тому же мы привыкли корректировать конфиги на горячую — это удобно. Да, я знаю про rollout restart и всё такое, но горячие конфиги — это удобно
Смысл в том, что очень полезно вносить описание параметров в конфигурационный файл — потому что когда редактируешь файл, то исходников под рукой нет, чтобы посмотреть, что это за параметр. А с помощью reflection нельзя прочитать javaDoc-и — остаётся аннотация.
Квантовая гравитация — сеё занятие конечно интересно, но есть одна маленькая мелочь — квантовая механика — это враньё.
Сильное конечно заявление и даже попахивает бредом… но когда я познакомился с теорией эфиродинамики Ацуковского… мир на самом деле устроен гораздо проще и элегантнее!
Мы все знаем Сноудена, который вскрыл существование Prism (это надеюсь не бред сумасшедьшего). Эта Prism до сих пор существует, и до сих пор функционирует, наплевав на все законы морали, чести и права.
У нас много «retryCount и timeout с batchSize», но мы их не пытались объединять — порознь с ними работать удобнее, как нам кажется. Хотя может у Вас другое мнение. И я согласен — библиотека должна позволять это делать.
Огромная благодарность команде habr-а за то, что Вы есть — мы намерены продолжать печататься здесь (у нас есть ещё пару «велосипедиков»!)
По поводу четырёх пунктов — часть из них уже есть, а части нету. И если будет принято решение развивать эту библиотеку, то они будут реализованы. По поводу разных типов параметров — я давно хотел сделать какой-нибудь кастомный конвертер, но всё руки не доходили.
Сильное конечно заявление и даже попахивает бредом… но когда я познакомился с теорией эфиродинамики Ацуковского… мир на самом деле устроен гораздо проще и элегантнее!