нестандартная реализация создает лишние сложности и сильно ограничивает кейсы их применимости (https://github.com/domenic/chai-as-promised/issues/1, например). поэтому — да, кривой. программисты с исторического факультета могут искать применение, но с практической точки зрения, чем раньше отправят в кунсткамеру это недоразумение, тем лучше — на сегодняшний день стандарт это реальность.
по примерам не понятно, как считать площадь фигур, в итоге, и каким образом преобразованный код иллюстрирует LSP, если ни наследования, ни полиморфизма в нем не осталось?
может вы смотрели, какие именно операции приводят к увеличению потребления памяти (выбор файлов в диалоговом окне, чтение в FileObject через readAsDataURI(), добавление картинки в DOM и т.п.)?
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
едва успели выпилить из браузера одно чудо-юдо, как другим уже не терпится запилить туда css с variables и calc.
кажется. что в купе с правилами применения каскадов, наследования (в понимании css), анимаций и традиционными вендор-специфичными глюками это должно стать умопомрачительным в отладке механизмом — или они таким способом хотят готовить персонал для программирования квантовых компьютеров?)
по-разному бывает. бывает, что разработчики в состоянии аффекта действительно забыли про какую-то важную штуку, например, про третье колесо для детского велосипеда — тогда да, надо половину рамы перекраивать. а иногда пытаются фонарик к рулю приделать методом всепроникающей диффузии, вместо того, чтобы заимплементить сей девайс с интерфейсом стандартного хомута. еще говорят, что сервисы это не ооп, поэтому понятие интерфейса к ним применимо лишь чисто условно.
не понимаю, что все к этому «loose coupling» так мм… прицепились ;). вот если бы автор еще и «high cohesion» так же красочно расписал, то половины интриги могло не получиться — как раз этот принцип не дает совершать всякие глупости. как то крошить код без надобности, или пилить рамы лисапедов на кусочки длиной 1см. в теории конечно: принципы-принципами, — они не мешают делать на практике весьма причудливые вещи.
report-uri — указывает URL, на который будут отправляться JSON-отчеты о нарушениях… Некоторые браузеры также указывают в отчете ссылку и строку JS, которые привели к нарушению политики безопасности.
офтопик. не про вас, а про механизм отчетов CSP вообще. расскажите подробнее как работает эта магия. интересно, может-ли таким образом владелец сайта получать дополнительную информацию о пользователях, которую раньше нельзя было бы получить?
смущает что владелец ресурса может получать в отчетах CSP ссылки. ведь ссылки могут содержать конфиденциальные данные (допустим, индентификатор пользователя в социальной сети, секретные ключи и т.п.). можно-ли намеренно «запретить» политиками CSP интересующие домены, чтобы затем получать эти сведения в отчетах?
гипотетический сценарий. допустим есть виджет социальной сети (//yy.ru/widget.js), который смотрит в куки своего домена и делает ajax-запрос к сервису авторизации, передавая логин в урле (//passport.yy.ru/?login=username). штатными средствами мониторить ajax запросы браузер не даст. добавляем виджет на страницу, политиками разрешаем загрузку виджета c домена yy.ru, но запрещаем доступ к домену авторизации passport.yy.ru. когда на сцену выходит CSP в отчетах получаем урлы с логинами, по которым пользователей можно идентифицировать. профит.
если все это нереальный бред про паранойю, буду признателен за конструктивную критику. :)
#include <string>
#include <cstdlib>
int main ()
{
// I do not hope that the empoyee will write a LL-parser. But we still have a vacancy web developer.
std::string const formula = "1 + 2 * (3 + 4)";
std::string const cmd = std::string("php -r 'echo ") + formula + ";'";
std::system (cmd.c_str());
return 0;
}
спасибо за перевод увлекательной серии. пусть изложенная автором в цикле статей точка зрения не претендует на абсолютную истину и в чем-то спорна, в ней определенно есть ряд рациональных моментов.
кажется, пример в последнем абзаце сбивает с толку. я всегда считал Entiy вполне нормальными объектами, т.к. они, по определению, обладают собственным абстрактным поведением. скорее, ближайшим родственником DTO является «сообщение», как пример структурированных данных, не обремененных собственной прикладной семантикой, которые летают между границами систем.
DTO это взгляд на сообщение со стороны кода. они абстрагируют приложение от конкретного формата сообщений (sql, xml, json,… ), предоставляя доступ к внутренностям в виде родных синтаксических конструкций языка (в случае с EF это еще и аннотации для автоматической сериализации/десериализации, схемогенерации, миграций и т.п. полезных наворотов, реализуемых фреймворком, но роли самих DTO это не меняет). в плане структурно-поведенческого дуализма объектов, DTO представляю собой вырожденный случай структурности в чистом виде.
как скрывание рефереров будет соотноситься с Островами, которые, если я правильно понимаю, были призваны формировать заходы с поисковой выдачи на посадочные страницы с еще более релевантными аргументами — разве здесь нет нарушения конфиденциальности и еще большего расширения возможностей для навязчивой рекламы и впаривания товара, который уже не нужен?
круть. теперь не только пользователи осчастливлены пресонификацией поисковой выдачи, но и владельцы сайтов будут вынуждены уверовать в данные об интересах пользователей, отображаемые метрикой. пожалуй, это самое любопытное. ведь таким образом обе стороны, из субъектов, взаимодействовавших через яндексный поиск, становятся объектами одной модели.
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
кажется. что в купе с правилами применения каскадов, наследования (в понимании css), анимаций и традиционными вендор-специфичными глюками это должно стать умопомрачительным в отладке механизмом — или они таким способом хотят готовить персонал для программирования квантовых компьютеров?)
:)
офтопик. не про вас, а про механизм отчетов CSP вообще. расскажите подробнее как работает эта магия. интересно, может-ли таким образом владелец сайта получать дополнительную информацию о пользователях, которую раньше нельзя было бы получить?
смущает что владелец ресурса может получать в отчетах CSP ссылки. ведь ссылки могут содержать конфиденциальные данные (допустим, индентификатор пользователя в социальной сети, секретные ключи и т.п.). можно-ли намеренно «запретить» политиками CSP интересующие домены, чтобы затем получать эти сведения в отчетах?
гипотетический сценарий. допустим есть виджет социальной сети (//yy.ru/widget.js), который смотрит в куки своего домена и делает ajax-запрос к сервису авторизации, передавая логин в урле (//passport.yy.ru/?login=username). штатными средствами мониторить ajax запросы браузер не даст. добавляем виджет на страницу, политиками разрешаем загрузку виджета c домена yy.ru, но запрещаем доступ к домену авторизации passport.yy.ru. когда на сцену выходит CSP в отчетах получаем урлы с логинами, по которым пользователей можно идентифицировать. профит.
если все это нереальный бред про паранойю, буду признателен за конструктивную критику. :)
кажется, пример в последнем абзаце сбивает с толку. я всегда считал Entiy вполне нормальными объектами, т.к. они, по определению, обладают собственным абстрактным поведением. скорее, ближайшим родственником DTO является «сообщение», как пример структурированных данных, не обремененных собственной прикладной семантикой, которые летают между границами систем.
DTO это взгляд на сообщение со стороны кода. они абстрагируют приложение от конкретного формата сообщений (sql, xml, json,… ), предоставляя доступ к внутренностям в виде родных синтаксических конструкций языка (в случае с EF это еще и аннотации для автоматической сериализации/десериализации, схемогенерации, миграций и т.п. полезных наворотов, реализуемых фреймворком, но роли самих DTO это не меняет). в плане структурно-поведенческого дуализма объектов, DTO представляю собой вырожденный случай структурности в чистом виде.