Забавно, что за 18к руб в мес вам предлагают 97% защиты.
365*0,03 — это почти 11 СУТОК в год! 22 часа в месяц!
Это при том, что за пару часов можно поднять балансировочный сервер и через 3-4 часа трафик пойдет через него.
Это «решение» для тех, кто жалеет 2-3 к руб админу, который сделает все быстрее и качественней.
Я думаю, что в РЖД просто решили запилить бабла на судебных издержках. Куда как проще переправить несколько сотен тысяч долларов на юридическую поддержку а потом отдать ведение дело студенту-юристу. Думаю, они теперь подадут апеляцию и опять потратят 100500 мильонов на адвокатов. Обычное дело.
Кстати, лет 10 назад мою компанию совершенно таким же образом хотели нагнуть за использование товарных знаков. И совершенно также было отказано в иске. Потому что подавали иск лохи, а я взял юриста — разработчика закона об авторском праве ;-)
скрытая реклама Pebble Watch
администрация! где вы?
всего, что написано, НЕТ именно в Pebble.
согласен полностью с enemo:
плюсы: держат 5 дней, проверяют почту, на смс от уродцев с рекламой не отвлекаешься, на совещаниях оч. удобно (телефон — в вибро, на часах видно кто звонит. можно сбросить или взять трубку), показывают время
минусы: выглядят по-уродски, высасывают iphone (30% только за ночь).
неправда ваша.
он не индексирует. он агрегирует фиды от партнеров, которыми как раз являются avito, drom и.т.д.
но auto.ru, например, отдает яндексу только регионы, москвы там нет. наверняка и остальные отдают с задержками, ведь тот же авито живет не только за счет рекламы, но и за счет продавцов, платящих за поднятие и т.д.
как-то действительно дорого получается.
я сразу захотел заказать много: портфели детей — 2, ключи — 4 комплекта + 2 от машин, один в бумажник, один в сумку жене — уже 12 штук.
и получается 200 баксов в год. как-то дорого.
странно, что не сделали подзарядку. и раз в год все заново перезаписывать — бред.
Between по 2 ключам никогда индексируется. Если уж Вы используйте spatial — функции, там есть замечательная MBRContains и SPATIAL KEY.
И кстати да, например для вывода на карту быстрее делать выборку с MBRContains с LIMIT и ORDER BY created DESC, а потом уже проверять расстояния. Тогда действительно работает быстро.
не скажите. одной только заменой названий функций и параметров не обойтись. логика тоже отличается.
что касается Яднекса, переход на v2 — это мрак полнейший. Парадигма API совсем другая.
А самое жесткое, это перевод с google V2 на яндекс V2. В этом случае переписывать код приходится полностью.
Вы забываете одну очень важную вещь — юзабилити.
Каждый ненужный щелчок по карте (на кластер) увеличивает процент отказов вдвое.
так что с 4 до 18 зума у Вас вряд ли кто доберется. если у Вас не останется точек, а будут одни кластеры, юзер плюнет и закроет страницу.
так что подумайте насчет 2000 кластеров. Для специальных сайтов типа недвижимости это еще сработает (там люди знают, что ищут), а для развлекательных — лучше меньше да лучше)
кстати, я работаю с картами уже года 4, как раз учился у kashey лично.
обратитесь к профессионалам, не изобретайте велосипед.
на масштабах 0-6 можно сделать хитро. делать выборку на масштабе +3 например.
то есть на 0 масштабе сделать выборку по тайлам на масштабе 3, но выбирать не все, а, скажем, 100 новых. получится максимум 6400 объектов. вот их-то и кластеризовать.
смысл в том, что если выбрать на 0 зуме последние 6400 объектов, если большая вероятность, что большинство из них будет в одной части карты (например, в мск) — некрасиво.
другой вариант — каждой точке давать поле с рэндомным значением при сохранении и выбирать по этому полю limit 6400. рэндом ещенощно обновлять.
проблема с серверной кластеризацией в слипании точек/кластеров по краям тайла.
в лубом случае, 10 точек на клиенте по-любому быстрее, чем постоянная закачка данных с сервера.
не нужна такая детализация. достаточно 32 бит — это 16-ый зум.
то есть индексируем тайлы до 16 зума. даже если на 18 зуме будет больше точек, их при обработке данных легко исключить.
вот как в php:
конвертите номер тайла в 1313101230130131 (16 зумом)
потом
tileId = base_convert('1313101230130131', 4, 10);
и сохраняете в базе для каждой точкb uint.
выборка точек:
MAX_ZOOM = 16
На мой взгляд это костыль. Хочешь оргинального оформления — делай свои контролы. Тем более что в гугл апи это отчень просто. А подмена css может выплыть проблемом по кроссбраузерности.
365*0,03 — это почти 11 СУТОК в год! 22 часа в месяц!
Это при том, что за пару часов можно поднять балансировочный сервер и через 3-4 часа трафик пойдет через него.
Это «решение» для тех, кто жалеет 2-3 к руб админу, который сделает все быстрее и качественней.
Кстати, лет 10 назад мою компанию совершенно таким же образом хотели нагнуть за использование товарных знаков. И совершенно также было отказано в иске. Потому что подавали иск лохи, а я взял юриста — разработчика закона об авторском праве ;-)
администрация! где вы?
всего, что написано, НЕТ именно в Pebble.
согласен полностью с enemo:
плюсы: держат 5 дней, проверяют почту, на смс от уродцев с рекламой не отвлекаешься, на совещаниях оч. удобно (телефон — в вибро, на часах видно кто звонит. можно сбросить или взять трубку), показывают время
минусы: выглядят по-уродски, высасывают iphone (30% только за ночь).
он не индексирует. он агрегирует фиды от партнеров, которыми как раз являются avito, drom и.т.д.
но auto.ru, например, отдает яндексу только регионы, москвы там нет. наверняка и остальные отдают с задержками, ведь тот же авито живет не только за счет рекламы, но и за счет продавцов, платящих за поднятие и т.д.
я сразу захотел заказать много: портфели детей — 2, ключи — 4 комплекта + 2 от машин, один в бумажник, один в сумку жене — уже 12 штук.
и получается 200 баксов в год. как-то дорого.
странно, что не сделали подзарядку. и раз в год все заново перезаписывать — бред.
И кстати да, например для вывода на карту быстрее делать выборку с MBRContains с LIMIT и ORDER BY created DESC, а потом уже проверять расстояния. Тогда действительно работает быстро.
что касается Яднекса, переход на v2 — это мрак полнейший. Парадигма API совсем другая.
А самое жесткое, это перевод с google V2 на яндекс V2. В этом случае переписывать код приходится полностью.
Каждый ненужный щелчок по карте (на кластер) увеличивает процент отказов вдвое.
так что с 4 до 18 зума у Вас вряд ли кто доберется. если у Вас не останется точек, а будут одни кластеры, юзер плюнет и закроет страницу.
так что подумайте насчет 2000 кластеров. Для специальных сайтов типа недвижимости это еще сработает (там люди знают, что ищут), а для развлекательных — лучше меньше да лучше)
кстати, я работаю с картами уже года 4, как раз учился у kashey лично.
обратитесь к профессионалам, не изобретайте велосипед.
то есть на 0 масштабе сделать выборку по тайлам на масштабе 3, но выбирать не все, а, скажем, 100 новых. получится максимум 6400 объектов. вот их-то и кластеризовать.
смысл в том, что если выбрать на 0 зуме последние 6400 объектов, если большая вероятность, что большинство из них будет в одной части карты (например, в мск) — некрасиво.
другой вариант — каждой точке давать поле с рэндомным значением при сохранении и выбирать по этому полю limit 6400. рэндом ещенощно обновлять.
в лубом случае, 10 точек на клиенте по-любому быстрее, чем постоянная закачка данных с сервера.
habrahabr.ru/post/145832/
У меня все 10000 точек на клиенте лежат.
и кластеризуются.
мдя, я думал Вы что-то новое предложите. а у Вас… в квартре газ.
то есть индексируем тайлы до 16 зума. даже если на 18 зуме будет больше точек, их при обработке данных легко исключить.
вот как в php:
конвертите номер тайла в 1313101230130131 (16 зумом)
потом
tileId = base_convert('1313101230130131', 4, 10);
и сохраняете в базе для каждой точкb uint.
выборка точек:
MAX_ZOOM = 16
if ($this->zoom <= Maps2Utils::MAX_ZOOM )
{
$tile_from = base_convert( $this->id. str_repeat('0', Maps2Utils::MAX_ZOOM — $this->zoom), 4, 10);
$tile_to = base_convert($this->id. str_repeat('3', Maps2Utils::MAX_ZOOM — $this->zoom), 4, 10);
} else {
$tile_from = $tile_to = base_convert($this->id, 4, 10);
};
в sql просто BETWEEN $tile_from AND $tile_end