Так а щас наблюдается четкое разделение на фронт и бек. Фронты своим занимаются, беки своим. Я вообще думаю что фуллстеки вымрут скоро.

Тогда вообще все плохо, вместо одного разработчика вам нужно два

Так а щас наблюдается четкое разделение на фронт и бек. Фронты своим занимаются, беки своим. Я вообще думаю что фуллстеки вымрут скоро.

И Node.js закопают обратно? Скорее бы уже.

Это не плохо - это прекрасно. Приложения усложняются же сильно. И разделение ответственности это хорошо

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

И Node.js закопают обратно? Скорее бы уже.

+

И Node.js закопают обратно? Скорее бы уже.

+

Да, но тренд идёт на разделение.

Node.js на беке - отстой - +

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

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

Я вот сейчас сел в свободное время (которого нет) писать на кторе рисовалку графиков https://github.com/altavir/kplot

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

к сожалению котлин пока не так хорошо дружит с клиентскими фреймворками. да, есть примеры для react, vue, но это наколенные поделки. офф поддержки нет

а есть еще angular

там вообще туши свет

к сожалению котлин пока не так хорошо дружит с клиентскими фреймворками. да, есть примеры для react, vue, но это наколенные поделки. офф поддержки нет

что в этих «наколенных поделках» не так?

JB же и сами пишут на реакте

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

Так а там и не надо дружить. Надо уметь по API JSON гонять. В хедеры уметь, с базой работать и все такое.

реакт почти единственный с кем хорошо удалось скрестить котлин

Так а там и не надо дружить. Надо уметь по API JSON гонять. В хедеры уметь, с базой работать и все такое.

с базой? мда.... клиентские фреймворки далеко не о том как сделать рест запрос...

реакт почти единственный с кем хорошо удалось скрестить котлин

почему? разве есть разница какой фронт вызывает твой бэк?

Если мы не про SPA, там это имеет значение. В SPA ничего дружить не надо. Условно фронт на одном сервере, общается по CORS с беком на другом. Они никак не связаны

почему? разве есть разница какой фронт вызывает твой бэк?

Речь о Kotlin/JS.

аа

почему? разве есть разница какой фронт вызывает твой бэк?

да не об этом речь, емае. я говорю о постоении сложного клиентского ПО

Если мы не про SPA, там это имеет значение. В SPA ничего дружить не надо. Условно фронт на одном сервере, общается по CORS с беком на другом. Они никак не связаны

wwwwat?

Бэк сидит на другом сервере. Фронт его просто дергает за ручку с другого сервера

И все. Не пойму какая там ещё дружба нужна

SPA вообще не на сервере крутится, а в браузере

не с другого сервера, а из браузера

Я не спорю) но кто то хтмльки же спашные отдал вам)

И все. Не пойму какая там ещё дружба нужна

нужна чтобы kotlin/js подружить с клиентски ми фреймворками на js

nginx

статика чистая, собранная npm'ом (webpack'ом)

Вооот. Итак Nginx отдаёт статику спашную. С одного хоста. На другом хосте, в другой стране, галактике висит бэк. Фронт его дергает по CORS. И меняются они json ну или графами. Это классическая штука же.

Я не спорю) но кто то хтмльки же спашные отдал вам)

хоть кто, хоть тот же бэк из рессурсов. факт в том что это html с допустим ангуляровским шаблоном, ему нужен клиентский код с запущенным ангуляром, который с kotlin не дружит, тут либо es6, либо typescript

Вооот. Итак Nginx отдаёт статику спашную. С одного хоста. На другом хосте, в другой стране, галактике висит бэк. Фронт его дергает по CORS. И меняются они json ну или графами. Это классическая штука же.

да понятно это, я тебе выше написал

хоть кто, хоть тот же бэк из рессурсов. факт в том что это html с допустим ангуляровским шаблоном, ему нужен клиентский код с запущенным ангуляром, который с kotlin не дружит, тут либо es6, либо typescript

ну так да, это разные приложения, в идеале в разных репозиториях в гите, с ними работают разные люди, между ними только API spec и http

Если Котлин дружит с http и умеет заворачивать объекты в JSON - то я честно не понимаю что ещё нужно там подружить. Я связи не вижу никакой просто. В котел приходит json в реквесте - он делает что то отдаёт такой же респонс - не?

Да я именно про API

Если Котлин дружит с http и умеет заворачивать объекты в JSON - то я честно не понимаю что ещё нужно там подружить. Я связи не вижу никакой просто. В котел приходит json в реквесте - он делает что то отдаёт такой же респонс - не?

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

Аа. Эм... ну я котел не рассматриваю для генерации хтмлек - и клиентского кода. Про то что меня бомбануло - от tr{} - это не относится к делу, про которое я думаю и для чего хочу котлин

Если Котлин умеет в API + ORM ну и весь красивый - это ок. Генерить хтмльки им - лично для меня не ок.

Если Котлин умеет в API + ORM ну и весь красивый - это ок. Генерить хтмльки им - лично для меня не ок.

Как письма будете рассылать клиентам?

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

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

+

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

Еще вариант - использовать внешний сервис, может даже на аутсорсе. Таким образом, вариантов много, и использовать dsl для генерации html - один из них, в каком-то случае, может, самый удобный

Так что не надо бомбить )

ну вот, я пропустил срач про спринг =(

Это было просто бросание какашек. Будет пресекаться.

я тут обновился до 2.1.0.M1, думая что мою проблему с вебсокетами пофиксили, а нет, нифига, она в другом месте вылезла =(

Могу еще пример за генерацию html на сервере предложить - допустим cервер генерирует какой-то отчет и сразу пишет в хранилище/в файл. А потом хайлоад и -тысячи- мильоны пользователей дергают этот отчет.

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

Да. Но это частные случаи. Я уже говорил - тут уже зависит от задачи.

Могу еще пример за генерацию html на сервере предложить - допустим cервер генерирует какой-то отчет и сразу пишет в хранилище/в файл. А потом хайлоад и -тысячи- мильоны пользователей дергают этот отчет.

генерится датасет отчета и по нему рендерится отчет у клиента а еще экономятся байтики в бд )

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

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

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

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

Спок спок, никто не посягал на SPA.

генерится датасет отчета и по нему рендерится отчет у клиента а еще экономятся байтики в бд )

schemaless датасет? Поддержка версионирования и кода? Спасибо, не надо.

ERROR: S client not available

проапгрейдился до kotlin 1.2.60 стала ломаться сборка из idea: Error:Kotlin: [Internal Error] java.lang.IllegalStateException: The provided plugin org.jetbrains.kotlin.kapt3.Kapt3ComponentRegistrar is not compatible with this version of compiler Кто нибудь с таким сталкивался, есть рецепты?

проапгрейдился до kotlin 1.2.60 стала ломаться сборка из idea: Error:Kotlin: [Internal Error] java.lang.IllegalStateException: The provided plugin org.jetbrains.kotlin.kapt3.Kapt3ComponentRegistrar is not compatible with this version of compiler Кто нибудь с таким сталкивался, есть рецепты?

1) Плагин идеи обновить 2) инвалидэйт кэш энд рестарт

делал, не помогает

да у меня та же фигня была пришось откативатся до 1.2.51

и у меня тоже последняя идея и плагин

У меня все работает. Судя по ошибке конфликт в каптовском плагине, а не в котлиновском

проапгрейдился до kotlin 1.2.60 стала ломаться сборка из idea: Error:Kotlin: [Internal Error] java.lang.IllegalStateException: The provided plugin org.jetbrains.kotlin.kapt3.Kapt3ComponentRegistrar is not compatible with this version of compiler Кто нибудь с таким сталкивался, есть рецепты?

Странно, только что апнулся, ничего не ломается

Странно, только что апнулся, ничего не ломается

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

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

Ага, ради обещанного ускорения kapt-a и поднимал

аааа, так это они его так ускорили...

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

проапгрейдился до kotlin 1.2.60 стала ломаться сборка из idea: Error:Kotlin: [Internal Error] java.lang.IllegalStateException: The provided plugin org.jetbrains.kotlin.kapt3.Kapt3ComponentRegistrar is not compatible with this version of compiler Кто нибудь с таким сталкивался, есть рецепты?

https://youtrack.jetbrains.com/issue/KT-24714

Всем привет. Использую ктор и столкнулся с одной проблемой сейчас. Для сериализации/десериализации объектов я использую GSON. Конкретно при десериализации использую метод call.receiveOrNull<Class>. До этого при десерилизации JSON'а, в котором переданы не все поля класса, этот метод возвращал null. Сейчас я заметил, что при десериализации таких JSON'ов теперь возвращается объект с дефолтными значениями, если они отстутствуют в JSON'е (null для string, 0 для int, если не указаны другие значения). Какое из этих двух поведений правильное? Могу ли я как то настроить, чтобы выполнялось первое вместо второго? Также в чем может быть причина изменения поведения? Недавно я обновил kotlin в idea, может ли быть в этом причина? В конфигах я точно ничего не менял.

Всем привет. Использую ктор и столкнулся с одной проблемой сейчас. Для сериализации/десериализации объектов я использую GSON. Конкретно при десериализации использую метод call.receiveOrNull<Class>. До этого при десерилизации JSON'а, в котором переданы не все поля класса, этот метод возвращал null. Сейчас я заметил, что при десериализации таких JSON'ов теперь возвращается объект с дефолтными значениями, если они отстутствуют в JSON'е (null для string, 0 для int, если не указаны другие значения). Какое из этих двух поведений правильное? Могу ли я как то настроить, чтобы выполнялось первое вместо второго? Также в чем может быть причина изменения поведения? Недавно я обновил kotlin в idea, может ли быть в этом причина? В конфигах я точно ничего не менял.

Так примитивные типы вроде ж не могут быть null

Так примитивные типы вроде ж не могут быть null

Те типы, которые не могут быть null и получают свое дефолтное значение (0 для Int, например). В моих дата классах, в которые происходит десериализация все типы не имеют "?" в конце (то есть я не использую String?). Однако в процессе десериализации туда все равно попадает null. В данном случае больше даже интересует поведение метода recieveOrNull, который теперь вообще null никогда не возвращает. В худшем случае объект с пустыми полями.

Те типы, которые не могут быть null и получают свое дефолтное значение (0 для Int, например). В моих дата классах, в которые происходит десериализация все типы не имеют "?" в конце (то есть я не использую String?). Однако в процессе десериализации туда все равно попадает null. В данном случае больше даже интересует поведение метода recieveOrNull, который теперь вообще null никогда не возвращает. В худшем случае объект с пустыми полями.

А дефолтные значения заданы в конструкторе класса?

А дефолтные значения заданы в конструкторе класса?

Нет

Кусок кода скажет больше тысячи слов

Кусок кода скажет больше тысячи слов

https://pastebin.com/3UC1AsC1 Вот такое например. Когда начинал проект (на 99% уверен) метод receiveOrNull возвращал null в случае, если в json'е приходил только логин, к примеру. Сейчас этот метод возвращает объект с полем passwordHash = null.

Те типы, которые не могут быть null и получают свое дефолтное значение (0 для Int, например). В моих дата классах, в которые происходит десериализация все типы не имеют "?" в конце (то есть я не использую String?). Однако в процессе десериализации туда все равно попадает null. В данном случае больше даже интересует поведение метода recieveOrNull, который теперь вообще null никогда не возвращает. В худшем случае объект с пустыми полями.

> о есть я не использую String? может дело в этом, вы говорите что нулл не может быть и тогда GSON кидает дефолты, имхо

Те типы, которые не могут быть null и получают свое дефолтное значение (0 для Int, например). В моих дата классах, в которые происходит десериализация все типы не имеют "?" в конце (то есть я не использую String?). Однако в процессе десериализации туда все равно попадает null. В данном случае больше даже интересует поведение метода recieveOrNull, который теперь вообще null никогда не возвращает. В худшем случае объект с пустыми полями.

Если Gson не находит no-arg constructor, он создаёт объект через Unsafe и там всё равно оказываются нули.

Если Gson не находит no-arg constructor, он создаёт объект через Unsafe и там всё равно оказываются нули.

Нельзя как то запретить GSON'у десериализовать такие объекты? Просто иначе в какой ситуации recieveOrNull вернет нам null?

Нельзя как то запретить GSON'у десериализовать такие объекты? Просто иначе в какой ситуации recieveOrNull вернет нам null?

Не знаю способа, сам хотел бы. Не знаю этого метода.

Можно как-нибудь спрятать internal-классы от Java-кода?

Можно как-нибудь спрятать internal-классы от Java-кода?

ты уже спрашивал

вроде как не нашлось способа

а надежда с тех пор так и не угасла :)

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