Ну точнее может и не слабо, но нужно убить еще времени, а его чет не совсем есть

Если у вас получится, поделитесь

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

Всем привет. Задам идиотский вопрос, но то ли я туплю, то ли.. В "Learning Concurrent Programming in Scala" Прокопец пишет, что compareAndSet() "из коробки", концептуально эквивалентен: def compareAndSet(ov: Long, nv: Long): Boolean = this.synchronized { if (this.get == ov) false else { this.set(nv) true } } Разве не "!=" должен быть в условии?

там все правильно

Други, вопрос тем кто разбирается в sbt. Использую sbt.Init.Initialize.mapReferenced. Он объявлен deprecated. А что использовать вместо него чтобы управлять скоупом зависимых сеттингсов/тасок?

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

сплошные колбеки

for немного спасает

Други, вопрос тем кто разбирается в sbt. Использую sbt.Init.Initialize.mapReferenced. Он объявлен deprecated. А что использовать вместо него чтобы управлять скоупом зависимых сеттингсов/тасок?

Сделать автоплагин?

Как это поможет?

Это поможет управлять скоупом зависимых сеттингсов/тасок

В плагине будет свой скоуп, свои таски и сеттинги

на текущий момент это рекомендуемый в сбт подход

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

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

А если метод возвращает еще какой-нибудь Future[Option[Set[MySuperModel]]] так вообще "волшебно"( Народ, как вы работаете с Future ?

Проблема не в том куда разложить таски и сеттинги. Проблема в том, что нужна функциональность mapReferenced. Но она deprecated. Вопрос в том - что использовать вместо нее.

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

а если у меня API такое, что оно все буквально на них...

@l3h3r Изначально какая стоит задача? Сделать отдельный скоуп?

https://github.com/sbt/sbt/issues/2234 Я насколько понимаю, в сбт просто не хотят наружу тащить кишки, и потихоньку всё закрывают

типа, используйте ребята := и .value макрос, и всё

А если метод возвращает еще какой-нибудь Future[Option[Set[MySuperModel]]] так вообще "волшебно"( Народ, как вы работаете с Future ?

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

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

Чтобы не писать в таске someSetting.all(...).value, а просто использовать someSetting.value

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

Какие стримы посоветуешь? scalaz тянуть не хочется в проект.

я пока только акковские пробовал некоторым monix нравится

типа, используйте ребята := и .value макрос, и всё

В том то и дело что .value нельзя :)

отлично...akka уже есть, возьму их.

@l3h3r А в гиттере сбт не спрашивал? Там как раз недавно чувак, который создал эту задачу, что-то обсуждал.

может он таки нашел, как это обойти

отлично...akka уже есть, возьму их.

http://doc.akka.io/docs/akka/2.4/scala/stream/stream-parallelism.html возможно это стоит прочесть, чтобы понять какпроцессы строить

В подкасте обсуждали что в чатике есть клевый гуру сбт :) mapReferenced пока работает. Как закроют я думаю предложат решение.

Возможно, @arzfreezy что-то знает

http://doc.akka.io/docs/akka/2.4/scala/stream/stream-parallelism.html возможно это стоит прочесть, чтобы понять какпроцессы строить

спасиб)

спасиб)

А еще вы можете подумать о отказе от возвращения Future[Option[T]] и в случае если элементов нет у вас будет варианта, в случае запроса на Seq[T] пустая коллекция, а в вместо None, можно выбрасывать, например, Entity Not Foud, тогда вы сможете достаточно элегантно строить свой код на Future внутри for блоков

Хм, что-то мне не кажется это элегантным. со стримами работал, это близко к Rx и мне кажется это более элегантным)

Я не одобряю кастомные бизнес исключения в Failure. Фейл должен быть фейлом :)

Лестница из map/flatMap и ступеньки из case match на каждый Option?

Я не одобряю кастомные бизнес исключения в Failure. Фейл должен быть фейлом :)

А аргументы? :)

Аргумент простой - Future вызова, но не бизнеса. Проблемы могут встретится например, при организации повторов при фейле Future

Лестница из map/flatMap и ступеньки из case match на каждый Option?

да, именно такая ситуация...

*абстракция

Если у вас запрос который может не вернуть ничего, то зачем на вызываемой стороне кидать исключение не понятно. Нужно вернуть правду - Future[Option[T]]

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

Если бы в одном For можно было распаковать Future и Option, я бы с вами согласился

да, это было бы замечательно

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

option внутри for-comprehension можно расматчить обычно

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

кстати, да, в своём первом же пет-проекте столкнулся с этим callback-месивом, решил всё-таки None в Failure мапить, в ином случае приходилось бы весь этот монадный зоопарк протаскивать по стеку

да это вообще жесть, если бы все было просто с Future + Option

Отслеживать доменные исключения сложно, их нет в сигнатуре future. Блоки с recover выглядят не лучше. По мне, как раз отказ от option в таких кейсах — прямая дорога в ад

ну что бы угар был угарнее можно вот так возвращать Future[Either[String, T]] и тогда с 90% вероятностью вы очень устанете с таким жить

Не надо в крайности уходить

Тем более, что either сам по себе неудобен

Я не спорю, даже если взять \/ вметос Either легче не станет :) но в целом я такое видел, и жить с этим очень сложно

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

В сигнатуре Option тоже нет информации о том, почему результат вычислений - None, если этот Option через пару тройку FlatMap'ов прошёл, то у тебя в принципе не остаётся возможности написать какую-либо вменяемую recover-логику. Тут Either выглядит предпочтительнее, но, опять-таки в ходе вычислений разные проблемы могут случится, в сигнатуре тоже всего не отразишь.

соглашусь, поэтому если вы переживаете что можно что-то забыть - пейшите тесты

Либо checked exceptions ?

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

это None

it seems to me, recover логика в этом чатике - это как священная корова. Не пойму почему это так важно. На джавушке всю жизнь писали без всяких 'recover' и всё было просто и понятно. Тут же я сомневаюсь что в большинстве случаев стоит дообрабатывать запрос если что-то раком встало, мне кажется это реально сложнее, чем просто выдать ошибку, и начать вообще всё заново

То что данных нет, часто может быть исключительной ситуацией - у вас API и юзер хочет то чего нет, это и есть исключение

В сигнатуре Option тоже нет информации о том, почему результат вычислений - None, если этот Option через пару тройку FlatMap'ов прошёл, то у тебя в принципе не остаётся возможности написать какую-либо вменяемую recover-логику. Тут Either выглядит предпочтительнее, но, опять-таки в ходе вычислений разные проблемы могут случится, в сигнатуре тоже всего не отразишь.

дело в том, что мы не говорим о кейсе, когда failure превращается в none, поэтому и в сигнатуре нам ничего не нужно

it seems to me, recover логика в этом чатике - это как священная корова. Не пойму почему это так важно. На джавушке всю жизнь писали без всяких 'recover' и всё было просто и понятно. Тут же я сомневаюсь что в большинстве случаев стоит дообрабатывать запрос если что-то раком встало, мне кажется это реально сложнее, чем просто выдать ошибку, и начать вообще всё заново

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

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

А как стримы помогут?

ERROR: S client not available

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

Ну за транзакцию 6 раз не будет данных, все 6 кейсов по спецификации вашего API мапятся в разные HTTP-ответы, ну и как с одним безмолвным None что-то понять?

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

Ну за транзакцию 6 раз не будет данных, все 6 кейсов по спецификации вашего API мапятся в разные HTTP-ответы, ну и как с одним безмолвным None что-то понять?

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

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

невозможности по техническим причинам

Насколько я знаю, в scala нет return и не принято бросать исключения через throw, потому и Failure

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

Известный мне подход - DomainException[A], где A - тип штатной для бизнес-логики ошибки.

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

Так изначально же обсуждение пошло именно с ситуации, когда тебе нужно по всему стеку таскать связку Future-option, когда её можно упростить до одного Future

В общем пока решением своей проблемы вижу: "укрупнение" футур и уменьшение использования контейнерных типов ))

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

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

Вот я тоже сейчас к этой мысли склоняюсь.

Вопрос: можно ли как-то изъе...ртнуться и сделать так чтобы с @tailrec скомпилировалось? @tailrec def bubbleSimple(source: Seq[Int]): Seq[Int] = { println(s"Sort: $source") source match { case current :: next :: tail if current < next => current +: bubbleSimple(next :: tail) case current :: next :: tail if current > next => bubbleSimple(next +: bubbleSimple(current :: tail)) case current :: Nil => source } }

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

Это все хорошо, но если вы зачем-то решаете брать Slick для похода в базу, вы тут же получаете сложный код из Future

Потому что поход в базу асинхронный? :)

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

Это все хорошо, но если вы зачем-то решаете брать Slick для похода в базу, вы тут же получаете сложный код из Future

Да, кстати. А почему так скептически в сторону слик отзываетесь?

ну и остается вариант лифтить композицию функций

Вопрос: можно ли как-то изъе...ртнуться и сделать так чтобы с @tailrec скомпилировалось? @tailrec def bubbleSimple(source: Seq[Int]): Seq[Int] = { println(s"Sort: $source") source match { case current :: next :: tail if current < next => current +: bubbleSimple(next :: tail) case current :: next :: tail if current > next => bubbleSimple(next +: bubbleSimple(current :: tail)) case current :: Nil => source } }

ИМХО не самое удачная идея реализовывать это в таком стиле.

а как он помогает вам с Future[Option[T]] ?

Уж лучше просто мутабельный массив и while.

он оставит для работы Option[T]

А изъебнуться можно.

Да, кстати. А почему так скептически в сторону слик отзываетесь?

ИМХО, как я уже тут писал, слик пытается заставить человека думать о SQL как о коллекциях используя filter map и так далее, но в реальности, как только нужно что-то сложнее простого селекта, вам надо идти читать отвратительную документацию слика что бы понять как вам изъебнуться. Еще огромным минусом я вижу что посмотреть в код почти невозможно из-за дикого месива implicit преобразований...

он оставит для работы Option[T]

Цепочка из двух трех зависимых походов в базу как будет написан? стрим внтури стрима? :)

yo dawg

I heard you like streams so we put a stream in you stream so you can stream while you’re streaming.

А изъебнуться можно.

Да я чисто во имя науки) понятно что обычный мутирующий лист круче в сто раз. Дык как можно, есть идеи?

Цепочка из двух трех зависимых походов в базу как будет написан? стрим внтури стрима? :)

Этот кусок я бы объединил цепочкой и засунул потом в mapAsync. Раз это слик, то jdbc и все равно там блокировки, переключение контеста погоды не сделает. Я со сликом давно не сталкивался, но разве в 3ьем не всунули стримы?

Да я чисто во имя науки) понятно что обычный мутирующий лист круче в сто раз. Дык как можно, есть идеи?

А какая тут наука? tailrec тот же цикл записанный рекурсиво. Вводи i, бери slice (что бы с двух сторон от i брать) и все будет иммутабельно и рекурсивно.

#offtop, подскажите, пожалуйста, какуюнибудь фундаментальную литературу по CQRS

field guide на ютюбе вполне достаточно