Но там как раз через аннотации ;)

Есть конфиг, там всё, где надо инжектим значение.

Другими словами твои объекты БУДУТ ЗНАТЬ о каком то там конфиге, и об спринг анотациях. А им это вовсе не нужно.

Другими словами твои объекты БУДУТ ЗНАТЬ о каком то там конфиге, и об спринг анотациях. А им это вовсе не нужно.

Не, о конфиге они особо знать не будут. Поле аннотируется аннотацией и все, дальше магия препроцессора аннотаций...

О конфиге знает библиотека которая собственно этим и занимается, просто не выворачивая кишки наружу.

(и они вывернутся в случае сбоя)

Не, о конфиге они особо знать не будут. Поле аннотируется аннотацией и все, дальше магия препроцессора аннотаций...

Почему б не передавать эти значения в виде параметров ?

Если конфигурирование через аннотации кто-то сделал....То наверное это кому-нибудь нужно?....))

Если конфигурирование через аннотации кто-то сделал....То наверное это кому-нибудь нужно?....))

С этим конечно не поспоришь)

Почему б не передавать эти значения в виде параметров ?

Потому-что экземпляр класса создается через DI

Если конфигурирование через аннотации кто-то сделал....То наверное это кому-нибудь нужно?....))

это конечно так. но ведь и ejb ктото сделал. это не значит что их нужно использовать.

это конечно так. но ведь и ejb ктото сделал. это не значит что их нужно использовать.

Но используют же до сих пор)))

И код этот тоже кто-то поддерживает.

А потом будут поддерживать ваш, с cats и другими волшебными вещами))) и так далее...в каждую эпоху все будут "удивляться"

Но используют же до сих пор)))

я в этом направлении дальше не пойду. я думаю идея ясна, а поболтать как нить в другой раз ))

И код этот тоже кто-то поддерживает.

Кстати как у тебя дела? Нашел работу?

Кстати как у тебя дела? Нашел работу?

Даже больше чем нашел.

Хотя с возрастом это все сложнее и сложнее.

Ко мне недавно приходил 45 летний...сказал - не берут никуда. Из-за возраста.

Программист.

Даже больше чем нашел.

Что за проект? Это там такая жопа с конфигом?

Ко мне недавно приходил 45 летний...сказал - не берут никуда. Из-за возраста.

Полюбому в этом возраст виноват

А потом будут поддерживать ваш, с cats и другими волшебными вещами))) и так далее...в каждую эпоху все будут "удивляться"

в том и суть что там волшебства нет

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

в том и суть что там волшебства нет

Смотря для кого)) для человека из EJB Java EE - это вообще шайтаномо )))

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

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

По поводу строгости и проверяемости полностью согласен.

По поводу строгости и проверяемости полностью согласен.

дык все аргументы сводятся к тому, что аноташка это быстро, но под капотом хрупкая магия, а прямой код - он и в африке прямой код

Почему в Spring это сделано не через явную загрузку конфига?

дык все аргументы сводятся к тому, что аноташка это быстро, но под капотом хрупкая магия, а прямой код - он и в африке прямой код

Помимо этого "аноташка" - метаинформация прибитая гвоздями к определённому участку кода.

Почему в Spring это сделано не через явную загрузку конфига?

Потому что Спринг не парится над тайпсейфностью?

Помимо этого "аноташка" - метаинформация прибитая гвоздями к определённому участку кода.

Ну...мне так и надо

Потому что Спринг не парится над тайпсейфностью?

Хороший аргумент, но слабый

Почему в Spring это сделано не через явную загрузку конфига?

потому что спринг стал модным по сравнению с EJB, сделали DI на аноташках и понеслось сам подход никогда не был хорош

Помимо этого "аноташка" - метаинформация прибитая гвоздями к определённому участку кода.

и что конкретно она делает, фиг поймешь, просто кляцнув go to definition

Ну, каждому своё.

Такой вроде бы мегафреймворк...а аннотациями...

плюс у явы большие проблемы с типизацией

поэтому много что прощается - никто не будет писать в 5 раз больше кода ради того, что потом нельзя использовать

Хотя с возрастом это все сложнее и сложнее.

это сколько лет должно быть чтобы не брали ?

это сколько лет должно быть чтобы не брали ?

Ну не знаю, вот чувака которому 45 - его не берут, прям так и сказали - не вписываешься ты в наш молодой коллектив. Хотя дядька знает-умеет.

пытаюсь не думать о себе в 45 лет, мало, кстати, видел адекватных программистов такого возраста, видимо в манагеры ушли но видел пачку людей дописывающих на делфи etc

Почему в Spring это сделано не через явную загрузку конфига?

Потому что так исторически сложилось. Ну и в джаве тебе придётся писать 100500 строк кода для представленгия своего конфига в виде кода, и это, естественно, так себе развлечение. Многие подходы в джаве обоснованны только тем, что джава многословный и невыразительный язык. В скале ты просто делаешь кейс класс, который мапится 1к1 на конфиг.

А вот так нормально или тоже плохо? trait MongoConfig { val config = ConfigFactory.load() val database = config.getString(s"mongodb.$mode.database") val servers = config.getStringList(s"mongodb.$mode.servers").asScala val userName = config.getString(s"mongodb.$mode.user") val password = config.getString(s"mongodb.$mode.password") val credentials = List(Authenticate(database, userName, password)) } //и далее подмешиваем где нам это нужно.

да, так норм. но вот чтобы убрать боилерплейт чтения из конфига используют pureconfig

вместо pureconfig может быть что угодно что тебе больше нравится

они все плохие, но pureconfig самый, хм, неплохой

А вот так нормально или тоже плохо? trait MongoConfig { val config = ConfigFactory.load() val database = config.getString(s"mongodb.$mode.database") val servers = config.getStringList(s"mongodb.$mode.servers").asScala val userName = config.getString(s"mongodb.$mode.user") val password = config.getString(s"mongodb.$mode.password") val credentials = List(Authenticate(database, userName, password)) } //и далее подмешиваем где нам это нужно.

Только лучше не подмешивать. Лучше сделать case class MongoConfig, и в нужные места передавать его как параметр конструктора: class MongoService(config: MongoConfig)

ну и да, pureconfig

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

Только лучше не подмешивать. Лучше сделать case class MongoConfig, и в нужные места передавать его как параметр конструктора: class MongoService(config: MongoConfig)

Ок, буду копать pureconfig.

Только лучше не подмешивать. Лучше сделать case class MongoConfig, и в нужные места передавать его как параметр конструктора: class MongoService(config: MongoConfig)

да, не заметил что это все внутри MongoConfig. Я думал это топлевел.

Ок, буду копать pureconfig.

тебе потом с этим будет очень удобно работать. Можно будет при старте приложения в консоль плюнуть конфиг - это очень помогает. И ошибки очень ясные будут. И тестировать всё будет просто - в тесте руками создал конфиг и в путь

тебе потом с этим будет очень удобно работать. Можно будет при старте приложения в консоль плюнуть конфиг - это очень помогает. И ошибки очень ясные будут. И тестировать всё будет просто - в тесте руками создал конфиг и в путь

Да, сейчас читаю тест https://github.com/pureconfig/pureconfig/blob/master/core/src/test/scala/pureconfig/ApiSuite.scala

Тут все приятно описано.

тебе потом с этим будет очень удобно работать. Можно будет при старте приложения в консоль плюнуть конфиг - это очень помогает. И ошибки очень ясные будут. И тестировать всё будет просто - в тесте руками создал конфиг и в путь

спасибо

тебе потом с этим будет очень удобно работать. Можно будет при старте приложения в консоль плюнуть конфиг - это очень помогает. И ошибки очень ясные будут. И тестировать всё будет просто - в тесте руками создал конфиг и в путь

а с большими конфигами удобно ? когда параметров по 40-50 ?

а с большими конфигами удобно ? когда параметров по 40-50 ?

ты же можешь вкладывать case classы друг в друга :)

Да, сейчас читаю тест https://github.com/pureconfig/pureconfig/blob/master/core/src/test/scala/pureconfig/ApiSuite.scala

Не за что

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

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

пишешь и проговариваешь - ух,мля

пишешь и проговариваешь - ух,мля

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

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

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

так что нет, никаких проблем с большими конфигами не возникает

и моки вообще не нужны - просто создаешь в коде теста инстанс конфига -и всё

а с большими конфигами удобно ? когда параметров по 40-50 ?

?

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

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

А что если конфиг монги состоит из множества полей? Ну, прямо вот много. Бизнес-логика у всех разная. Плюс, если вайрингом занимается какой-то macwire, то в сервис ты передаешь весь конфиг, и мокаешь ту часть, которая в сервисе используется, ну, например, when(appConfig.someConfig).thenReturn и тут вот этот огромный конфиг.

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

Мешает, я не хочу, чтобы от корректности читалки конфига из файла зависели тесты вообще других сервисов

Читалки конфига в тесте и не будет

Ты сам можешь руками создать кеис класс

Мешает, я не хочу, чтобы от корректности читалки конфига из файла зависели тесты вообще других сервисов

ну тебе же все равно нужно где-то эти конфиги как-то написать если ты хочешь чтобы в тестах от них была зависимость. я не могу представить как можно задать n полей проще чем задать n полей. все равно где и как из задавать - в конфиге или через создание case class

Читалки конфига в тесте и не будет

Но мне же предложили прочитать из файла в тесте, ты опять не читаешь сообщения в чате

Нет, не читаю

А что если конфиг монги состоит из множества полей? Ну, прямо вот много. Бизнес-логика у всех разная. Плюс, если вайрингом занимается какой-то macwire, то в сервис ты передаешь весь конфиг, и мокаешь ту часть, которая в сервисе используется, ну, например, when(appConfig.someConfig).thenReturn и тут вот этот огромный конфиг.

Я не сталкивался с такими проблемами. В реальности там обычно параметров не больше 10-15 на один сервис. Это вполне норм. Насчёт маквайр ничего не скажу, но выглядит как проблема маквайра

Потому что у вас тут опять дичь )

Я не сталкивался с такими проблемами. В реальности там обычно параметров не больше 10-15 на один сервис. Это вполне норм. Насчёт маквайр ничего не скажу, но выглядит как проблема маквайра

Так ты утверждаешь, что моки не нужны, проблем не возникает, но ты не сталкивался с таким? Не сталкивался, но утверждаешь, всё верно?

Мне кажется Кирилл прошёл школу начинающего гопника)

Так ты утверждаешь, что моки не нужны, проблем не возникает, но ты не сталкивался с таким? Не сталкивался, но утверждаешь, всё верно?

Я просто передаю все через параметры конструкторы, соответственно мне не нужны моки для конфига

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

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

Потому что ты работал в сбертехе

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

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

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

Не напомнишь, где я сказал, что создание кейс класса конфига в тесте это "сложно"?

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

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

Не напомнишь, где я сказал, что создание кейс класса конфига в тесте это "сложно"?

а ты что собственно хочешь выяснить? можешь вопрос повторить?

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

Дефолтные параметры?

а ты что собственно хочешь выяснить? можешь вопрос повторить?

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

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

Да никто тебе не запрещает)

Дефолтные параметры?

ну не всегда хочется дефолты задавать в кейс классе. мне больше нравится модель typesafe config.

Да никто тебе не запрещает)

Спасибо, Ник, без тебя я бы не разобрался ))

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

Приходи на скала митап в четверг, я расскажу как над делать)

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

а, ну то есть обсуждение закончено? мне просто нечего добавить. тебе тоже :)

а, ну то есть обсуждение закончено? мне просто нечего добавить. тебе тоже :)

Да, всё так

Приходи на скала митап в четверг, я расскажу как над делать)

Ехать это в ваш питерсбурх, ну его

Ехать это в ваш питерсбурх, ну его

Тут будет вся топ банда

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

Ты все мои слова переврал

Тут будет вся топ банда

Я в мск-то не мог до митапа дойти, так теперь тут вообще не проводится :D

Ты все мои слова переврал

Поцитировать?

Я просто предлагал решение, которое хорошо работает. Если ты делаешь иначе - твое право

А что если конфиг монги состоит из множества полей? Ну, прямо вот много. Бизнес-логика у всех разная. Плюс, если вайрингом занимается какой-то macwire, то в сервис ты передаешь весь конфиг, и мокаешь ту часть, которая в сервисе используется, ну, например, when(appConfig.someConfig).thenReturn и тут вот этот огромный конфиг.

Если настроек мало, то передаем их в виде параметров (конструктора) Если много - то они разбиваются на тематические интерфейсы IConnectDBCfg ILogCfg ISvcCfg И передаем в виде параметра Если у вас сингл респонсибилити объекты(привет Solid) то обычно достаточно передать всего один интерфейс