Я так понимаю эти проценты банку уже включены в стоимость покупки?
Мне как-то предлагали в рассрочку в МВидео стиралку, дошёл до финала и увидел реальную стоимость стиралки и "комиссию" за рассрочку. И да, переплаты не было, относительно цены в МВидео. Она была относительно цены в других магазинах и как раз на сумму процентов банку.
Но не исключаю, что в качестве рекламной приманки на некоторые товары нет этой наценки. Эдакое вложение в рекламу, видимо.
Но это ухудшило бы читабельность, т.к. планы различаются в основном ключевыми словами, вроде конкретного типа join.
Не знаю на кого рассчитана статья, но если на тех, кто только учится, то им как раз было бы полезно увидеть что именно из текста ANALYZE надо найти. Не просто "что искать", а прямо на примере "вот здесь есть строчка, вот так она выглядит, обратите внимание".
Ну и опять же, можно приводя примеры ответов, скрывать ненужные детали и оставить только ключевые моменты. Так или иначе, пример на что смотреть - не лишний.
Сейчас получается так - читаешь статью и что бы понять как это работает, надо обязательно сесть за рояль и самому накидать всяких примеров, что бы увидеть результат. С одной стороны - безусловно полезно закрепить на практике. С другой - посмотреть заранее что закреплять было бы лучше. Да и впечатление от статьи сложилось бы другое.
В целом хорошо описано, приятно читать, нет воды. Но вот этот момент, как мне кажется, не помешал бы.
Ну понятно, но транзакция позволит не появиться фантомной записи (без индекса в эластике), а resilient позволит или убедиться, что они всегда парой или вернуть ошибку. Прямо как первый вариант. Просто не пойму почему нельзя было повторить запросы эластика, если они не сработали в первый раз. Было какое-то бизнес требование?
А почему нельзя используя транзакцию PostgreSQL сделать запись в эластик (как в самом первом варианте) и если она не прошла, повторить? Resilient вариант, так сказать. Если он не пройдёт ещё несколько раз, вернуть ошибку клиенту, т.к. если что-то с эластиком случилось, то клиент всё равно не получит из него данных, если ему вернуть ОК.
Там шорткаты на разные действия можно настраивать. Показать, скрыть, показать, снова скрыть. Сами листики можно отдельно настраивать так же. Думаю стоит просто глянуть.
Вообще штука удобная когда надо какой-то кусок кода/текста быстро куда-то сохранить, что бы оно не потерялось после внезапно апдейта системы. Быстро заметочку сделать тоже хорошо. Но не эти. Открыл для себя https://www.simplestickynotes.com/. Функций больше, пользоваться проще и таскбар не захламляет.
У меня был кейс, когда диаграмму надо было в ворде держать для последующей распечатки. Но потом выяснилось, что печатать надо в разных форматах (А5, А4, А3 и т.п.). Пересохранил в SVG и вопрос был закрыт. Когда было в PNG печаталось, мягко говоря, не очень. А так отдал и пусть ресайзят как хотят.
Единственная проблема, не все SVG одинаково полезны. Были с этим заморочки при сохранении из Word в PDF. Не знаю почему, но иногда SVG растеризовался в PNG, со всеми вытекающими. Пришлось перебрать разные варианты настроек экспорта и перегонять из одного приложения диаграмм в другое.
Не совсем. Довольно часто бывает, что на госуслугах один полис, а сам фонд обязательного медицинского страхования выдал другой. И потом с такими вот выкрутасами приходиться что-то придумывать.
Ну на самом деле MudBlazor в этом плане довольно показателен. Туда много людей коммитит и, по сути, это такая сборная солянка проблем. О чём, кстати, в упомянутом issue и сказано. К тому же компоненты эти существуют давно, так что вероятно и легаси подходы ещё остались где-то. Другие популярные наборы делают уже отдельные компании в качестве free версий своих компонент. Там уже дела чуть получше, т.к. нет такого базара и больше контроля.
А уж какое там количество проблем с асинхронностью... Одни только вызовы асинк методов в сеттерах чего стоят. Из-за этого часто натыкался на то, что тот или иной клик по меню просто не реагирует и не ругается. А всё из-за того, что где-то внутри обработчика по пути вызовов была ошибка логики (у меня), но сам обработчик клика асинхронностью, однако "его никто не ждёт". Коммитил туда несколько раз, но авторы очень тяжко отвечают.
Потому что в обработчике команды у меня теперь диссонанс. Вызвать команду? Звучит странно, команду из обработчика команды, или можно? И насколько быстро мне станет тяжело понимать, что происходит?
Событие? Нужно убедиться, что оно перехватиться и это подходит только в том случае, если я допускаю ошибки в обработчике события, т.к. исключения, брошенные в процессе обработки события игнорятся - ну специфика такая, что событие бросил и забыл. Вызвать сервис? А на кой мне медиатор, чтоб только в контроллере его юзать?
Опять же, от ситуации зависит. Думаю где-то вызвать команду вполне себе. Где-то ивент послать. Где запрос. Где-то сервис.
Нельзя так взять и сказать что лучше.
События они несколько про другое. Это больше асинхронное исполнение. Их не надо ждать. Как раз буквально "бросил и забыл".
Я выше упустил Ваш поинт про "Достаточно взять любую ситуацию с необходимостью изменения контракта", давайте к нему, чтоб выяснить всё таки, какие преимущества даёт mediatr и какие проблемы решает?
Если меняются входные параметры - в любом случае менять и вызов и реализацию. Если меняется возвращаемый результат - аналогично. А что ещё в контракт входит?
В принципе да, согласен. Пример в этом плане не подходящий.
В моём случае мне показалось проще использовать его для разделения функциональности. Не внедряя в контроллеры сервисы и разделяя функции по хендлерам потом проще в этом всём ориентироваться. Не создавать один сервис с кучей методов и использовать его в контроллере, а создавать на каждую функцию свой хендлер. Отделяя их по фичам.
"Проблема" которую он решил для меня - разделение функциональности по файлам.
А про душу! Про их душу ничего не сказали! Нашли или нет в итоге?
А что за прикол во фризах после всяких супер-комбо и каких-то мощных ударов? Не в первый раз замечаю в файтингах.
Я так понимаю эти проценты банку уже включены в стоимость покупки?
Мне как-то предлагали в рассрочку в МВидео стиралку, дошёл до финала и увидел реальную стоимость стиралки и "комиссию" за рассрочку. И да, переплаты не было, относительно цены в МВидео. Она была относительно цены в других магазинах и как раз на сумму процентов банку.
Но не исключаю, что в качестве рекламной приманки на некоторые товары нет этой наценки. Эдакое вложение в рекламу, видимо.
Не знаю на кого рассчитана статья, но если на тех, кто только учится, то им как раз было бы полезно увидеть что именно из текста ANALYZE надо найти. Не просто "что искать", а прямо на примере "вот здесь есть строчка, вот так она выглядит, обратите внимание".
Ну и опять же, можно приводя примеры ответов, скрывать ненужные детали и оставить только ключевые моменты. Так или иначе, пример на что смотреть - не лишний.
Сейчас получается так - читаешь статью и что бы понять как это работает, надо обязательно сесть за рояль и самому накидать всяких примеров, что бы увидеть результат. С одной стороны - безусловно полезно закрепить на практике. С другой - посмотреть заранее что закреплять было бы лучше. Да и впечатление от статьи сложилось бы другое.
В целом хорошо описано, приятно читать, нет воды. Но вот этот момент, как мне кажется, не помешал бы.
Везде указаны EXPLAIN ANALYZE, но нет ни одного примера вывода. Надо было промпт дополнить. Ну или руками надёргать примеров.
Только дошло. Это же сам автор плеера.
Пардон, не туда тыкнул в ответ. Надо было чуть выше.
Сейчас выяснится, что заплатить не так уж и сложно (в 2025 году!), а смотреть на компьютере вообще, как минимум, странно.
Ну понятно, но транзакция позволит не появиться фантомной записи (без индекса в эластике), а resilient позволит или убедиться, что они всегда парой или вернуть ошибку. Прямо как первый вариант. Просто не пойму почему нельзя было повторить запросы эластика, если они не сработали в первый раз. Было какое-то бизнес требование?
А почему нельзя используя транзакцию PostgreSQL сделать запись в эластик (как в самом первом варианте) и если она не прошла, повторить? Resilient вариант, так сказать. Если он не пройдёт ещё несколько раз, вернуть ошибку клиенту, т.к. если что-то с эластиком случилось, то клиент всё равно не получит из него данных, если ему вернуть ОК.
Было бы интересно посмотреть на применение этого подхода в случае вычисляемых выражений.
Например, когда у продукта есть список покупателей и надо отфильтровать по его количеству.
Мне одному кажется, что его голова предполагает режим с красным цветом "лампочки"?
Там шорткаты на разные действия можно настраивать. Показать, скрыть, показать, снова скрыть. Сами листики можно отдельно настраивать так же. Думаю стоит просто глянуть.
Нет. Но если открыть любое окно после "свернуть всё", они снова отображаются. Да и отдельный шорткат есть на "показать/скрыть".
Вообще штука удобная когда надо какой-то кусок кода/текста быстро куда-то сохранить, что бы оно не потерялось после внезапно апдейта системы. Быстро заметочку сделать тоже хорошо. Но не эти. Открыл для себя https://www.simplestickynotes.com/. Функций больше, пользоваться проще и таскбар не захламляет.
У меня был кейс, когда диаграмму надо было в ворде держать для последующей распечатки. Но потом выяснилось, что печатать надо в разных форматах (А5, А4, А3 и т.п.). Пересохранил в SVG и вопрос был закрыт.
Когда было в PNG печаталось, мягко говоря, не очень. А так отдал и пусть ресайзят как хотят.
Единственная проблема, не все SVG одинаково полезны. Были с этим заморочки при сохранении из Word в PDF. Не знаю почему, но иногда SVG растеризовался в PNG, со всеми вытекающими. Пришлось перебрать разные варианты настроек экспорта и перегонять из одного приложения диаграмм в другое.
Не совсем. Довольно часто бывает, что на госуслугах один полис, а сам фонд обязательного медицинского страхования выдал другой. И потом с такими вот выкрутасами приходиться что-то придумывать.
Ну на самом деле MudBlazor в этом плане довольно показателен. Туда много людей коммитит и, по сути, это такая сборная солянка проблем. О чём, кстати, в упомянутом issue и сказано. К тому же компоненты эти существуют давно, так что вероятно и легаси подходы ещё остались где-то.
Другие популярные наборы делают уже отдельные компании в качестве free версий своих компонент. Там уже дела чуть получше, т.к. нет такого базара и больше контроля.
А уж какое там количество проблем с асинхронностью... Одни только вызовы асинк методов в сеттерах чего стоят. Из-за этого часто натыкался на то, что тот или иной клик по меню просто не реагирует и не ругается. А всё из-за того, что где-то внутри обработчика по пути вызовов была ошибка логики (у меня), но сам обработчик клика асинхронностью, однако "его никто не ждёт".
Коммитил туда несколько раз, но авторы очень тяжко отвечают.
Опять же, от ситуации зависит. Думаю где-то вызвать команду вполне себе. Где-то ивент послать. Где запрос. Где-то сервис.
Нельзя так взять и сказать что лучше.
События они несколько про другое. Это больше асинхронное исполнение. Их не надо ждать. Как раз буквально "бросил и забыл".
В принципе да, согласен. Пример в этом плане не подходящий.
В моём случае мне показалось проще использовать его для разделения функциональности. Не внедряя в контроллеры сервисы и разделяя функции по хендлерам потом проще в этом всём ориентироваться. Не создавать один сервис с кучей методов и использовать его в контроллере, а создавать на каждую функцию свой хендлер. Отделяя их по фичам.
"Проблема" которую он решил для меня - разделение функциональности по файлам.
Да, но в Вашем примере речь про ивент, а не вызов сервиса.
Ну от ситуации зависит. Всё же это разные вещи.