Телеграмм чат группы kotlin

Alexander Nozik

К вопросу о котлин, мне очень нравится как ютрэк на ксодусе работает

Вот только он не масштабируется 🌚

13:23пожаловаться #1

Надо ли это - отдельный вопрос, но я видел, как он не всегда хорошо работает на большом количестве пользователей.
При этом на сайте JB он вроде бы вывозит.

13:24пожаловаться #2

Alexander Nozik in Kotlin Community

У меня нет. Тормозит со страшной силой, но может быть это не он виноват... надо кстати под проксей попробовать...

13:25пожаловаться #3

Alexander Nozik in Kotlin Community

Под впном еще больше тормозит

13:27пожаловаться #4

Alexander Nozik in Kotlin Community

Вот кстати было бы интересно от разработчиков узнать, что там так тормозит - база или приложуха

13:28пожаловаться #5

Ерлан Ибраев

Э-э-э. Для репозитория все просто, достаточно включить трассировку запросов в хибернейт. И сразу станет видно что и как делается.

Если так рассуждать, то ни один программист, ну кроме разработчиков БД (да и то для Oracle есть сомнения). Нельзя допускать до работы с БД.🤣

Угу, а какой такой Iterable мне возвращается из findAll? Есть там ленивость? А кэширование?

14:40пожаловаться #6

Угу, а какой такой Iterable мне возвращается из findAll? Есть там ленивость? А кэширование?

А доку для кого писали? Или всё, что не понятно из кода - неведомое говно?

14:40пожаловаться #7

central hardware

+ к этому вы не думали что такие вещи которые поставляются в форме сервера, расчитаны на использование множеством продуктов а не только вашим одним процессом

Мы думали. Но нам так не нужно.

14:42пожаловаться #8

А доку для кого писали? Или всё, что не понятно из кода - неведомое говно?

Джавадок читал.
Да, именно так.

14:42пожаловаться #9

Джавадок читал.
Да, именно так.

Я не про джавадок 😉
Ну что ж, с таким подходом тяжеловато жить с фреймворками

14:43пожаловаться #10

Я не про джавадок 😉
Ну что ж, с таким подходом тяжеловато жить с фреймворками

Так фреймворки зло, им самим осталось недолго жить у меня в проекте.

14:45пожаловаться #11

Так фреймворки зло, им самим осталось недолго жить у меня в проекте.

Звучит как религия. Но это конечно выбор каждого.

14:46пожаловаться #12

Звучит как религия. Но это конечно выбор каждого.

Звучит как инженерный подход: всё должно быть чётко и понятно, а плюсы должны перевешивать минусы.

14:47пожаловаться #13

Звучит как инженерный подход: всё должно быть чётко и понятно, а плюсы должны перевешивать минусы.

Инженерный подход - это не отказываться от инструментов, когда они уместны. А "фреймворки зло" - не очень похоже на это.
Я не спорю, что в целом явное лучше неявного, и простые либы использовать проще. Но иногда есть смысл затащить условный спринг. И наверняка во многих случаях целесообразно затащить даже Spring Data JPA (хотя я бы не стал 😁).

14:49пожаловаться #14

Если я такие случаи встречу, то обязательно так и сделаю.

14:50пожаловаться #15

Вот у Руслана какие-то слабосвязанные модули, которые без Спринга задолбаешься делать.

14:51пожаловаться #16

Ruslan Ibragimov in Kotlin Community

Возмущения в силе чувствую я

Не со спрингом, а с IoC контейнером. Spring-Context один из примеров такого контейнера

15:15пожаловаться #17

Bogdan Panchenko in Kotlin Community

Угу, а какой такой Iterable мне возвращается из findAll? Есть там ленивость? А кэширование?

Читать доки и знать что итератор подразумевает последовательность, и ленивость в нем не предусмотрена, поэтому стрим не был унаследован от итератора (сейчас не знаю не следил). Поэтому следует предположить что он не ленивый

15:44пожаловаться #18

Bogdan Panchenko in Kotlin Community

Звучит как инженерный подход: всё должно быть чётко и понятно, а плюсы должны перевешивать минусы.

После того как прочитаешь доку по серингу и посмотришь Марин потрошитель - спринг станет простым, но даже так он мне не очень нравится

15:45пожаловаться #19

Bogdan Panchenko in Kotlin Community

Вот у Руслана какие-то слабосвязанные модули, которые без Спринга задолбаешься делать.

У меня тоже желательно разбить на такие модули, но спринг не затащил 🌚