company_banner

Вредные советы от создателей API Яндекс.Карт. Как сделать так, чтобы всё было плохо

    Если гонится за вами
    Слишком много человек,
    Расспросите их подробно
    Чем они огорчены?
    Постарайтесь всех утешить.
    Дайте каждому совет,
    Но снижать при этом скорость
    Совершенно ни к чему.
    Г. Остер

    Сегодня чудесный весенний день. И не только потому что он весенний и очень скоро кому-то придется ехать на дачу копать картошку. А потому что сегодня версия 2.1 API Яндекс.Карт перестает быть beta-версией и становится основной.

    К этому событию мы полностью обновили документацию, добавили новых примеров в песочницу и написали эту статью. В этот раз мы решили не рассказывать только про версию 2.1, так как про нее мы уже и так достаточно поговорили во время запуска беты. Поговорим об использовании API Яндекс.Карт в целом.

    Разработка API – очень специфичная область программирования. На любую задумку дизайнера и разработчика накладываются потребности и умения пользователей API. Основной фидбек, который мы получаем – это сообщения пользователей в нашем клубе. Туда присылают примеры сайтов с Яндекс.Картами, багрепорты и рекомендации по улучшению нашего продукта. Мы видим, как API смотрится в боевых условиях, и мотаем на ус.

    Некоторые вещи часто делают неправильно. Сегодня я хочу о них рассказать. Все советы, которые вы прочтете — вредные. Если вы поймете, что соблюдаете некоторые из рекомендаций этой статьи, ничего страшного – никогда не поздно сделать ваш проект немного лучше. Итак, Irony mode ON.

    Ни в коем случае не читайте пользовательское соглашение


    Многовековой опыт использования Windows кое-чему нас научил. Мы даже не пытаемся читать пользовательские соглашения. Мы смело говорим: «Я со всем согласен» — и думаем, что кармическое возмездие никогда нас не настигнет, — «Дураки они, что ли? Ехать из своей силиконовой долины в Гусь Хрустальный, чтобы запретить мне пользоваться моей пиратской виндой?»
    В случае использования API Яндекс.Карт стоит придерживаться той же стратегии.

    Потому что если вы прочитаете пользовательское соглашение, то сможете понять, что вашу клевую идею воплощать на API незаконно. Например, вы не сможете сделать мониторинг транспорта или использовать API в админке к 1С. Или еще чего похуже.

    Поэтому перед самым началом работы дайте себе установку – если вы не читали соглашение, вы в принципе не в курсе ограничений и мир картографии для вас безграничен. Есть конечно в этом всем минус — API могут забанить на вашем сайте, если засекут нарушение. Но, как известно, проблемы нужно решать по мере поступления, поэтому спокойно движемся дальше.

    Вообще идеальный вариант — сделать сайт, отдать его заказчику, получить честно заработанную зарплату и забыть об этом навсегда. Если сумма гонорара была большой, рекомендуется сменить место жительства. Все-таки деньги портят людей.

    Избегайте чтения документации в любом виде


    Как известно, хороший код в комментариях не нуждается. Точно так же хорошее API не нуждается в документации. Вообще любая библиотека или модуль должны быть понятны интуитивно, а идеальный API не должен требовать навыков программирования. Поэтому если вы хотите посмотреть примеры у нас в песочнице, или почитать что-то про возможности API в руководстве, или тем более заглянуть в справочник (!) – боритесь с порывом. Верная стратегия — случайным образом выбрать один пример (желательно наименее подробный) и послушать зов сердца – оно подскажет, как писать.

    Итак, куда не надо смотреть перед началом разработки приложения:

    Не стоит задумываться о знании JavaScript


    Как известно, программист на JavaScript – это не программист, а так – верстальщик. Вас ни в коем случае не должно сбивать с этой мысли то, что API, который вы хотите использовать, написан на JavaScript. Изучая конструкции этого языка (если так вообще можно сказать), вы рискуете забыть что-то важное из другого языка, запутаться и все пойдет прахом.

    Идеальный вариант – это печатать конструкции JavaScript с помощью PHP. Приведу пример:

    <?php foreach($maps as $map): ?>
    myPlacemark = new ymaps.Placemark(["<?php echo $map['lantitude']; ?>" ,"<?php echo $map['longitude']; ?>" ]);
    myMap.geoObjects.add(myPlacemark);
    <?php endforeach;?>


    Видите, как изящно мы обошлись без JavaScript!

    Этот подход позволит вам избежать многих неприятных последствий
    • Ваше приложение будет работать достаточно медленно, чтобы дать пользователю время подумать о смысле жизни.
    • Ваш код не будет требовать обфускации, так как он достаточно запутан с самого начала.
    • Код страницы не будет кешироваться браузером, а будет генерироваться каждый раз заново на сервере.

    Печально, что многие программисты все-таки пытаются идти против системы. Они пишут код на чистом, хорошо структурированном JavaScript. Загружают данные пачками по одним и тем же URL, засоряя кеш браузера. В результате их приложения работают быстро, пользователи воспринимают это как должное и даже не смотрят на другие сайты. Подумайте о подрастающем поколении – хватит делать сайты, на которых школьники проводят свою молодость, освободим человечество от интернет-зависимости!

    Книга, которую не стоит читать, если вы решите разработать приложение на JavaScript:

    image

    Избегайте структурирования кода


    Если вы планируете сделать что-то чуть более сложное, чем схема проезда, вам может прийти в голову продумать архитектуру вашего сайта. Возможно, вы даже захотите выделить в коде компоненты, создать классы или разбить код на функции.

    Этого не стоит делать по нескольким причинам:
    • Код, разбитый на модули, сложно читать, потому что команды стоят не по порядку.
    • На разработку архитектуры требуется много времени.
    • Приложение, использующее карты, просто недостойно вашего времени и внимания. Точка.

    Вещи, которых стоит избегать при разработке приложения, использующего карты:
    • Не надо разбивать код на классы или функции.
    • Не стоит использовать модульные системы, никакие RequireJS вам не нужны.
    • Не надо разделять код и данные по разным файлам – если файлов много, в них легко запутаться.

    К сожалению, у нас есть примеры, которые вопреки всему используют эти подходы. Посмотреть и оценить их нелепость можно в песочнице.

    // Задание собственного модуля.
    ymaps.modules.define('CustomModule', function (provide) {
        var CustomModule = function (defValue) {
            this.field = defValue;
        };
        provide(CustomModule);
    });
    
    // Запрос модулей.
    ymaps.modules.require(['CustomModule'])
        .spread(
            function (CustomModule) {
                // ...
            },
            this
    );
    


    В версии 2.1 разработчики API буквально расставили ловушки, открыв модульную систему, которая используется в API. Теперь слабый духом разработчик может не выдержать и разбить свой код на модули. Мужайтесь.

    Книги, которые могут помешать вам писать идеальный код, писали коварные люди. У них система ценностей перевернута с ног на голову. Врага надо знать в лицо, вот некоторые из потенциально опасных изданий:

    imageimageimage

    Готовьте все заранее


    Если вы планируете показать на карте большое количество объектов, нужно решить, в какой момент загружать данные с сервера на клиент. Единственно правильный путь – загрузить данные сразу и желательно до загрузки контента страницы, на которой показана карта. Подумайте сами – если не сейчас, то когда? У человека может отключиться интернет и тогда плакали наши меточки. Не все программисты поняли эту простую истину и все еще пытаются загружать данные по требованию.

    Вот грустный пример, показывающий, как подгрузить данные в балун метки по требованию. Вот еще один грустный пример, показывающий, как создать карту по требованию. И чего только эти разработчики не учудят…

    Загружайте с запасом


    API – это много кода, разбитого на модули и пакеты. После разработки вашего сайта нужно решить еще один важный вопрос: какой код API подключать на свой сайт?

    Тут будет не лишним вспомнить о случаях, когда вы посылали друга за баночкой колы, а он одну и приносил. Ровно то же правило работает и для загрузки кода. Лучше загрузить весь код API целиком – никогда не знаешь, что тебе пригодится. В версии 2.0 разработчики насоздавали пакеты, которые пользователь может случайно начать использовать, если скопирует пример из песочницы не задумываясь.

    image

    Как избежать подобных ошибок? При использовании версии 2.0 любые комбинации загружаемых модулей надо поменять на package.full. При таком подходе пользователь получит намного больше кода, что хорошо.

    В версии 2.1 разработчики, к сожалению, просекли, что люди не поддаются на провокации и грузят API целиком. Поэтому в версии 2.1 вообще отменили пакеты, а package.full теперь разбит на части, которые подгружаются асинхронно по мере надобности.
    Вместо пакетов теперь можно подключать одиночные модули, которые вы хотите использовать. Вообще без всякого запаса.

    image

    Программировать хорошо становится все сложнее.

    Добавляйте элементы управления


    Пользователь всегда рад, когда на карте есть кнопки. Кто не любит кнопки? Кнопки любят все! Вы можете скопировать пример из песочницы для версии 2.0, демонстрирующий работу всех имеющихся элементов управления, и добавить код на свой сайт как есть.



    Опытный пользователь может заметить, что на этой карте представлены не все элементы управления. Нерадивые программисты забыли добавить на карту второй элемент управления масштабом и контрол поиска. Кстати, раньше этот пример содержал сразу два элемента управления масштабом. Поэтому мы периодически находим сайты, на которых все работает как надо – на карте есть все, что нужно: и большой контрол, и маленький. Зачем понадобилось делать пример хуже, остается загадкой и по сей день.

    Версия 2.1 опять поставила нам подножку. В ней стало меньше элементов управления (злодеи выпилили мини-карту), они установлены на карту по умолчанию и на маленькой карте схлопываются до небольших размеров.



    Убедитесь сами – кнопок мало, сами они маленькие. Карта вообще как голая! В общем 2.1 вообще лучше не использовать.

    Покажите пользователю, насколько слаб его браузер


    Если вам надо показать сотни или даже тысячи объектов на карте, смело идите в бой. Создавайте метки и мужественно наносите их на карту в полном объеме. При достаточном количестве меток вы сразу покажете пользователю, кто в мире хозяин – человек или браузер. Потому что при большом количестве меток (100 для IE, 500 для всех остальных) браузер крякнет и зависнет на неопределенный срок. Так ему и надо.

    Разработчики, пытающиеся скрыть несовершенство браузеров, маскируют их недостатки весьма изощренными способами:
    • Используют кластеризацию объектов. Этому хитроумному приему у нас посвящено немало примеров и даже целая статья.
    • Используют технологию активных областей. Несмотря на сложность разработки, она снимает любые ограничения на количество отображаемых объектов. Оценить коварство замысла можно, прочитав руководство разработчика или посмотрев пример в песочнице.

    Не пытайтесь экономить запросы к геокодеру


    Очень часто пользователи сталкиваются вот с какой задачей. У них есть список адресов магазинов, аптек, достопримечательностей и многого другого. Все эти адреса нужно показать на карте. Задача решается просто – нужно взять все адреса, отправить их на клиентскую сторону, и просто-напросто геокодировать адреса в координаты меток на клиенте.

    Неподготовленный читатель может спросить «Правильно ли то, что набор меток у нас один и тот же, а геокодируется он каждый раз при каждом вызове моего приложения у каждого пользователя заново?». Мы отвечаем на этот вопрос прямо: «Не волнуйтесь». Сервера Яндекса достаточно отказоустойчивы и выдержат все. Единственная загвоздка – при большом количестве запросов с вашего сайта вы можете превысить лимит в 25 000 запросов на геокодирование и ваш сайт забанят. Но эту проблему мы уже освещали выше, поэтому не будем засорять голову по пустякам.

    Разработчики, которые не читали эту статью и не верят в силу серверов Яндекса, придумали геокодировать данные на сервере. А один наш сотрудник даже написал модуль для серверного геокодирования на node.js. Этому посвящен раздел в руководстве разработчика.

    image

    И не лень же было…

    Не отбирайте хлеб у службы техподдержки


    В какой-то момент вы можете почувствовать странное непреодолимое желание пообщаться со службой техподдержки API Яндекс.Карт. К этому событию нужно подойти серьезно, а не абы как.

    Постарайтесь не грузить службу техподдержки лишними подробностями. Идеальный багрепорт состоит из пяти слов – «все сломалось, ничего не работает». Вообще, наша служба техподдержки уже давно сократила эти пять ключевых слов в одно – «всесломалосьничегонеработает». И теперь у нас появился термин, по которому и поддержка, и разработчики мгновенно понимают суть вещей.

    Вот хороший пример обращения в клубе:



    Разработчик при виде этого сообщения мгновенно понимает, что вся его работа – тлен. Вселенная появилась из большого взрыва, расширяется и вот-вот схлопнется. Все пропало. Ничего не работает.

    Вещи, которых стоит избегать при обращении в техподдержку или клуб:
    • Подробное описание проблемы.
    • Приведение кода, с помощью которого можно повторить баг.
    • Ссылка на страницу, где воспроизводится баг.


    Если вы хотите написать о проблеме в клуб разработчиков, не стоит пользоваться поиском, читать ответ на FAQ и пытаться каким-то другим образом найти решение своей проблемы. Подумайте – если все будут находить ответы на вопросы сами, чем тогда заниматься работникам техподдержки?

    Заключение


    Вот и все вредные советы, о которых мы хотели рассказать. Вообще типовые ошибки для вас – это задачи для нас. Если разработчики наступают на одни и те же грабли при использовании API, то это в какой-то мере и наша вина. Возможно мы не предусмотрели кейс, написали мало примеров, плохо сделали документацию и т.д и т.п. В частности, в версии 2.1 мы постарались сделать так, чтобы человеку было сложнее ошибиться, чем в версии 2.0. И работы в этом направлении еще выше крыши.

    Не принимайте нашу статью близко к сердцу, улучшайте свои проекты, присылайте нам добрые и гневные пожелания. Мы вам все объясним и расскажем, даже если все сломалось и ничего не работает =)
    Яндекс
    503.50
    Как мы делаем Яндекс
    Share post

    Comments 75

      +12
      Спасибо за первый пункт!

      «Яндекс вправе по своему усмотрению отказать в доступе к Сервису без объяснения причин.»
      На этом можно было, по сути, и закончить :)
        +8
        Стесняюсь спросить, сколько вы предоставляли бесплатных сервисов пользователям.
          +7
          Стесняюсь вам ответить, но при таком раскладе есть неиллюзорный шанс получить не работоспособный бесплатный сервис для пользователей.

          Все ближе склоняюсь к идее реализовать поддержку минимум двух картографических сервисов.
            0
            И ваш бесплатный сервис для пользователей будет поставляться с обязательством не отключать пользователей никогда и ни при каких условиях?
              +1
              Ну, скажем, в рамках договора-оферты.
                –2
                Это как?
                  +9
                  Нарушил правила — забанил. Не нарушил, но «дико бесит, хочется взять и забанить» — низзя!
                    –2
                    Удачи вам, она пригодится.
                      +3
                      Спасибо ;)
            +5
            вы знаете, яндекс так же и с платными сервисами поступает…
              0
              s/Яндекс/любая другая компания
                +6
                любая-другая-компания не брала мои деньги в заложники и не требовала за них выкуп ;)
                  –7
                  Из этого не следует, что любые-другие-компании так не поступают.
                    +1
                    Железная логика.
                    +1
                    Кстати да, после таких веселых побегушек с целью доказать, что ты не баран, я полностью отказался от ЯД.
            +11
            А вот еще совет — если вы сделали свою модульную систему, похожую на уже существующую, но не совместимую, ни в коем случае не пишите по ней документации. Два с половиной примера будет достаточно.
                +2
                Позволю себе ответить на этот завуалированный выпад.

                Нет, мы не написали 15-ый конкурирующий стандарт.
                Модульностей на рынке много, но у нас есть вполне конкретные требования:
                1. Асинхронный require
                2. Асинхронный provide
                Первое требование означает, что по modules.require мы можем сходить на сервер и подгрузить нужные модули.
                Второе требование означает, что модуль сам может быть декомпозирован и (а) догрузить что-то в тот момент, когда его кто-то захотел использовать (например, пробки догрузят актуальные данные — баллы пробок — именно в тот момент, когда их используют), (б) разбить длительную инициализацию на несколько этапов, чтобы не подвешивать браузер.

                Нам пришлось выдвинуть такие требования, когда мы начали заниматься декомпозицей package.full. Например, код и картинки для «линейки» на карте не грузятся, пока пользователь не включил её.

                Мы очень хотели использовать какую-нибудь из имеющихся модульных систем, но быстро обнаружили, что ни одна (requirejs, commonjs, AMD, LMD, etc) не удовлетворяет этим требованиям.

                Мы используем модульную систему, написанную нашим коллегой dfilatov. Она доступна на гитхабе, прошу любить и жаловать:
                github.com/ymaps/modules
                  0
                  Я помню пост про эту систему, и не возражаю против ее существования в принципе.

                  Просто названия совпадают с AMD-шными, но ведут себя по другому, документации кот наплакал, и чтобы выудить даже эту ссылку, пришлось делать «выпад»:)
                  0
                  Судя по коду Яндекс.Карт, модульная система используется намного шире, например, для загрузки css через метод provideCss. Почему тогда открытый проект на гитхабе такой скудный? Я понимаю, что можно поднапрячься и расширить функциональность вашей библиотеки, но не вижу смысла на фоне уже имеющихся библиотек. Если уж идти в открытую, то идти до конца, не ограничиваясь модульностью только в картах. Задумка с двойной асинхронностью очень хорошая, уверен, что не только вы решали эту проблему.
                    0
                    css = просто строка, которую мы добавим в тэг link. Не вижу особого смысла открывать эту функцию, но мы подумаем, спасибо.

                    > Задумка с двойной асинхронностью очень хорошая, уверен, что не только вы решали эту проблему.

                    Ну, я не нашел ни одной библиотеки с такой функциональностью год назад. Может, вы нашли?
                      0
                      Ну, я не нашел ни одной библиотеки с такой функциональностью год назад. Может, вы нашли?

                      Не встречал таких.

                      Загрузка css лишь малый пример того, что скрыто. Скрыта сама суть независимого модуля, который тянет за собой стили, картинки, шаблоны, мета данные и т. д. Поэтому и говорю, что тот обрубок на гитхабе не интересен для использования в своих проектах. Кроме того, модули еще надо как-то собирать и компоновать с учетом дерева зависимостей для использования на продуктивной системе, и тут опять — тишь да гладь, ничего не предоставлено. Если бы выкатили все до конца, был бы успех, потому что кроме Component я не могу назвать примера библиотеки с инкапсуляцией зависимостей.
                        0
                        > Загрузка css лишь малый пример того, что скрыто.

                        Нет, это неправда.
                        provideCss — просто шорткат для записи строки в link. Картинки и шаблоны также поставляются как строки, даже без шорткатов.

                        Поверх modules на гитхабе мы используем только шорткат для css + оборачиваем в промисы (с использованием другого публичного проекта github.com/dfilatov/vow)
                0
                Вместо указания загрузки модулей в src "//api-maps.yandex.ru/2.1/?load=Map,Placemark"
                удобно было бы сделать
                ymaps.ready(function (Map, Placemark) {
                var map = new Map();
                //…
                })
                чтобы только код пользователя во всем моем приложении знал какие модули ему нужны. А-ля dependency injection в ангуляре
                  0
                  Можно использовать ymaps.load(['список модулей']) — эффект будет примерно такой
                    0
                    Вы можете поставить пустой GET-параметр load "...?load=&lang=...". В таком случае будет загружена только модульная система. А дальше при помощи метода modules.require производить загрузку только тех модулей, которые нужны.
                    api.yandex.ru/maps/doc/jsapi/2.1/ref/reference/modules.require.xml
                    api.yandex.ru/maps/jsbox/2.1/module_request
                    +7
                    Классно было бы прямо на api.yandex.ru/maps/doc/intro/concepts/rules.xml выписать основные правила и ограничения.

                    То, что яндекс-карты можно использовать только на сайтах и в мобильных приложениях, — неочевидно и зарыто в середине одного из трёх соглашений. А это, в отличие от многих других очевидных пунктов, написанных сложным юридическим языком, важно знать.
                      +1
                      Да, вы правы, попросим наших документаторов.
                      +4
                      Поясните по пункту «2.3.2. Сервис может использоваться Пользователем только в рамках сайтов или мобильных приложений, доступных для бесплатного открытого использования неограниченным кругом лиц. Сервис не может использоваться для проектов, требующих оплаты, или иным образом ограничивающих доступ к ним третьих лиц. Необходимость зарегистрироваться не считается ограничением доступа в рамках настоящего пункта.»

                      могу ли я написать софт, для внутреннего использования внутри компании. например, ГИС своих магазинов, объектов, etc… ведь я предоставляю данный сервис только ограниченному кругу лиц., хоть и бесплатно, но только сотрудникам своей компании.
                        0
                        Добрый день. Подобная реализация нарушает Пользовательское соглашение. Страница с картой долдна быть доступна для неограниченного круга третьих лиц.
                          +2
                          Я не в коем случае не пытаюсь потроллить, действительно интересно.
                          Предположим мне нужно решить задачу описанную выше. Я беру, и на публично доступном сайте компании, на публично доступной странице все реализую, но страница находится по длинному и нечеловекопонятному урлу + закрыта от индексирования. Т.е. не зная урл — туда не попадешь.
                          Пойдет?
                            +1
                            Я ни в коем случае не пытаюсь потроллить. Но в Гражданском кодесексе есть понятие о доведении до всеобщего сведения.
                              +1
                              а как связаны доступность и доведение? вот я, например, работая по публичной оферте, должен пускать в свой магазин всех желающих. Но я же не должен его нигде рекламировать.

                              К тому же, страницу всегда можно сделать и индексируемой, но с разным функционалом для разных пользователей.
                                0
                                Карма еще не позволяет лайкнуть ваш комментарий :)
                              +1
                              Да, как только не извернутся лишь бы нарушить. чем вас OpenStreetMap не устраивает?
                                0
                                Я вопрос задавал исключительно в познавательных целях. Я в работе сталкиваюсь с похожими проблемами (договор оферты и страшно умные пользователи, вот это все), и мне было любопытно как коллеги из Яндекса отреагируют на «хак» договора, который ну просто первым приходит в голову.
                                  0
                                  вот вы сейчас спросили, а они потом правила поправят и «дырку» прикроют
                                    0
                                    Всё исключительно на вашей совести :)
                                  0
                                  на заметку: требований к тому, чтобы страница была публично доступна нет — только к сайту.
                                    0
                                    Вот эту дырку мы скорее всего исправим :) Потому что имеется ввиду конечно страница сайта на которой используется API. Спасибо.
                                0
                                Если вы ограничиваете круг лиц, которые могут зарегистрироваться, очевидно вы нарушаете условие про «неограниченный круг лиц» и использовать API не можете.
                                  0
                                  Если вы будете использовать только внутри компении, а не продавать софт на сторону тысячам пользователей, то вероятность быть пойманным за руку пренебрежительно мала. Если совесть позволяет, то можно не париться.
                                    0
                                    Также вопрос по данному пункту пользовательского соглашения.
                                    Получается в бэкэнде использовать яндекс.карты запрещено?
                                    Опишу конкретный кейз:
                                    Допустим я делаю раздел бэкэнда для сайта, например… управление списком точек продаж. Для удобства контентщику — я вставляю яндекс карты, с поиском, чтобы он тыкнул на карту и координаты зафиксировались.
                                    Это бэкэнд, и он по определению имеет ограниченный доступ. Таким образом использование яндекс.карт нарушает данный пункт и формально я должен быть забанен?
                                      +1
                                      Да. Именно так. Вы правы.
                                        0
                                        Не подскажете, а Битрикс с вами на каких-то особенных условиях работает?
                                        beta.hstor.org/files/449/af4/731/449af4731dbf40d7be9bce27178ab984.png
                                        Битрикс
                                          +1
                                          Спасибо за сообщение.
                                          0
                                          Боюсь те кто держит сайты с метками на карте сейчас повесились или пошли переводить админки к гуглу. Как можно модерировать метки без возможности их отображения на карте я плохо представляю.

                                          Простой пример:
                                          — есть сервис для обмена информацией между поставщиками и дистрибьютерами
                                          — у каждого контрагента есть адреса складов/офисов/подразделений со схемами проезда

                                          Вопрос: для модерации отметок на карте поставленных пользователем мне необходимо зайти под его учетной записью и проверять все с клиентской части сайта?

                                          Или существуют иные программы лицензирования, кроме существующей бесплатной, и я это упускаю?
                                            0
                                            Добрый день. Действительно существует платная лицензия для использования в закрытых системах и для мониторинга транспорта. Такая возможность появилась совсем недавно и пока она не публичная. Для выяснения подробностей можете написать мне ache@yandex-team.ru и я с радостью вам помогу с реализацией.
                                      +9
                                      Вы хотите чтобы ваше пользовательское соглашение читали? ОТлично — прикрепите к нему краткую выдержку с описанием основных моментов нормальнычм человеческим языком.
                                      Как минимум пользователь увидит общую картинку и если уже возникнут вопросы — полезет детально читать конкретный пункт соглашения.
                                      Моей жизни(как и большинства людей) не хватит чтобы детально прочитать все соглашения с которыми приходится иметь дело.
                                      Да и ладно прочитать. Понять юридический язык призванный затыкать все лазейки стоит весьма не малых затрат времени и сил, особенно у людей далеких от юриспуреднции.

                                      Отдельный способ, который позволит значительно улучшить восприятие пользователями лицензионного соглашения — это интерактивный тест.
                                      К примеру вот тест для публикации в AppStore:
                                      www.makayama.com/checklist.html

                                      Хотите чтобы пользователи читали соглашение? Нет проблем, сделайте его удобочитаемым.
                                        0
                                        Типа «Хотите чтобы УК соблюдался — расклейте по улицам демотиваторы с основными статьями, эти тома никто в здравом уме не осилит.»?
                                          +5
                                          Именно так.
                                          Поэтому основные законы доносят родители в начале жизни ребенка.
                                          Также в школах проходят основы ПДД и других законов.
                                          Мало того, ГИБДД регулярно пишет разъяснения по ПДД, в том числе в картинках:
                                          www.kolesa.ru/article/2012/04/20/gibdd_govorit_pokazyvaet_i_shtrafuet
                                          Странно, что у Вас это удивляет. Это нормальный подход, когда цель донести информацию, а не запутать в юридических терминах.

                                          Ну и да, сколько Вы знаете людей, которые читали УК целиком? Вы сами читали?
                                          +3
                                          С радостью сделаю это в виде статьи для начала. Спасибо за идею.
                                          +1
                                          2.3.7.3. Создавать на основе Сервиса системы мониторинга транспортных средств, отображающих информацию в реальном времени, и любые другие услуги, связанные с управлением и диспетчеризацией транспортных средств.


                                          Вот иногда такое ощущение, что юридический язык используют не для того, что бы добиться однозначности, а для того… ну просто положено так писать и все.
                                          Вот создам я сервис на основе собственного программного кода, в котором буду использовать карты для отображения, пусть и в реальном времени. И что? Как это соотносится с указанным пунктом?
                                            0
                                            Как я написала выше, мы попросим документаторов подготовить более «человекочитаемые» выдержки из пс.
                                              +1
                                              и я даже боюсь спросить, а не входят ли варианты использования описанные у вас вот тут api.yandex.ru/maps/solutions/?p=shop в противоречие с 2.3.7.3 если вдруг курьер, посмотревший адрес, внезапно сел за руль?
                                                0
                                                Нет не входят :)
                                                  0
                                                  это вы так сказали, или из текста так следует? Потому что у меня курьеры на автомобилях, наряды я им формирую исходя из заказов. То есть фактически именно карта формирует наряд, а значит участвует в диспетчеризации.
                                                    0
                                                    Мы исправим текст так, чтобы из него это не следовало, так как такой кейс, если карта отображается не только для ваших курьеров, но и для всех желающих пользователей, не нарушает ПС.
                                              0
                                              Ваш сервис на основе вашего кода будет использовать API для отображения. Использовать отдельно карты (то есть тайлы) нельзя согласно пункту 2.3.3. Пользователь может использовать Данные и функции, полученные при помощи Сервиса, только в рамках функциональности, предоставляемой Сервисом.
                                            • UFO just landed and posted this here
                                                +2
                                                Очень сложно получить полезный прогноз даже на час. После часа прогноз тихо превращается в обычную статистику пробок.
                                                Так что если вам надо ехать куда-то через 8 часов, посмотрите статистику пробок на это время.
                                                0
                                                Почему на яндекс картах названия стран либо подписаны бледно и мелко либо вообще в большинстве масштабов отсутствуют? А также почему очень невнятно обозначены границы между странами?
                                                Приходиться запускать гугловские там хоть с этим и есть проблемы, но по сравнению с яндекс картами небо и земля.
                                                  0
                                                  Этот вопрос скорее надо адресовать к дизайнерам нашей подложки. Напишите в службу поддержки, что вызывает сложности.
                                                  +2
                                                  Вообще любая библиотека или модуль должны быть понятны интуитивно, а идеальный API не должен требовать навыков программирования.

                                                  Абсолютно согласен с этим утверждением. Где-то год назад довелось работать с VK API, и я 3 дня потратил чтобы выполнить кроссдоменный запрос на javascript. Конечно, мои знания на тот момент оставляли желать лучшего, но даже сейчас я понимаю что с моими нынешними знаниями это было бы сложно
                                                    0
                                                    2.3.7.4. Создавать на основе Сервиса игровые проекты или приложения

                                                    имеется в виду игровые приложения или вообще любые приложения (в том числе не взывающие плату и не ограничивающие доступ к картам)?
                                                      0
                                                      Имеются в виду игровые приложения
                                                        0
                                                        Вот опять. Почему «имеется в виду» а не написано явно. Что мешает сказать «игровые проекты или игровые приложения». Поймите правильно. У вас имеется в виду, а нам, как пользователям, с этим работать. И когда речь заходит о вариантах применения, чуть более сложных, чем «как проехать», пограничные варианты всплывают постоянно.
                                                          0
                                                          Мы передадим юристам это уточнение
                                                      0
                                                      Нигде не нашел описания апгрейда с 2.0 на 2.1. В документации есть описание перехода 1.1 -> 2.1, которое мне совсем не подходит.

                                                      Такое описание действительно нужно, потому что есть несовместимые изменения, например, пресеты точек на карте теперь называются не 'twirl#darkgreenIcon' a 'islands#darkgreenIcon'
                                                        +1
                                                        Сейчас описания перехода с 2.0 на 2.1 действительно нет, но люди просят, так что видимо мы его сделаем. Пока что можете сравнить, как сделаны примеры в песочнице для версии 2.0 и для 2.1, там в принципе видны различия.
                                                        0
                                                        Ну а если мне надо тупо сделать карту фестиваля для публичного её размещения. Обозначить десяток объектов и подписать их. Мне обязательно надо учить ява-скрипт? Что помешало реализовать подписанные маркеры в конструкторе карт?

                                                        Only users with full accounts can post comments. Log in, please.