Я бы в статье такого плана добавил бы сравнение как минимум с самыми популярными уже существующими решениями. Типа популярных Winston и Pino и т.д. Мне кажется нужно подсвечивать преимущества и недостатки для общего понимания аудитории. Короче я бы раскрыл больше раздел про мотивацию.
Но вообще вы очень правильно делаете, что системно создаете продукты, которых самим не хватает. Это верный путь!
Хорошая статья. Добавлю лишь, что: - Подход с Callback'ами в Java - это больше редкость; намного чаще с Future пишется асинхронная логика - Реактивный код - это структура с определенным набором элементов и иногда бывает ваша логика в нее не может вписаться никак, а фьючеры более гибки - Дебагинг реактивного кода не нативен и сложнее императивного - В реактивном коде можно динамически строить пайплайн как конструктор, что иногда спасает - И самое главное - в статье не упоминаются Virtual Threads, которые призваны решить упомянутые проблемы фьючеров, уйти от КоллбекХела и сделать императивный вариант лучше; в общем они сокращают число преимуществ реактивного подхода над императивным для определенного круга задач (с интенсивным IO, как у вас).
И еще: как по мне эти реактивные пайплайны выглядят очень симпатично с эстетической точки зрения.
Т.е. должно отписаться и все ок. Так же у вас есть: observer.disconnect(). Вы его и используете в примерах с коллбеками, так как там нет ссылки на элемент, когда его выключаете. Можно этот метод тут использовать.
Я к тому, что почему выше указанный пример не работает? Вроде бы все должно быть ок.
В целом техника нормальная. Не знал про нее. Благодарю за статью. Как минимум можно иногда избежать хранения ref переменной в компоненте.
А почему нужно держать? Деньги работать должны. Тратьте на себя, на семью, на свое дело/бизнес, на идеи, поморщь, ... Деньги должны работать. И люди должны работать. Это и есть здоровая экономика. Деньги не создавались, что бы их где-то держали.
В этом и будет и достаток, и свобода и удовлетворение.
А лежать и сгребать сливки - это миф. Миллиардер Х занесет в пузырь слегка, что бы обычные люди повелись. А обычные люди понесут туда все что есть в погоне за халявой. Но ее нет. Вот и прогорают. Под миф, что им что-то где то нужно держать и процент получать. Что так вот типа все делают и успешны. И т.д.
Знаю, сейчас это не можно. Но все же обычная работа и традиционный подход к финансам выглядит более перспективным и устойчивым.
П.С. Есть еще ситуация, когда человек (например ИТшник) заработал, отложил, но не знает куда потратить, а деньги лежат и дела своего придумать не смог. Такие примеры есть и не мало. Это и говорит о том, что нужно искать/читать/думать над инвестициями в реальный бизнес или его создание. А не над поисками крипты. В крипту мейчас каждая собака ищет путь. Это и делает там пузырь. А в реале сильно меньше народу пробует. Поэтому там сложнее начать, но шансов больше.
И забудьте уже наконец миф, что кто-то возьмет ваши деньги, а через время вернет вам больше. Нет такого в массовости. Все те люди, кто заработал на таких мутках - для них это был не пассив. Это был актив. Они там пахали, что бы выгрызть свой плюс.
Вопрос в целом холиварный, так что уверен тут будет достаточно не согласившихся. Это ок. Как есть.
Мне кажется, что у всех пузырей общее не какой то там треугольник абстрактных показателей, а вполне понятное стремление людей к ХАЛЯВЕ. Это и есть признак, который видим, понятен и знаком всем людям. Его и стоит избегать.
Это относится не к компаниям, которые все это организовывают, а именно к людям, которые несут деньги. Компании как раз пашут сильно.
Как вывод - не хотите прогореть на пузыре, не гонитесь за халявой. Ее в массовости нет.
Просто мнение.
П.С. Первая часть про историю Sun была интересней. Про пузыри и ИИ я бы в другую выносил.
Перекос в сторону ИИ в количестве из-за того, что вы большке следите за ИИ или это в среднем в индустрии так? Иными словами: превосходство ИИ в стартап тематике объективно +/- по вашему, или просто вас больше эта тема интересует?
По хорошему в статье нужно бы еще указывать информацию про то, на каком железе запускались тесты, какие были параметры помимо указаных (в идеале просто писать команду запуска тестов) и какова структура Memory Heap. Но я понимаю, что статья - перевод, и этой инфы может просто не быть.
П.С. Я бы еще указывал параметрами при старте максимальный Heap, что бы все тестовые данные влезали в память с запасом и по-минимуму привлекался сборщик мусора. Что бы не искажать результаты (отрицательная память и т.д.).
И не-перформанс фичи и у Bun и у Deno все еще сильно нишевые; и потому не несут достаточной для перехода на них ценности для среднего проекта (типа другой движек, области безопасности, нативная линковка, ...).
И согласен с вами - как только будет фича стоящая перехода - сразу Node будет делать ее тоже. Bun/Deno для Node выходят как бы разведчиками "куда идти".
Мне кажется, что в такого рода статьях, в начале нужно указывать сколько у вас самих реального опыта в годах. Что бы люди понимали с каких позиций вы выходите +/-. Просто как совет.
Мощная статья.
Нубский вопрос: в начале в разделе "Энергопотребление", чем вы его меряли и делали такие красивые скрины?
Я бы в статье такого плана добавил бы сравнение как минимум с самыми популярными уже существующими решениями. Типа популярных Winston и Pino и т.д. Мне кажется нужно подсвечивать преимущества и недостатки для общего понимания аудитории. Короче я бы раскрыл больше раздел про мотивацию.
Но вообще вы очень правильно делаете, что системно создаете продукты, которых самим не хватает. Это верный путь!
Может есть у вас есть ссылка на видео или статью как это все собирается?
Хорошая статья.
Добавлю лишь, что:
- Подход с Callback'ами в Java - это больше редкость; намного чаще с Future пишется асинхронная логика
- Реактивный код - это структура с определенным набором элементов и иногда бывает ваша логика в нее не может вписаться никак, а фьючеры более гибки
- Дебагинг реактивного кода не нативен и сложнее императивного
- В реактивном коде можно динамически строить пайплайн как конструктор, что иногда спасает
- И самое главное - в статье не упоминаются Virtual Threads, которые призваны решить упомянутые проблемы фьючеров, уйти от КоллбекХела и сделать императивный вариант лучше; в общем они сокращают число преимуществ реактивного подхода над императивным для определенного круга задач (с интенсивным IO, как у вас).
И еще: как по мне эти реактивные пайплайны выглядят очень симпатично с эстетической точки зрения.
В разделе "Изменения в обработчике прерываний" наверное лучше использовать слово "исключение".
И вы пропустили раздел "08. Exception" из оригинальной книги. Без него выше указанный раздел не клеется никак :(
Вопрос: А почему в разделе "Какие проблемы решают callback refs в коде" в первом примере вы говорите, что обычный useRef не работает? Там же:
Т.е. должно отписаться и все ок. Так же у вас есть:
observer.disconnect(). Вы его и используете в примерах с коллбеками, так как там нет ссылки на элемент, когда его выключаете. Можно этот метод тут использовать.Я к тому, что почему выше указанный пример не работает? Вроде бы все должно быть ок.
В целом техника нормальная. Не знал про нее. Благодарю за статью. Как минимум можно иногда избежать хранения ref переменной в компоненте.
Хорошая статья. Еще можно это использовать при отрисовке попапов и модальных окон (параметром передавать контент попапа).
И рендеринга можно передавать и функцию, и компонент и элемент, как и писалось выше. Есть разные плюсы у разных методов.
П.С. У вас "Плюсы пользовательских хуков" дважды в конце.
А почему нужно держать? Деньги работать должны. Тратьте на себя, на семью, на свое дело/бизнес, на идеи, поморщь, ... Деньги должны работать. И люди должны работать. Это и есть здоровая экономика. Деньги не создавались, что бы их где-то держали.
В этом и будет и достаток, и свобода и удовлетворение.
А лежать и сгребать сливки - это миф. Миллиардер Х занесет в пузырь слегка, что бы обычные люди повелись. А обычные люди понесут туда все что есть в погоне за халявой. Но ее нет. Вот и прогорают. Под миф, что им что-то где то нужно держать и процент получать. Что так вот типа все делают и успешны. И т.д.
Знаю, сейчас это не можно. Но все же обычная работа и традиционный подход к финансам выглядит более перспективным и устойчивым.
П.С. Есть еще ситуация, когда человек (например ИТшник) заработал, отложил, но не знает куда потратить, а деньги лежат и дела своего придумать не смог. Такие примеры есть и не мало. Это и говорит о том, что нужно искать/читать/думать над инвестициями в реальный бизнес или его создание. А не над поисками крипты. В крипту мейчас каждая собака ищет путь. Это и делает там пузырь. А в реале сильно меньше народу пробует. Поэтому там сложнее начать, но шансов больше.
И забудьте уже наконец миф, что кто-то возьмет ваши деньги, а через время вернет вам больше. Нет такого в массовости. Все те люди, кто заработал на таких мутках - для них это был не пассив. Это был актив. Они там пахали, что бы выгрызть свой плюс.
Вопрос в целом холиварный, так что уверен тут будет достаточно не согласившихся. Это ок. Как есть.
Скорее "устанавливается". Так вроде бы понятнее.
Я бы добавлял в каком то виде ссылку на такое пояснение. Что бы было ясно откуда взялась подборка.
На мой вопрос ответили. Благодарю. Нужное дело.
Мне кажется, что у всех пузырей общее не какой то там треугольник абстрактных показателей, а вполне понятное стремление людей к ХАЛЯВЕ. Это и есть признак, который видим, понятен и знаком всем людям. Его и стоит избегать.
Это относится не к компаниям, которые все это организовывают, а именно к людям, которые несут деньги. Компании как раз пашут сильно.
Как вывод - не хотите прогореть на пузыре, не гонитесь за халявой. Ее в массовости нет.
Просто мнение.
П.С. Первая часть про историю Sun была интересней. Про пузыри и ИИ я бы в другую выносил.
Уточняющий вопрос к Продукт Радару:
Перекос в сторону ИИ в количестве из-за того, что вы большке следите за ИИ или это в среднем в индустрии так? Иными словами: превосходство ИИ в стартап тематике объективно +/- по вашему, или просто вас больше эта тема интересует?
Это просто не указано в статье вроде бы.
Интересно.
По хорошему в статье нужно бы еще указывать информацию про то, на каком железе запускались тесты, какие были параметры помимо указаных (в идеале просто писать команду запуска тестов) и какова структура Memory Heap. Но я понимаю, что статья - перевод, и этой инфы может просто не быть.
П.С. Я бы еще указывал параметрами при старте максимальный Heap, что бы все тестовые данные влезали в память с запасом и по-минимуму привлекался сборщик мусора. Что бы не искажать результаты (отрицательная память и т.д.).
Удивлен, что еще не упомянули про "Ворона, или как Иван-Дурак за кладом ходил" (очень давно очень много в нее играл):
Наверное имелось ввиду что-то типа: ... написаный на языке Go, использующем сборщик мусора ...
И в целом в последнем абзаце я бы пересмотрел формулировки. Как то не естественно написаны.
И не-перформанс фичи и у Bun и у Deno все еще сильно нишевые; и потому не несут достаточной для перехода на них ценности для среднего проекта (типа другой движек, области безопасности, нативная линковка, ...).
И согласен с вами - как только будет фича стоящая перехода - сразу Node будет делать ее тоже. Bun/Deno для Node выходят как бы разведчиками "куда идти".
Мне кажется, что в такого рода статьях, в начале нужно указывать сколько у вас самих реального опыта в годах. Что бы люди понимали с каких позиций вы выходите +/-. Просто как совет.
Интересно бы почитать про такое.
Ссылка на Ютуб лекцию Дейкстры битая. Вот рабочая.
Ну и статью от вас мы ждем. Очень интересно!