тогда уже реально проще дуби взять

там внутре эта самая фри манатка и есть

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

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

там внутре эта самая фри манатка и есть

самая модная монада этого сезона

любого =)

все ж любят корутины и интерпретаторы

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

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

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

те Н запросов разной сложности, дждбс и *любимая_стучалка_к_бд*

желательно, чтобы итоговый sql был примерно одинаковым, те смотреть только на прямой оверхед

Doobie параллельно собирается с cats и fs2

причём очень интересным образом реализована поддержка обоих ФП-библиотек. что-то в стиле Си-макросов

yax там препроцессор

технологии 70х

выглядит как-то так https://github.com/tpolecat/doobie/blob/series/0.3.x/yax/core/src/main/scala/doobie/hi/resultset.scala#L29-L45

А как это работает?

Господа, дамы, не забываем регаться на московский митап https://data-monsters.timepad.ru/event/manage/360185/

Че там в Киеве со Скала-митапами? Я бы пошел, да что-то не видать

а где список докладов?)

а где список докладов?)

Формируется.

видео же будет?

видео же будет?

Да.

А есть люди которые знают как сделать Work Pull на Akka stream ?

Sink.queue?

или паттер с мастер-актором и воркерами, которые будут просить работу

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

ну на стейдже можно сделать же

он вроде для того и нужен

Стейдж?

PushPullStage вот это всё

ваще как сделать не Work Pulling я не понял

там же бэкпрешша

это ж и значит ворк пулл -_-

А чем Sink - очередь не устраивает?

меня ничем, мне хоть как :)

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

звучит обычно для акка стримс -_-

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

А можно пример, вот задача, есть Array[Item], нужно что бы первые N Item обрабатывались по 10 Item за заход, а потом по 1

я возможно не понимаю чего-то очень корневого в том как строить эти акка стримы

пусть оттуда читает PushPullStage, который и следит за этим. Сначала по 10 тащит, потом по 1

Стоит прочитать документацию от и до

вот за это я люблю рускоговорящее комьюнити :)

За посыл в документацию?

а где-то бывает по-другому?

smart question на многих языках написано

http://www.catb.org/esr/faqs/smart-questions.html

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

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

Проблемы и задачи решались бы быстрее

люди заходят на QA ресурсы, чтобы не читать

странное утверждение

люди заходят туда, чтобы спрашивать или отвечать

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

так-то QA по сути решает проблему прямой передачи опыта

а это нужно когда ты все свои собственные варианты решения испробовал

вот чтобы все случаи пользования QA были такими, люди должны иметь в голове smart questions или что-то подобное

должно быть уважение к чужим мозгам

А есть те кому не жалко пол часа в личку поотвечать на вопросы нуба по стримам?

А есть те кому не жалко пол часа в личку поотвечать на вопросы нуба по стримам?

Я б тоже послушал

А есть те кому не жалко пол часа в личку поотвечать на вопросы нуба по стримам?

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

ну и да, могу ответить на любые вопросы по стримам

Всем привет, народ, а можно пачку глупых вопросов? Меня можно просто послать что почитать :)

В общем как правильно разграничивать фронт и бэк? Бэкенду в принципе возможности фронта не нужны, он может работать сам по себе. Но - фронт может быть, и быть он может разным, как веб так и не веб, и если не веб - у меня еще какие то мысли есть, то с вебом - я почему то постоянно думаю в сторону брать данные из БД..., но там будут не все данные... и как быть?

> я почему то постоянно думаю в сторону брать данные из БД..., но там будут не все данные... и как быть? ничего не понял.

> я почему то постоянно думаю в сторону брать данные из БД..., но там будут не все данные... и как быть? ничего не понял.

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

ERROR: S client not available

Или я слишком всё усложняю?

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

Да

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

не у клиента, клиенту хочется спросить бэкенд что у него происходит

прогресс процесса? ну значит надо делать состояние с флагом этапа

это как самый примитивный вариант

не у клиента, клиенту хочется спросить бэкенд что у него происходит

значит у бакэнда должен быть метод: чтоУТебяПроисходит() который будет вызывать клиент когда ему, клиенту надо

прогресс процесса? ну значит надо делать состояние с флагом этапа

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

вот прям напрашивается CQRS

да. Event Sourcing точнее

значит у бакэнда должен быть метод: чтоУТебяПроисходит() который будет вызывать клиент когда ему, клиенту надо

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

нет ничего плохого в том чтобы писать состояние в постоянное хранилище

> клиент должен знать что вообще этот бэкенд есть ну как бы так всегда

…фронтенд как минимум откуда-то загрузился

или куда то подключается (если нативная аппликуха)

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

вебсокеты лишь транспорт, а тут архитектурный вопрос

> клиент должен знать что вообще этот бэкенд есть ну как бы так всегда

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

Как-то так запутано

Хотя фактически получается прослойка - БД - бэк - фронт(может быть не один)

я думаю тут вопрос всё-таки в транспорте

тогда как самый просто вариант - REST

вебсокеты использовать только если они реально нужны

ну хорошо, допустим, но тогда веб должен дергать другой веб получается? пусть и не только через get/post?

какой другой?

первый веб - это фронтенд?

да, первый - фронт

так все веб-приложения и работают

веб дёргает за веб

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

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