Роль JS не сводится к "управлению DOM", хотя это одна из важных задач, для которых он создавался. Бизнес-логика, валидация форм, взаимодействие с пользователем (реация на события) и вот это вот все.
Что касается роли конкретно jQuery, то он появился тогда, когда был зоопарк реализаций API в браузерах. Сейчас API стандартизирован, и рабочая лошадка document.queryselector работает везде. Так ли нужен он (jQuery) вообще?
Если вам нужно манипулировать DOM, валидировать формы или анимировать элементы, то вы можете спокойно делать разработку на pure js, но с jQuery может быть удобнее, особенно если вам нужно поддерживаться старые браузеры.
Если вам нужна реактивность, вы можете реализовать свой велосипед хоть на pure js, хоть с jQuery, но с React/Vue/Angular/... это делать удобнее и быстрее.
Если вам нужен базовый UI, вы можете рисовать свои компоненты, но удобнее взять Bootstrap/MUI/Tailwind/Materialize
Когда задача сделать продукт, который будет работать максимально быстро на очень ограниченных устройствах и в плохом сетевом окружении - конечно вы будете думать об оптимизации верстки, графики, JS (лучше вообще без сторонних либ).
Каждый слой абстракции pure js -> jQuery -> React.. добавляет свой оверхед, с этим спорить глупо. Хотя, конечно, в разном объеме, но вот будет ли он значимым для примера с простым магазином? Я думаю что нет. Именно поэтому мой поинт в том, что ничего страшного в этом нет.
Справедливости ради есть и другой тренд - когда для решения какой-то простой задачи (условно 2+2) начинают тянуть сторонные либы, и в результате общий бандл пухнет, при том что 99% функционала этих либ никак не используется, но вроде современные сборщики с этим научились успешно справляться.
Согласен. Но если вы не знаете когда нужно заниматься оптимизацией, то вы просто никогда не запустите крупный проект.
А ведь еще может оказаться, что вы все-таки добежали с вашим очень оптимизированном продуктом до пользователя, а он такая зараза его не оценил. Потому что вы не попали в хотелки пользователя, или у конкурента продукт не оптимизированный, но зато решает задачи лучше. И все ваши усилия по оптимизации просто почешут ваше самолюбие, которое на хлеб не намажешь.
Понимать когда нужно и когда не нужно вкладываться в оптимизацию на порядок важнее на мой взгляд.
В сухом остатке - оверинженеринг зло, но и убиваться в оптимизацию зло не меньше.
Если медленее - вопросов нет. Мой поинт в том, что нет ничего плохого в условном "магазине с десятком товаров на Laravel/Django с React/Vui", если есть выигрышь в скорости создания. У опытного разработчика может быть в запасе много наработок, и если копи-паст за час позволит получить рабочий продукт, который требует немного больше ресурсов, то ну и фиг с ним. Бизнесу важна скорость, а не идеальные (с точки зрения инженеров) решения.
Если у вас в проекте жесткие требования по производительности и по ограничению ресурсов - конечно нужен иной подход. Если с применением либ время разработки больше, чем без, и нет требований к поддержке и развитию - конечно же не нужно их туда тащить.
имхо это "общеводство". Жрут ли сайты с React больше памяти? При прочих равных да. Но и сайт с jQuery тоже потребляют больше, если сравнивать с ванильным JS, вообще без использования каких-то бибилиотек.
И это при "прочих равных", при условии, что разработчик квалифицированный. В противном случае утечками памяти можно выжрать ого-го и на ванильном JS.
Но! Скорость разработки с использованием бибилиотек и фреймворков заметно выше, чем без них. И это важнее для бизнеса, чем вопрос потребление лишних десятков и сотен мегабайн на клиенте. А компромис скорость разработки vs потребление ресурсов начал смещаться когда с Assembler перешли на более высокие языки программирования, если даже не раньше.
Возвращаясь к промеру - для магазина с десятком товаров вообще лучше бы использовать no-code/low-code подходы, или простигосподи налайвкодить. Но и катастрофы от выстрела пушкой тоже нет, если это прямо быстро. Пусть лучше инженер страдает от нарушенного чувства прекрасного, чем от голода =)
Конечно, есть более удобные продукты для взрослых решений, но если нужно что-то быстро сделать без гибких возможностей и инкрементальных бэкапов, то кажется, вполне годное решение.
Если сообщение было отклонено всеми потребителями, превышено количество попыток обработки или просрочилось по 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 # мучайтесь, уроды"
Роль JS не сводится к "управлению DOM", хотя это одна из важных задач, для которых он создавался. Бизнес-логика, валидация форм, взаимодействие с пользователем (реация на события) и вот это вот все.
Что касается роли конкретно jQuery, то он появился тогда, когда был зоопарк реализаций API в браузерах. Сейчас API стандартизирован, и рабочая лошадка document.queryselector работает везде. Так ли нужен он (jQuery) вообще?
Если вам нужно манипулировать DOM, валидировать формы или анимировать элементы, то вы можете спокойно делать разработку на pure js, но с jQuery может быть удобнее, особенно если вам нужно поддерживаться старые браузеры.
Если вам нужна реактивность, вы можете реализовать свой велосипед хоть на pure js, хоть с jQuery, но с React/Vue/Angular/... это делать удобнее и быстрее.
Если вам нужен базовый UI, вы можете рисовать свои компоненты, но удобнее взять Bootstrap/MUI/Tailwind/Materialize
Когда задача сделать продукт, который будет работать максимально быстро на очень ограниченных устройствах и в плохом сетевом окружении - конечно вы будете думать об оптимизации верстки, графики, JS (лучше вообще без сторонних либ).
Каждый слой абстракции pure js -> jQuery -> React.. добавляет свой оверхед, с этим спорить глупо. Хотя, конечно, в разном объеме, но вот будет ли он значимым для примера с простым магазином? Я думаю что нет. Именно поэтому мой поинт в том, что ничего страшного в этом нет.
Справедливости ради есть и другой тренд - когда для решения какой-то простой задачи (условно 2+2) начинают тянуть сторонные либы, и в результате общий бандл пухнет, при том что 99% функционала этих либ никак не используется, но вроде современные сборщики с этим научились успешно справляться.
Согласен. Но если вы не знаете когда нужно заниматься оптимизацией, то вы просто никогда не запустите крупный проект.
А ведь еще может оказаться, что вы все-таки добежали с вашим очень оптимизированном продуктом до пользователя, а он такая зараза его не оценил. Потому что вы не попали в хотелки пользователя, или у конкурента продукт не оптимизированный, но зато решает задачи лучше. И все ваши усилия по оптимизации просто почешут ваше самолюбие, которое на хлеб не намажешь.
Понимать когда нужно и когда не нужно вкладываться в оптимизацию на порядок важнее на мой взгляд.
В сухом остатке - оверинженеринг зло, но и убиваться в оптимизацию зло не меньше.
Если медленее - вопросов нет. Мой поинт в том, что нет ничего плохого в условном "магазине с десятком товаров на Laravel/Django с React/Vui", если есть выигрышь в скорости создания. У опытного разработчика может быть в запасе много наработок, и если копи-паст за час позволит получить рабочий продукт, который требует немного больше ресурсов, то ну и фиг с ним. Бизнесу важна скорость, а не идеальные (с точки зрения инженеров) решения.
Если у вас в проекте жесткие требования по производительности и по ограничению ресурсов - конечно нужен иной подход. Если с применением либ время разработки больше, чем без, и нет требований к поддержке и развитию - конечно же не нужно их туда тащить.
имхо это "общеводство". Жрут ли сайты с React больше памяти? При прочих равных да. Но и сайт с jQuery тоже потребляют больше, если сравнивать с ванильным JS, вообще без использования каких-то бибилиотек.
И это при "прочих равных", при условии, что разработчик квалифицированный. В противном случае утечками памяти можно выжрать ого-го и на ванильном JS.
Но! Скорость разработки с использованием бибилиотек и фреймворков заметно выше, чем без них. И это важнее для бизнеса, чем вопрос потребление лишних десятков и сотен мегабайн на клиенте. А компромис скорость разработки vs потребление ресурсов начал смещаться когда с Assembler перешли на более высокие языки программирования, если даже не раньше.
Возвращаясь к промеру - для магазина с десятком товаров вообще лучше бы использовать no-code/low-code подходы, или простигосподи налайвкодить. Но и катастрофы от выстрела пушкой тоже нет, если это прямо быстро. Пусть лучше инженер страдает от нарушенного чувства прекрасного, чем от голода =)
Ну если так быстрее в разработке, то почему нет.
Браво, то что 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 # мучайтесь, уроды"