Я так и не понял в чем ценность этой статьи. Вы решили рассказать, что начали использовать регрессионное тестирование для js в своих проектах?
Ну ок, только что в этом нового, интересного, неизвестного? Кажется, что профита от этой статьи ноль.
Ну и да, попробуйте делать регрессионные тесты для css (like gemini, huxley, etc), кажется, что для ваших проблем это эффективней.
На данный момент такой функциональности нет, и я не уверен, что она появится, поскольку такой кейс использования тепловых карт все же реже. Но схожих картинок, как у вас в проекте, можно добиться и с нашим модулем несколькими методами:
отквантовать данные на несколько дискретных уровней, задать для каждого соответствующий градиент (изменяя в нем только прозрачность, но не цвет), для каждого уровня задать отдельный слой heatmap'а и наложить его на карту
расставить точки на большом расстоянии друг от друга, чтобы они минимально аффектили друг друга, задать каждой точке вес равный определенному значению (дополнительные данные, которые вы хотите отобразить)
1) Я не уверен, что это не нарушает пользовательское соглашение.
2) Не стоит строить свои системы на хаках в чужих, это редко приводит к чему-то хорошему.
Можно будет попробовать нафигачить, делать то почти ничего и не надо;)
Только вряд ли для этого Яндекс.Погода подойдет, насколько я знаю, API у них нет, а вот у openweathermap можно получить данные вполне легально.
Это булевое значение, которое говорит нужно ли уменьшать пиксельный размер точек при уменьшении зума. Просто в некоторых случаях, если этого не делать, то на маленьких зумах все точки сливаются в одно большое красное пятно.
Аа, с этой прозрачностью, да, можно что-то сделать. Было бы здорово, если бы вы прислали нам pull-request c градиентом, который считаете более приятным, чтобы мы говорили не о каких-от абстрактных значениях, а о реальных цветах.
Мы были бы вам очень благодарны;)
В текущей версии прозрачность задается на весь слой и не изменяется от текущей «температуры» точки, это сделали для того, чтобы не уменьшать читабельность самой карты, возможно, это не идеальное решение, но показалось, что такое решение весьма удобно. А в целом, я готов к дискуссии и допиливанию;)
В качестве градиента по умолчанию используется самый стандартый градиент для всех тепловых карт, люди к этому привыкли и поэтому решили, что не стоит переворачивать с ног на голову представление пользователей о тепловых картах.
Градиент цвета задается специальной опцией gradient, поэтому вы сможете откорректировать его как вам захочется. Прозрачность же задается одна для всего слоя heatmap'а.
Cool.
И вот действительно, еще очень резонный вопрос, почему вы отказались от привычных интерфейсов, как у большинства библиотек для unit-тестирования, были ли на это какие-то серьезные причины? Мелочь, конечно, но пользователям было бы приятней.
Тут больше вопрос как решаются задачи классификации токенов, если есть более крупные запросы, например, [авито объявления с телефонами] в нескольких случаях:
1) если токен «объявления» или «телефон» не размечены в базе (или такого не бывает)?
2) если оба токена («объявления» и «телефон») размечены, как путь?
И второй момент: как происходит классификация токенов «объявления» и «телефон» в запросе [авито объявления с телефонами], если по запросам [авито объявления] и [авито телефоны] люди кликали на два разных url в 95%+ случаев.
Возможно, конечно, такие запросы просто идут как запросы смешанного типа.
Крупные компании пытаются следовать трендам, а Вася Пупкин из Васюков, который создал свой сайт, чтобы как у всех было, никогда им не следовал и следовать не будет
На досуге ознакомьтесь со статьей, ссылку на которую я привел выше, тогда вы поймете о чем я говорю.
Очевидно, что у каждого рынка свои особенности, но достаточно много схожих черт.
Универсального рецепта нет, но вот опыт разных успешных проектов есть. Многие гуру данной области сформировали не плохие рекомендации для интернет маркетинга.
Привлекать аудиторию на продающий сайт просто необходимо и за это можно и нужно платить, просто делать это необходимо вовремя. Сначала продукт, потом продажа. А вообще достаточно много есть статей, как правильно развивать продающие сайты (for example).
Компания делает правильные шаги, она не пытается выбросить очередной продукт в «красные океаны», она просто ищет незанятые ниши. Как показывает история большинства it-компаний, такой подход более удачный.
Насколько это релевантный метод поиска — вопрос достаточно спорный. Как мне кажется, минимум не хватает анализа коллокаций. А вообще на выходных обсуждали вопрос релевантности поиска с Otkrick, и как мне кажется, он предложил несколько достаточно интересных идей.
Ну ок, только что в этом нового, интересного, неизвестного? Кажется, что профита от этой статьи ноль.
Ну и да, попробуйте делать регрессионные тесты для css (like gemini, huxley, etc), кажется, что для ваших проблем это эффективней.
2) Не стоит строить свои системы на хаках в чужих, это редко приводит к чему-то хорошему.
Только вряд ли для этого Яндекс.Погода подойдет, насколько я знаю, API у них нет, а вот у
openweathermap можно получить данные вполне легально.
Мы были бы вам очень благодарны;)
В качестве градиента по умолчанию используется самый стандартый градиент для всех тепловых карт, люди к этому привыкли и поэтому решили, что не стоит переворачивать с ног на голову представление пользователей о тепловых картах.
И вот действительно, еще очень резонный вопрос, почему вы отказались от привычных интерфейсов, как у большинства библиотек для unit-тестирования, были ли на это какие-то серьезные причины? Мелочь, конечно, но пользователям было бы приятней.
1) если токен «объявления» или «телефон» не размечены в базе (или такого не бывает)?
2) если оба токена («объявления» и «телефон») размечены, как путь?
И второй момент: как происходит классификация токенов «объявления» и «телефон» в запросе [авито объявления с телефонами], если по запросам [авито объявления] и [авито телефоны] люди кликали на два разных url в 95%+ случаев.
Возможно, конечно, такие запросы просто идут как запросы смешанного типа.
Очевидно, что у каждого рынка свои особенности, но достаточно много схожих черт.