Начну с них, потом, наверно курс возьму на корусере, спасибо)

кто-нибудь писал кастомный GraphStage[SourceShape[]], который бы постоянно забирал элементы из какого-то хранилища?

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

https://www.infoq.com/presentations/etl-streams

Николай: вроде бы никак. Делаешь вторым элементом после источника стандартный буфер. Он сосёт из источника, пока буфер не наполнится. Если буфер пустой, сообщение сразу идёт дальше

https://scalafiddle.io/sf/QqgYVZs/1

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

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

сделай тредик)

м?

thread

иии?

вобщем. в твоем варианте что конкретно тебе не нравится? ты можешь там вместо isEmpty проверять size < N и у тебя и так уже есть тредик(за счет асинка). просто помечай, что уже есть запрос и не запускай параллельно еще один гет-батч

ну и деливер соответственно не всегда требуется

ты просто можешь это сделать через обертку и спрятать бойлер плейт

тогда аут-хендлере у тебя все станет няшно и феншуйно

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

https://scalafiddle.io/sf/QqgYVZs/4

не знаю, так вот можно…

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

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

так пушка же как раз это и делает? или нет?

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

так пушка же как раз это и делает? или нет?

Ты немного неправильно рассуждаешь. Тебе не обязательно прописывать мета информацию в классах. Это одна из фич пушки. Веб сокеты - просто транспорт. У тебя по этому транспорту туда сюда что-то ходит. Так как ты контролируешь и сервер и клиент, то они оба знают, в каком случае какой тип куда придет или уйдет. Например, ты спросил сервер - эй, дай мне юзера, и например, передал айди запроса. Потом ждёшь и слушаешь сокет. Пришел ответ с твоим айди - значит там юзер. Все, ты можешь сделать read[User]

Ты немного неправильно рассуждаешь. Тебе не обязательно прописывать мета информацию в классах. Это одна из фич пушки. Веб сокеты - просто транспорт. У тебя по этому транспорту туда сюда что-то ходит. Так как ты контролируешь и сервер и клиент, то они оба знают, в каком случае какой тип куда придет или уйдет. Например, ты спросил сервер - эй, дай мне юзера, и например, передал айди запроса. Потом ждёшь и слушаешь сокет. Пришел ответ с твоим айди - значит там юзер. Все, ты можешь сделать read[User]

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

Передавай requestId, так точно не ошибешься

Сервер ответит чем-то с другим айди - ну значит это что-то другое

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

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

Про это же даже пункт в доке есть

Передавай requestId, так точно не ошибешься

И создавать тонны колбеков? на каждый запрос )))

Юрий подскажи название, что-то я видимо слеп

И создавать тонны колбеков? на каждый запрос )))

Достаточно просто слой абстракции сделать. Снаружи будет просто def getUser(id: UserId): Future[User]

Достаточно просто слой абстракции сделать. Снаружи будет просто def getUser(id: UserId): Future[User]

А что делать, если сервер захочет сам послать любое сообщение?

Юрий подскажи название, что-то я видимо слеп

https://www.playframework.com/documentation/2.5.x/ScalaFunctionalTestingWithScalaTest

А что делать, если сервер захочет сам послать любое сообщение?

Что значит любое?

Именно это и означает. Любое сообщение без запроса с клиента

Тут скала вообще никак не повлияет. Вот пишешь ты клиента на js. Слушаешь сокет. Пришел непонятный меседж. Что делать будешь?

вы про сервер и клиент на scala?

Сам язык не повлияет, а нормальная библиотека сериализации еще как повлияет. Например в upickle, можно определить type сообщения. И не надо строить абстракцию с костылями для определения типа.

upickle работает и на клиенте и на сервере

Не понял, о каких костылях речь?

Не понял, о каких костылях речь?

о сохранении requestId для определения типа пришедшего сообщения. Это очевидный костыль

Это не костыль, это нормальное решение. Как upickle решит проблему двух однотипных ответов? Вот сделал ты два раза подряд getUser. Что делать?

Это не костыль, это нормальное решение. Как upickle решит проблему двух однотипных ответов? Вот сделал ты два раза подряд getUser. Что делать?

Это не проблема библиотеки сериализации, а бизнес логики

в случае запрос-ответ - ориентироваться на requestId нормально. если сервер пушит данные на клиент - понятное дело что нужна метаинформация

Лол, это все проблемы одного слоя - слоя доступа к серверу

Что делать? а тут вариантов миллион. Все зависит от требований. И это не может решать библиотека сериализации

Ну то есть пришли к тому, что upickle таки не решает проблему в общем случае

Ну то есть пришли к тому, что upickle таки не решает проблему в общем случае

Пришли к тому, что вы смешиваете все в одну кучу. Рассказываете как с помощью пушки определить какое сообщение придет через requestID. Я указал как в другой, более удобной библиотеке это сделать без костылей в виде requestID. Вы тут же начли рассказывать про проблемы слоя доступа... где логика Билли?

Сериализация сообщения != слой доступа к серверу

Это разные проблемы и решать их надо по разному

К слову, умение библиотеки сериализации самостоятельно определять тип сообщения. Не противоричит наличию requestID в слое доступа

Я вообще отвечал на вопрос выше, подходит ли пушка для случая, когда сервер пушит сообщения. Мой ответ - да подходит.

Вот. Подходит, но с неудобствами в виде неумения самой пушки понять, какое сообщение ей надо десериализовать. юпикл это умеет

К слову, умение библиотеки сериализации самостоятельно определять тип сообщения. Не противоричит наличию requestID в слое доступа

Это естественно есть в пушке, причем без меты. Там в доке есть пример с ьрейтом

Вот. Подходит, но с неудобствами в виде неумения самой пушки понять, какое сообщение ей надо десериализовать. юпикл это умеет

upickle определяет типы при чтении точно также, как и пушка.

upickle определяет типы при чтении точно также, как и пушка.

А зачем вы тогда учите человека определять тип через requestID ? О_о

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

Понятно, но это частный случай конечно

Ну без этого не обойтись для полноценной работы

Всем привет, подскажите метод который находит подстроку в строке пожалуйста!

в смысле находит?

индекс вхождения или просто типа есть или нет?

есть или нет

как много методов в StringOps...

string1.contains(string2)

string1.contains(string2)

благодарю

ERROR: S client not available

утром фримонады, вечером контэйнс =)

Вечерний контэйнс)

Это же хорошо, что тут есть как entry-level, так и задроты

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

почему недостаточно? берем и решаем что отправлять будем используя JSON подобной структуры: { "type":"example", "data": { .... } } Дальше просто проверяем что находится в type и на основе этого уже проводим десериализацию.... Или можо проще и без этой обертки?

Ну, я бы так и сделал

http://paste.debian.net/902043/

почему такое может не работать?

http://doc.akka.io/docs/akka/2.4.11/scala/testing.html#Using_Multiple_Probe_Actors

вроде сделал все как в примерах в документации

какая красота пополнять динамический массив : mArray.+= моиДействия; Прям ваще ненарадуюсь.... Слышал о манадах, говорят буду в восторге от них ?

>.+= нет, только fold иначе забанят

? ну вот....

можно без точки

можно без точки

это стеб над новичком? ?

выше сказали только fold ?

это стеб над новичком? ?

смотри в глаза. var используешь?

да

все, зобаним точно

ой да лдно вам.... я еще в дошколятах в scala.....

ой да лдно вам.... я еще в дошколятах в scala.....

проходи одерского на coursera

окЪ

смотри в глаза. var используешь?

это можно сделать без var? protected[this] var users: HashSet[ActorRef] = HashSet.empty[ActorRef] ... override def receive: Receive = LoggingReceive { case Create(id, out, rh) => val child: ActorRef = injectedChild(childFactory(out, rh), s"userActor-$id") users = users + child sender() ! child

это можно сделать без var? protected[this] var users: HashSet[ActorRef] = HashSet.empty[ActorRef] ... override def receive: Receive = LoggingReceive { case Create(id, out, rh) => val child: ActorRef = injectedChild(childFactory(out, rh), s"userActor-$id") users = users + child sender() ! child

все, что угодно, можно сделать без var

все, что угодно, можно сделать без var

как?

все, что угодно, можно сделать без var

И даже fold?

Можно через context.become

Почитай в доке

как?

я не знаю конкретно про твой пример, но в куче языков нету var вообще

Почитай в доке

щас гляну

и все можно сделать без него, в scala и подавно

и все можно сделать без него, в scala и подавно

но...как же...стдлибная реализация foldLeft...

но...как же...стдлибная реализация foldLeft...

а что в нем var? acc?