Раздел про SOP вышел довольно невнятным - и даже неверным. Как будто автор устал к концу статьи (статья в целом годная!)
"Происхождение скриптов" совершенно неважно в контексте SOP (но важно в контексте CSP, который их может просто заблокировать).
X-Frame-Options регулируют то, разрешает ли ваш сайт внедрять свои страницы как iframe на чужих доменах. (При этом еще надо, чтобы и сам чужой домен разрешил нас внедрять - посредством своей CSP)
Access-Control-Allow-Origin - как раз направлен на то, чтобы разрешать кросс-доменные запросы в определенных сценариях, а не запрещать их. Если этого заголовка нет, то кросс-доменный запрос будет отклонен браузером.
Еще до кучи можно добавить, что Same Origin Policy оперирует понятием Origin (кэп?). А вот SameSite cookie (SameSite=Strict, SameSite=Lax) - с понятием Site. И это не всегда одно и то же! (Одно - подмножество другого)
Расчет на то, что юзер один раз когда-то открыл этот сайт у себя дома(без MITMа), и браузер запомнил, что на этот сайт надо ходить по HTTPS. И в следующий раз, даже если юзер попробует открыть его по HTTP, подключившись к открытому вайфаю в кафешке, браузер все равно пойдет на сайт по HTTPS. Расстроив козни злоумышленника
Давайте, прежде всего, четко обрисуем проблему которую мы собираемся решать
Так давайте же! А то дальше несколько экранов текста про мракоделов и капитализм. Написано живо и эмоциально - что есть, то есть. Но очень уж размыто. Мысль я так и не уловил.
Вам не трудно было бы уточнить (в одном-двух предложениях), в чем конкретно проблема, с которой боремся. Можно с примерами кода для наглядности. Спасибо!
Затем вы переходите к описанию методики, которая решает эту проблему. Но на самом деле, это не методика, а туториал по использованию какого-то стартового шаблона. Методика - это все-таки по подходы, а не про инструменты / реализацию. Именно по подходам, я увидел в статье рекомендации использовать миксины для переиспользуемых блоков стилей и константы для цветов/брейкпойнтов. Что, конечно, хорошо и правильно, но как-то на методику не тянет.
Меня не покидает мысль, что я упустил что-то основное и главное в статье, без чего пазл не складывается.
Спасибо, было любыпотно следить за полемикой. Согласен с @lair, что наблюдатель тут применен не по назначению. В принципе, все аргументы выше уже были приведены. Зависимость от четкого порядка наблюдателей, неявное выражение намерения.
Открыл вторую задачку по ссылке из статьи, пару минут подумал, еще минут 15 писал код, еще минут 5 поисправлял off-by-one ошибки с с индексами. Готово.
Понятно, что на интервью из-за стресса все это займет, допустим в 1.5-2 раза больше времени. Но все же - сложной я задачу тоже не назову.
Другой вопрос - а что именно она проверяет (какую информацию о кандидате она дает интервьюеру)? Но, наверное, им там виднее :)
Насчет js.tree. А как его расширять доп метаданными?
К примеру, для генерации сорсмапов нам для каждого узла AST надо знать позицию в исходном файле. Babel это записывает в поле range каждого узла. Как это будет выглядеть в js.tree?
В качестве предупреждения: если хотите маппить стек трейс ошибок (например, из логов приложения) на исходники - забудьте по Safari как про страшный сон. Ну или помните - и игнорируйте.
Ибо Safari генерит трейсы как бог на душу положит, и после применения сорс мапов в лучшем случае что-то просто не смаппится, а в худшем - смаппится не туда, и долго разбираешься, что же пошло не так.
А это в leetcode бага такая. Он почему-то не умеет нормально измерять время работы решений на C++. На других языках такой проблемы не замечал ни разу. А на C++ - чуть менее, чем всегда.
Ну даже в ExampleTest — нет там никакой утечки даже без static, разве не так?
Я бы даже сказал, что утечка будет в каких-то экзотических (синтетических, по большей части) случаях — вроде примера с LargeObject
A ponyfill, in contrast, doesn't monkey patch anything, but instead exports the functionality as a normal module, so you can use it locally without affecting other code.
В случае Ангуляра — бОльшая часть "повторяющихся" функций — это выход из tsc с даунгрейдом. Ангуляр, как и сам компилятор тайпскрипт, написан на TS, а автор в статье проверяет уже скомпилированные .js файлы.
Даунгрейд синтаксиса классов и вызовов super() — в прототипы. ES-module в CommonJS.
Вс остальное — это преимущественно "пустышки", которые бессмысленно рефакторить/переиспользовать.
Сборшики работают эффективно
Не, это просто в бандл вошли совсем не те файлы, которые были проаналзированые ранее. По списку самых больших файлов видно, что все это — сама система сборки (typescript, angular compiler, sass).
Второй совет полезен в случае, когда у функции много параметров. Например, обертка над апи-запросом, в котором вдобавок еще часть параметров необязательная.
Можно же уверенно ответить, что, мол этого не знаю, а выдумывать лажу не буду.
Ну, то есть понимание рамок своей компетенции - тоже довольно полезная штука (чтобы знать, когда пора пойти спросить у старших коллег)
Раздел про SOP вышел довольно невнятным - и даже неверным. Как будто автор устал к концу статьи (статья в целом годная!)
"Происхождение скриптов" совершенно неважно в контексте SOP (но важно в контексте CSP, который их может просто заблокировать).
X-Frame-Options регулируют то, разрешает ли ваш сайт внедрять свои страницы как iframe на чужих доменах. (При этом еще надо, чтобы и сам чужой домен разрешил нас внедрять - посредством своей CSP)
Access-Control-Allow-Origin - как раз направлен на то, чтобы разрешать кросс-доменные запросы в определенных сценариях, а не запрещать их. Если этого заголовка нет, то кросс-доменный запрос будет отклонен браузером.
Еще до кучи можно добавить, что Same Origin Policy оперирует понятием Origin (кэп?). А вот SameSite cookie (SameSite=Strict, SameSite=Lax) - с понятием Site. И это не всегда одно и то же! (Одно - подмножество другого)
Расчет на то, что юзер один раз когда-то открыл этот сайт у себя дома(без MITMа), и браузер запомнил, что на этот сайт надо ходить по HTTPS. И в следующий раз, даже если юзер попробует открыть его по HTTP, подключившись к открытому вайфаю в кафешке, браузер все равно пойдет на сайт по HTTPS. Расстроив козни злоумышленника
Спасибо, так понятней!
Не вполне очевидно, почему
Так давайте же! А то дальше несколько экранов текста про мракоделов и капитализм. Написано живо и эмоциально - что есть, то есть. Но очень уж размыто. Мысль я так и не уловил.
Вам не трудно было бы уточнить (в одном-двух предложениях), в чем конкретно проблема, с которой боремся. Можно с примерами кода для наглядности. Спасибо!
Затем вы переходите к описанию методики, которая решает эту проблему. Но на самом деле, это не методика, а туториал по использованию какого-то стартового шаблона. Методика - это все-таки по подходы, а не про инструменты / реализацию. Именно по подходам, я увидел в статье рекомендации использовать миксины для переиспользуемых блоков стилей и константы для цветов/брейкпойнтов. Что, конечно, хорошо и правильно, но как-то на методику не тянет.
Меня не покидает мысль, что я упустил что-то основное и главное в статье, без чего пазл не складывается.
Спасибо, было любыпотно следить за полемикой. Согласен с @lair, что наблюдатель тут применен не по назначению. В принципе, все аргументы выше уже были приведены. Зависимость от четкого порядка наблюдателей, неявное выражение намерения.
Открыл вторую задачку по ссылке из статьи, пару минут подумал, еще минут 15 писал код, еще минут 5 поисправлял off-by-one ошибки с с индексами. Готово.
Понятно, что на интервью из-за стресса все это займет, допустим в 1.5-2 раза больше времени. Но все же - сложной я задачу тоже не назову.
Другой вопрос - а что именно она проверяет (какую информацию о кандидате она дает интервьюеру)? Но, наверное, им там виднее :)
Насчет js.tree. А как его расширять доп метаданными?
К примеру, для генерации сорсмапов нам для каждого узла AST надо знать позицию в исходном файле. Babel это записывает в поле
rangeкаждого узла. Как это будет выглядеть в js.tree?В качестве предупреждения: если хотите маппить стек трейс ошибок (например, из логов приложения) на исходники - забудьте по Safari как про страшный сон. Ну или помните - и игнорируйте.
Ибо Safari генерит трейсы как бог на душу положит, и после применения сорс мапов в лучшем случае что-то просто не смаппится, а в худшем - смаппится не туда, и долго разбираешься, что же пошло не так.
Собственно, у автора примерно так и работало в первой версии, насколько я понял. Через IPC.
И согласен, что не раскрыта тема того, почему собственно это было медленно. Без этого остаток статьи не очень понятен.
А это в leetcode бага такая. Он почему-то не умеет нормально измерять время работы решений на C++. На других языках такой проблемы не замечал ни разу. А на C++ - чуть менее, чем всегда.
Для полноты картины — не tuiLet-ом единым:
rxLet: https://github.com/rx-angular/rx-angular/blob/master/libs/template/docs/api/let-directive.mdngrxLet: https://ngrx.io/guide/component/letНу даже в ExampleTest — нет там никакой утечки даже без static, разве не так?
Я бы даже сказал, что утечка будет в каких-то экзотических (синтетических, по большей части) случаях — вроде примера с LargeObject
Спасибо, не знал. Действительно, полезно перечитывать документацию.
Но так все же зачем конкретно в колбэке для
usort(приведенном в начале статьи) static? Просто по привычке (кабы не было чего)?Я до последнего ожидал увидеть в статье ссылку на "Смертоносный мусор". Не увидел. Ловите!
https://librebook.me/deadly_litter
Да не то чтоб.
https://github.com/sindresorhus/ponyfill
В случае Ангуляра — бОльшая часть "повторяющихся" функций — это выход из tsc с даунгрейдом. Ангуляр, как и сам компилятор тайпскрипт, написан на TS, а автор в статье проверяет уже скомпилированные .js файлы.
Даунгрейд синтаксиса классов и вызовов super() — в прототипы. ES-module в CommonJS.
Вс остальное — это преимущественно "пустышки", которые бессмысленно рефакторить/переиспользовать.
Не, это просто в бандл вошли совсем не те файлы, которые были проаналзированые ранее. По списку самых больших файлов видно, что все это — сама система сборки (typescript, angular compiler, sass).
Второй совет полезен в случае, когда у функции много параметров. Например, обертка над апи-запросом, в котором вдобавок еще часть параметров необязательная.
Привычки бывают разные. У одних они одни, у других другие. Так что кого-то заставят, а кого-то и нет — неважно в каком стиле код писать.
Это практически из той же оперы, что и type assertion.
И в том, и в том случае программист говорит компилятору, что программисту лучше знать, какой там будет тип.