не чаще трех раз в неделю?

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

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

Я тоже так сначала подумал, поэтому начал ковырять ask + pipe Но оказалось что нет и все прекрасно можно сделать на сообщениях между акторами, просто передаем больше параметров, делаем сообщения более самостоятельными как бы выносим state в них

Нет, изначально я просто уточнил, что реакция на футурку не есть часть акторов. Просто маленькое уточнение, а не противоречие. А потом ты писал всякие забавные вещи, но джунам можно)

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

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

Сейчас делаю через req resp, напишу с чем столкнуля когда закончу

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

напрашивается идея для плагина к... идее

Сейчас делаю через req resp, напишу с чем столкнуля когда закончу

Расскажи лучше какую проблему ты решаешь? Типа залогинить юзера?

Tell это истинно акторный подход, он и по remote работает и вобще в этом идея акторов. А ask как уже заметили это не про акторы и нада использовать его редко, когда невозможно/неудобно делать req resp через сообщения

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

@CapDev ты вообще сколько уже опыта имеешь с аккой?

в slick 3.2.0 вместро (foo, bar) <> (FooBar.tupled, FooBar.unapply) можно писать (foo, bar).mapTo[FooBar]

наконец то)

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

он все так же доступен

ну я саркастически написал) лучше бы убрали его

и даже (FooBar.apply _).tupled не нужен будет если companion-object определен?

и даже (FooBar.apply _).tupled не нужен будет если companion-object определен?

не знаю, нужно попробовать

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

только список коммитов с ссылками на них

ну я саркастически написал) лучше бы убрали его

не скажи. иногда нужно явно передать функции конвертации

Кто знает как с телефона нормально смотреть это https://scalafiddle.io/sf/aMU66L4/1 ?? Там код по 1 символу читать приходится, а я не машина тьюринга

Может кто-нибудь помочь и в личку кинуть текст кода оттуда?

Спасибо Николай!

одинарные линии это tell двойные это обращения к TypedActor

Избавляюсь от TypedActor

Sessions это хранилище инфы игрока а Storage работает с базой

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

@CapDev ты вообще сколько уже опыта имеешь с аккой?

полгода

А как ты планируешь Sessions scalability?

Ты там один прогер чтоле? Этот проект работа или хобби?

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

Хобби переросшее в работу Да я тоже к этому пришёл сейчас делаю Sessions и Storage на сообщениях без асков и футур

А как ты планируешь Sessions scalability?

к ней запросы не часты, во время логина пользователя и после боя (который идёт минут 10) основной поток идёт от PacketLogic в GamesMan и к многочисленным game (50к на ноду) Когда sessions будет узким местом видимо вынесу её на отдельную ноду вместе со Storage и базой

А эти game - они шардятся? У них есть состояние? Персистишь куда-то?

пока не шардятся, нет такой нагрузки (50к игр это нагруз тестирование), реально пока 1к (игра вышла в бета тест пару недель назад) Но будут шардится т.к. основная нагрузка на них Game внутри это игровая логика , ходы по очереди, построенная на scheduler ах без персистентности

а что именно построено на шедулерах?

таймаут хода?

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

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

а что именно построено на шедулерах?

Да, переключение хода, таймауты что не кастанул ничего и т.д.

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

а чем это лучше чем Req Resp сообщения ?

Про сохранение результатов после боя - это больше ответственность game - а если хочешь какую-то статистику по игроку обновить - то тут я бы строил аля ream model from game's journal (с сохранением оффсета), иначе у тебя игра будет заниматься обеспечением гарантийной доставки результатов самой себя

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

Ну это конечно если у тебя игра что-то вообще персистит

Про сохранение результатов после боя - это больше ответственность game - а если хочешь какую-то статистику по игроку обновить - то тут я бы строил аля ream model from game's journal (с сохранением оффсета), иначе у тебя игра будет заниматься обеспечением гарантийной доставки результатов самой себя

game результат боя отсылает gameManager тот форвардидт в sessions , она обновляет у себя данные, и говорит Storage-у а он записывает в базу

Всем привет, я - новичок в скала, решил узнать у знатоков. Вопрос состоит в следующем - есть ли возможность работать с Google Guice следующим образом? def bindSomething[T]() : Unit = { bind[T].to[ServiceImplementation] }

Sessions единый источник данных в системе, а Storage единый писатель читатель базы

Про сохранение результатов после боя - это больше ответственность game - а если хочешь какую-то статистику по игроку обновить - то тут я бы строил аля ream model from game's journal (с сохранением оффсета), иначе у тебя игра будет заниматься обеспечением гарантийной доставки результатов самой себя

"то тут я бы строил аля ream model from game's journal (с сохранением оффсета), иначе у тебя игра будет заниматься обеспечением гарантийной доставки результатов самой себя" вот это не понял

Сам понял ошибку, вопрос исчерпан

game результат боя отсылает gameManager тот форвардидт в sessions , она обновляет у себя данные, и говорит Storage-у а он записывает в базу

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

"то тут я бы строил аля ream model from game's journal (с сохранением оффсета), иначе у тебя игра будет заниматься обеспечением гарантийной доставки результатов самой себя" вот это не понял

типа вот так http://doc.akka.io/docs/akka/current/scala/persistence-query.html#Resumable_projections

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

Почему это станет узким местом ? пересылка сообщения практически бесплатна а так бардак будет если все подряд будут обращаться к базе

Гарантия доставки в этом проекте не важна

обращайся к базе через один коннектор - это ок, но зачем же через сессии?

и вообще хорошая практика иметь разные repository/store для разных данных

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

ну вобще да результаты игры к сессиям не сильно относятся, хотя и увеличивают там победы поражения, т.е. сделать что бы gameManager к storage обращался ?

И storage разделить ? Чтоб потом по разным базам разнести при масштабировании ?

да пусть сама игра пишет в некий Store.save(gameResult): Future

зачем парента напрягать этой работой

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

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

ERROR: S client not available

хоть через некий сервис который будет сохранять результат игры и асинхронно обновлять статистику (тут нужно убедится что у тебя не будет дубликатных запросов, либо посылать сообщение at-most-once/fire&forget/tell либо если есть перепосылка то с принимающей стороны где у тебя статистика меняется нужно обеспечить идемпотентность)

тут можно еще на будущее, если понадобится, подумать о backpressure - и если надо прикрутить akka-streams например, ну или чем тебе удобнее тротлить

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

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

Это плохо когда такие связи через голову, запутаться легко когда система разрастётся

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

"так у тебя игра это актор и типа есть гарантия что только один актор для одной игры в один момент времени работает? akka sharding?" Да gamesManager создаёт игры и форвардит им меседжи. claster sharding имеется ввиду ? Ещё не делал кластер (нагрузки не те), только разбираюсь с Кластером

кстати, а кто как с докером работает?

docker-compose, rancher ):

в скалалазе Женя говорил о его опыте с деплоем контейнеров помнится

мезоса много тогда было

кстати, а кто как с докером работает?

руками или головой?

руками или головой?

оба варианта рассмотрим)

@fundamentalparticle а насколько красиво jrebel.jar ложить в docker image?)

@fundamentalparticle а насколько красиво jrebel.jar ложить в docker image?)

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

вообще можно через compose конечно сунуть)

@fundamentalparticle а насколько красиво jrebel.jar ложить в docker image?)

ложить не очень, попробуй класть

ложить не очень, попробуй класть

накладывать

наложивать

наложивать

однопокладено, в пятницу можно все)

присунуть

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

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

домашку долго делать, а меседжи бесплатные Зато чётко понятно game ни с кем кроме gamesMan не взаимодействует ! С ростом системы это окупится сторицей.

иерархия !

Всем привет. Собрал в одном месте все чаты для программистов - @Chats_Developers, пользуйтесь на здоровье. Ваш чат у нас тоже есть, не удаляйте это сообщение.

Всем привет. Собрал в одном месте все чаты для программистов - @Chats_Developers, пользуйтесь на здоровье. Ваш чат у нас тоже есть, не удаляйте это сообщение.

а чего без тегов то?

Всем привет! Заранее прошу прощения за длиннопост, но по ходу другой группы для общения на тему вакансий у нас нет. Требования: - Опыт разработки на Scala от года, опыт разработки от трёх лет. Используем Scala 2.12.x, ; - Опыт работы с БД. Используем Postgres через Slick, Elastic, Redis; - Devops-практики: kubernetes, docker, ansible, bamboo, akka; - Умение грамотно документировать код (поверьте, это важно), confluence; - Умение создать и поддерживать API для внешних интеграций; - Git (bitbucket), Jira Задачи: - Предстоит разрабатывать и поддерживать внутреннюю Customer Experience Management system, которая является основным инструментом для работы агентов по продаже недвижимости, и ее внешние части - сайты по продаже недвижимости jqestate.ru, rublevka.ru и другие. Условия работы: - Работа в офисе в центре Москвы; - Молодой коллектив (средний возраст сотрудников – 25 лет); - Возможность начинать рабочий день с 10 до 12; - Конкурентоспособная индексируемая заработная плата, в среднем от 150 тыс., обсуждается с кандидатом; Дополнительно: Напишите небольшой рассказ о себе и своих проектах, (особое внимание уделите тому, что делали вы) и приложите ссылку на GitHub. Если там ничего нет, то пришлите пример своего сложного и красивого кода, объясните почему он вам нравится. #job #work

Если кому-то интересно – пишите мне лично или на почту mail@ignat.co.uk

смысл писать CRM на скале?

а почему нет?

смысл писать CRM на скале?

почему бы и нет. не на PHP же