Не очень понял задумку. На уровне бэкенда действительно много готовых решений, библиотек и специализрованых баз данных, но мы не можем перенести эту логику на бэк, тк это приведет к рассинхрону фронтовому. То есть, пока мы будем готовить данные для клиента 1 от клиента 2, клиент 1 уже успеет внести ряд изменений. И тогда проблема становится многослойной. В данном случае конфликты необходимо решать "на месте".
Если мы хотим работать в онлайн режиме через простой блокнот, то это сложно будет реализовать таким способом, поэтому всякие google doc и прочие текстовые редакторы работают через ОТ. В простейшем случае можно представить CRDT как гарантию того, что мы можем разбить объект на такие независимые части, что изменение одной не повлияет на изменение другой. В моем проекте был текстовый редактор, который под капотом работает с немного кастомизированным html. Мы представили каждый элемент dom дерева в нем как независимый элемент и присвоили id. Таким образом, получалось дерево условно независимых объектов.
Конечно, вы правы в том, что использование thenApplyAsync без специфичного Executor кажется избыточным. Однако, стоит понимать, что демонстрация асинхронных возможностей Java с помощью CompletableFuture в данном случае была направлена на показ возможностей языка, а не на идеальную оптимизацию производительности. Не каждый пример должен быть прямым указанием к действию, иногда это просто демонстрация возможностей.
Что касается вашего комментария о Kotlin и использовании withContext — да, конечно, можно всё сделать проще и понятнее, если использовать GlobalScope.async. Тем не менее, использование различных контекстов исполнения служит для показа гибкости корутин. Мне показалось это очевидным, тк заголовок называется Цепочка многопоточных вычислений, что предполагает понимания причин происходящего.
Категорически не согласен. Мне кажется, что это вредный совет. Если на крутого специалиста, который занимается публичной деятельностью это и может сработать, то для мидл/джунов нет. Вот приходит мне пачка резюмех мидлов (которые предварительно отсеил hr) и я понимаю, что не смогу всех прособесить, надо отсеить лучшие. Я же не буду писать уточняющие вопросы каждому кандидату. Поэтому резюме очень сильно решает. Кроме того, если hr написала кандидату, то совершенно не факт, что специалист согласится прособесить и тем более взять кандидата. Между тем как написала hr и взяли на работу пропасть, которую было бы не плохо заполнить чем-то.
Ну модули можно наследовать импортом, динамика типов даёт полиморфизм, ну и приватные методы и переменные тоже можно делать (на сколько это допустимо в языке). Я мог бы написать пример, но обучение вас питону не входит сейчас в мои планы. :)
Откройте почти любую документацию и вы увидите там игрушечные примеры. Так же и здесь. Просто вы не разобрались с материалом. А доказывать, что в Java нет kind'ов мне надоело. :)
Я возможно вас удивлю, но существует не только Энтерпрайз разработка. Например, в разработке под МК постоянные аллокации памяти часто нежелательны. Поэтому там редко делается выбор в сторону C++.
Спасибо! Гляну
Не очень понял задумку. На уровне бэкенда действительно много готовых решений, библиотек и специализрованых баз данных, но мы не можем перенести эту логику на бэк, тк это приведет к рассинхрону фронтовому. То есть, пока мы будем готовить данные для клиента 1 от клиента 2, клиент 1 уже успеет внести ряд изменений. И тогда проблема становится многослойной. В данном случае конфликты необходимо решать "на месте".
Если мы хотим работать в онлайн режиме через простой блокнот, то это сложно будет реализовать таким способом, поэтому всякие google doc и прочие текстовые редакторы работают через ОТ. В простейшем случае можно представить CRDT как гарантию того, что мы можем разбить объект на такие независимые части, что изменение одной не повлияет на изменение другой. В моем проекте был текстовый редактор, который под капотом работает с немного кастомизированным html. Мы представили каждый элемент dom дерева в нем как независимый элемент и присвоили id. Таким образом, получалось дерево условно независимых объектов.
Конечно, вы правы в том, что использование
thenApplyAsyncбез специфичногоExecutorкажется избыточным. Однако, стоит понимать, что демонстрация асинхронных возможностей Java с помощью CompletableFuture в данном случае была направлена на показ возможностей языка, а не на идеальную оптимизацию производительности. Не каждый пример должен быть прямым указанием к действию, иногда это просто демонстрация возможностей.Что касается вашего комментария о Kotlin и использовании
withContext— да, конечно, можно всё сделать проще и понятнее, если использоватьGlobalScope.async. Тем не менее, использование различных контекстов исполнения служит для показа гибкости корутин. Мне показалось это очевидным, тк заголовок называется Цепочка многопоточных вычислений, что предполагает понимания причин происходящего.Спасибо за своевременный комментарий!)))
Категорически не согласен. Мне кажется, что это вредный совет. Если на крутого специалиста, который занимается публичной деятельностью это и может сработать, то для мидл/джунов нет. Вот приходит мне пачка резюмех мидлов (которые предварительно отсеил hr) и я понимаю, что не смогу всех прособесить, надо отсеить лучшие. Я же не буду писать уточняющие вопросы каждому кандидату. Поэтому резюме очень сильно решает. Кроме того, если hr написала кандидату, то совершенно не факт, что специалист согласится прособесить и тем более взять кандидата. Между тем как написала hr и взяли на работу пропасть, которую было бы не плохо заполнить чем-то.
Я и не смел надеяться :)
Откройте почти любую документацию и вы увидите там игрушечные примеры. Так же и здесь. Просто вы не разобрались с материалом. А доказывать, что в Java нет kind'ов мне надоело. :)
То есть, если я получаю optional с результатом запроса из базы, то мой код плох и надо было в случае отсутствия информации возвращать null?
А да, ещё же старый добрый js с замыканиями вместо классов. :)
Не понял вашу мысль (
Модули в Python
Я возможно вас удивлю, но существует не только Энтерпрайз разработка. Например, в разработке под МК постоянные аллокации памяти часто нежелательны. Поэтому там редко делается выбор в сторону C++.
Ну так, а что вы ответите про Optional или асинхронные вычисления??? :)
ООП не про классы, а про объекты :)