BV
Просто долго и надо друг к другу подгонять, в спринге худо-бедно уже подогнано
Size: a a a
2018 October 16
BP
Я вот тоже не понимаю, откуда столько нелюбви к спрингу. Это же счастье, что есть очень прилично сделанные инструменты, которые можно взять и решить очень большое число проблем. При этом никто не заставляет их использовать, пожалуйста, есть тот же ктор и ещё пачка других либ из которых можно вполне собрать рабочий стэк
+
SZ
я может конечно бред спрашиваю, ибо кубера не знаю, но все же
наверное стоило начало с того что "я не знаю кубера"?
IP
Как-то обманчиво звучит "я тут разбираюсь с многопоточкой", ждёшь вопрос из разряда Hello World
Не хотел никого пугать, да и в принципе разобрался)
d
есть?
все есть там
d
другой вопрос - ты прибит намертво к инфраструктуре
AE
наверное стоило начало с того что "я не знаю кубера"?
может ответить на вопрос есть или нет - тогда можно продолжить разговор о том стоят ли они рядом
AE
другой вопрос - ты прибит намертво к инфраструктуре
вот я об этом и говорю...
2018 October 17
KA
Иногда хочется измерить частоту споров Spring vs Libs, но вломмм.
Ну предположим вы доказали что одно во всём лучше чем другое.. и что?
Ну предположим вы доказали что одно во всём лучше чем другое.. и что?
SZ
тут скорее спор, о том что не спрингом мы едины)
KA
Мне вот интересно как убедить лида и нанимателей использовать в бэке Котлин хотя бы в моем модуле..
AL
Иногда хочется измерить частоту споров Spring vs Libs, но вломмм.
Ну предположим вы доказали что одно во всём лучше чем другое.. и что?
Ну предположим вы доказали что одно во всём лучше чем другое.. и что?
Ну, я бы сказал, зависит от конкретных выводов.
Если одно лучше другого и в короткой перспективе и в долгой - популяризовать доказательство, популяризовать победившую технологию.
Если одно лучше другого в короткой перспективе, а другое в долгой - опять таки популяризовать рассуждения через доклады/статьи и тогда новый проект вполне себе сможет выбирать в зависимости от того, как они себя ощущают (быстро сделать и очень слегка доделывать или делать долго и упорно)
Если одно лучше другого в одних кейсах, другое в других - впринципе тоже самое, что пунктом выше. Доступно рассказать, дальше смогут хорошо выбирать.
Если одно лучше другого и в короткой перспективе и в долгой - популяризовать доказательство, популяризовать победившую технологию.
Если одно лучше другого в короткой перспективе, а другое в долгой - опять таки популяризовать рассуждения через доклады/статьи и тогда новый проект вполне себе сможет выбирать в зависимости от того, как они себя ощущают (быстро сделать и очень слегка доделывать или делать долго и упорно)
Если одно лучше другого в одних кейсах, другое в других - впринципе тоже самое, что пунктом выше. Доступно рассказать, дальше смогут хорошо выбирать.
AL
Тут например не один раз приходили спрашивать - что взять в бек фреймворком. Ну вот можно будет ответить без срача, например.
AL
*в мечтах, т.к. спринг против ктора и тд и тп не особо затухающий вопрос*
SZ
если кто-то выбирает себе инструмент по рекомендациям чатика.. то даже не знаю)
QH
Тут есть глобальная идея: один подход навязывает плохой код, другой позволяет писать нормально.
Переманивание на свою сторону в теории может приводить к возрастанию качества опенсорса.
Переманивание на свою сторону в теории может приводить к возрастанию качества опенсорса.
SZ
срач срачом, но перед тем как что-то берешь, надо ж альтернативы смотреть и оценивать под свою задачу, как выше написали
AL
если кто-то выбирает себе инструмент по рекомендациям чатика.. то даже не знаю)
Ну, это немного лучше, чем выбирать исключительно по принципу хайпа, что происходило и происходит. Понятно, что не прямо идеальный вариант.
KA
Хорошо бы люди доказали такое с помощью статей и докладов
KA
Спринговое облако против кубера, интересно же, я вот не знаю как на кубере такое сделать