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

В твоём варианте тоже будет новый таск, просто через map а не flatMap

В твоём варианте тоже будет новый таск, просто через map а не flatMap

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

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

Нет, в спеке всё описано

А где пример стрима?

Все что есть - это итератор получаемый в ответ, как встроить в такую схему стрим - не понимаю.

@rockjam завтра расскажешь кароч) заинтересовал

Это называется feature toggles - ранняя интеграция в мастер с ручным активированием фичи

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

По моему хром так пишут

Как раз потому что много людей одновременно работает

SRE из гугла рассказывал что там так часто делают.

Делать так можно, но нужно соблюсти много условий

По моему хром так пишут

хром пишут не совсем так

у них там несколько веток

Проблема с код ревью - либо работать в парах, либо не деплоить автоматически на прод

Ну у хрома есть версии, да

что мешает юзать обычный гитфлоу?)

Стоимость интеграции долгих веток

Никогда не слышали "этот класс пока не трогай, я у себя в ветке отрефакторил".

кто первый смержил, того и тапки

Никогда не слышали "этот класс пока не трогай, я у себя в ветке отрефакторил".

Про бэкмерж не слышали?

Да, если есть код ревью, то можно придираться пока свою ветку не смержишь

Про бэкмерж не слышали?

А причём тут это. Проблему тапок это не решает.

Чем больше wip не интегрированный, тем больше конфликтов

Размер wip пропорционален количеству разработчиков и размеру фич

В какой-то момент это становится серьёзной проблемой

А причём тут это. Проблему тапок это не решает.

Но уменьшает боль и зуд в анусе

Проблема не в том как и когда решать конфликты, а в том что они вообще есть

Эт не проблема)

конфликты в одних и тех же местах - признак неподходящей архитектуры/дизайна, в разных - плохого планирования

условный гитфлоу и WIPы могут решить вторую проблему, но не первую

Допустим, я отрефакторил класс повсеместно использующийся и смерджил в мастер. 10 моих коллег в ветках этот класс тоже использовали поняли что у них конфликты, но не вполне осознают суть изменений (ну потому что им нужно больше вникнуть в контекст, чем автору). Зовут автора или тихо матерясь правят свой код, тратя своё время. Поэтому для значительных изменений люди пытаются подобрать момент когда меньше wip, зная какой гемор с конфликтами иначе.

Все что есть - это итератор получаемый в ответ, как встроить в такую схему стрим - не понимаю.

https://gist.github.com/Odomontois/1d8faa4cf653d24d69380b66aafebb38

Выделить в отдельный модуль и подвергнуть его версионированию?

Допустим, я отрефакторил класс повсеместно использующийся и смерджил в мастер. 10 моих коллег в ветках этот класс тоже использовали поняли что у них конфликты, но не вполне осознают суть изменений (ну потому что им нужно больше вникнуть в контекст, чем автору). Зовут автора или тихо матерясь правят свой код, тратя своё время. Поэтому для значительных изменений люди пытаются подобрать момент когда меньше wip, зная какой гемор с конфликтами иначе.

Плохой менеджмент

В чем плохой?

https://gist.github.com/Odomontois/1d8faa4cf653d24d69380b66aafebb38

благодарю, отпишу

благодарю, отпишу

Это пример с https://github.com/travisbrown/iteratee

Выделить в отдельный модуль и подвергнуть его версионированию?

тоже больно

Нужно сделать митинг "рефакторим класс A"?

Выделить в отдельный модуль и подвергнуть его версионированию?

это уже архитектурное решение (скорее верное для описанного кейса)

В чем плохой?

Плохо когда у тебя люди один класс правят

А представьте что коллег не 10, а 100. Договориться не получится.

Плохо когда у тебя люди один класс правят

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

писали 30 людями в 5 командах в 1 мастер, боли были при мерджах но не огромные

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

Использование не должно конфликтов порождать

Э?

А представьте что коллег не 10, а 100. Договориться не получится.

архитектор на что? 100 человек в гибкость и договоры p2p не влезут, надо менеджить

А представьте что коллег не 10, а 100. Договориться не получится.

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

Я просто объясняю когда это может быть нужно. Не призываю создавать монорепу на 100 человек, но у кого-то это объективная реальность.

Я просто объясняю когда это может быть нужно. Не призываю создавать монорепу на 100 человек, но у кого-то это объективная реальность.

это уже огромная проблема

тоже больно

Ну, выбирайте ту боль, с которой вы готовы смириться

это уже огромная проблема

Монолит на 15 команд, 100 человек, 200+ модулей. Бывает.

Переписывание на микросервисы - несколько лет...

Скаланы, а есть ли разница между x ne null и x != null ?

Бывает. Но если всем участвующим окей такой оверхед - на конфликты, проблемы, сложности развития - на большое бабло, в общем - то, наверное, есть и бенефиты. Наверное)

либо кто-то деньги считать не умеет

Скаланы, а есть ли разница между x ne null и x != null ?

зависит от того, как ты определил equals

Уточню вопрос

если equals дефолтный. Безо вяских def equals(x: Any) = true

Можт ты написал у себя if (that == null)

либо кто-то деньги считать не умеет

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

дефолтный это Object.equals или сгенеренный для case class?

вызов equals вс вызов сравнения ссылок для null нет разницы

В любом случае ne null быстрее до первого JITа

Проверку на null надо через ne делать имхо

почему?

ERROR: S client not available

Проверку на null надо через ne делать имхо

Через Option(...)

Через Option(...)

+

разница скорости этих 2 вариантов -- даже не спичка, а пылинка

+1 к опшну)

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

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

дефолтный это Object.equals или сгенеренный для case class?

Ты меня застиг врасплох. У объекта по ссылке, у кейса по полям, если я не фейлю еще больше . Но все равно же не должено быть разницы?

Ты меня застиг врасплох. У объекта по ссылке, у кейса по полям, если я не фейлю еще больше . Но все равно же не должено быть разницы?

кейс-класс всегда не равен null же

какую проблему решаешь? (ц)

Ты меня застиг врасплох. У объекта по ссылке, у кейса по полям, если я не фейлю еще больше . Но все равно же не должено быть разницы?

Ты пытаешься найти поддержку в чате, чтобы оправдаться в пулреквесте?

@odomontois глянь лс

кейс-класс всегда не равен null же

11th commandment?

Thou shall not nullify case classes ?

за обнуление в коде и убить можно

Ты пытаешься найти поддержку в чате, чтобы оправдаться в пулреквесте?

нет :( я чиню чужой код. Смотрю в него и мне как-то неуютно

Например, там есть object A { @volatile var e: A = _ } и ниже trait A { if (A.instance ne null) { LOG.error("A is already initialized!") } A.instance = this }

и у меня течет крыша.

вот эт ничего себе паттерны проектирования

за обнуление в коде и убить можно

KMP https://scastie.scala-lang.org/Odomontois/FHVehheLSV2O4BPwXmJ0pg

У меня теперь 7 дней или что там?

Олег, я не к тому что это невозможно, а к тому что человек, допускающий такую небезопасную реализацию в коде - не друг проекту и каждому программисту лично

@odomontois в отрывке выше ты видишь рациональное зерно? Я на него уже полчаса смотрю и не укладывается.

@odomontois в отрывке выше ты видишь рациональное зерно? Я на него уже полчаса смотрю и не укладывается.

Вижу. Имплементер - жавист

Погоди ....

Это у него такой lazy val из 90-х

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

ага

так ведь все равно утекает полусозданный объект

и у меня течет крыша.

м, ну ясно, что вызов null.equals сломается, и поэтому там ne сделай lazy val

потому и проверка

volatile не гарантирует же, что оно создастся...

именно