криваярожажпг

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

А вейланд не работает

Да пока, еще куча времени пройдет, я надеюсь хоть в старости увидеть работающею замену иксов. П.С. я еще молодой

кстати кто что думает о мире?

кстати кто что думает о мире?

надо его захватить

Когда я последний раз на это смотрел там были глючные кеды и гонки в ядре

кстати кто что думает о мире?

Может в оффтопе ?

Так что так себе альтернатива иксам)

о мире, т.е и дисплейном сервере mir

а не о "мире"

Когда я последний раз на это смотрел там были глючные кеды и гонки в ядре

В убунте 17 без дров работает, но приложения то все на иксах

И это да

мне кажется wayland просто никто особо и не пилит поэтому он никогда не будет готов, это как халфа

Интересно, когда половина предустановленных приложений в убунте будет поддерживать Wayland -)

мне кажется wayland просто никто особо и не пилит поэтому он никогда не будет готов, это как халфа

Только халфу весь мир ждёт )

а вейланд только линуксойды

пацаны поработать не хотите?

?

пацаны поработать не хотите?

нет, спасибо, мы уже

пацаны поработать не хотите?

это к скалистам, остальные уже

я имею ввиду офтопить тут хватит

это к скалистам, остальные уже

скалисты тож

под одной jvm работаем*

Надеюсь не будет спамом, тут в java 8 и 10 нашли 8 крит. уязвимостей аж по 8.3 CVSS Score т.е думаю важная инфа https://www.opennet.ru/opennews/art.shtml?num=48984

Ребят в котле как можно просканировать пакет ?

кто что юзает для DI на замену спринга? Guice, Koin, Kodein?

не надо вскрывать эту тему...

? dagger2 не предлагать

кто что юзает для DI на замену спринга? Guice, Koin, Kodein?

так и не смогли спрыгнуть - на столько простого DI как в спринге не нашли

не сказал бы что он прям простой

guice как-то проще, хотя в нем и меньше фичей

Ребят в котле как можно просканировать пакет ?

в KtJVM — тем же ужасом, что и в Java — открывая джарники из classpath

но от @Inject constructor( до сих пор подташнивает

+ большая часть очень плохо работает со списком зависимостей, когда например есть интерфейс ISmthAction и много имплементов, в спринге он биндится просто через @Component - а в остальных нужна магия

в Guice ну или где JSR330

в спринге кроме @Component вообще ничего не надо)

+ большая часть очень плохо работает со списком зависимостей, когда например есть интерфейс ISmthAction и много имплементов, в спринге он биндится просто через @Component - а в остальных нужна магия

Чем @Component не магия? В Dagger есть qualifier. Вроде везде одинаково неюзабельно.

если у тебя Ktor, то тащить спринг ради DI как-то странно

с 4.2 версии, но это был вопрос о Guice

если у тебя Ktor, то тащить спринг ради DI как-то странно

Если у тебя ктор то и ди не нужен, имхо

Если у тебя ктор то и ди не нужен, имхо

где связь?

Если у тебя ктор то и ди не нужен, имхо

Это что значит? Объекты не создавать?

если ktor это не значит что у тебя проект на 5 компонентов)

Да нет, kodein вроде норм. Просто мне ди еще ниразу не ригодились, ну пока большое и серезное не писал

если ktor это не значит что у тебя проект на 5 компонентов)

Ну в торнадофх ди через декораторы сделан, вроде удобно

Ну в торнадофх ди через декораторы сделан, вроде удобно

Это не совет его тащит в ктор ??

вообще можно попробовать из спринга только bean + context взять, но что-то мне подсказывает что оно весь core затащит зависимостью

вообще можно попробовать из спринга только bean + context взять, но что-то мне подсказывает что оно весь core затащит зависимостью

Затащит

а guice за собой целую guava тащит

кто что юзает для DI на замену спринга? Guice, Koin, Kodein?

Kodein

Kodein

почему его выбрали? на сколько большой проект? были ли какие-то проблемы?

с Koin проблема что там все lazy и в рантайме можешь обнаружить что сервиса не хватает

кто что юзает для DI на замену спринга? Guice, Koin, Kodein?

А почему dagger2 не предлагать?)

А почему dagger2 не предлагать?)

ни разу не слышал чтобы его на бекенде юзали)

ни разу не слышал чтобы его на бекенде юзали)

у нас в проде и норм

почему его выбрали? на сколько большой проект? были ли какие-то проблемы?

Проект маленький Сначала сидели на dagger2, но показался несколько громоздким + dagger все-таки из java, а kodein изначально для котлина Проблем никаких не было

Проект маленький Сначала сидели на dagger2, но показался несколько громоздким + dagger все-таки из java, а kodein изначально для котлина Проблем никаких не было

а в каком плане громоздкий?

Проект маленький Сначала сидели на dagger2, но показался несколько громоздким + dagger все-таки из java, а kodein изначально для котлина Проблем никаких не было

вы его как сервис локатор используете?

а в каком плане громоздкий?

ну в dagger2 слишком много кода обвязочного надо было писать на kodein сократился раза в 2-3

вы его как сервис локатор используете?

это как?

это как?

class Component{ val dependency = Kodein.get(MyDependency::class.java) }

у кодеина, кстати, какие-нибудь киллерфичи по отношению к коину есть?

ERROR: S client not available

вы его как сервис локатор используете?

у нас есть файлик, который рожает все сервисы и перевязывает их друг с другом, примерно так: bind<QuestServiceImpl>() with eagerSingleton { val questService = QuestServiceImpl( instance<ProfileServiceImpl>(), instance(), instance(), serverConf.profile ) rpcNode().registerQuestService(questService) instance<MissionAgentSubscribers>().addSubscriber(questService) questService }

вот когда сервисов порядка 300 и начинается самое веселое

вот когда сервисов порядка 300 и начинается самое веселое

без автовайринга это грустно

да, потому ничего кроме спринга по факту не прошло, но мы используем из него только DI и app events

вместо spring mvc голый undertow, вместо spring data голый jdbc, итп

вот когда сервисов порядка 300 и начинается самое веселое

Это при том, что часто зависимость и не надо инъектить в конструктор, а можно передать аргументом в метод подходящий.

вместо spring mvc голый undertow, вместо spring data голый jdbc, итп

а что по памяти?

koin/kodein в теории можно будет на native пускать?

проблем не наблюдали, железный сервер и там 256 гигов - даж не особо думаем

вот когда сервисов порядка 300 и начинается самое веселое

да в принципе проблемы не будет 30 или 300, оно линейно скейлится к тому же можно по модулям разбить

Вы как будто каждый день сидите и добавляете по 300 сервисов

а spring bean dsl юзаете?

В чем проблема собрать через конструктор?

да в принципе проблемы не будет 30 или 300, оно линейно скейлится к тому же можно по модулям разбить

Расскажи это SOP (spring oriented programming) программирующием

Вы как будто каждый день сидите и добавляете по 300 сервисов

хз мне как-то проще один раз @Component написать, чем идти и прописывать еще зависимости пусть даже в виде bean { A(ref(), ref(), ref() }

Спринг головного мозга - это вообще отдельная тема для разговора

хз мне как-то проще один раз @Component написать, чем идти и прописывать еще зависимости пусть даже в виде bean { A(ref(), ref(), ref() }

А гарантии что это поднимится уже на компайл тайме не желаете?

вот пытаемся слезть со спринговой иглы)

А гарантии что это поднимится уже на компайл тайме не желаете?

что предоставляет такие гарантии?

Компилятор

Что ты правильно собрал свой граф зависимостей

без автовайринга это грустно

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

предлагаешь вручную все зависимости собрать?

да

Зависимость появляется в худшем случае раз в день

и то на старте написания приложения

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

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

на поддержке раз в месяц

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

Как оно догадается, какие реализации интерфейсов нужны?

Как оно догадается, какие реализации интерфейсов нужны?

@Named