А есть какие-нибудь годные cheatsheet по спарку и/или плею?

https://www.gitbook.com/book/jaceklaskowski/mastering-apache-spark/details правда там чуть-чуть много

/toxic

/toxic

/toxic

/verytoxic

чё сразу токсик-то

Я тут внезапно в мск заехал. Ни кто не хочет небольшую скалапойку устроить?

Я бы с удовольствием, но блин болею...

/toxic

да не умеет бот еще это делать, Даниил же говорил вроде

я думаю все просто тыкают на команду, и она постится. Сомнительное UX решение канеш.

/toxic

/shrug

В Италии что-то знают :)

что то? мне кажется вполне конкретное знают, например, итальянский язык =)

туалет типа Лестница

Why so serious? )

в Германии у меня был точно такой же!

это не в котлин ресторане?

коресторан

Reactive Sink implementation for scala

/toxic

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

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

бота, который будет меншн Олега делать

гифку с бритни

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

в личку

Какие вы скучные. Поеду домой.

уже уехал? Oo

уже уехал? Oo

Ну вот сижу в паровозе.

Ну вот сижу в паровозе.

шож ты такой внезапный

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

блин :( как-то некогда было проверить скала-чатик

блин :( как-то некогда было проверить скала-чатик

Теперь проверяй чаще!

@fomkin ты когда в мск перезжаешь?

а наврен интернета нету уж укатил за час в дали

@fomkin ты когда в мск перезжаешь?

Пока не собираюсь :)

форы однозначно мапятся на мат-флатмап-фильтр каста там нет, если очень надо, оно эмулируется через имплисит класс

filterWith

Я тут внезапно в мск заехал. Ни кто не хочет небольшую скалапойку устроить?

я хочу

Не сталкивался кто с таким склайкеджбс (2.10) package macros contains object and package with same name: blackbox

.ivy2\cache\org.scalikejdbc\scalikejdbc-interpolation_2.10\jars\scalikejdbc-interpolation_2.10-2.5.2.jar(scalikejdbc/SQLSynt axSupportFeature.class)' is broken [error] (class java.lang.RuntimeException/error reading Scala signature of SQLSyntaxSupportFeature.class: package macros contains object and package with same name: blackbox

@krivdaallstarts попробуй флаг -Yresolve-term-conflict ?

/toxic

Сорри)

Чат, подскажи. Пытаюсь разобраться с akka-persistence и CQRS подходом на примере простого сервиса управления пользователями. Примерно так я себе представляю реализацию: https://pastebin.com/bdwSKiuf

насколько это правильно\неправильно?

Чат, подскажи. Пытаюсь разобраться с akka-persistence и CQRS подходом на примере простого сервиса управления пользователями. Примерно так я себе представляю реализацию: https://pastebin.com/bdwSKiuf

не скомпилилось

Эххх...

А че компилятор пишет?

/toxic

@krivdaallstarts попробуй флаг -Yresolve-term-conflict ?

scalacOptions ++= Seq("-Yresolve-term-conflict:package") собрало, спасибо

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

лол

@krivdaallstarts попробуй флаг -Yresolve-term-conflict ?

но не работает)

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

нормальный пример - вполне реализуемый на cqrs эвенчуал консистенси здесь не причем - агрегат держит состояние о существующих логинах и консистентно проверяет уникальность я правда не очень понял про UserCommandProcessor: - это отдельный актор такой? на самом деле лучше создавать агрегаты именно по консистетной области - тоесть для регистрации лучше создать какого нибудь UserRegistrator который будет знать что есть пользователи и у них есть логины

лучше я думаю на это ответит @notxcain - но сюда по унитазу он в италии сейчас))

нормальный пример - вполне реализуемый на cqrs эвенчуал консистенси здесь не причем - агрегат держит состояние о существующих логинах и консистентно проверяет уникальность я правда не очень понял про UserCommandProcessor: - это отдельный актор такой? на самом деле лучше создавать агрегаты именно по консистетной области - тоесть для регистрации лучше создать какого нибудь UserRegistrator который будет знать что есть пользователи и у них есть логины

Да, все так

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

А держать их id в памяти не очень

ну шарды, консистент хэшинг и вперед

А держать их id в памяти не очень

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

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

сорри не оч понял - я же говорю можно всегда сделать шардирование по логину

Я бы вообще не стал делать это на акка персистенсе. Уж больно много головной боли будет.

Ок, спасибо!

сорри не оч понял - я же говорю можно всегда сделать шардирование по логину

итак вернёмся к консистентности В нашем вполне подходящем примере у нас есть шардированный "аггрегат" по логину шардированный "аггрегат" по имейлу шардированный "аггрегат" по каждому из социальных аккаунтов шардированный "аггрегат" авторизованных сессий Теперь кейз. Юзер сайнапится по аккаунту гитхаба. Шард гитхаба говорит, что это новый юзер, по oauth мы получаем имейл, просим ввести юзернейм и готовы к действию. Можно теперь описать беспроблемную реализацию строго-консистентного создания юзера, можно не стесняться раскрывать все нюансы двухфазных коммитов.

Можно заюзать сагу

И не мучатся с 2PC

Но конечно да, без event sourcing будет проще

Я теперь жалею, что проголосовал не за ES в гусёвом твиттере. Он бы вам показал, где акки зимуют

а нафиг ты за ES голосовал

тамж конкаренси был, явно интереснее)

итак вернёмся к консистентности В нашем вполне подходящем примере у нас есть шардированный "аггрегат" по логину шардированный "аггрегат" по имейлу шардированный "аггрегат" по каждому из социальных аккаунтов шардированный "аггрегат" авторизованных сессий Теперь кейз. Юзер сайнапится по аккаунту гитхаба. Шард гитхаба говорит, что это новый юзер, по oauth мы получаем имейл, просим ввести юзернейм и готовы к действию. Можно теперь описать беспроблемную реализацию строго-консистентного создания юзера, можно не стесняться раскрывать все нюансы двухфазных коммитов.

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

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

а нафиг ты за ES голосовал

я за дистрибьютед компьютинг

Олег долго печатает мне страшно...

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

ещё раз. У нас есть X независимых состояний, уникальность и доступность которых необходимо поддерживать. И множество операций задевающие несколько из этих состояний одновременно. Как проектировать данные в кассандре я знаю, но вот как взять идею легковесных транзакций оттуда и притащить в вашу акку добившись, подчёркиваю, стронг консистенси, имея возможность добавлять в эти сети состояний без перезапуска кластера новые, и не зафакапившись ни в одном месте, учитывая, что IT к такой системе будет эквивалентент рандомизированному нагрузочному тестированию и всё равно хрен что гарантирует

не знаю

Вот добрый человек рассказал про сагу

Читаю

не, сага это это и есть распределенная транзакция

это не стронг консистенси

за акку не топлю) говорим про cqrs/es и аггрегаты(я тоже на автомате с двумя г написал))) cqrs/es не золотой молоток - не все ситуации с помощью него можно легко и просто решить - особенно сложно жить с миграциями(если события наперсистил плохо) > ещё раз. У нас есть X независимых... разговор про то что не надо делать x независимых состояний и множество операций задевающие несколько из этих состояний одновременно. в приведенном примере про пользователей АгрегатИмейлов и АгрегатИмейловЛогиновГитхаб - не должны быть связаны тогда проблема занял имейл в одном агрегате а в другом не занял - значит отдаем это на откуп UX и ивенчуал консистенси разрешает уже сам пользователь

за акку не топлю) говорим про cqrs/es и аггрегаты(я тоже на автомате с двумя г написал))) cqrs/es не золотой молоток - не все ситуации с помощью него можно легко и просто решить - особенно сложно жить с миграциями(если события наперсистил плохо) > ещё раз. У нас есть X независимых... разговор про то что не надо делать x независимых состояний и множество операций задевающие несколько из этих состояний одновременно. в приведенном примере про пользователей АгрегатИмейлов и АгрегатИмейловЛогиновГитхаб - не должны быть связаны тогда проблема занял имейл в одном агрегате а в другом не занял - значит отдаем это на откуп UX и ивенчуал консистенси разрешает уже сам пользователь

ну нельзя отдавать юзеров на откуп

ребят, объясните, заеч нужны объекты-компаньены? я вижу смысл только в том, что 1) объекты-компаньены упрощают создание синглтона, 2) разделение динамических и статических методов между классами и объектами-компаньенами. Что-то еще?

ребят, объясните, заеч нужны объекты-компаньены? я вижу смысл только в том, что 1) объекты-компаньены упрощают создание синглтона, 2) разделение динамических и статических методов между классами и объектами-компаньенами. Что-то еще?

самая няшка - имплисит скоуп

ещё раз. У нас есть X независимых состояний, уникальность и доступность которых необходимо поддерживать. И множество операций задевающие несколько из этих состояний одновременно. Как проектировать данные в кассандре я знаю, но вот как взять идею легковесных транзакций оттуда и притащить в вашу акку добившись, подчёркиваю, стронг консистенси, имея возможность добавлять в эти сети состояний без перезапуска кластера новые, и не зафакапившись ни в одном месте, учитывая, что IT к такой системе будет эквивалентент рандомизированному нагрузочному тестированию и всё равно хрен что гарантирует

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

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

но ведь запросы независимые

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