Если всем нужен работник в офисе, откуда тогда берутся люди работающие удаленно? ?

Рынок удалённых вакансий сильно меньше и там точно без опыта не возьмут. Слишком большой риск, что человек без опыта тупо не сможет организовать своё рабочее время сам.

А в чем проблема пойти в офис на первое время?

Я немного в другой стране

Без опыта:) а без опыта не берут

Начальный опыт на петпроджектах, с начальным берут

почти в самой её жопе на данный момент, хотя в телеге, как видно, сижу

Я немного в другой стране

и в твоей стране совсем-совсем нет никакой работы для JVM-разраба?

и в твоей стране совсем-совсем нет никакой работы для JVM-разраба?

Я не хочу работать в Китае на китайцев ?

во всяком случае, развиваться я тут врядли буду

у меня на первом курсе код лучше был

Кгм, ребят, мы в @kotlin_lang.

@Enleur а какой у тебя юзкейс был для currentScope?

@Enleur а какой у тебя юзкейс был для currentScope?

запустить локальный launch внутри suspend функции

в слаке у чувака был похожий кейс с каналами

Ага, а ты получается не прокидывал сверху CoroutineScope?

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

запустить локальный launch внутри suspend функции

withContext(coroutineContext)

неа. ну можно обойти это и завернуть coroutineContext в скоуп

withContext(coroutineContext)

это будет идентично coroutineScope и launch заблокирует дальше выполнение же

неа. ну можно обойти это и завернуть coroutineContext в скоуп

CoroutineScope(coroutineContext).launch {}?

CoroutineScope(coroutineContext).launch {}?

да) ну по сути это и есть функция currentScope

да) ну по сути это и есть функция currentScope

Ну вот я о том же

withContext(coroutineContext)

а почему задепрекейтили currentScope?

вот кейс Луиса suspend inline fun <E> ReceiveChannel<E>.doOnEach( context: CoroutineContext = EmptyCoroutineContext, noinline action: suspend (E) -> Unit ) = currentScope { launch(context) { consumeEach { action(it) } } } вполне реальный

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

наверное стоит просто не выделываться и брать GlobalScope для fire and forget)

currentScope (судя по примерам, которые мы видели) это “ну, без скоупа launch не работает, GlobalScope не рекомендован, вкорячу-ка я currentScope”

примерно так и было)

создал новый проект с kotlin и gradle. Ноут обжёг ноги, где я свернул не туда?)

а если серьёзно, то пытаюсь слезть с java, maven связки. Кто-то может подсказать туториал по gradle?

создал новый проект с kotlin и gradle. Ноут обжёг ноги, где я свернул не туда?)

в выборе ноута не туда свернул)

а если серьёзно, то пытаюсь слезть с java, maven связки. Кто-то может подсказать туториал по gradle?

maven polyglot

а если серьёзно, то пытаюсь слезть с java, maven связки. Кто-то может подсказать туториал по gradle?

https://guides.gradle.org/creating-new-gradle-builds/ https://guides.gradle.org/building-kotlin-jvm-libraries/ Build Scan только скипай, это не нужно

Ну и можно еще сразу на Gradle Kotlin DSL перейти попробовать https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/

пора начинать миграцию на Kotlin DSL?

Думаю если билд не сложный то можно незадумываясь переходить

Если много кастомного - то будет сложно, то тоже реально

В целом Idea почти не виснет и не делает весь файл красным уже

Гредл в поддержке почти не виснет не делает весь файл красным

Ну когда делаешь что-то поверх ?не всегда можно сделать ?

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

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

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

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

Я вот банально не запомню что нужно писать в груви когда хочешь сделать exclude: compile(smth) { exclude // че тут дальше писать? group? groupId? artifact? artifactId? } вот, буквально сейчас писал такое с старом проекте, и пришлось гуглить. а в kotlin dsl идея подсказывает например, и я когда писал такое-же там не пошел в duckduckgo

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

надо в доке ктора на kotlin-dsl примеры переписать ?

можно поконтрибьютить)

Всем привет. Есть кто юзает Exposed? Вы пользуетесь какими то дополнительными инструментами миграций? Или дефолтного функционала createMissingTablesAndColumns() достаточно для поддержания схемы в актуальном состоянии?

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

пора начинать миграцию на Kotlin DSL?

А в чем профит?

А в чем профит?

единый язык для билдов и приложения. почему бы и нет?

единый язык для билдов и приложения. почему бы и нет?

и статическая типизация путёвая

единый язык для билдов и приложения. почему бы и нет?

А почему бы и да?) Мне важно понимать, зачем мне тратить кучу времени на переписывания градл скрипта. Что я получу?

ну не кучу, а где-то час

и вон выше Руслан приводил пример. меньше времени тратить потом на поддержку этого дела

плюс на новых проектах сразу делать на kotlin dsl

так он же разваливается через раз

так он же разваливается через раз

кто разваливается?

Не, ну допустим не много времени. Час. Что я получу?

так он же разваливается через раз

они над этим работают активно) ну и в 5.0 гредле будет стабильный релизик

файлы на котлин дсл

мы перешли а потом кучу проблем огребли и откатились

а можно примеры? Просто имею несколько проектов и пока не увидел чтобы они "разваливались"

Оно сейчас у меня работает. Я перепишу, возможно будет работать точно так же или чуть хуже. В чем смысл?

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

Оно сейчас у меня работает. Я перепишу, возможно будет работать точно так же или чуть хуже. В чем смысл?

смысл уйти от градл груви сиинтаксиса)

смысл уйти от градл груви сиинтаксиса)

Та будь оно хоть на паскале написано. Хоть на лиспе. Хоть пролог. Оно же работает. Зачем переписывать?

Та будь оно хоть на паскале написано. Хоть на лиспе. Хоть пролог. Оно же работает. Зачем переписывать?

ну вот пишешь новый сервис или проект, там уже берешь Kotlin DSL, потом еще один и тд. и в конечном итоге у тебя зоопарк из билдфайлов

Та будь оно хоть на паскале написано. Хоть на лиспе. Хоть пролог. Оно же работает. Зачем переписывать?

уменьшить стоимость поддержки

ERROR: S client not available

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

ну вот пишешь новый сервис или проект, там уже берешь Kotlin DSL, потом еще один и тд. и в конечном итоге у тебя зоопарк из билдфайлов

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

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

видимо в IDEA только? При подобных проблемах мне помогал переоткрытие проекта. Хотя постоянно генерятся "IDE Fatal Errors" на DSL - это факт

видимо в IDEA только? При подобных проблемах мне помогал переоткрытие проекта. Хотя постоянно генерятся "IDE Fatal Errors" на DSL - это факт

в AS

уменьшить стоимость поддержки

Каким образом?

Каким образом?

один язык вместо двух

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

вам нет профита) у нас разрабы на груви писать не умеют

Каким образом?

удобнее (дешевле) дописывать в скрипт что-то

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

++

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

На ассемблере писать тоже неудобно. Так что теперь, надо все ассемблерные вставки и все проги на ассемблере переписывать?

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

кажется тут даже не в груви дело а именно в градл дсл этом

потмоу что тесты на споке писать поприятнее чем скрипты на градле. хотя тоже груви

На ассемблере писать тоже неудобно. Так что теперь, надо все ассемблерные вставки и все проги на ассемблере переписывать?

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

поэтому и прогресс идет

в общем, если вам нет профита - не переходите, никто ж не заставляет)

у нас есть профит, ждем только стабильности и релиза

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

Так может тогда подучить это надо вместо переписывания? Все проекты не перенесут. Придет время, попросят мелочь какую то пофиксить в градл скрипте. А ты такой, нееее, тут 6иче не понятно, надо переписывать.

Получается знать джаву бесполезно. Изначально надо котлин учить и на нем писать. Один язык вместо двух.

зачем мне там что-то учить, если я потрачу щас час и там будет то что я знаю?

зачем мне там что-то учить, если я потрачу щас час и там будет то что я знаю?

Учить что то вообще не надо. Можно просто копипастить со стэковерфлоу))

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

Учить что то вообще не надо. Можно просто копипастить со стэковерфлоу))

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

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

А в котлин дсл не слетает ничего? Человек знающий груви дсл при взгляде на котлин дсл быстрее разберется чем человек знающий котлин дсл при взгляде на груви дсл?

хаха вот ты пристал)) ты что хочешь чтобы мы тебя убедили перейти?

ты много гредл скриптов писал?

Нет, я не пойму этого хайпа))

Нет, я не пойму этого хайпа))

Причем тут хайп, тупо удобнее писать и поддерживать

хайпа то и нет)

ты много гредл скриптов писал?

Не много

и что чувстваовал?)

и что чувстваовал?)

Что пишу скрипт))))