Конечно, есть более удобные продукты для взрослых решений, но если нужно что-то быстро сделать без гибких возможностей и инкрементальных бэкапов, то кажется, вполне годное решение.
Если сообщение было отклонено всеми потребителями, превышено количество попыток обработки или просрочилось по TTL, то сообщение попадает в очередь Dead Letter Queue (DLQ)
Увы и ах, нет в RabbitMQ условия "превышено число попыток обработки", такую логику нужно реализовывать на стороне клиента.
Тема анализа производительности и алармов очень интересна. Но статья как-будто написана chatgpt с плохим промптом - сухо, дергано, и не понятна ее цель, что именно вы хотели донести.
У меня не сложилось понимания как мне взять и попробовать, очень бы хотелось увидеть пошаговый рецепт внедрения и получения первых результатов. И уже после можно погружаться глубже - в то как оно устроено и в теорию.
Я понимаю, что 4 года прошло, но мне не дает покоя ответ на вопрос: а нафига делать DailyEventService, в котором нет никакой логики? Нафига "инжектитм сервис в любую часть приложения и подписываемся на rxjs Subject", если в том месте, где у нас есть потребность ежедневной обработки мы просто можем сделать метод с декоратором @Cron(...)? Зачем нам декоратора, который уже рализует запуск по расписанию еще и обмазывать сверху rxjs?
Но тут, как и всегда, дорожка очень узкая - можно прийти к "зоопарку" хаотично налепленных копонентов, и систему становится сложно поддерживать и развивать. Конечно, можно сделать отсылку к здравому смыслу, но и он у все разный, и работает лучше всего "задним числом".
Мой поинт только в том, что на мой взгляд неправильно это называть паттерном "душитель". Скорее тут речь про более высокоуровневый подход к общей архитектуре - там где можно делать копоненты системы максимально независемыми. И применяя его нужно очень хорошо понимать, что это тоже не бесплатно.
Мне кажется, но тут термин "DWH" в той же степени как и "паттерн" - это все для красоты, вполне себе менеджерской.
Прикрутить сбоку сервис с БД (для приведенного кейса в статье требрвание к наличию DWH не очевидно, а не всякая БД есть DWH), реплицировать туда нужные данные, реализовать там какие-то фичи и соединить с основным сервисом через API - это можно назвать "прикрутить сбоку", или если очень хочется "сервисной архитектурой" (без приставки "микро"). Это как бы вполне обычная история.
Если говорить именно про паттерн Strangler - это подход именно к разделению существующего монолита на части. Со своей стратегией решения как выделить эту часть, и как интегрировать ее обратно в общую схему работы существующего решения. Там другой класс проблем решается, в отличие от создания нового компонента рядом с существующим.
Мой комментарий был скорее "keyboard" vs "keyboard + mouse". Конечно, есть еще трекбол, тачпад, джойстик, планшет для рисования. Но мышь наиболее универсальный инструмент, особенно если речь про работу программиста. Тачпад сойдет для работы на коленке когда ждешь самолета, там экран в какой-то мере тоже (но вряд ли вы будете прямо активно разрабатывать что-то тыкая в планшет или в смартфон). У меня кстати был ноут с тач экраном, и после первых двух недель эффекта новизны я про него вообще забывал. Вспоминал только если чихнешь на него, и запускались все приложения с иконками на десктопе =)
Если вы программируете микроконтроллеры, и при этом используете не среду разработки, а архаичный черно-зелентый терминал вместо современного ПК - то соглашусь, мышь не нужна. В остальных случаях не понимаю как вы без нее обходитесь. Как программист с 30-летним стажем вам отвечаю =)
Мне кажется, или вы только что "изобрели" наследование? 🙂
const ogp = Object.getPrototypeOf;
class MyClass1 {
get name () {
return 'MyClass1';
}
}
class MyClass2 extends MyClass1 {
get name () {
return 'MyClass2';
}
}
const obj = new MyClass2();
console.log(obj); // MyClass2 {}
console.log(obj.name); // MyClass2
console.log(obj.hasOwnProperty('name')); // false
console.log(ogp(obj).hasOwnProperty('name')); // true
Но может я не очень понял, что вы хотели получить, просто как можно ещё "поиграться".
Я ничего не хотел получить, просто хотел показать, что конструктор технически может вернуть объект любого типа. Но я не вижу для этого трюка практического применения. И более того, считаю что такой код нарушает принципы ООП и дурно пахнет. В программировании должно быть как при управлении автомобилем - чем прозрачнее и понятнее твои действия, тем лучше.
Max навязываться государством, причём государством полицейским, карательным в отношении инакомыслия. Причем навязывается очень топорно, и еще и под лозунгом заботы о гражданах.
Поэтому и отношение к нему ровно такое, как к навязавающему его. У прочих-других тоже, конечно, есть куча нюансов и недостатков, но во-первых в сравнении их можно простить, а во-вторых если не можно простить, то есть выбор.
Получается, что в любом месте у вас может быть изменен объект, созданный в другом месте. Да, для синглотона это ровно то что ожидается. Но одно дело, когда вы пишете код явно понимая, что работаете с синглтоном. И совсем другое, когда у вас уже есть база кода, написанная без учета синлотона. Где-то вы получите ну совсем неожиданное поведение, и у какого-то клиента спишутся деньги за услуги другого =( Напоминает шутку про "define true=false # мучайтесь, уроды"
В качестве прикладного смысла могу предложить возвращать уже существующий экземпляр текущего класса, если входные параметры эквивалентны уже созданному и закешированному экземпляру этого класса.
Для этого уже существуют паттерны, не нарушающие ООП - статические фабричные методы или отдельный FlyweightFactory.
Еще в голову приходит идея возвращать наследников текущего класса на основе передаваемых параметров. Да, это немножко "не по правилам ооп", но мне кажется довольно удобным решением, когда в базовый класс ты передаешь параметры, а он уже сам решает, что создать.
Да в принципе конструктор может вернуть все что угодно, в том числе и объект другого класса. Но, имхо, это пахнет говнокодом.
class MyClass1 {
name='MyClass1'
}
class MyClass2 {
constructor() {
return new MyClass1()
}
}
const obj = new MyClass2();
console.log(obj)
MyClass1 {name: 'MyClass1'}
console.log(obj instanceof MyClass1);
true
console.log(obj instanceof MyClass2);
false
Если говорить про то что "под капотом" реализации классов JS - то да.
Но если на уровне TypeScript или ES6 - то там есть явно выделенные классы, и экземпляр объекта можно получить созданием из класса, как в языках с "правильным" ООП. И если нужно получить два объекта с одинаковым классом, мы берем и создаем два объекта. Опять же оговорюсь, на этому уровне абстракции нам пофигу что это синтаксический сахар пад прототипным наследованием.
const obj1 = new MyClass();
...
const obj2 = new MyClass();
А вот зачем нам может понадобиться создавать новый объект из существующего объекта? Зачем из почти настоящего ООП нам обратно нырять в не совсем настоящую реализацию?
Я могу представить только какой-то экзотиеческий сценарий, когда мы работаем с какой-то легаси библиотекой, куда нам нужно пробросить объект конкретного класса, но нам по какой-то причине недоступен конструктор таких объектов (не экпортирован из либы?), и мы объект нашего класса заставляем прикидываться другим классом. Но это какой-то фантастический на мой взгляд сценарий.
"Рекурсивные конструторы и наследование от экземпляров" звучит как инструмент или решение, но для каких прикладных задач? Для какой фичи? Можете привести пример "из жизни" когда это требуется?
"Наследование от экземпляра" уже звучит несколько жутковато, и кажется результатом неудачной архитектуры.
Браво, то что chatgpt объясняет в четырех преждложениях вы превратили в целую статью :)
А можете подробнее рассказать почему?
Конечно, есть более удобные продукты для взрослых решений, но если нужно что-то быстро сделать без гибких возможностей и инкрементальных бэкапов, то кажется, вполне годное решение.
У многих хостеров есть услуга S3, и не надо свой vps поднимать.
Увы и ах, нет в RabbitMQ условия "превышено число попыток обработки", такую логику нужно реализовывать на стороне клиента.
Тема анализа производительности и алармов очень интересна. Но статья как-будто написана chatgpt с плохим промптом - сухо, дергано, и не понятна ее цель, что именно вы хотели донести.
У меня не сложилось понимания как мне взять и попробовать, очень бы хотелось увидеть пошаговый рецепт внедрения и получения первых результатов. И уже после можно погружаться глубже - в то как оно устроено и в теорию.
Я понимаю, что 4 года прошло, но мне не дает покоя ответ на вопрос: а нафига делать DailyEventService, в котором нет никакой логики? Нафига "инжектитм сервис в любую часть приложения и подписываемся на rxjs Subject", если в том месте, где у нас есть потребность ежедневной обработки мы просто можем сделать метод с декоратором @Cron(...)? Зачем нам декоратора, который уже рализует запуск по расписанию еще и обмазывать сверху rxjs?
Этот посыл яростно плюсую.
Но тут, как и всегда, дорожка очень узкая - можно прийти к "зоопарку" хаотично налепленных копонентов, и систему становится сложно поддерживать и развивать. Конечно, можно сделать отсылку к здравому смыслу, но и он у все разный, и работает лучше всего "задним числом".
Мой поинт только в том, что на мой взгляд неправильно это называть паттерном "душитель". Скорее тут речь про более высокоуровневый подход к общей архитектуре - там где можно делать копоненты системы максимально независемыми. И применяя его нужно очень хорошо понимать, что это тоже не бесплатно.
Мне кажется, но тут термин "DWH" в той же степени как и "паттерн" - это все для красоты, вполне себе менеджерской.
Прикрутить сбоку сервис с БД (для приведенного кейса в статье требрвание к наличию DWH не очевидно, а не всякая БД есть DWH), реплицировать туда нужные данные, реализовать там какие-то фичи и соединить с основным сервисом через API - это можно назвать "прикрутить сбоку", или если очень хочется "сервисной архитектурой" (без приставки "микро"). Это как бы вполне обычная история.
Если говорить именно про паттерн Strangler - это подход именно к разделению существующего монолита на части. Со своей стратегией решения как выделить эту часть, и как интегрировать ее обратно в общую схему работы существующего решения. Там другой класс проблем решается, в отличие от создания нового компонента рядом с существующим.
Мы раньше назывли это "прикрутить сбоку", а это теперь это оказывается паттерн 🤣
Стаж трудовой, коллега =)
Мой комментарий был скорее "keyboard" vs "keyboard + mouse". Конечно, есть еще трекбол, тачпад, джойстик, планшет для рисования. Но мышь наиболее универсальный инструмент, особенно если речь про работу программиста. Тачпад сойдет для работы на коленке когда ждешь самолета, там экран в какой-то мере тоже (но вряд ли вы будете прямо активно разрабатывать что-то тыкая в планшет или в смартфон). У меня кстати был ноут с тач экраном, и после первых двух недель эффекта новизны я про него вообще забывал. Вспоминал только если чихнешь на него, и запускались все приложения с иконками на десктопе =)
Если вы программируете микроконтроллеры, и при этом используете не среду разработки, а архаичный черно-зелентый терминал вместо современного ПК - то соглашусь, мышь не нужна. В остальных случаях не понимаю как вы без нее обходитесь. Как программист с 30-летним стажем вам отвечаю =)
А ведь вместо стетоскопа можно к груди телефон приложить. А вместо визуального осмотра камеру включить. Кажется, прекрасное далеко почти настало.
Мне кажется, или вы только что "изобрели" наследование? 🙂
Я ничего не хотел получить, просто хотел показать, что конструктор технически может вернуть объект любого типа. Но я не вижу для этого трюка практического применения. И более того, считаю что такой код нарушает принципы ООП и дурно пахнет. В программировании должно быть как при управлении автомобилем - чем прозрачнее и понятнее твои действия, тем лучше.
Max навязываться государством, причём государством полицейским, карательным в отношении инакомыслия. Причем навязывается очень топорно, и еще и под лозунгом заботы о гражданах.
Поэтому и отношение к нему ровно такое, как к навязавающему его. У прочих-других тоже, конечно, есть куча нюансов и недостатков, но во-первых в сравнении их можно простить, а во-вторых если не можно простить, то есть выбор.
Хороший кейс. Но выглядит как вредительство =)
Получается, что в любом месте у вас может быть изменен объект, созданный в другом месте. Да, для синглотона это ровно то что ожидается. Но одно дело, когда вы пишете код явно понимая, что работаете с синглтоном. И совсем другое, когда у вас уже есть база кода, написанная без учета синлотона. Где-то вы получите ну совсем неожиданное поведение, и у какого-то клиента спишутся деньги за услуги другого =( Напоминает шутку про "define true=false # мучайтесь, уроды"
Для этого уже существуют паттерны, не нарушающие ООП - статические фабричные методы или отдельный FlyweightFactory.
Да в принципе конструктор может вернуть все что угодно, в том числе и объект другого класса. Но, имхо, это пахнет говнокодом.
Если говорить про то что "под капотом" реализации классов JS - то да.
Но если на уровне TypeScript или ES6 - то там есть явно выделенные классы, и экземпляр объекта можно получить созданием из класса, как в языках с "правильным" ООП. И если нужно получить два объекта с одинаковым классом, мы берем и создаем два объекта. Опять же оговорюсь, на этому уровне абстракции нам пофигу что это синтаксический сахар пад прототипным наследованием.
А вот зачем нам может понадобиться создавать новый объект из существующего объекта? Зачем из почти настоящего ООП нам обратно нырять в не совсем настоящую реализацию?
Я могу представить только какой-то экзотиеческий сценарий, когда мы работаем с какой-то легаси библиотекой, куда нам нужно пробросить объект конкретного класса, но нам по какой-то причине недоступен конструктор таких объектов (не экпортирован из либы?), и мы объект нашего класса заставляем прикидываться другим классом. Но это какой-то фантастический на мой взгляд сценарий.
"Рекурсивные конструторы и наследование от экземпляров" звучит как инструмент или решение, но для каких прикладных задач? Для какой фичи? Можете привести пример "из жизни" когда это требуется?
"Наследование от экземпляра" уже звучит несколько жутковато, и кажется результатом неудачной архитектуры.
Я, возможно, чего-то не понимаю.
Очень ждал что будет раскрыт какой-то прикладной смысл этого упражнении. Но так и не нашёл :(
А ещё есть is distinct from, которое нормально работает с null