Pull to refresh
3
0
Send message
Ничего не понял.

Обратите внимание, что когда мы рассчитали все Z-баллы для каждого времени доставки пиццы и построили стандартную кривую нормального распределения

Где все эти расчёты? Как построили кривую?

Теперь, когда мы собрали несколько выборочных данных о времени доставки, мы выполнили расчет и обнаружили, что среднее время доставки больше на 10 минут с p-значением 0,03.

Где данные? Где расчёт? От куда все эти числа взялись?

Начиналось всё хорошо — лёгкий пример с пиццерией, понятные гипотезы с конкретными числами. А потом понеслось: пачка абстрактных определений, формулы с одними буквами, ни одного примера использования этих формул с подстановкой чисел. И в итоге: «Пиццерия нам врёт, потому что p=0.03 и это меньше чем 0.05».

Что бы админом зайти к нему в ресурсы и всё там сломать (шутка).
Или не админом, а просто другим пользователем, у которого есть разрешение на доступ (например член семьи). В общем тут та же история про "яйца в корзине". Одна "корзина" в api удобна для админского UI, а для пользовательского надо чётко, на уровне url, разделять ресурсы. Так проще реализовать доступ к "чужим" ресурсам — не надо лепить костыли для указания серверу, что Я не Я, а типа другой пользователь, который дал мне доступ.
И в логах понятнее становится к ресурсам какого юзера был запрос и какой (возможно другой) юзер сделал этот запрос.
Тут подходит аналогия с раскладкой папок в многопользовательских ОС — у каждого пользователя есть своя папка, а не все в одной ютятся.

Вы "сложили все яйца в одну корзину" и потом пытаетесь подпорками и if-чиками бить по рукам клиента, который потянулся не за своим яйцом.
Разделите "яйца" по отдельным "корзинам" и станет немного проще. Сделайте, например, /company_tasks и /emploee_tasks. Так и документация станет понятнее.
Я бы предложил вообще сделать вот так:
/<user_id>/company_tasks
/<user_id>/emploee_tasks
что бы еще точнее конкретизировать содержимое "корзин". Но я не в курсе насколько легко такое делать в DRF.
С роутингом по регекспам очень неудобно делать вложенные ресурсы т.к. не получается разнести в коде по разным ресурсам ответственность за доступ к его подресурсам. Приходится всю логику с проверками делать во вьюшке ресурса на который указывает url. Это в свою очередь мешает переиспользованию кода, т.к. в другом месте эту вьюшку не получится прикрутить из-за того, что там будут другие проверки и условия для извлечения того же самого ресурса (например надо получить задачу заказчика от лица исполнителя).
Для REST очень хорошо подходит механизм роутинга, который называется traversal. Но его нет в джанге и в DRF видимо тоже.

«Не упоминай имя REST всуе.»

Не увидел в вашем примере ничего такого, что позволяло бы проще писать приложения с архитектурой REST. Хотя правильнее сказать — ничего такого, что заставляло бы писать этом стиле. Т.е. накладывало бы какие-то ограничения на программиста, которые исходят из ограничений описанных в REST.
У вас просто минималистичный web-фреймворк, который ни к чему не обязывает.
Предлагаю автору сравнить свой алгоритм сортировки ещё с Intellij Idea, Eclipse, Vim, Emacs (функция M-x::sort-lines) и обязательно с «Microsoft Notepad».
В плане написания кроссплатформенных не веб приложений есть стандарт WASI. А вот чем GUI рисовать кроссплатформенно без браузера — про это я не знаю.
Было бы неплохо сделать аналогичный пакет для botocore. Наверное это должно быть не очень сложно, раз изначально всё генерируется из его данных.

Нуу, тут можно книгу написать по этой теме. Всё зависит от требований к системе и имеющихся ресурсов. Варианты навскидку:


  • ничего не делаем, продолжаем листать;
  • перечитываем всё с начала в бесконечном цикле, пока не успеем всё прочитать в промежуток между изменениями;
  • продолжаем листать дальше, а потом запрашиваем с сервера историю изменений за время пока листали, и с её помощью фиксим полученный список;
  • и т.д. и т.п

Само по себе значение ETag не так важно. Важен факт его изменения. А это несколько проще реализовать. Например хранить в отдельной таблице (или даже в чём-то вроде Redis) некий uuid или просто автоинкремент, генерируемый при каждом изменении данных.

Да, разновидность этой проблемы (добавление данных после начала "листания") в статье уже указана. Решать её надо другими методами, которые зависят от критичности этой проблемы. Например можно с каждой страницей возвращать некий ETag, который сможет показать клиенту, что данные, с момента начала листинга, изменились.

А в чём вы тут видите проблему? Если у вас в ТЗ указано условие, что данные надо сортировать по ID или по другому полю (которое укажет пользователь), то какая разница в каком реально порядке эти записи попали в базу? Значение имеет только то, что увидит пользователь. А при использовании сортировки он всегда увидит данные в строгом порядке.
Да, индекс по паре (sort_column, unique_column) и использование его для сортировки при паджинации — это подходящее решение. Но надо понимать, что оно увеличивает размер индексов (особенно если надо уметь сортировать по разным полям).
Часто «уникальное» поле и поле для сортировки — это разные поля. Например часто сортировать надо по дате создания/обновления записи. И что бы такое поле было ещё и уникальным — это надо заморочится в самом начале разработки (менять старые данные не всегда допустимо).
Автор забыл (а может и специально умолчал) про важное ограничение для этого способа. А именно то, что поле (или поля), используемое для паджинации по ключу, должно быть «уникальным» и обязательно указываться на первом месте с списке полей используемых для сортировки.
Такие ограничения очень сильно уменьшает возможности использования этого метода.
какую ссылку должен вернуть сервер?

Сервер отдаёт либо ссылку на тот же домен на который пришёл запрос (например домен балансировщика), или на что-либо другое в соответствии с какой-то внутренней логикой.

должен ли HATEOAS описывать данные

HATEOAS по определению не описывает то, что клиент должен делать с ссылкой.

Основная цель REST — разработка масштабируемой распределённой архитектуры, а не протокол описания API. Все ограничения накладываемые REST связанны исключительно с упрощением жизни разработчикам в контексте распределённого сервиса, который надо легко масштабировать. Всё остальное не является областью действия для REST.

Ссылки на ресурсы — это первое что «страдает» в процессе масштабирования. Их приходится менять, что бы перераспределить нагрузку на серверы. Единый балансировщик на одном домене не является «серебряной пулей» в вопросах распределения нагрузки.
А если автор этой статьи поменяет в ней ссылки на предыдущие части цикла, перенаправит их на копию в своём личном блоге, пользователи, при переходе по ним, тоже «тупо упадут» потеряв навыки чтения?

Изменение ссылки ведущей на ресурс не означает, что алгоритм работы с этим ресурсом тоже меняется и все старые клиенты сломаются. Это всё в руках разработчиков API — если им не всё равно, то они обеспечат на новом URL-е точно такие же интерфейсы как и на прежних.

Фактически клиентам вообще нет ни какого прока от URL-ов зашитых в их исходниках, в них почти нет ничего для них полезного — это в общем случае просто какой-то текущий адрес ресурса. Код клиентов работает с самими ресурсами, а не ссылками на них. В концепциях REST правильнее для получения ресурсов пользоваться более высокоуровневыми абстракциями, а не ссылками, захардкожеными в исходниках.
HATEOAS встречал хорошо если в 1% от всех rest api

Мне кажется что API, которым можно хотя бы с натяжкой повесить ярлык REST на самом деле очень мало. И если многие разработчики даже не смогли дотянуть до этого уровня, то какой уж там HATEOAS — естественно что редко его встретишь. Но если формально подойти к вопросу то, как указал выше arthuriantech, весь Web на базе HTTP-HTML — это самый настоящий REST, в котором даже HATEOAS есть. И это уже совсем не 1%.
Всё очень просто — клиенту не надо хардкодить ссылки, ему надо хардкодить relation-ы, т.е. некие имена/идентификаторы тех ссылок, которые ему нужны.
Зная имя ссылки на какое-то действие или связанный ресурс, саму ссылку клиент получает из ответа сервера. Остаётся только правильно разместить все эти ссылки в ответах сервера, что бы клиент, начав с некоего одного «захардкоженного» URL-а (например корень API), смог оптимально получать нужные ему ссылки без лишних запросов.
Такой подход позволяет не меняя код клиентов вносить изменения в ссылки:
— менять в них query-string;
— менять расположение ресурсов, вплоть до изменения домена (например для распределения нагрузки).

PS: HAL — это один из вариантов реализации HATEOAS, в котором гиперссылки передаются в теле ответа в специальном поле. При желании можно для получения гиперссылок использовать упомянутые выше OPTIONS запросы. Только в этом случае придётся озаботится вопросами консистентности, т.к. между GET и OPTIONS запросами состояние ресурса на сервере может изменится.
Но у вас ведь обработчик Click стоит именно на Label. И если он «не срабатывает» при клике мимо текста, то значит у вас и сейчас всё это не работает.

Наверное вы не поняли исходный вопрос. Событие Click возникает когда кликнули мышкой по Label-у. А это означает что курсор мышки находится внутри Label-а. Зачем ещё делать дополнительную проверку положения курсора?
Хм, можете немного расшифровать? Что значит «плохо срабатывает»? Не очень понятно что вы пытаетесь «починить» в плохо срабатывающем нажатии с помощью обработчика события, которое возникает при этом самом нажатии?

Information

Rating
Does not participate
Location
Россия
Registered
Activity