Comments 34
Таких введений полно, а отличие от титориалов, скажем, как сделать последовательность типа:
Ждем логина, ждем интернета, открываем базу, берем из базы список несинхронизированных данных, закачиваем их, закрываем базу.
Тонна подводных камней в стиле "если интернет моргнет 2 раза — мы загрузим несинхронизированные данные 2 раза?"
Или "как закрыть базу если от событий интернета у нас идет поток без onCompleted" и пр.
Когда закончу с циклом статей, обязательно напишу для вас подобный туториал :)
как сделать последовательность типа:
Ждем логина, ждем интернета, открываем базу, берем из базы список несинхронизированных данных, закачиваем их, закрываем базу.
А зачем такую «последовательность» вообще делать на Rx? Это же не поток событий, это обычный процесс.
логин это событие, статус интернета это вообще поток событий. Или вы все данные будете в одном потоке загружать?
Назовите пример "потока событий", а не обычного процесса.
что мешает просто выполнить их в фоне? ни один из описанных этапов не требует действий пользователя
Или вы все данные будете в одном потоке загружать?
В разных, но зачем мне для этого обязательно Rx?
Назовите пример «потока событий», а не обычного процесса.
Вы сам его назвали — изменение статуса подключения к интернету. Еще типовые примеры — нажатия клавиш клавиатуры, биржевые ставки и так далее.
Да в общем-то низачем. RX он даже не про асинхронность, а про chaining — это способ консистентно и декларативно описать разнородную последовательность операций. Когда у тебя поток шлет лишь один value — это превращается в обычную future.
Иметь консистентный способ проводить преобразования этих самых фьюч и не заботиться о том, моментальная эта операция или растянутая во времени, синхронная или асинхронная.
Концепция биндинга экономит много времени на кофе и комментарии на хабре :-)
А достигнуть сходного качества организации кода можно и без RX.
В чем плюс RX в этом смысле — что когда появятся более настоящие RX задачи — они в строятся в остальной код таким образом, что никто этого и не заметит
Иметь консистентный способ проводить преобразования этих самых фьюч и не заботиться о том, моментальная эта операция или растянутая во времени, синхронная или асинхронная.
Концепция биндинга экономит много времени на кофе и комментарии на хабре :-)
А достигнуть сходного качества организации кода можно и без RX.
В чем плюс RX в этом смысле — что когда появятся более настоящие RX задачи — они в строятся в остальной код таким образом, что никто этого и не заметит
Чтобы «не заботиться о том, моментальная эта операция или растянутая во времени, синхронная или асинхронная» достаточно работать с любой операцией как с future, и если ваш язык поддерживает async workflows, у вас все легко и хорошо. А вот смешивать одиночные и множественные операции уже совсем не так полезно для прозрачности кода, к сожалению.
Ну вот здесь на самом деле вопрос — что такое одиночная операция.
Кнопка, скажем — не одиночная операция — а сигнал нажатий на нее
Логин — не одиночная операция — любой запрос тебе может вернуть 403, и ты зарелогинишься, вызвав при этом какой-то навешенный на это флоу.
И так далее.
Вообще с точки зрения реактивщины — почти все — стримы, сиречь множественные операции — а что одиночные — в общем-то и не стоит отдельного эффорта.
Пы-сы. Да, если ваш язык поддерживает async workflows… Ну мой язык, скажем, не поддерживает) и опять же с точки зрения реактивного программировния и прочих биндингов — все эти асинки-авэйты лишь частный случай преобразований control/data flow — и этим прекрасны.
Вообще из всех моих личных комплейнтов к реактивщине — она всегда читабельна. Но иногда несет избыточный бойлер с потерей производительности.
Кнопка, скажем — не одиночная операция — а сигнал нажатий на нее
Логин — не одиночная операция — любой запрос тебе может вернуть 403, и ты зарелогинишься, вызвав при этом какой-то навешенный на это флоу.
И так далее.
Вообще с точки зрения реактивщины — почти все — стримы, сиречь множественные операции — а что одиночные — в общем-то и не стоит отдельного эффорта.
Пы-сы. Да, если ваш язык поддерживает async workflows… Ну мой язык, скажем, не поддерживает) и опять же с точки зрения реактивного программировния и прочих биндингов — все эти асинки-авэйты лишь частный случай преобразований control/data flow — и этим прекрасны.
Вообще из всех моих личных комплейнтов к реактивщине — она всегда читабельна. Но иногда несет избыточный бойлер с потерей производительности.
Логин — не одиночная операция — любой запрос тебе может вернуть 403, и ты зарелогинишься, вызвав при этом какой-то навешенный на это флоу.
А надо ли вызывать этот флоу, или он на самом деле актуален только для первого логина, а релогин — это совсем другое?
Вообще с точки зрения реактивщины — почти все — стримы, сиречь множественные операции — а что одиночные — в общем-то и не стоит отдельного эффорта.
С точки зрения молотка все — гвозди. И да, так можно жить, но это не всегда удобно.
Вообще из всех моих личных комплейнтов к реактивщине — она всегда читабельна.
Хм, можете показать пример чистого Rx, описывающий «последовательность» из стартового коммента — мне интересно, насколько это будет читабельно.
Или вы под читабельностью понимаете то же самое, что и многие другие (включая меня, кстати): «я легко и бегло это читаю, потому что я привык»?
А надо ли вызывать этот флоу, или он на самом деле актуален только для первого логина, а релогин — это совсем другое?
Нет, не надо — это разные задачи. Которые можно описать единообразно.
С точки зрения молотка все — гвозди. И да, так можно жить, но это не всегда удобно.
И это правда. И тут имеет место tradeoff — консистентность против сиюминутной выгоды. На текущем проекте на данный момент первое выигрывает — но у меня нет оснований говорить что так будет всегда
Хм, можете показать пример чистого Rx, описывающий «последовательность» из стартового коммента — мне интересно, насколько это будет читабельно.
Вот кстати можно написать) Как раз завтра делаю доклад на тему того, как весь набор действий приложения инициируемых какой-нибудь кнопкой может быть завернут в единый реактивный пайплайн. Могу предложить Вам презентацию оного, вроде как он затрагивает более злые примеры, чем в статье, возможно это поможет ответить на вопрос
я легко и бегло это читаю, потому что я привык
Вот завтра как раз на докладе и узнаю :-) Простой ли это код, или просто привычный)
Нет, не надо — это разные задачи. Которые можно описать единообразно.
Вот и возникает вопрос — не становится ли эта единообразность избыточной, когда вы пытаетесь единообразно описать разные вещи?
И тут имеет место tradeoff — консистентность против сиюминутной выгоды.
А вы уверены, что речь идет о «против сиюминутной выгоды», а не «против семантической точности», скажем?
Могу предложить Вам презентацию оного, вроде как он затрагивает более злые примеры, чем в статье, возможно это поможет ответить на вопрос
Давайте, это интересно.
А вы уверены, что речь идет о «против сиюминутной выгоды», а не «против семантической точности», скажем?
Ну вообще практика показывает — что правильно приготовленная реактивщина очень и очень семантически точна, но вопрос очень уместный — потому что правильно ее приготовить не очень просто. Насчет избыточности? Возникало такое ощущение, да, но в итоге пришел к тому, что это приемлемая цена за тестируемый код, с гарантированно меньшим количеством сайд-эффектов и высоким уровнем инкапсуляции
К сожалению, презентация заточена под устный доклад — поэтому возможно чего-то будет не хватать — но с удовольствием объясню все недостающее при желании узнать. Ссылко
что правильно приготовленная реактивщина очень и очень семантически точна, но вопрос очень уместный — потому что правильно ее приготовить не очень просто
Так может быть, если есть более простые способы достигнуть семантической точности (я сейчас не буду обсуждать семантическую точность полученной реактивщины, ее надо почитать для этого на конкретных примерах), не надо усложнять?
приемлемая цена за тестируемый код, с гарантированно меньшим количеством сайд-эффектов и высоким уровнем инкапсуляции
Мне вот интересно, откуда вы берете это «гарантированно меньшее количество сайд-эффектов», и, что важнее, с чем вы сравниваете.
Так может быть, если есть более простые способы достигнуть семантической точности (я сейчас не буду обсуждать семантическую точность полученной реактивщины, ее надо почитать для этого на конкретных примерах), не надо усложнять?
Да — вы правы — тут уже надо брать куски кода и разговаривать по ним. С чем сравниваю? Ну, скажем, со «средним по
я полагаю — что реактивный подход действительно хорошо справляется с задачей честного описания стейта сущности (включая транзитный) даже на уровне сигнатур.
«Хорошо» или «лучше всех»? Когда речь идет именно об описании состояния — чем потоки RX выгоднее, скажем, чем акковские акторы?
Хорошо. Странно говорить «Лучше всех» в IT — где каждое решение — компромисс))
Разные классы сущностей. Потоки RX — не про потоки и асинхронность — а про контракт монадного биндинга в первую очередь — то есть про декларативное описание последовательности действий.
Акторы больше похожи на аспектный подход.
Их странно сравнивать) Но если очень хочется — то по моему опыту. аспекты гораздо гибче и дают больший эффект при меньших вложениях сил — однако больше тяготеют к потере контроля над качеством кодовой базы.
Разные классы сущностей. Потоки RX — не про потоки и асинхронность — а про контракт монадного биндинга в первую очередь — то есть про декларативное описание последовательности действий.
Акторы больше похожи на аспектный подход.
Их странно сравнивать) Но если очень хочется — то по моему опыту. аспекты гораздо гибче и дают больший эффект при меньших вложениях сил — однако больше тяготеют к потере контроля над качеством кодовой базы.
в IT — где каждое решение — компромисс
Вот именно, что компромис. И поэтому осмысленно понимать, что находится на разных его (компромиса) плечах, и какие есть альтернативы в каждый момент.
Их странно сравнивать
Почему же? И то, и другое — способы борьбы с проблемами, возникающими при асинхронии (более того, в одном малоизвестном курсе это даже дают одно после другого).
больше тяготеют к потере контроля над качеством кодовой базы.
… а выше вы же писали, что чтобы реактивщина была семантически точной, ее нужно правильно готовить, что не очень просто.
… а выше вы же писали, что чтобы реактивщина была семантически точной, ее нужно правильно готовить, что не очень просто.
Могу раскрыть мысль — выработка хорошего подхода при работе с реактивным кодом требует существенных затрат в начале. И Вообще имеет высокий порог входа. Однако после преодоления этого порога оказалось, что в итоговом коде нет проблем, которые возникали при аспектном подходе (хотя я не исключаю, что просто неправильно его готовил)
На мой взгляд эти два подхода просто решают различные задачи, хотя оба лежат в области стиля организации кода и борьбы с проблемами асинхронности, как вы упомянули
На мой взгляд эти два подхода просто решают различные задачи
Вот мне и интересно, для каких задач оптимально выбирать Rx.
Большой профит RX — он очень хорошо тестируется. Соответственно если при разработке приложения высокие требования к качеству — я буду смотреть в сторону RX.
Засчет биндинга — он очень хорошо покрывает задачи где данные собираются больше чем с одного источника (неважно — разные эндпоинты API, системные ресурсы, БДшечка) и претерпевают какие-то преобразования попути. То есть очень похоже на развитие идей LINQ.
Минус — Быстродействие — соответственно — если у меня много разных маленьких элементиков и требования к 60fps — выберу что-то более простое и прямое
RX очень требователен к уровню команды — соответственно с разномастной командой я бы в RX не ввязывался — его невозможно отлаживать — только тестировать.
То есть если я буду писать быстрый прототипчик чего-нибудь или игру, или буду работать в команде возможностей которой я не знаю — я, вероятно, выберу не RX
Если я буду писать алгоритмически сложную задачу требовательную к ресурсам и нуждающуюся в магии — я выберу не RX
Иначе — RX
Засчет биндинга — он очень хорошо покрывает задачи где данные собираются больше чем с одного источника (неважно — разные эндпоинты API, системные ресурсы, БДшечка) и претерпевают какие-то преобразования попути. То есть очень похоже на развитие идей LINQ.
Минус — Быстродействие — соответственно — если у меня много разных маленьких элементиков и требования к 60fps — выберу что-то более простое и прямое
RX очень требователен к уровню команды — соответственно с разномастной командой я бы в RX не ввязывался — его невозможно отлаживать — только тестировать.
То есть если я буду писать быстрый прототипчик чего-нибудь или игру, или буду работать в команде возможностей которой я не знаю — я, вероятно, выберу не RX
Если я буду писать алгоритмически сложную задачу требовательную к ресурсам и нуждающуюся в магии — я выберу не RX
Иначе — RX
Большой профит RX — он очень хорошо тестируется.
«Профит» — это когда не просто «хорошо», а «лучше». Я знаю много технологий, которые хорошо тестируются (те же акторы, скажем, не говоря уже про PO?O). Конкретно в Rx я знаю только один профит тестируемости — заранее встроенные места для подмены шедулеров и времени, что позволяет имитировать разные ситуации с таймаутами, наложениями, гонками и прочей красотой. А во всем прочем… тестируется как и любой другой хороший фреймворк.
Засчет биндинга — он очень хорошо покрывает задачи где данные собираются больше чем с одного источника (неважно — разные эндпоинты API, системные ресурсы, БДшечка) и претерпевают какие-то преобразования попути.
Вот это как раз последовательности данных, о которых я говорил в самом начале, и в этом качестве я Rx как раз очень ценю.
тестируется как и любой другой хороший фреймворк.
Я, как вероятно и автор статьи — из мира мобилок) тут гораздо меньше таких вот «хороших подходов» — и тестируемость по прежнему считается достижением :-) Но вообще да, пожалуй согласен. Просто реактивный подход для меня оказался первым где получилось построить что-то действительно красивое — поэтому я его переоцениваю — хотя тех же результатов можно добиться и иначе.
Благодарю за беседу)
Хм, можете показать пример чистого Rx, описывающий «последовательность» из стартового коммента — мне интересно, насколько это будет читабельно.
Вот кстати можно написать) Как раз завтра делаю доклад на тему того, как весь набор действий приложения инициируемых какой-нибудь кнопкой может быть завернут в единый реактивный пайплайн. Могу предложить Вам презентацию оного, вроде как он затрагивает более злые примеры, чем в статье, возможно это поможет ответить на вопрос
Собственно мой коммент был как раз о том, что гонять integer'ы и всякие Observable.never это весело и прикольно и об этом куча статей, а вот злых примеров rx никто не дает. Иногда берут один пример и пишут подробную статью, мешая архитектуру к объяснениями как отправлять запрос.
Потому что мне этот пример актуален и проблему «мигания интернета» я решил отвратительно, с помощью списка «отправляемых в данный момент моделей» и второй цепочкой Observable внутри Observable (иначе я не могу понять когда «подцепочка» завершилась). Что мне вообще не нравится, но умишка сделать лучше нехватает
С точки зрения молотка все — гвозди. И да, так можно жить, но это не всегда удобно.
разумеется RX не панацея — но цель автора статья, да и моя — показать, что это достаточно взрослая парадигма для того, чтобы занимать ключевую позицию в реальных задачах.
В вашем случае стоит юзать Observable.using и еще немного операторов
Rx Programming goes on mainstage.
Очень жду Ваших статей по RxJava2, если они планируются. Плюс было бы интересно посмотреть на более продвинутые use-case-ы реактивного расширения, возможно, в отдельных статьях.
Sign up to leave a comment.
Введение в RxJava: Создание последовательности