Отличное замечание. Спасибо за уточнение философской глубины подхода!
Однако я сознательно упростил формулировку.
Моя цель была показать практическую разницу, которую видит разработчик при переходе от 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 уже занято.
Думаю, скотч не дал результата потому, что площадь фильтрующей поверхности осталась прежней, а закрыв часть воздушного канала ещё и придушили эффективность всасывания самого вентилятора (но это уже в пределах погрешности, т.к. рабочая область крыльчатки изначально перекрыта фильтом).
Вот если бы вентилятор был больше фильтра, тогда да, эффект был бы заметен, хоть и несущественный (зависит от того, насколько фильтр менше вентилятора).
Другими словами, количество проходящего воздуха через фильтр не изменилось после герметизации, тогда почему должна была измениться скорость очистки?
Допустим, рядом с этим вентилятором мы поставим ещё один, но без фильтра. Разве это как-то ухудшит скорость очистки? То же самое и здесь - без герметизации часть воздуха проходила мимо фильтра так же, как он частично будет проходить мимо если мы поставим рядом ещё один вентилятор, создающий поток в том же направлении.
Это неудобно. В каких-то случаях — да, если речь идет о нескольких мерах, на поведение которых можно повлиять с помощью специального «настроечного» измерения.
Здесь речь идет о периоде, который должен влиять на 99,9% показателей, за исключением каких-нибудь счетчиков по товарной или клиентской базе.
Когда пользователей сотни и показателей тоже, то для каждого варианта формул не напасешься. Сегодня им надо так, а завтра иначе. Если прописывать в каждой мере все эти OR'ы и AND'ы, то листинг выражений станет такой, что проще застрелиться, чем поддерживать этого мутанта.
С Power Pivot не все так просто.
Во-первых, с точки зрения лицензии — начиная с Office2013 надстройка есть только в редакциях Pro Plus. Цену можете загуглить.
Во-вторых, сама надстройка изначально сделана не для добавления плюшек к интерфейсу по работе с кубом, она сделана для удобства создания локальных моделей данных, пусть даже эти данные базируются на кубе и других источниках. Это прослойка, позволяющая получить данные из различных источников с дополнительными трансформациями и слияниями, чтобы впоследствии использовать этого франкенштейна как единую модель, которую предварительно надо готовить и все равно в ней не будет сабжа.
Как известно, из коробки Excel не позволяет устанавливать фильтры по списку значений для сводных таблиц, а это ведь такая нужная вещь! Как отфильтровать товары по сотне кодов, а потом по другой сотне?
На этот вопрос Вы не ответили своими картинками. Расскажите, как это делается для любителя Excel 2010?
Готов посыпать голову пеплом, если покажете, как с помощью этого красивого ползунка установить период С… ПО… введя его с клавиатуры, а не выискивать где же там эта дата. Не переключаясь сначала на годы, потом кварталы и месяцы/дни.
Это риторический вопрос. Нужно пойти в фильтр, во вложенном меню поставить «между».
Но теперь нам надо добавить к этому периоду аналогичный предшествующего года.
Иии… что делать?
Далее нам нужно быстро применить только к одной текущей таблице, а через минуту ко всем на листе.
Проставлять галочки в настройке, к каким таблицам применить? А если их создавали в разной последовательности на разных листах, таким образом на первом листе есть таблица1, таблица5 и таблица8, это нужно сначала посмотреть какие таблицы на листе и потом по одной галочке снимать/ставить? А когда в книге пара десятков таблиц, но в окошке «Подключение к отчетам» нет кнопочки «Выделить все» и «Снять выделение», будем полчаса щелкать, снимая галочки, а потом столько же их ставить назад?
Спасибо, но я предпочитаю день подождать…
И самое главное (в данной версии этого нет, но у нас есть): когда с одним из филиалов есть временной лаг и нужно смотреть обороты по всем филиалам, но ограничив период не максимальным значением в календаре, а максимальным значением, на которую есть данные по тому отстающему филиалу, чтобы выровнять… ну вы поняли. Как это сделать красивым ползунком?
Это магическая часть, без нее работать не будет)))
Как Вы понимаете, не было цели блеснуть идеальным кодом. Хотелось поделиться инструментом. Эх, если бы со мной кто-то поделился таким лет несколько назад, хотя бы одной кнопочкой установки фильтров по списку…
Понятное дело, что данная поделка не имеет ничего общего с BigData, к SQL server она относится примерно также. На мой взгляд, целевая аудитория, и, вероятно, содержащая их в своем зоопарке, обитает именно в этих хабах, поэтому получился такой набор. Может быть я ошибаюсь.
В какой хаб надо было поместить?
Нужно отделять мух от котлет. Пытаться подтянуть все в одну систему, пусть даже она является чисто интерфейсной, в данном случае, — плохая практика. Сбор данных из куба в Excel или PowerBI, со всеми их доп. возможностями, не то же самое, что просматривать их в ProClarity
Если речь идет о статическом отчете, а куб используется для быстроты получения данных, то здесь еще можно понять, однако при таком раскладе нужно учитывать затраты на разработку и поддержку этой модели, а также на затраты по оборудованию, допуск по временному лагу на пополнение куба и т.д.
Понятное дело, что и с прежним вариантом интерфейса можно было жить. Я лишь хотел подчеркнуть, что консерватизм — упрямая штука. Даже когда предлагаешь реально более удобный вариант, его не сразу принимают.
И тут возникает вопрос — каждый ли негативный отзыв в начале означает концептуальное неудобство или это лишь вопли консерватизма, которые завтра стихнут?
Да, Вы павы, это растровый шрифт, поэтому, несмотря на включенный ClearType, он не сглаживался, вот и было не заметно, что опция включена. Я как-то не подумал об этом сразу. Мне почему-то казалось, что он TTF, в то время как на самом деле битмап. Ну и мне он просто больше нравится по начертанию. А когда в очередной версии винды его сменили на тахому, к которому тут же применилось сглаживание, в силу его векторности, это сразу бросилось в глаза.
Ну, при нестандартном для экрана разрешении все шрифты будут мыльные. Это не мое дело, конечно, но если Вы понижаете разрешение чтобы шрифты стали крупнее, то лучше воспользоваться специальной опцией — увеличение масштаба шрифта. Тогда и разрешение будет нормальным, а шрифты ровными и крупными. В настройках экрана это делается.
cmd> control userpasswords2 открывает стандартное окно Учетные записи пользователей, которое было доступно из панели управления в win2k, и в нем есть галочка Требовать ввод имени пользователя и пароля. Сняв эту галку можно указать от имени кого логиниться автоматом, даже при наличии пароля и даже если машина в домене (в домене галочка скрыта, но ключи в реестре всё те же и они работают по прямому назначению без проблем).
Однако начиная с WinXP его убрали из панели управления, заменив ссылкой на упрощенный, свистопердельный вариант, но команда осталась и прекрасно работает даже в последних версиях винды (правда, на Win10 не пробовал, но скорее всего тоже работает).
Отличное замечание. Спасибо за уточнение философской глубины подхода!
Однако я сознательно упростил формулировку.
Моя цель была показать практическую разницу, которую видит разработчик при переходе от 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 уже занято.
объяву!
Думаю, скотч не дал результата потому, что площадь фильтрующей поверхности осталась прежней, а закрыв часть воздушного канала ещё и придушили эффективность всасывания самого вентилятора (но это уже в пределах погрешности, т.к. рабочая область крыльчатки изначально перекрыта фильтом).
Вот если бы вентилятор был больше фильтра, тогда да, эффект был бы заметен, хоть и несущественный (зависит от того, насколько фильтр менше вентилятора).
Другими словами, количество проходящего воздуха через фильтр не изменилось после герметизации, тогда почему должна была измениться скорость очистки?
Допустим, рядом с этим вентилятором мы поставим ещё один, но без фильтра. Разве это как-то ухудшит скорость очистки? То же самое и здесь - без герметизации часть воздуха проходила мимо фильтра так же, как он частично будет проходить мимо если мы поставим рядом ещё один вентилятор, создающий поток в том же направлении.
Здесь речь идет о периоде, который должен влиять на 99,9% показателей, за исключением каких-нибудь счетчиков по товарной или клиентской базе.
Когда пользователей сотни и показателей тоже, то для каждого варианта формул не напасешься. Сегодня им надо так, а завтра иначе. Если прописывать в каждой мере все эти OR'ы и AND'ы, то листинг выражений станет такой, что проще застрелиться, чем поддерживать этого мутанта.
Во-первых, с точки зрения лицензии — начиная с Office2013 надстройка есть только в редакциях Pro Plus. Цену можете загуглить.
Во-вторых, сама надстройка изначально сделана не для добавления плюшек к интерфейсу по работе с кубом, она сделана для удобства создания локальных моделей данных, пусть даже эти данные базируются на кубе и других источниках. Это прослойка, позволяющая получить данные из различных источников с дополнительными трансформациями и слияниями, чтобы впоследствии использовать этого франкенштейна как единую модель, которую предварительно надо готовить и все равно в ней не будет сабжа.
На этот вопрос Вы не ответили своими картинками. Расскажите, как это делается для любителя Excel 2010?
Это риторический вопрос. Нужно пойти в фильтр, во вложенном меню поставить «между».
Но теперь нам надо добавить к этому периоду аналогичный предшествующего года.
Иии… что делать?
Далее нам нужно быстро применить только к одной текущей таблице, а через минуту ко всем на листе.
Проставлять галочки в настройке, к каким таблицам применить? А если их создавали в разной последовательности на разных листах, таким образом на первом листе есть таблица1, таблица5 и таблица8, это нужно сначала посмотреть какие таблицы на листе и потом по одной галочке снимать/ставить? А когда в книге пара десятков таблиц, но в окошке «Подключение к отчетам» нет кнопочки «Выделить все» и «Снять выделение», будем полчаса щелкать, снимая галочки, а потом столько же их ставить назад?
Спасибо, но я предпочитаю день подождать…
И самое главное (в данной версии этого нет, но у нас есть): когда с одним из филиалов есть временной лаг и нужно смотреть обороты по всем филиалам, но ограничив период не максимальным значением в календаре, а максимальным значением, на которую есть данные по тому отстающему филиалу, чтобы выровнять… ну вы поняли. Как это сделать красивым ползунком?
ЗЫ. Пепел я уже приготовил :-)
Как Вы понимаете, не было цели блеснуть идеальным кодом. Хотелось поделиться инструментом. Эх, если бы со мной кто-то поделился таким лет несколько назад, хотя бы одной кнопочкой установки фильтров по списку…
В какой хаб надо было поместить?
Если речь идет о статическом отчете, а куб используется для быстроты получения данных, то здесь еще можно понять, однако при таком раскладе нужно учитывать затраты на разработку и поддержку этой модели, а также на затраты по оборудованию, допуск по временному лагу на пополнение куба и т.д.
И тут возникает вопрос — каждый ли негативный отзыв в начале означает концептуальное неудобство или это лишь вопли консерватизма, которые завтра стихнут?
Но если все равно не видно разницы, сделайте его скрин и увеличьте.
Однако начиная с WinXP его убрали из панели управления, заменив ссылкой на упрощенный, свистопердельный вариант, но команда осталась и прекрасно работает даже в последних версиях винды (правда, на Win10 не пробовал, но скорее всего тоже работает).