Вы очень лукавите, рассказывая о сложностях настройки кластера.
В предложенном вами решения, все компоненты стандартные, хорошо документтрованы и достаточно просты в настройке и эксплуатации.
Сложность любого кластера не в его настройке, а в его поддержке. Чем ваше решение поможет когда кластер развалиться, окажеться в не согласованном состоянии и будет два мастера каждый со своим набором не отреплицированных транзакций?
Поддержу на 100%, я учавствовал в проекте по созданию low-code платформы. Из своего опыта могу сказать следующее.
Очень узкий сегмент потребителей, это точно не enterprise, а часто даже не SMB.
Для сборки тупеньких проектов и mvp вполне себе решение, но как только заходит разговор про кастомные интеграции например или про сложный BPM, то ничего лучше классической разработки просто нет.
Уровень вхождения в технологию. Предельно низкий, но и на выходе получаеться решение предельно низкого качества, за частую просто не пригодное к масштабированию и дальнейшему развитию.
В целом направление больше распиарено, чем может реально принести пользу.
В америке где заказчик не так притязателен, может и можно клепать сайты на Bubble, но в России зачастую на простейший сайт такой UI/UX накрутят, что даже опытные разрабы воют, а глубина кастомизации именно UI у подобных решений весьма ограничена, и даже не столько возможностями продукта, сколько необходимостью дать простые инструменты для не разработчика и не заставлять учить его js/html/css/etc.
Намешали пресное с солёным, да и пример с сахарницей как и любые за уши притянутые с бургерами, ничего не объяснил, а только жути нагнал.
Паттерн наблюдатель никакого не имеет отношения к событиям. Это разные вещи, и зауши притягивать MediatR и его реализацию к событиям net вообще не стоит.
Статья вообще не расскрывает сути как устроены события, что такое просто deligate и чем он отличаеться от multicast delegate.
Про вызов событий не верно написано, в каком потоке будет вызвано события зависит от того как вызываеться событие. Invoke вызовет в потоке в котором вызываеться событие. BeginInvoke сделает вызов с переключение контекста на сторону обработчика.
Если не отписываться от событий то GC такой объект не удалит, для него это зависшие ссылки.
В общем можно долго продолжать, но посыл я думаю понятен.
Слишком абстрактно, если расматривать с точки зрения программиста совсем путанно.
Сначала как мне кажеться стоило бы чётко прояснить что есть однопоточный код и много поточный.
Таск это абстракция, но не над потоком, а над задачей, которая в свою очередь может выполнена и в текущем потоке.
Асинхронное выполнение тоже не говорит о том что выполнение будет передано отдельному потоку. Это термин часто путают с параллелтеым выпонением, но это не так, это два разных способа выполнения.
Про асинхронность стоит вспоминать когда задача передаёться третьей стороне, например сетевые вызовы. Запрос уходит за границы выполняемого кода, там выполняються свои обработчики и к нам приходит лишь результат.
Вроде бы похоже на параллельное выполнение, нл только потребляються ресурсы не нашего прлцесса и даже не нашего исполняющего устройства, а где то с боку по сути
Обычный npm умеет link и довольно давно. Если это чем то хуже чем то что делает pnpm то чем? Визуально быстрее, тут вообще без комментариев, без замеров нет смысла об этом писать.
Вы очень лукавите, рассказывая о сложностях настройки кластера.
В предложенном вами решения, все компоненты стандартные, хорошо документтрованы и достаточно просты в настройке и эксплуатации.
Сложность любого кластера не в его настройке, а в его поддержке. Чем ваше решение поможет когда кластер развалиться, окажеться в не согласованном состоянии и будет два мастера каждый со своим набором не отреплицированных транзакций?
Не первый раз вижу статьи с анализом чужих продуктов, из этого закономерный вопрос, а можно результаты проверок самой Pvs-Studio увидеть?
Такая прекрасная статья ни о чём, что даже комментировать не хочеться.
Накидали в кучу всего, ни слова как правильно писать запросы.
Какие конструкции в запросах к каким последствиям приводят, какие конструкции следует использовать и когда.
Короче сколько их статей не читал, вода водой.
Поддержу на 100%, я учавствовал в проекте по созданию low-code платформы. Из своего опыта могу сказать следующее.
Очень узкий сегмент потребителей, это точно не enterprise, а часто даже не SMB.
Для сборки тупеньких проектов и mvp вполне себе решение, но как только заходит разговор про кастомные интеграции например или про сложный BPM, то ничего лучше классической разработки просто нет.
Уровень вхождения в технологию. Предельно низкий, но и на выходе получаеться решение предельно низкого качества, за частую просто не пригодное к масштабированию и дальнейшему развитию.
В целом направление больше распиарено, чем может реально принести пользу.
В америке где заказчик не так притязателен, может и можно клепать сайты на Bubble, но в России зачастую на простейший сайт такой UI/UX накрутят, что даже опытные разрабы воют, а глубина кастомизации именно UI у подобных решений весьма ограничена, и даже не столько возможностями продукта, сколько необходимостью дать простые инструменты для не разработчика и не заставлять учить его js/html/css/etc.
Намешали пресное с солёным, да и пример с сахарницей как и любые за уши притянутые с бургерами, ничего не объяснил, а только жути нагнал.
Паттерн наблюдатель никакого не имеет отношения к событиям. Это разные вещи, и зауши притягивать MediatR и его реализацию к событиям net вообще не стоит.
Статья вообще не расскрывает сути как устроены события, что такое просто deligate и чем он отличаеться от multicast delegate.
Про вызов событий не верно написано, в каком потоке будет вызвано события зависит от того как вызываеться событие. Invoke вызовет в потоке в котором вызываеться событие. BeginInvoke сделает вызов с переключение контекста на сторону обработчика.
Если не отписываться от событий то GC такой объект не удалит, для него это зависшие ссылки.
В общем можно долго продолжать, но посыл я думаю понятен.
Причём тут ETL?
Кастомный парсер SQL диалекта, коих уже вагон, будет +1.
Код не эквивалентен ни разу.
Js вызываеться последовательно цепочкой then.
Эквивалентный вызов был бы.
DoFirstThing().ContinueWith(_ => DoSecondThing().ContinueWith(_ => DoThirdThing()));Перестановка одной скобки в корень бы поменяло поведение. И никакой UnWrap вам тут был бы не нужен.
А причём тут эпичное вступление про питон?
Слишком абстрактно, если расматривать с точки зрения программиста совсем путанно.
Сначала как мне кажеться стоило бы чётко прояснить что есть однопоточный код и много поточный.
Таск это абстракция, но не над потоком, а над задачей, которая в свою очередь может выполнена и в текущем потоке.
Асинхронное выполнение тоже не говорит о том что выполнение будет передано отдельному потоку. Это термин часто путают с параллелтеым выпонением, но это не так, это два разных способа выполнения.
Про асинхронность стоит вспоминать когда задача передаёться третьей стороне, например сетевые вызовы. Запрос уходит за границы выполняемого кода, там выполняються свои обработчики и к нам приходит лишь результат.
Вроде бы похоже на параллельное выполнение, нл только потребляються ресурсы не нашего прлцесса и даже не нашего исполняющего устройства, а где то с боку по сути
Не понятно к чему статья?
Обычный npm умеет link и довольно давно. Если это чем то хуже чем то что делает pnpm то чем? Визуально быстрее, тут вообще без комментариев, без замеров нет смысла об этом писать.
Ничего интерестного, а некоторые решения вообще вызывают вопросы.
Зачем считать k при каждом селекте? Почему не считаеть его при апдейтах и вставках.
Зачем считать такой сложный индекс, когда его можно посчитать по заранее рассчитанному полю.
Для хранения номеров задач можно использовать векторы и не заниматься разбиением строк.
В целом если говорить про реально большой объем данных то решение так себе.
Построение виртуальных списков с виртуальными скролами старо как мир, поэтому выносить его в разряд новаций я бы не стал.
Это больше смахивает на композицию, но уж никак не на декортатор