Не думаю, что они сделали это специально. Просто сами немного недопоняли алгоритм, поэтому он у них такой получился. Они шли на контакт без проблем. Я разговаривал с ними по телефону (еще до дизассемблера), пытаясь выяснить алгоритм контрольной суммы. Они искренне не понимали моего вопроса, ссылаясь на спецификацию modbus, что у них все сделано ровно как там написано. Документация к устройствам была подробная, к ней вопросов не было. Кроме того они предоставили испытательный стенд, который сами использовали - коробочка с разъемами, которая подключалась к контроллеру и эмулировала тензодатчики, концевики и силовые установки. Понятно, что внутри там пара конденсаторов с сопротивлениями и реле. Но это готовое устройство. Подключил и работай. Цена там какая-то смешная была, в районе 5к. Адамовские I/O модули стоили дороже.
О каком временном периоде вы говорите? О домах в деревне, в которых жили наши бабушки и дедушки? Я тоже задавался этим вопросом. Думаю, ответ примерно такой:
Теплопотери в тех домах были совершенно другими (намного выше), как раз из-за утеплителя и прочего. Окна были деревянные, рассохшиеся, стекла прижаты штапиком, не герметично, через которые сквозило, как и через двери. Поэтому окна заклеивали на зиму. Сейчас же стремятся минимизировать теплопотери. Везде пластиковые или качественные деревянные окна с уплотнителями. Современный дом превратился в термос не только с точки зрения тепла, но и влаги.
В тех домах часто не было ни ванны, ни туалета, стирка тоже выполнялась вне дома.
Обычно была баня, там мылись и стирали. Туалет на улице. То есть пара в доме было в разы меньше. Пар образовывался только от выдыхаемого воздуха и от приготовления пищи. А летом в доме никто не готовил, готовили в летних кухнях или верандах.
Когда вы принимаете душ или просто горячую ванну, зеркало запотевает, потому что пара выделяется больше, чем может протянуть вентиляция. А еще в ванной дверь закрыта, слабая приточка. Естественно, весь этот пар пойдет в кровлю.
Кроме того были печи, которые постоянно вытягивали воздух из помещения, это как дополнительное проветривание.
Поэтому вопрос грибка на крыше не стоял так остро.
Я бы сказал, что это не паразиты, а определенная категория людей. Она была, есть и будет. Называть их можно как угодно, я лишь использовал термин из статьи, чтобы разночтений не возникало. С ними ничего сделать невозможно и не нужно. Это просто статистическая реальность. Нужно ее принять :)
Эти товарищи обитают в большой концентрации в крупных организациях, где одна рука не знает, что делает другая. Очень хорошо показано в фильме Секрет моего успеха (1987).
Вы спросили как, я ответил Но я не говорил, что это просто :)
Вы правы, что это куча накладных расходов, но, при желании, этот стиль можно натянуть не только на HTTP.
По поводу ответа для сокета, я лишь написал это слово (Ответ) чтобы две строчки отличались по смыслу, чтобы было понятно направление сообщения, а вы зачем-то меня тыкаете носом в техническую неточность. Я ведь не на экзамене и у нас нет задачи друг друга на чем-то подлавливать в этой дискуссии... Или есть?
На мой взгляд, описываемая вами проблема лежит на другом уровне. Предложенные вами методы правильные, я с ними абсолютно согласен, но, как это ни печально, они из идеального мира и в большинстве случаев не работают. Все потому, что есть другой феномен и он на уровне психологии.
Есть очень хорошая статья Четыре типажа программистов. Хоть ее название указывает нам на программистов, в действительности, все эти типажи подходят для любых других типов профессий, потому что они описывают типаж человека, профессия здесь не имеет значения. Обратите внимание на типаж "Пассажир" и на то, что "Начальники таких обожают".
Из опыта и наблюдений:
Головной офис очень крупной компании (40к+ человек). ТОПы - сплошные пассажиры. Практически все руководящие должности занимают пассажиры. Как очень точно подмечено в статье - руководители их обожают. Вот и получается замкнутый круг: руководители высшего звена берут себе в подчинение пассажиров, а те берут себе пассажиров. Пассажиры мастерски заставляют работать кого-то вместо себя. Но поощрять они их не будут. Если простой смертный работяга заикнется про премию и если пассажиру это не в тягость, если бюджет есть, он, с барского плеча, может и отвесить, но рвать задницу не будет. Мастерски придумает 10 аргументов, почему подчиненный премию не заслужил или что сейчас очень сложный период, давай в другой раз. И может кормить завтраками годами!
Однако когда пассажир пойдет к своему руководителю просить для себя, там вопрос о премии и повышении з/п долго висеть не будет. В итоге, в сложный период (даже если он действительно настал для компании), не повысят никому, а пассажирам, хоть на копейку, но повысят.
Еще пассажиры очень хорошо чувствуют, когда начинает пахнуть жареным. Они чувствуют это еще когда нет даже намека на дым. Поэтому очень своевременно принимают подходящее решение - устранить угрозу или срочно перейти на другой проект/должность/компанию. За руку их поймать практически невозможно. Потому что вышестоящие их обожают, а подчиненные не имеют выхода на начальника пассажира, а если имеют, то не смогут доказать начальнику некомпетентность. Начальник не поверит, ибо если бы начальник сам был достаточно грамотным и проницательным, никогда бы не взял себе в подчинение пассажира и тем более не доверил бы ему ответственный проект.
Я наблюдал за одним таким человеком N, его переводили с одного ответственного проекта на другой. Каждый проект поднимался с нуля, вокруг было много бурной деятельности. Когда появлялся новый проект, этого N вновь бросали на новый проект, как незаменимого, хотя старый так и не взлетел. И последующий не взлетел. Но вот в одном из департаментов вдруг увольняется руководитель. Как вы думаете, кого ставят в качестве И.О. на место руководителя? Правильно, этого N! Он не довел до ума ни один проект и ему за это ни разу ничего не было, при этом он везде на подхвате, на хорошем счету. Все сотрудники, во всех проектах или направлениях, где этот N побывал, каждый раз с облегчением вздыхают, когда того переводят. И при этом не перестают удивляться - как?! Почему ему это доверяют?! Ну ведь он некомпетентен! Вот только этот N умеет говорить как бог, он умеет сказать 1000 слов и не сказать ничего.
Прошу прощения, за столь длительное вступление.
Ваш рецепт хороший, но в таких ситуациях он не сработает. Этот N и его окружение будут водить за нос, вы не сможете провести с ним интервью. Вы будете искать окно в его расписании и найдете только 20 минут в конце следующего месяца. Когда час Х наконец настанет, его срочно вызовет руководитель прямо во время вашей беседы. Руководители других направлений точно такие же, они могут только сказать - сделайте! И убегут на очередное совещание. Они не скажут как сделать, они не скажут на что обратить внимание. Они могут даже не сказать конкретно "сделайте", а как-то расплывчато, то есть непонятно надо делать или нет. Когда пройдет время и вопрос этого коснется, он воскликнет - а вы что, не сделали?! Все, кто присутствовал на прошлом и на этом разговоре только переглянутся в недоумении (ведь в прошлый раз не было четкой команды, в прошлый раз он просто сбежал на очередное совещание, потому что вопрос был неудобный и этот человек просто не хотел брать ответственность).
Такие люди никогда не наймут аналитика бизнес-процессов. Они убедят вышестоящих в том, что такой человек не нужен. А если таки он будет нанят, они будут всячески саботировать его деятельность и когда аналитик придет к нанимателю в обещанный срок с неполными данными, эти саботажника скажут: Вот, ВиванИваныч! Мы же говорили! Этот аналитик ничего не решит, все эти аналитики - шарлатаны, это пустая трата денег! Почешут ИванИванычу за ушком, тот расплывется в кресле и успокоится.
Нет, я не призываю сложить руки и ничего не делать )))
Я лишь привел пример ситуации. Есть ли у вас рекомендации на этот счет?
Отличное замечание. Спасибо за уточнение философской глубины подхода!
Однако я сознательно упростил формулировку.
Моя цель была показать практическую разницу, которую видит разработчик при переходе от RPC к REST.
Технически вы правы - REST это не просто "перенос", а смена парадигмы. Но психологически для разработчика это выглядит именно как "перенос глаголов". Большинство разработчиков не вникали в суть философии REST, отсюда и такие реализации. Повторюсь - REST очень красив, но у него высокий порог вхождения из-за его абстракции, иначе не было бы столько обсуждений вокруг него. Ваша ссылка на RSDN это доказывает, но там человек хочет разобраться и грамотный специалист ему объясняет на пальцах. Никто не обсуждает TCP/IP в таких масштабах, потому что протокол, там все понятно. В современном мире, ждать, что когда-то джуны познают эту философию - это что-то из области фантастики. Когда вокруг фреймворки и фреймврками погоняют, когда программируют мышкой, когда никто не знает и не хочет знать, что происходит под капотом метода из библиотеки, которая вызывает другую библиотеку, а та использует третью, мы получаем тонны багованного софта, который никто никогда не будет исправлять и который тратит ресурсы железа. Откуда столько фреймворков? Потому что это попытка (безусловно, успешная) снизить порог вхождения, упростить процесс разработки, повысить скорость разработки. Если человек выбирает фреймворк, он уже практически находится на пути невежества. Лишь единицы понимают, что происходит под капотом какого-нибудь коробочного ORM, а большинство перебирают в цикле строки, будто это какой-то массив в памяти. О какой философии REST может идти речь?
Это может быть сколько угодно неправильно, это может сколько угодно противоречить философии, но это факт и этого не изменить. Я лишь поднимаю этот факт на поверхность и даю несколько рекомендаций, как жить в такой ситуации.
Идемпотентность - прекрасное замечание. Но ведь это не свойство самого PUT, это вопрос некой договоренности, что при реализации PUT нужно делать идемпотентность, надо было об этом где-то почитать.
Давайте переложим ваш вопрос с лампочкой на JSON-RPC 2.0. Что будет при повторном запросе? Ошибка? Выключение?
Что мешает сделать идемпотентность при реализации POST? Отсутствие договоренности, из-за которой вы не можете быть уверены, что она есть?
А вы уверены, что те, кто реализовывал такие кривые методы, которые я приводил в статье, знали про идемпотентность и реализовали это свойство для PUT?
Я вот не уверен. Если они не смогли нормально разложить операции по доменам, есть ли гарантия, что для PUT они сделали как надо? Остается только надеяться, что они про это слышали и не забыли.
Идемпотентность должна быть всегда, в случае с POST в REST-RPC, этого требует сам подход, это неизбежность. При реализации такого подхода разработчик сам столкнется с этой проблемой при первых тестовых прогонах и реализует идемпотентность, если он о ней забыл. Ведь других методов нет.
Я вовсе не критиковал json-rpc 2.0, а лишь приводил его, как противовес. Но не рассматривал его как альтернативу, потому что и в нем всё не так, как разработчикам хотелось бы интуитивно. Он не плохой, со своими задачами справляется, но, как сказал Билли, в исполнении Караченцова, в фильме Человек с бульвара капуцинов:
Вот так мы отдыхаем, Джонни. А душе хочется чего-то другого: светлого, большого...
Каждый раз в статье, упоминая про json-rpc 2.0, я лишь подчеркиваю, что большинство реализаций псевдо-REST это по факту какой-то JSON-RPC или HTTP-RPC или как-то иначе его назвать, но он ничего не имеет общего с json-rpc 2.0, вот какая мысль звучит в статье. Название json-rpc уже занято.
Думаю, скотч не дал результата потому, что площадь фильтрующей поверхности осталась прежней, а закрыв часть воздушного канала ещё и придушили эффективность всасывания самого вентилятора (но это уже в пределах погрешности, т.к. рабочая область крыльчатки изначально перекрыта фильтом).
Вот если бы вентилятор был больше фильтра, тогда да, эффект был бы заметен, хоть и несущественный (зависит от того, насколько фильтр менше вентилятора).
Другими словами, количество проходящего воздуха через фильтр не изменилось после герметизации, тогда почему должна была измениться скорость очистки?
Допустим, рядом с этим вентилятором мы поставим ещё один, но без фильтра. Разве это как-то ухудшит скорость очистки? То же самое и здесь - без герметизации часть воздуха проходила мимо фильтра так же, как он частично будет проходить мимо если мы поставим рядом ещё один вентилятор, создающий поток в том же направлении.
Нужно отделять мух от котлет. Пытаться подтянуть все в одну систему, пусть даже она является чисто интерфейсной, в данном случае, — плохая практика. Сбор данных из куба в Excel или PowerBI, со всеми их доп. возможностями, не то же самое, что просматривать их в ProClarity
Если речь идет о статическом отчете, а куб используется для быстроты получения данных, то здесь еще можно понять, однако при таком раскладе нужно учитывать затраты на разработку и поддержку этой модели, а также на затраты по оборудованию, допуск по временному лагу на пополнение куба и т.д.
Понятное дело, что и с прежним вариантом интерфейса можно было жить. Я лишь хотел подчеркнуть, что консерватизм — упрямая штука. Даже когда предлагаешь реально более удобный вариант, его не сразу принимают.
И тут возникает вопрос — каждый ли негативный отзыв в начале означает концептуальное неудобство или это лишь вопли консерватизма, которые завтра стихнут?
Да, Вы павы, это растровый шрифт, поэтому, несмотря на включенный ClearType, он не сглаживался, вот и было не заметно, что опция включена. Я как-то не подумал об этом сразу. Мне почему-то казалось, что он TTF, в то время как на самом деле битмап. Ну и мне он просто больше нравится по начертанию. А когда в очередной версии винды его сменили на тахому, к которому тут же применилось сглаживание, в силу его векторности, это сразу бросилось в глаза.
Быть может потому, что в те времена на заводах были обязательные работы по техобслуживанию. За высочайшей подписью мастера цеха ИванИваныча.
На запчастях не экономили и дефицита в них не было. В плановое ТО входила регулярная замена цанг и других частей, поэтому и проблемы не было.
А частники умеют считать копеечку и пользуют эти цанги до тех пор, пока они не развалятся. Ну и запчасти сейчас достать сложно.
Не думаю, что они сделали это специально. Просто сами немного недопоняли алгоритм, поэтому он у них такой получился. Они шли на контакт без проблем. Я разговаривал с ними по телефону (еще до дизассемблера), пытаясь выяснить алгоритм контрольной суммы. Они искренне не понимали моего вопроса, ссылаясь на спецификацию modbus, что у них все сделано ровно как там написано. Документация к устройствам была подробная, к ней вопросов не было. Кроме того они предоставили испытательный стенд, который сами использовали - коробочка с разъемами, которая подключалась к контроллеру и эмулировала тензодатчики, концевики и силовые установки. Понятно, что внутри там пара конденсаторов с сопротивлениями и реле. Но это готовое устройство. Подключил и работай. Цена там какая-то смешная была, в районе 5к. Адамовские I/O модули стоили дороже.
О каком временном периоде вы говорите? О домах в деревне, в которых жили наши бабушки и дедушки? Я тоже задавался этим вопросом. Думаю, ответ примерно такой:
Теплопотери в тех домах были совершенно другими (намного выше), как раз из-за утеплителя и прочего. Окна были деревянные, рассохшиеся, стекла прижаты штапиком, не герметично, через которые сквозило, как и через двери. Поэтому окна заклеивали на зиму. Сейчас же стремятся минимизировать теплопотери. Везде пластиковые или качественные деревянные окна с уплотнителями. Современный дом превратился в термос не только с точки зрения тепла, но и влаги.
В тех домах часто не было ни ванны, ни туалета, стирка тоже выполнялась вне дома.
Обычно была баня, там мылись и стирали. Туалет на улице. То есть пара в доме было в разы меньше. Пар образовывался только от выдыхаемого воздуха и от приготовления пищи. А летом в доме никто не готовил, готовили в летних кухнях или верандах.
Когда вы принимаете душ или просто горячую ванну, зеркало запотевает, потому что пара выделяется больше, чем может протянуть вентиляция. А еще в ванной дверь закрыта, слабая приточка. Естественно, весь этот пар пойдет в кровлю.
Кроме того были печи, которые постоянно вытягивали воздух из помещения, это как дополнительное проветривание.
Поэтому вопрос грибка на крыше не стоял так остро.
Я бы сказал, что это не паразиты, а определенная категория людей. Она была, есть и будет. Называть их можно как угодно, я лишь использовал термин из статьи, чтобы разночтений не возникало. С ними ничего сделать невозможно и не нужно. Это просто статистическая реальность. Нужно ее принять :)
Эти товарищи обитают в большой концентрации в крупных организациях, где одна рука не знает, что делает другая. Очень хорошо показано в фильме Секрет моего успеха (1987).
Мой приняли как раз по поводу sunxi (Allwinner), но в Retroarch )))
Бинго! :)
Вы спросили как, я ответил
Но я не говорил, что это просто :)
Вы правы, что это куча накладных расходов, но, при желании, этот стиль можно натянуть не только на HTTP.
По поводу ответа для сокета, я лишь написал это слово (Ответ) чтобы две строчки отличались по смыслу, чтобы было понятно направление сообщения, а вы зачем-то меня тыкаете носом в техническую неточность. Я ведь не на экзамене и у нас нет задачи друг друга на чем-то подлавливать в этой дискуссии... Или есть?
Обычно колбэки в этом случае применяют, если по HTTP
Что-то типа
POST /process/123/commands{"action": "exec""replyTo": "https://foo.any/api/foo"}Можно применить REST при работе с брокером сообщений. Очереди/топики, как ресурсы, например.
Для вебсокета
Сообщение
{"method": "POST", "resource": "/process/123/commands"}Ответ
{"status": 200, "body": }На мой взгляд, описываемая вами проблема лежит на другом уровне. Предложенные вами методы правильные, я с ними абсолютно согласен, но, как это ни печально, они из идеального мира и в большинстве случаев не работают. Все потому, что есть другой феномен и он на уровне психологии.
Есть очень хорошая статья Четыре типажа программистов. Хоть ее название указывает нам на программистов, в действительности, все эти типажи подходят для любых других типов профессий, потому что они описывают типаж человека, профессия здесь не имеет значения. Обратите внимание на типаж "Пассажир" и на то, что "Начальники таких обожают".
Из опыта и наблюдений:
Головной офис очень крупной компании (40к+ человек). ТОПы - сплошные пассажиры. Практически все руководящие должности занимают пассажиры. Как очень точно подмечено в статье - руководители их обожают. Вот и получается замкнутый круг: руководители высшего звена берут себе в подчинение пассажиров, а те берут себе пассажиров. Пассажиры мастерски заставляют работать кого-то вместо себя. Но поощрять они их не будут. Если простой смертный работяга заикнется про премию и если пассажиру это не в тягость, если бюджет есть, он, с барского плеча, может и отвесить, но рвать задницу не будет. Мастерски придумает 10 аргументов, почему подчиненный премию не заслужил или что сейчас очень сложный период, давай в другой раз. И может кормить завтраками годами!
Однако когда пассажир пойдет к своему руководителю просить для себя, там вопрос о премии и повышении з/п долго висеть не будет. В итоге, в сложный период (даже если он действительно настал для компании), не повысят никому, а пассажирам, хоть на копейку, но повысят.
Еще пассажиры очень хорошо чувствуют, когда начинает пахнуть жареным. Они чувствуют это еще когда нет даже намека на дым. Поэтому очень своевременно принимают подходящее решение - устранить угрозу или срочно перейти на другой проект/должность/компанию. За руку их поймать практически невозможно. Потому что вышестоящие их обожают, а подчиненные не имеют выхода на начальника пассажира, а если имеют, то не смогут доказать начальнику некомпетентность. Начальник не поверит, ибо если бы начальник сам был достаточно грамотным и проницательным, никогда бы не взял себе в подчинение пассажира и тем более не доверил бы ему ответственный проект.
Я наблюдал за одним таким человеком N, его переводили с одного ответственного проекта на другой. Каждый проект поднимался с нуля, вокруг было много бурной деятельности. Когда появлялся новый проект, этого N вновь бросали на новый проект, как незаменимого, хотя старый так и не взлетел. И последующий не взлетел. Но вот в одном из департаментов вдруг увольняется руководитель. Как вы думаете, кого ставят в качестве И.О. на место руководителя? Правильно, этого N! Он не довел до ума ни один проект и ему за это ни разу ничего не было, при этом он везде на подхвате, на хорошем счету. Все сотрудники, во всех проектах или направлениях, где этот N побывал, каждый раз с облегчением вздыхают, когда того переводят. И при этом не перестают удивляться - как?! Почему ему это доверяют?! Ну ведь он некомпетентен! Вот только этот N умеет говорить как бог, он умеет сказать 1000 слов и не сказать ничего.
Прошу прощения, за столь длительное вступление.
Ваш рецепт хороший, но в таких ситуациях он не сработает. Этот N и его окружение будут водить за нос, вы не сможете провести с ним интервью. Вы будете искать окно в его расписании и найдете только 20 минут в конце следующего месяца. Когда час Х наконец настанет, его срочно вызовет руководитель прямо во время вашей беседы. Руководители других направлений точно такие же, они могут только сказать - сделайте! И убегут на очередное совещание. Они не скажут как сделать, они не скажут на что обратить внимание. Они могут даже не сказать конкретно "сделайте", а как-то расплывчато, то есть непонятно надо делать или нет. Когда пройдет время и вопрос этого коснется, он воскликнет - а вы что, не сделали?! Все, кто присутствовал на прошлом и на этом разговоре только переглянутся в недоумении (ведь в прошлый раз не было четкой команды, в прошлый раз он просто сбежал на очередное совещание, потому что вопрос был неудобный и этот человек просто не хотел брать ответственность).
Такие люди никогда не наймут аналитика бизнес-процессов. Они убедят вышестоящих в том, что такой человек не нужен. А если таки он будет нанят, они будут всячески саботировать его деятельность и когда аналитик придет к нанимателю в обещанный срок с неполными данными, эти саботажника скажут: Вот, ВиванИваныч! Мы же говорили! Этот аналитик ничего не решит, все эти аналитики - шарлатаны, это пустая трата денег! Почешут ИванИванычу за ушком, тот расплывется в кресле и успокоится.
Нет, я не призываю сложить руки и ничего не делать )))
Я лишь привел пример ситуации. Есть ли у вас рекомендации на этот счет?
Не уловил суть вопроса. Можете пояснить?
Отличное замечание. Спасибо за уточнение философской глубины подхода!
Однако я сознательно упростил формулировку.
Моя цель была показать практическую разницу, которую видит разработчик при переходе от RPC к REST.
Технически вы правы - REST это не просто "перенос", а смена парадигмы.
Но психологически для разработчика это выглядит именно как "перенос глаголов". Большинство разработчиков не вникали в суть философии REST, отсюда и такие реализации. Повторюсь - REST очень красив, но у него высокий порог вхождения из-за его абстракции, иначе не было бы столько обсуждений вокруг него. Ваша ссылка на RSDN это доказывает, но там человек хочет разобраться и грамотный специалист ему объясняет на пальцах. Никто не обсуждает TCP/IP в таких масштабах, потому что протокол, там все понятно. В современном мире, ждать, что когда-то джуны познают эту философию - это что-то из области фантастики. Когда вокруг фреймворки и фреймврками погоняют, когда программируют мышкой, когда никто не знает и не хочет знать, что происходит под капотом метода из библиотеки, которая вызывает другую библиотеку, а та использует третью, мы получаем тонны багованного софта, который никто никогда не будет исправлять и который тратит ресурсы железа. Откуда столько фреймворков? Потому что это попытка (безусловно, успешная) снизить порог вхождения, упростить процесс разработки, повысить скорость разработки. Если человек выбирает фреймворк, он уже практически находится на пути невежества. Лишь единицы понимают, что происходит под капотом какого-нибудь коробочного ORM, а большинство перебирают в цикле строки, будто это какой-то массив в памяти. О какой философии REST может идти речь?
Это может быть сколько угодно неправильно, это может сколько угодно противоречить философии, но это факт и этого не изменить. Я лишь поднимаю этот факт на поверхность и даю несколько рекомендаций, как жить в такой ситуации.
Идемпотентность - прекрасное замечание. Но ведь это не свойство самого PUT, это вопрос некой договоренности, что при реализации PUT нужно делать идемпотентность, надо было об этом где-то почитать.
Давайте переложим ваш вопрос с лампочкой на JSON-RPC 2.0. Что будет при повторном запросе? Ошибка? Выключение?
Что мешает сделать идемпотентность при реализации POST? Отсутствие договоренности, из-за которой вы не можете быть уверены, что она есть?
А вы уверены, что те, кто реализовывал такие кривые методы, которые я приводил в статье, знали про идемпотентность и реализовали это свойство для PUT?
Я вот не уверен. Если они не смогли нормально разложить операции по доменам, есть ли гарантия, что для PUT они сделали как надо? Остается только надеяться, что они про это слышали и не забыли.
Идемпотентность должна быть всегда, в случае с POST в REST-RPC, этого требует сам подход, это неизбежность. При реализации такого подхода разработчик сам столкнется с этой проблемой при первых тестовых прогонах и реализует идемпотентность, если он о ней забыл. Ведь других методов нет.
Ваш личный опыт - самый правильный учитель :)
Я лишь поделился своим опытом и наблюдениями, быть может, они окажутся полезными тем, у кого своего опыта недостаточно.
Я вовсе не критиковал json-rpc 2.0, а лишь приводил его, как противовес. Но не рассматривал его как альтернативу, потому что и в нем всё не так, как разработчикам хотелось бы интуитивно. Он не плохой, со своими задачами справляется, но, как сказал Билли, в исполнении Караченцова, в фильме Человек с бульвара капуцинов:
Каждый раз в статье, упоминая про json-rpc 2.0, я лишь подчеркиваю, что большинство реализаций псевдо-REST это по факту какой-то JSON-RPC или HTTP-RPC или как-то иначе его назвать, но он ничего не имеет общего с json-rpc 2.0, вот какая мысль звучит в статье. Название json-rpc уже занято.
объяву!
Думаю, скотч не дал результата потому, что площадь фильтрующей поверхности осталась прежней, а закрыв часть воздушного канала ещё и придушили эффективность всасывания самого вентилятора (но это уже в пределах погрешности, т.к. рабочая область крыльчатки изначально перекрыта фильтом).
Вот если бы вентилятор был больше фильтра, тогда да, эффект был бы заметен, хоть и несущественный (зависит от того, насколько фильтр менше вентилятора).
Другими словами, количество проходящего воздуха через фильтр не изменилось после герметизации, тогда почему должна была измениться скорость очистки?
Допустим, рядом с этим вентилятором мы поставим ещё один, но без фильтра. Разве это как-то ухудшит скорость очистки? То же самое и здесь - без герметизации часть воздуха проходила мимо фильтра так же, как он частично будет проходить мимо если мы поставим рядом ещё один вентилятор, создающий поток в том же направлении.
Если речь идет о статическом отчете, а куб используется для быстроты получения данных, то здесь еще можно понять, однако при таком раскладе нужно учитывать затраты на разработку и поддержку этой модели, а также на затраты по оборудованию, допуск по временному лагу на пополнение куба и т.д.
И тут возникает вопрос — каждый ли негативный отзыв в начале означает концептуальное неудобство или это лишь вопли консерватизма, которые завтра стихнут?