Шансы на что? На ошибку?
Либо я что-то упустил в статье, либо получается, что связь с другими словами запроса через триграммы будет крайне маленькой и малоинформативной в плане омонимии. На мой взгляд это принесёт дополнительный шум. Поправьте, если я не прав.
Также не ясно, как обрабатываются спам-документы?
Ну и если я правильно понял, что алгоритм работает только по заголовкам документа:
Если мы анализируем только TITLE — что делать с сайтами, где идёт глупая генерация этих заголовков и они на половину состоят из например названия сайта?
Насколько в принципе эффективно работать именно с заголовками, учитывая, что количество уникальных и заполненных заголовков в принципе существенно мало по сравнению с общим количеством документов в интернете?
Ну таки XSS действительно имеет место, однако внедрена не картинка, а HTML.
Также стоит справедливо отметить, что это не mid.ru, а archive.mid.ru — старая, архивная версия сайта.
Если посмотреть, что происходит по ссылке, которую упоминает в своём твиттере Jester — мы видим форму, отсылающую post запрос на archive.mid.ru.
Полный HTML на pastebin.
На данный момент XSS судя по всему пофиксили.
Конечно, назвать это дефейсом нельзя — для того, чтобы этот дефейс увидеть — надо перейти по заранее подготовленной ссылке.
Политика :-(
Виджет для javascript-кода
…
Но в строке не во всех редакторах есть подсветка, да и с кавычками могут быть проблемы, а без строки он выведется в середине.
В PhpStorm можно использовать следующий приём в view-файле:
<?php
$js = <<<js
// here be dragons
js;
$this->registerJs($js);
PhpStorm подсветит JavaScript как надо.
Также стоит отметить, что в вашем примере отсутствует смысл в дополнительном оборачивании js-кода в $(document).ready, поскольку registerJs по-умолчанию работает с \yii\web\View::POS_READY(документация).
Заметка для тех, кто боится использовать Yii2 и php7 — не бойтесь.
Мы используем со времён php 7.0.0 — полёт успешный, а этот релиз yii2 только придал уверенности в правильности перехода на семёрку. На боевых и посещаемых сайтах не встречали даже segfault, хотя коллеги замечали пару раз на dev-серверах.
Прирост в производительности php7 ощутим и на yii2 в том числе — TTFB в среднем на 30% меньше, потребление памяти на ~40% меньше. Статистика по e-commerce проектам(php7 vs php56), примерная. Если нужна конкретика — соберём, покажем.
В общем и целом по фреймворку наблюдаем хороший тренд — правильно оформленные и дельные пул-реквесты в последнее время принимаются на удивление быстро и без лишней бюрократии, что не может не радовать.
Calltracking замечательный инструмент. Но про многоканальные последовательности тоже забывать не стоит.
Кампания, которая по итогам прямого замера звонков-заказов стала неэффективной, вполне могла быть важной промежуточной стадией в мультиканальной последовательности заказа. Другое дело, что всё это надо замерять и считать конечную стоимость лида по цепочке.
а лет через 5 (надеюсь) можно будет тот же самый код отдавать уже без трансляции без каких-либо его исправлений
Боюсь, что через 5 лет появится уже какой-нибудь ES2020, который вообще ни в одном месте не совместим ни с одним браузером. И опять всем придётся пользоваться babel или его аналогами.
Ну либо js браузерный всё же будет развиваться в другую сторону, нежели (io|node).js.
Качества поисковой выдачи вы имели в виду?
С точки зрения оценки ответ может быть релевантным, даже если имеется какой-то спам(например спамные ссылки).
Получается наличие обратной связи
Если этим пользуется один оптимизатор/агентство, то и сайтов с такими признаками немного. В общей массе это может быть на уровне погрешности. Другое дело, если это уйдет в массы и все подряд будут использовать одну и ту же технику.
Если у вас сайт с рецептами и цель — найти похожие/крайне похожие рецепты — я бы поигрался с Tomita Parser(покритикуйте идею).
1. Выделяем факты из текстов
2. Сравниваем факты
3. На выходе имеем совпавшие факты + какой % они занимают от общего текста сравниваемых статей
+ как бонус имеем более-менее структурированные данные, которые можно уже использовать например для фильтров
+ рецепты на одну тему, но с несколько разными пропорциями можно объединить в один тематический цикл
Ну а вообще я всегда считал, что дубликаты эффективнее искать по шинглам
Как раз для таких случаев у поисковиков есть классификаторы запросов, которые будут вносить свой вклад в вес того же самого https. Иными словами, по запросам типа «купить» https важен, а для запросов «картинки для рабочего стола» https не так уж и принципиален.
Уважаемый, вы меня просто кормите, спасибо.
Я прекрасно знаю, что такое тестирование, каких видов оно бывает и как с ним работает.
Но вот в чем вы тут точно не правы, так это в последнем высказывании.
В моей практике есть примеры, когда риски реально свести к минимуму за счет глубокой первоначальной аналитики и своевременном анализе уже запущенного тестирования. Да, минус 1 заказ, но опыт крайне полезный.
К тому же, тестов на страницах может проводиться сразу несколько — в этом плане очень интересно устроено всё в Яндексе. Чем вам не огромный проект?
В конце концов, можно проводить предварительные тестирования: на фокус группе, с использованием eye tracker-ов, на дополнительном тестовом сайте через тот же самый дополнительный контекст.
Не знаю, может быть нам очень везёт, но мы ещё нигде, даже при очень резких изменениях, не получали на практике снижение конверсии/объема заказов/прибыли.
Обновите доки на официальном сайте, а то там от 13 октября
Шансы на что? На ошибку?
Либо я что-то упустил в статье, либо получается, что связь с другими словами запроса через триграммы будет крайне маленькой и малоинформативной в плане омонимии. На мой взгляд это принесёт дополнительный шум. Поправьте, если я не прав.
Также не ясно, как обрабатываются спам-документы?
Ну и если я правильно понял, что алгоритм работает только по заголовкам документа:
Всё круто, результаты интересные. Но как эта модель обрабатывает омонимию?
Также стоит справедливо отметить, что это не mid.ru, а archive.mid.ru — старая, архивная версия сайта.
Если посмотреть, что происходит по ссылке, которую упоминает в своём твиттере Jester — мы видим форму, отсылающую post запрос на archive.mid.ru.
Полный HTML на pastebin.
На данный момент XSS судя по всему пофиксили.
Конечно, назвать это дефейсом нельзя — для того, чтобы этот дефейс увидеть — надо перейти по заранее подготовленной ссылке.
Политика :-(
В PhpStorm можно использовать следующий приём в view-файле:
PhpStorm подсветит JavaScript как надо.
Также стоит отметить, что в вашем примере отсутствует смысл в дополнительном оборачивании js-кода в
$(document).ready, посколькуregisterJsпо-умолчанию работает с\yii\web\View::POS_READY(документация).Мы используем со времён php 7.0.0 — полёт успешный, а этот релиз yii2 только придал уверенности в правильности перехода на семёрку. На боевых и посещаемых сайтах не встречали даже segfault, хотя коллеги замечали пару раз на dev-серверах.
Прирост в производительности php7 ощутим и на yii2 в том числе — TTFB в среднем на 30% меньше, потребление памяти на ~40% меньше. Статистика по e-commerce проектам(php7 vs php56), примерная. Если нужна конкретика — соберём, покажем.
В общем и целом по фреймворку наблюдаем хороший тренд — правильно оформленные и дельные пул-реквесты в последнее время принимаются на удивление быстро и без лишней бюрократии, что не может не радовать.
Кампания, которая по итогам прямого замера звонков-заказов стала неэффективной, вполне могла быть важной промежуточной стадией в мультиканальной последовательности заказа. Другое дело, что всё это надо замерять и считать конечную стоимость лида по цепочке.
Боюсь, что через 5 лет появится уже какой-нибудь ES2020, который вообще ни в одном месте не совместим ни с одним браузером. И опять всем придётся пользоваться babel или его аналогами.
Ну либо js браузерный всё же будет развиваться в другую сторону, нежели (io|node).js.
mcrypt не требуется для yii2 начиная с версии 2.0.3.
Качества поисковой выдачи вы имели в виду?
С точки зрения оценки ответ может быть релевантным, даже если имеется какой-то спам(например спамные ссылки).
Если этим пользуется один оптимизатор/агентство, то и сайтов с такими признаками немного. В общей массе это может быть на уровне погрешности. Другое дело, если это уйдет в массы и все подряд будут использовать одну и ту же технику.
1. Выделяем факты из текстов
2. Сравниваем факты
3. На выходе имеем совпавшие факты + какой % они занимают от общего текста сравниваемых статей
+ как бонус имеем более-менее структурированные данные, которые можно уже использовать например для фильтров
+ рецепты на одну тему, но с несколько разными пропорциями можно объединить в один тематический цикл
Ну а вообще я всегда считал, что дубликаты эффективнее искать по шинглам
Я прекрасно знаю, что такое тестирование, каких видов оно бывает и как с ним работает.
Но вот в чем вы тут точно не правы, так это в последнем высказывании.
В моей практике есть примеры, когда риски реально свести к минимуму за счет глубокой первоначальной аналитики и своевременном анализе уже запущенного тестирования. Да, минус 1 заказ, но опыт крайне полезный.
К тому же, тестов на страницах может проводиться сразу несколько — в этом плане очень интересно устроено всё в Яндексе. Чем вам не огромный проект?
В конце концов, можно проводить предварительные тестирования: на фокус группе, с использованием eye tracker-ов, на дополнительном тестовом сайте через тот же самый дополнительный контекст.
Не знаю, может быть нам очень везёт, но мы ещё нигде, даже при очень резких изменениях, не получали на практике снижение конверсии/объема заказов/прибыли.
Да с чего вы взяли то?
Если мы говорим про непринятие резких изменений(например в дизайне), то да.
© возможно Генри Форд
Делать надо так, чтобы людям было комфортно, чтобы у них было желание покупать на вашем сайте.