У меня в команде Девопс Jesus, испанец. При этом коллеги неиспанцы (немцы в основном) постоянно шутят насчет этого. "Так, почему Хесус не пришел на митинг?". "Так он же умер 2000 лет назад, хохохо". "Только с божью помощью мы с можем решить эту проблему на проекте. Хесус, ты ведь нам поможешь? хохохохо". Хорошо, что он тоже с чувством юмора и ржет громче всех.
Да электрон вроде исправляется. Года два назад было ужасно, но сейчас, кажется, более или менее стабильно, я даже я не замечаю, что приложение на электрон: Postman, Slack, Lens работают норм. Или это действительно не электрон приложения
С удовольствием для развития кругозора, но хотелось бы почитать аргументы Dart vs. Kotlin, KMM vs. Flutter. В данной статье автора они не приводятся. Ибо для меня, например, пока преимущества одного против другого не очевидны, кроме одного пункта в пользу котлина - я его уже знаю
Я расматриваю эти два языка вне версий, так как от версии к версии в них меняется не сильно. Хотя в джаве конечно больше функционала завозят в последние годы, то что в котлине завезли с самого начала. Тем не менее, я не думаю что в Java17 добавили/когда либо добавят то, что я люблю в котлине. Null safety, от которого я в самом начале работы с котлином просто плевался, а сейчас жить не могу. Optional очень слабый конкурент удоству null safety. Максимально удобная функциональщина, и то, как это сделано в джаве - у меня просто кровь из глаз. Функции расширения и многое другое.
На dart я пока никак не смотрю, я бекенд разработчик. Но в планах есть пойтив мобильные разработчики, но я любо перейду на нейтив-андроид, либо на KMM, потому как мысли, выраженные автором я читал много где. Ну и поэтому я думаю, что Flutter я все же пропущу.
Ну так и джаве сколько лет по сравнению с котлин, а котлин, хоть и моложе, но уже где-то опережает джаву. Меня самого долго ломало переходить на котлин, я считал этот язык каким-то несерьезным что ли. Но когда перешел, на джаву без боли смотреть не могу, хотя считаю, что она наконец поднажала и старается догнать котлин в удобстве и новом функционале. Я может быть когда-нибудь и вернусь на джаву, ибо котлин, в стремлении закрыть недостатки джавы, их закрыл, но при этом добавил свои недостатки и костыли. Но при этом взросление котлина, я считаю, пока более динамичное, и недостатки и баги исправляются быстрее.
Когда я запускаю IDEA, то в правом нижнем углу она показывает разные информационные маленькие окошки, вот оно из окошек гласит "Вы используете hibernate, а не хотите ли настроить плагин под него" (сообщение на английском, но смысл вот такой). Я нажимаю настроить, выходит окно установки плагина, где показывается ваш плагин и мне нужно только нажать Ок. В принципе, не критично, но вот обратил внимание на такое поведение. На указанную почту скину версии всего используемого и скрины
Спасибо за инструмент. Он до сих пор вызывает некоторые проблемы у меня, IDEA при каждом своем перезапуске просит настроить его, но в любом случае вижу тенденцию к полезности вашего плагина.
Я хотел @Repositoryиспользовать исключительно для минимазации изменений в коде, как это работает с теми же @Entity, по сути переход очень малозатратный в случае с сущностями, ничего править не нужно, соответственно возможно переиспользование кода, так как у меня миграция - это совмещение старого кода с новым реактивным. Поэтому я ищу легкий путь, а не заниматься дублированием кода, так как разработка ведется паралелльно с миграцией. За ссылку query-dsl спасибо, давно приглядываюсь к нему, так как в своей время, не найдя что-то похожее, пришлось писать такую библиотеку самому
Я к такой мысли тоже приходил, хотел уже плюнуть на эти реактивные библиотеки и шедулить выполнение запросов вручную, как это делается под реактинвым капотом, но мне показалось это очень трудоемко и создание велосипеда. Но идея значит не такая уж плохая, если к ней пришел не только я. Спасибо
А вы не знаете, есть ли в реактивном Хибернейте @Repositoryстиль написания обращений к бд, чтобы не городить сложные конструкции с кодом JPQL/HQL. Написал в интерфейсе метод без тела, например findById и Хибернейт понял, что я хочу. R2DBC такое поддерживает, например.
Выгода такая же, как от перехода с обычного стека на реактивный. Если в приложении хоть что-то не реактивное, то все преимущества пропадают. А тем более, если это самый нижний слой, откуда поток данных начинается. Так что без перехода с блокирующего jdbc на что-то неблокирующее смысла не вижу использовать реактивщину. Ибо асинхронный поток данных будет блокироваться в самых неподходящих местах, останавливая всю асинхронную цепочку бизнес логики
Спасибо большое. Да, наверное это как-то получится уложить в рамки моего приложения. Ситуация у меня чуть сложнее, чем в таком же приложении, но на Java. Я решил делать всё в Котлин-way c suspendable. Project Reactor дает легкое преобразование из Mono и Flux в suspend вызов, через executeAndAwait например. Uni/Multi я такого не нашел, но ваша ссылка вроде дает подсказку, в каком направлении копать.
Тоже задумал мигрировать сервлетное приложение Spring boot на реактивную платформу. Правда у меня стек полностью котлин, там еще надо ужить WebFlux с suspend. Но вроде это наименьшая головная боль в миграции. Миграцию решил делать прозрачную, так чтобы фронтэнд даже этого не заметил и с минимальными правками бизнес логики. Тоже столкнулся с совмещением реактивных и нереактивных библиотек, но на данном этапе завести все вместе пока не получилось, хотя по части бизнес логики, в сервисном слое действительно правок у меня не много. Чего не скажешь про слой хранения данных. Вот где геморроя полно. Весь код придется переписывать, ибо из того, что я нарыл - R2DBC и Hibernate Reactive - совместимость никакая, у хибера процентов 70%, у r2dbc - 20%. Хибернетовские 70% еще куда ни шло, но у меня реактивный хибернейт очень плохо ложится на Котлин и Spring. Из вашей статьи надеюсь вынесу полезный опыт, спасибо за то что поделились.
Если вас не сильно беспокоит тэги ваших финальных сборок (если они вообще тэгируются), то могу предложить такое решение (если я правильно понял вашу задачу): последний шаг в dev ветке заливает ваши артифакты в хранилище (container registry, artifactory), а в мастер ветке через rules запрещаем билд, или переводим билд в мануальный режим. Мастер - только как хранилище рабочего проверенного кода, от которого просто отбранчевываются. По сути какая разница где был создан артефакт, в дев ветке или в мастере, если он сбилдился. А Деплой в прод берет их из хранилища. Только одно условие - в дев ветку должны сливаться все остальные ветки, а то получится расхождение в реальзованных фичах. Но я так понимаю, что у вас данное условие выполняется, ибо вы считаете, что мастер у вас делает бесполезный билд, значит в дев ветке у вас все фичи есть
Про теги я упомянул, потому что на некоторых проектах бранчи и теги в них - метаинформация для системы версионирования артефактов, поэтому зачастую важно в какой ветке был создан артефакт
У меня есть ноут, DELL XPS 2017 года, все как вы описываете. Работал с 800 Mhz из 2400, только с одним работающим ядром из 8, без какой либо нагрузки. Работать было невозможно на Windows, c Linux все было норм. Месяц потратил на выяснение, и выяснил, что причина в дровах от microsoft, но прилетевших мне по каналу обновления Dell. Дрова по дате довольно старые, но мой ноут их установил почему-то вот только сейчас, и при этом в сети есть дрова по версии более молодые, при этом ни встроенное средство обновления, ни делловская тулза их не видит. Кроме как запланированным устареванием я не могу назвать
У меня так бош мясорубка работает. Но правда современная. Там защита по закливанию с остановкой двигателя. И даже вилка один раз сорвалась внутрь вместе с мясом, погнулась, но никаких пластиковых деталей не сломалось, тупо двигатель остановился
Я попробую вашу либу, которая для JVM. У меня есть бек полностью на котлине + спринг, правда он сделан на блокирующих библиотеках, но я его потихоньку мигрирую на реактивные с использованием корутин. Подключу и буду юзать, спасибо за хорошую идею
Спасибо за перевод. Давно искал туториал как WebFlux подружить с корутинами. Пусть он и не подробный, но для старта мне пока хватит. Правда подход с написанием рутера для контролера мне не нравится. В самом спринге это сделано через аннотации, а здесь только строк писать надо, и я так понимаю на все контролеры надо не забыть написать свой рутер
А вы не рассказали, за что его народ не взлюбил и башку ему открутил? Бюджет воровал, коррупцию ли допустил, обнулением себя и конституции занимался? Да и вообще не понятно, что это за привычка - сначала убить, а потом чуть ли не в святые возводить?
У меня в команде Девопс Jesus, испанец. При этом коллеги неиспанцы (немцы в основном) постоянно шутят насчет этого. "Так, почему Хесус не пришел на митинг?". "Так он же умер 2000 лет назад, хохохо". "Только с божью помощью мы с можем решить эту проблему на проекте. Хесус, ты ведь нам поможешь? хохохохо". Хорошо, что он тоже с чувством юмора и ржет громче всех.
Да электрон вроде исправляется. Года два назад было ужасно, но сейчас, кажется, более или менее стабильно, я даже я не замечаю, что приложение на электрон: Postman, Slack, Lens работают норм. Или это действительно не электрон приложения
С удовольствием для развития кругозора, но хотелось бы почитать аргументы Dart vs. Kotlin, KMM vs. Flutter. В данной статье автора они не приводятся. Ибо для меня, например, пока преимущества одного против другого не очевидны, кроме одного пункта в пользу котлина - я его уже знаю
Я расматриваю эти два языка вне версий, так как от версии к версии в них меняется не сильно. Хотя в джаве конечно больше функционала завозят в последние годы, то что в котлине завезли с самого начала. Тем не менее, я не думаю что в Java17 добавили/когда либо добавят то, что я люблю в котлине. Null safety, от которого я в самом начале работы с котлином просто плевался, а сейчас жить не могу. Optional очень слабый конкурент удоству null safety. Максимально удобная функциональщина, и то, как это сделано в джаве - у меня просто кровь из глаз. Функции расширения и многое другое.
На dart я пока никак не смотрю, я бекенд разработчик. Но в планах есть пойтив мобильные разработчики, но я любо перейду на нейтив-андроид, либо на KMM, потому как мысли, выраженные автором я читал много где. Ну и поэтому я думаю, что Flutter я все же пропущу.
Ну так и джаве сколько лет по сравнению с котлин, а котлин, хоть и моложе, но уже где-то опережает джаву. Меня самого долго ломало переходить на котлин, я считал этот язык каким-то несерьезным что ли. Но когда перешел, на джаву без боли смотреть не могу, хотя считаю, что она наконец поднажала и старается догнать котлин в удобстве и новом функционале. Я может быть когда-нибудь и вернусь на джаву, ибо котлин, в стремлении закрыть недостатки джавы, их закрыл, но при этом добавил свои недостатки и костыли. Но при этом взросление котлина, я считаю, пока более динамичное, и недостатки и баги исправляются быстрее.
Когда я запускаю IDEA, то в правом нижнем углу она показывает разные информационные маленькие окошки, вот оно из окошек гласит "Вы используете hibernate, а не хотите ли настроить плагин под него" (сообщение на английском, но смысл вот такой). Я нажимаю настроить, выходит окно установки плагина, где показывается ваш плагин и мне нужно только нажать Ок. В принципе, не критично, но вот обратил внимание на такое поведение. На указанную почту скину версии всего используемого и скрины
Спасибо за инструмент. Он до сих пор вызывает некоторые проблемы у меня, IDEA при каждом своем перезапуске просит настроить его, но в любом случае вижу тенденцию к полезности вашего плагина.
Я хотел @Repositoryиспользовать исключительно для минимазации изменений в коде, как это работает с теми же @Entity, по сути переход очень малозатратный в случае с сущностями, ничего править не нужно, соответственно возможно переиспользование кода, так как у меня миграция - это совмещение старого кода с новым реактивным. Поэтому я ищу легкий путь, а не заниматься дублированием кода, так как разработка ведется паралелльно с миграцией. За ссылку query-dsl спасибо, давно приглядываюсь к нему, так как в своей время, не найдя что-то похожее, пришлось писать такую библиотеку самому
Я к такой мысли тоже приходил, хотел уже плюнуть на эти реактивные библиотеки и шедулить выполнение запросов вручную, как это делается под реактинвым капотом, но мне показалось это очень трудоемко и создание велосипеда. Но идея значит не такая уж плохая, если к ней пришел не только я. Спасибо
А вы не знаете, есть ли в реактивном Хибернейте @Repositoryстиль написания обращений к бд, чтобы не городить сложные конструкции с кодом JPQL/HQL. Написал в интерфейсе метод без тела, например findById и Хибернейт понял, что я хочу. R2DBC такое поддерживает, например.
Выгода такая же, как от перехода с обычного стека на реактивный. Если в приложении хоть что-то не реактивное, то все преимущества пропадают. А тем более, если это самый нижний слой, откуда поток данных начинается. Так что без перехода с блокирующего jdbc на что-то неблокирующее смысла не вижу использовать реактивщину. Ибо асинхронный поток данных будет блокироваться в самых неподходящих местах, останавливая всю асинхронную цепочку бизнес логики
Спасибо большое. Да, наверное это как-то получится уложить в рамки моего приложения. Ситуация у меня чуть сложнее, чем в таком же приложении, но на Java. Я решил делать всё в Котлин-way c suspendable. Project Reactor дает легкое преобразование из Mono и Flux в suspend вызов, через executeAndAwait например. Uni/Multi я такого не нашел, но ваша ссылка вроде дает подсказку, в каком направлении копать.
Тоже задумал мигрировать сервлетное приложение Spring boot на реактивную платформу. Правда у меня стек полностью котлин, там еще надо ужить WebFlux с suspend. Но вроде это наименьшая головная боль в миграции. Миграцию решил делать прозрачную, так чтобы фронтэнд даже этого не заметил и с минимальными правками бизнес логики. Тоже столкнулся с совмещением реактивных и нереактивных библиотек, но на данном этапе завести все вместе пока не получилось, хотя по части бизнес логики, в сервисном слое действительно правок у меня не много. Чего не скажешь про слой хранения данных. Вот где геморроя полно. Весь код придется переписывать, ибо из того, что я нарыл - R2DBC и Hibernate Reactive - совместимость никакая, у хибера процентов 70%, у r2dbc - 20%. Хибернетовские 70% еще куда ни шло, но у меня реактивный хибернейт очень плохо ложится на Котлин и Spring. Из вашей статьи надеюсь вынесу полезный опыт, спасибо за то что поделились.
Если вас не сильно беспокоит тэги ваших финальных сборок (если они вообще тэгируются), то могу предложить такое решение (если я правильно понял вашу задачу): последний шаг в dev ветке заливает ваши артифакты в хранилище (container registry, artifactory), а в мастер ветке через rules запрещаем билд, или переводим билд в мануальный режим. Мастер - только как хранилище рабочего проверенного кода, от которого просто отбранчевываются. По сути какая разница где был создан артефакт, в дев ветке или в мастере, если он сбилдился. А Деплой в прод берет их из хранилища. Только одно условие - в дев ветку должны сливаться все остальные ветки, а то получится расхождение в реальзованных фичах. Но я так понимаю, что у вас данное условие выполняется, ибо вы считаете, что мастер у вас делает бесполезный билд, значит в дев ветке у вас все фичи есть
Про теги я упомянул, потому что на некоторых проектах бранчи и теги в них - метаинформация для системы версионирования артефактов, поэтому зачастую важно в какой ветке был создан артефакт
У меня есть ноут, DELL XPS 2017 года, все как вы описываете. Работал с 800 Mhz из 2400, только с одним работающим ядром из 8, без какой либо нагрузки. Работать было невозможно на Windows, c Linux все было норм. Месяц потратил на выяснение, и выяснил, что причина в дровах от microsoft, но прилетевших мне по каналу обновления Dell. Дрова по дате довольно старые, но мой ноут их установил почему-то вот только сейчас, и при этом в сети есть дрова по версии более молодые, при этом ни встроенное средство обновления, ни делловская тулза их не видит. Кроме как запланированным устареванием я не могу назвать
У меня так бош мясорубка работает. Но правда современная. Там защита по закливанию с остановкой двигателя. И даже вилка один раз сорвалась внутрь вместе с мясом, погнулась, но никаких пластиковых деталей не сломалось, тупо двигатель остановился
Я попробую вашу либу, которая для JVM. У меня есть бек полностью на котлине + спринг, правда он сделан на блокирующих библиотеках, но я его потихоньку мигрирую на реактивные с использованием корутин. Подключу и буду юзать, спасибо за хорошую идею
Спасибо за перевод. Давно искал туториал как WebFlux подружить с корутинами. Пусть он и не подробный, но для старта мне пока хватит. Правда подход с написанием рутера для контролера мне не нравится. В самом спринге это сделано через аннотации, а здесь только строк писать надо, и я так понимаю на все контролеры надо не забыть написать свой рутер
Большое спасибо за развернутый ответ. Вот что значит зарождение гражданского общества.
А вы не рассказали, за что его народ не взлюбил и башку ему открутил? Бюджет воровал, коррупцию ли допустил, обнулением себя и конституции занимался? Да и вообще не понятно, что это за привычка - сначала убить, а потом чуть ли не в святые возводить?