привет

ктонибудь вплотную работал с akka stream

насколько "вплотную"?

если есть вопрос, то просто задай его

кто-нибудь найдется

ну чтобы прям ух)

вопрос в следующем

я прравильно понял

fast source -> slow flow

это решается автоматически

то есть пока не будет отработан flow source не будет выдавать данные на flow

и корректно ли процессить на этапе flow - или это дело sink

пока flow не будет готов принять данные, source не будет их посылать

но всетаки flow это этап трансформации

где идеологически верно "процессить" в sink?

что значит процессить?

флоу тоже процессит

просто синк на выходе ничего не дает

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

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

тогда дальше тоже не пройдет ничего)

"процессить" - то есть выполянть какуето логику или сохранение

вообще sink то для чего нужен

у меня вся эта конфепция в голове немного перемешалась

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

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

в случае если мне нужно распаралелить source

например тот же map reduce ораганизваотть (шаг map)

mapAsync

даст мне паралельную обработку

напрмиер 10

mapAsync(10)

а ты читал раздел про параллели в доках? ))

я все читал

чтобы вкурить

она не настолька плоха, чтобы уж совсем от нее отказываться)

и кажется зря

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

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

хм - очень внятно объяснил

mapAsync - это просто преопределенная реализация внутреннго интерфейса, которая на вход принимают твою функцию, но обязательно такую - чтобы результат был Future[T] - и вот на выход этот узелочек просигнализирует только после того как футур выполнится и просигнализирует, что можно забрать на выходе T

тобишь это просто реализовали за тебя бойлерплейчик)

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

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

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

и вот все вместе - эти цепочечки, с подцепочечками - они там вроде это графом называют)

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

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

я бы сказал, что в 100%

Например мы искали что то и не нашли. Закэшировали результат "не найдено"

Если твердо знаем что и не появится

тогда и называть "не найдено" надо иначе

слишком легко спутать с дефолтным методом на apply

эм. если мапа типизированная - значит и дефолт валуе тоже должен быть этого же типа)

а делать кеш общего типа Any - как-то странно)

так тип есть

а если не делать - то всегда можно и так по пути опшина пойти - сделать object от этого типа (аналог None) - но в целом это конечно и будет похоже на Map[Option[T]]

или был бы Option[Any]

тогда и называть "не найдено" надо иначе

Завести свой Maybe?

но с Map[Option[T]] - все равно есть проблема если нет дефолт валуе)

и так и так - от задачи как всегда прыгать надо)

Завести свой Maybe?

это как не maybe есть результат "ничего не нашлось"

а вдруг там еще ситуация, что пока мы что-то делали - для ключа что-то может появиться - чего раньше не было)

ну дело вкуса, в общем)

это как не maybe есть результат "ничего не нашлось"

Да. Результат = нашли None. Но в целом да, разницы особой нет. Просто use case для такого типа данных привел

Mikhail спасибо! немного прояснил ситуацию в голове

коллеги кто кверит SOQL - какие юзаете библиотеки / писали сами?

ERROR: S client not available

вот чел пошел в интересном направление http://developers.redhat.com/blog/2015/06/11/type-safe-salesforce-queries-soql-in-scala/

но как то не доделал, а за шейплесс братся страшно пока

Посоны. Чо там Ибрахим с зарплатой в Дубае говорил? 80к мидлу + бонусы будут? Может, свалить к арабам @ принять ислам.

но зачем? ©

Иди в армию, говорили они, увидишь мир.

говорили они

Посоны. Чо там Ибрахим с зарплатой в Дубае говорил? 80к мидлу + бонусы будут? Может, свалить к арабам @ принять ислам.

Дома ток не взрывай

Дома ток не взрывай

Да это если бы я в фсб пошел...

Посоны. Чо там Ибрахим с зарплатой в Дубае говорил? 80к мидлу + бонусы будут? Может, свалить к арабам @ принять ислам.

Иди кароч, расскажешь, потом я к вам пойду

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

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

Видимо нужно все-таки что-то взорвать

Да это если бы я в фсб пошел...

?

Кто знает можно в SBT из теста убрать некоторые зависимости основного проекта?

Хм, я знаю как добавить, а вот как убрать...

эксклуд в тестовой зависимости?

нет в основной

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

libraryDependencies in run так можно писать еще

Коллеги, а как проще всего в Play ограничение на кол-во запросов по конкретному action запилить? Мне в голову приходит завести статичную переменную и через synchronize проверять/инкрементить её. Но хз, может есть лучший способ

лучший способ на nginx

или тут бизнес логика?

или просто rate limit?

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

в каком разрезе даже я бы сказал )

Я применял вот такую штуку. https://github.com/inoio/play-requests-limiter Оно контролирует, чтобы количество _одновременных_ запросов не превышало определенное число, а все остальное ставит в очередь. В nginx описанное выше сделать невозможно, там на эту тему только достаточно топорные решения.

ну очередь тоже не всем нужна

Там это легко регулируется

подойдет, если что-то типа надо ограничить запросы per userId?

> Alexandr В nginx описанное выше сделать невозможно, там на эту тему только достаточно топорные решения. http://nginx.org/ru/docs/http/ngx_http_upstream_module.html

max_conns

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