Написать разработчикам яндекс: 404

Содержание

Техподдержка Яндекс Музыки, как написать в службу поддержки

В этой статье выясним, работает ли горячая линия сервиса Яндекс Музыка, по какому телефону можно связаться, как отправить обращение онлайн?

О сервисе

Яндекс.Музыка — это популярный сервис, позволяющий прослушивать или искать музыкальные композиции по свои запросам и рекомендациям. Уникальная система фильтрации позволит отыскать интересующих исполнителей и жанры. В некоторых странах существует плата за использование, так называемая подписка.

Подробней о том, как пользоваться ресурсом читайте на сайте https://yandex.com/support/music/index-mobile.html?lang=ru.

Как написать в службу поддержки Яндекс Музыки?

Сервис музыка от Яндекс стал популярен во многих странах, пользователи готовы делиться впечатлениями, своим видением дальнейшего развития. Но, не только с отзывами или замечаниями могут обратиться клиенты. Не редко в службу поддержки обращаются ввиду каких-то трудностей с оплатой или установкой расширений.

Чтобы задать вопрос, можно воспользоваться одним из способов:

Заполнить форму «Написать в техподдержку» по ссылке https://yandex.com/support/music/troubleshooting/wishes.html.
Написать сообщение через учетную запись в подразделе «Помощь».

В сообщениях нужно уточнить контактный email-адрес, ФИО, тему, описать суть вопроса. В отдельных случаях можно прикрепить доп. материалы (видео, фото).

Социальные сети

Связаться со специалистами Яндекс Музыка можно и привычным для пользователей способом, оставив комментарий в одной из соц. сетей. Компания для развития сервиса, оповещения клиентов о новых возможностях создала официальные страницы:

Можно делиться впечатлениями или просто просматривать информацию об изменениях.

Какой телефон горячей линии Яндекс Музыки?

Существует ли телефон горячей линии сервиса?

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

В теории клиенты могут позвонить на номер телефона справочного центра компании — 8 (800) 234 24 80. Но, будут ли готовы ответить операторы на интересующие вопросы, не известно.

Для каких случаев предназначена служба поддержки?

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

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

В каком случае поддержка не сможет помочь?

Все что касается Яндекс Музыки можно обсудить со специалистами. Но, поддержка не сможет ответить, если пользователи не готовы представиться, назвать email-адрес, другие сведения.

При обращениях с нецензурными высказываниями или темами, не касающимися Yandex, на помощь также не стоит рассчитывать.

Связь с техподдержкой через личный кабинет

Авторизовавшись на сайте или в приложении, пользователи смогут написать сообщение с просьбами, замечаниями, отзывами, вопросами.

Для входа в личный кабинет используйте ссылку: https://passport.yandex.ru/auth.

Для этого перейдите в подраздел «Техподдержка».

Как написать жалобу?

Если не знаете, как оставить жалобу, изучите внимательно блок справочной информации в подразделе «Частые вопросы».

Сообщить о своих сложностях, проблемах с оплатой или использованием приложения и т.д., можно несколькими способами:

Через форму обратной связи.
В соц. сетях, оставив комментарий.

Жалобы рассматриваются наряду с обычными сообщениями.

Время работы

Режим работы техподдержки круглосуточный.

Но, из-за количества запросов специалистам нужно время на обработку сообщений и ответ.

Служба поддержки Яндекс Маркет: телефоны, как написать жалобу?

На чтение 3 мин Просмотров 1.6к. Опубликовано 05.07.2021
Обновлено 05.07.2021

В этой статье узнаем, можно ли дозвониться по горячей линии Яндекс Маркет? Какие вопросы возможно обсудить? Как написать обращение в службу поддержки?

О сервисе

С Яндекс.Маркетом пользователи смогут сравнить цены, товары от различных магазинов. Сервис работает с большинством компаний в РФ и некоторых других странах. Информация о платформе, её возможностях и нюансах использования доступна на сайте: https://market.yandex.ru/about.

Если хотите пообщаться с техподдержкой, обратите внимание на доступные каналы взаимодействия.

Телефон горячей линии Яндекс Маркет

На официальном сайте заявлены, как ответы по всем наиболее востребованным темам, так и способы для связи с менеджерами.

Если отправить сообщение онлайн не удается либо есть другие причины, позвоните на действующий телефон горячей линии: 8 (800) 234 27 12 (бесплатно).

Номер телефона доступен круглосуточно, а операторы call-центра смогут найти ответы по большинству вопросов. Представлен и вспомогательный номер офиса в Москве (куда могут обращаться и юридические лица): +7 (495) 414 30 00.

Адреса пунктов выдачи

Адреса доступны на Яндекс Картах.

Как написать в службу поддержки?

Если хотите оставить замечание в адрес работы сервиса, разработчики предлагают форму по ссылке: https://pokupki.market.yandex.ru/help/feedback.html.

Также на запросы, замечания касающиеся работы сервиса готовы ответить в единой службе поддержки Яндекс (выбирайте вкладку «Маркет»).

Здесь же https://yandex.ru/support/market/troubleshooting/general.html, возможно ознакомиться с инструкциями, рекомендациями, разъяснениями от сотрудников Яндекс Маркет.

Социальные сети

В качестве альтернативы некоторые пользователи могут использовать соц. сети:

Обращение в поддержку через личный кабинет

Оформление покупок, оплату лучше проводить через учетную запись. Личный кабинет позволяет упростить подачу обращений в техподдержку.

Для входа в профиль используйте ссылку: https://passport.yandex.ru/auth/list.

Для каких случаев нужна служба поддержки?

Помощь специалистов платформы пригодиться, если возникли проблемы с доступом, восстановлением данных, оформлением покупки или переводом средств.

Свяжитесь различными способами и расскажите в деталях о произошедшем (рекомендуется вставлять фотоматериалы).

В каком случае поддержка не сможет помочь?

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

Требование к клиентам касается лишь правдивого указания причин, ввода корректных сведений.

Как написать жалобу?

Чтобы оставить жалобу эффективней воспользоваться личным профилем и заполнить вкладку «Отзывы, предложения и претензии».

Сообщить о замечаниях получится через call-центр или соц. сети.

Опишите жалобу, с чем возникли трудности, какие нарекания на работу сервиса (прикрепите фото, видео).

Время работы

Специалистам не всегда удается быстро ответить на сообщения от клиентов.

Режим работы техподдержки Яндекс Маркет круглосуточный (телефон и онлайн формы).

Вакансии компании Яндекс — работа в Москве, Санкт-Петербурге, Екатеринбурге, Ростове-на-Дону

Будет сложно, будет интересно

Яндекс — одна из крупнейших IT-компаний в России. Мы развиваем самую популярную в стране поисковую систему и создаем сервисы для миллионов людей.

Благодаря нашим технологиям то, что вчера казалось фантастикой, сегодня становится реальностью. Пару лет назад мы не могли представить, что можно мгновенно узнать адрес ближайшей работающей аптеки, находясь в любой точке города. Что такси не надо ждать или заказывать заранее. Что можно заказать свежий хлеб, и его привезут прямо домой за 15 минут. А сейчас это всё — совершенно обычные вещи.

Наши технологии

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

Во многих наших продуктах используются машинное обучение и нейронные сети. На их основе создаются и развиваются новые технологии, которые востребованы во всём мире. Например, беспилотные автомобили Яндекса уже проходят испытания на дорогах России, Израиля и США. Платформой Yandex.Cloud пользуются крупные международные компании. Сервис онлайн-заказа такси Yango доступен в семнадцати странах.

Наша команда

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

Наши направления

Мы развиваем несколько бизнес-направлений:

Это поиск, рекламные, облачные и портальные сервисы, к которым относится работа над Алисой и умными устройствами.
Это сервисы онлайн-заказа такси, товаров и еды. Например, Маркет и Лавка.
Это беспилотные автомобили.
Это сервисы объявлений: Недвижимость и Работа.
Это медиасервисы: Музыка, Афиша и КиноПоиск.

Какие-то из этих направлений и сервисов существуют давно, а какие-то появились недавно. Мы постоянно ищем новые направления, проводим эксперименты и проверяем разные идеи и гипотезы.

Карьерные возможности

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

Откуда можно работать

У нас есть 20 офисов в России и 17 офисов в других странах. Если рядом с вами нет офиса, то у нас есть программа релокации.

Условия работы

Комфортные офисы, где есть место не только для работы, но и для спорта и отдыха. Офисы открыты для сотрудников 24/7.
Гибкий график работы.
Дресс-код описан одной фразой: на работу нужно приходить одетыми.
Начиная с первого дня работы у каждого сотрудника есть объёмный пакет услуг ДМС. Также мы компенсируем 80% стоимости полиса ДМС для супругов и детей.
Мы поощряем квалифицированных сотрудников программой опционов. Для этого чтобы получить опционы, не нужно быть большим начальником. Достаточно хорошо работать и приносить пользу компании. Опционы дают существенный бонус к зарплате и регулярным премиям. 59% сотрудников принимают участие в опционной программе Яндекса по результатам своей работы.
Для специалистов высокой квалификации есть программы жилищного займа: под 3% или вообще без процентов.

Контакт-центр: Яндекс.Чат

Канал Яндекс.Чат позволяет создать открытую линию c помощью сервиса Яндекс.Диалоги, и клиент может обратиться в линию вашей компании сразу же со страницы результатов Яндекс-поиска.

16 августа 2021 года все действующие Яндекс-чаты и кабинет оператора закроются, а виджет Яндекс.Диалогов перестанет работать. Если вы разместили виджет у себя на сайте, удалите его код со всех страниц, где он есть.

Как подключить канал Яндекс.Чат

Для подключения канала необходимо перейти в соответствующий раздел настроек коннектора Яндекс.Чат в Контакт-центре Битрикс24, скопировать Идентификатор канала, который потом нужно будет вставить при создании Яндекс.Диалога:

Далее в сервисе Яндекс.Диалоги нажать кнопку Создать диалог > Чат для бизнеса:

Заполнить Основные настройки диалога:
- Сайт для верификации прав использования бренда – адрес вашего сайта. Здесь нужно правильно указать адрес вашего сайта со схемой (например, https://example.ru).
  Внимание! Прежде, чем создавать диалог, убедитесь, что подключаемый сайт у вас верифицирован в сервисе Яндекс.Вебмастер. Там несколько простых схем подтверждения владения доменом на выбор. Проблем возникнуть не должно.
- Провайдер – выбираем Bitrix.
- ID – идентификатор канала, который мы скопировали из настроек канала Яндекс.Чат Открытой линии (см. п.1 выше).
- URL – адреса страниц, для которых должен включаться этот чат в результатах поиска. С помощью этого поля можно ограничить чат определенными страницами сайта.
  
  Если оставить это поле пустым, то кнопка Начать чат будет отображаться в сниппете каждой страницы вашего сайта, которая попадает в результаты поиска. Подробнее про правила указания URL читайте в рекомендациях Яндекс.Диалоги.

Затем вам нужно заполнить данные для Публикации в каталоге:

Сохраните настройки диалога.

Подробнее о требованиях к каждому полю настроек читайте в документации Яндекс.Диалоги.

Если все настройки вас устраивают, отправьте диалог на Модерацию:

После одобрения модератором вашего диалога, вы сможете запустить работу чата кнопкой Опубликовать. Публикация чата может занимать до 1 часа.

Все готово. Теперь вы можете принимать чаты прямо из Яндекс-поиска. :)

Отключить или удалить чат в выдаче Яндекс-поиска вы можете c помощью соответствующих кнопок в разделе Общие сведения:

Проверка от Яндекса

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

Особенности автоматической проверки от Яндекса:

Если в ответ на такое сообщение никакого другого отправлено не было (автоматического ответа Открытой линии), то время приема ответа неограничено.

Если же в ответ на такое сообщение был получен неверный ответ, то Яндекс ожидает верный ответ 30 минут.

Если отправить неверный ответ, то Яндекс оставляет за собой право отключить данный вид канала.

Мы рекомендуем выставлять правильное рабочее время в настройках Публикация в каталоге Яндекс.Диалога и в настройках вашей Открытой линии Битрикс24, чтобы контрольные вопросы от Яндекса приходили в рабочее время ваших операторов:

Как это работает

Клиент находит ваш магазин в Яндекс-поиске. Нажимает на кнопку Чат с компанией и у него открывается диалог с вашим оператором открытой линии:

У оператора весь диалог происходит в Бизнес-чате на портале (в десктоп- и в мобильном приложении Битрикс24).

Все просто! :)

Для подключения Открытых линий в коробочной версии Битрикс24 необходимо сделать предварительные настройки сервера и модулей портала.

Особенности подключения канала Яндекс.Чат:

Если вы настроили несколько каналов общения для разных страниц вашего сайта, создайте отдельный чат для каждого канала.

Создавать диалоги нужно в том же аккаунте Яндекс, для которого подтверждены права на ваш сайт в Яндекс.Вебмастере.

Модерация и публикация диалога в Яндекс-поиске может занять некоторое время.

Собеседование в Яндекс: театр абсурда :/ / Хабр

Привет, хабр!

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

Напомню, что в той статье я рассказывал, каким я вижу идеальное собеседование и что я нашёл компанию, которая так и делает — и я туда прошёл, хотя это был адский отбор. Я, довольный как слон, везде отметил, что я не ищу работу, отовсюду удалился и стал работать работу.

Как вы думаете, что делают рекрутеры, когда видят «Alexandr, NOT OPEN FOR WORK»? Правильно, пишут «Алексей, рассматриваете вариант работать в X?» Я обычно игнорирую это, но тут мне предложили попытать счастья с Яндекс.Лавкой, и я не смог пройти мимо — интересно было, смогу ли я устроиться куда-нибудь, когда введут великий российский файерволл. К тому же за последние 3 года я проходил только два интервью, и мне показалось, что я не в теме, что нынче требуется индустрии. Блин, я оказался и вправду не в теме. И вы, скорей всего, тоже — об этом и статья.

Короче, я согласился — буду продавать дошики и похмелье!

Мне назначили дату интервью, и также прислали методичку, чтобы я понимал, что меня ждёт и как готовиться. Чтобы ничего не заспойлерить, я замазал квадратиками важную информацию.

Вы тоже заметили «вопросы на C++» в методичке для питониста? Не то чтобы я знал C++, но в институте проходили, авось что-нибудь да вспомню на интервью.

Тут что-то написано про leetcode, но я человек ответственный, поэтому к интервью не готовлюсь. Это кстати я не шуткую, реально: если вы ответственный человек, то вы, когда предстаёте перед компанией, отвечаете за то, что вы заявляете как ваши умения. Можно выучить типовые вопросы и даже казаться умнее и опытнее, чем есть, но по факту это переобучение на тестовых заданиях/вопросах. Ребята из ml поймут. Поэтому я гол как сокол и чист как стёклышко или что там ещё блин, если что-то знаю — скажу, что-то не знаю — скажу что не знаю. Таким образом работодатель знает, что он покупает и сколько ещё нужно вложить в меня средств на обучение. Все счастливы.

Интервью 1

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

Мне кинули ссылку на Яндекс.Блокнот (это я его так называю, вообще он Яндекс.Код и живёт тут) — там можно вместе писать текст и включать подсветку синтаксиса. Запускать там, естественно, ничего нельзя, потому что это уже реализовано в coderpad, а он недостоин Яндекса. Ну ок, мне на самом деле проще, потому что написать код и написать хотя бы запускаемый код — это очень разные вещи. Минус — нельзя прогнать тесты и вообще тут как битва самураев: ваша правда против правды рекрутера, один доказывает, почему работает, другой — почему нет.

Итак, о чём вас спросит Яндекс на интервью? Выберите один правильный вариант:

1) прежний опыт

2) текущие проекты

3) как вы будете решать вот эту бизнес-задачу

4) как решить вот эту алгоритмическую задачу без стандартной библиотеки

Именно так! Так давайте решим эту алгоритмическую задачу. Помните, у нас нет collections.Counter, itertools.groupby, set.intersection, вообще случилась война и стандартная библиотека питона погибла, оставив после себя int, bool, for, if и while. Ну ок, хотят проверить знание каких-то базовых вещей.

Задача 1

Даны два массива: [1, 2, 3, 2, 0] и [5, 1, 2, 7, 3, 2]
Надо вернуть [1, 2, 2, 3] (порядок неважен)

Фактически нам нужно вернуть пересечение множеств, но с повторением элементов. Не включая мозг, я начал сразу кидать что-то вроде

common = set(a).intersection(set(b))  # найдём общие элементы
for el in common:
    occurs = min(a.count(el), b.count(el))  # и посчитаем, сколько они встречаются

Но меня осадили — у нас война, поэтому никаких intersection, только хардкор. После нескольких итераций и намёков интервьюера я родил вот это:

def common_elements(a, b):
  b_dict = defaultdict(int)  # defaultdict выжил :)
  for el in b:
      b_dict[el] += 1  # я считаю все элементы из b, т.е. типа collections.Counter

  result = []

  for el in a:
      count = b_dict[el]
      if count > 0:  # если какой-то элемент из a встречается в b
          result.append(a)  # то это успех
          b_dict[a] -= 1  # и я "вынимаю" его из b, т.е. уменьшаю его количество на 1

  return result

Внимательные читатели намекнули, что на строчках 11 и 12 нужно использовать el, а не a, но на интервью и так прокатило 🙂

Тут же меня спросили, какова сложность алгоритма — ок, норм, это нужно знать, потому что в реальном программировании мне это потребовалось целых 0 раз. Ответил.

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

Кстати, как вы наверно догадываетесь, есть большая разница между решением, написанным в обычной рабочей атмосфере, и решением, написанным на собеседовании в яндекс.блокнотике с интервьюером на связи и ограничением по времени. Здесь и далее я привожу те решения, которые сообразил на интервью, какими бы ужасными они не были. Можно ли написать лучше? Да, в каждой из задач можно лучше.

Задача 2

Ладно, лоу-левел алгоритмическая муть позади, давайте теперь нормальную задачу, распарсить там что-нибудь или накидать архитектуру высоконагруженного прило…

Дана строка (возможно, пустая), состоящая из букв A-Z: AAAABBBCCXYZDDDDEEEFFFAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBНужно написать функцию RLE, которая на выходе даст строку вида: A4B3C2XYZD4E3F3A6B28
И сгенерирует ошибку, если на вход пришла невалидная строка.
Пояснения: Если символ встречается 1 раз, он остается без изменений; Если символ повторяется более 1 раза, к нему добавляется количество повторений.

Ну ок, хотят проверить знание каких-то базовых вещей.

Вроде просто: for grouper, items in groupby(string)… А, да, у нас была война. Ничего нет.

def convert(s: str) -> str:
  result: List[str] = []
  last_sym = None  # последний символ, что мы видели
  count = 0  # и сколько мы его видели

  # мы будем идти по строке и записывать в result при смене символа
  for sym in (list(s) + [None]):  # последний None искусственно триггерит посленюю смену символа

      if last_sym and sym != last_sym:  # если случилась смена символа

          if count == 1:
              result.append(last_sym)
          else:
              result.append(last_sym + str(count))

      	  # начнаем запоминать новый символ
          count = 1
          last_sym = sym

      else:  # символ просто повторился
          count += 1  # ну ок, запомнили что символ видели на 1 раз больше

  return ''.join(result)

Не помню точно, но с вероятностью 3 сигма я продолбал граничные условия — это я делать люблю. Помните, тут нельзя ничего запускать, вместо этого тут принято запускать интервьюера, который интерпретирует ваш код прям в голове и говорит какие случаи не работают, чтобы вы могли пропатчить код.

Так, давайте может что-то другое?

Задача 3

Дан список интов, повторяющихся элементов в списке нет. Нужно преобразовать это множество в строку, сворачивая соседние по числовому ряду числа в диапазоны. Примеры:
[1,4,5,2,3,9,8,11,0] => «0-5,8-9,11»
[1,4,3,2] => «1-4»
[1,4] => «1,4»

Так блин, серьёзно? Я наверно очень мутный тип, если две предыдущие задачи не показали мой скилл на этом классе задач.

Ну ок, хотят проверить знание каких-то базовых вещей.


def repr(group_start, group_end) -> str:
    # это просто правильно печатает группу
    
    if last_group_start == last_group_end:
        return str(last_group_end)

    return f'{last_group_start}-{last_group_end}'


def squeeze(numbers) -> str:
    if not numbers:  # граничный случай
        return ''

    numbers_ = sorted(numbers)  # сначала располагаем по порядку
    groups = []  # тут будем хранить группы

    last_group_start = None
    last_group_end = None

    for n in numbers_:
        # это первая итерация, просто говорим, что группа началась и закончилась
        if last_group_end is None:
            last_group_start = n
            last_group_end = n

        # если предыдущая группа отличается от текущего числа на 1, 
        # то это число входит в группу, то есть становится концом группы
        elif last_group_end == n-1:
            last_group_end = n

        # иначе мы понимаем, что группа закончилась,
        # мы её запоминаем и начинаем новую
        else:
            groups.append(repr(last_group_start, last_group_end))
            last_group_start = n
            last_group_end = n

    else:
        # посленюю группу придётся обработать вручную
        groups.append(repr(last_group_start, last_group_end))

    return ','.join(groups)

На этом интервью закончилось, и я стал ждать вестей от рекрутера.

Через пару часов мне сказали, что всё отлично и меня ждут на следующих интервью — 2 штуки подряд — задачи на написание кода. Так, минуточку, а что было до этого — написание говнокода? Ладно, там видно будет. Уж точно что-то новенькое, следующий этап всё-таки.

Интервью 2

В назначенный час я бахнул кофейку и встретился в зуме с новым рекрутером. Интервью #2 началось.

Задача 4

Я, признаюсь, был готов ко всему, но не к этому:

Дан массив из нулей и единиц. Нужно определить, какой максимальный по длине подинтервал единиц можно получить, удалив ровно один элемент массива.
[1, 1, 0]

Ну ок, хотят проверить знание каких-то базовых вещей. Вот такой ужас у меня вышел:

# пример: [0, 0, 1, 1, 0, 1, 1, 0]

def max_ones_length(lst: List[int]) -> int:

    max_ones_length = 0

    # тут мы хотим получить сгруппированные 0 или 1 и их количество:
    subranges = []  # [(0, 2), (1, 2), (0, 1), (1, 2), (0, 1)]
    last_el = None  # последний элемент, который мы просмотрели

    # идём по элементам списка
    for el in lst + [0]:  # [0] - это ручной триггер для обработки последнего элемента

        if last_el != el:  # если произошла смена 0 на 1 или наоборот
            if el == 0:  # если это была смена 1 на 0
              
              	# пример: subranges == [(0, 2), (1, 2), (0, 1), (1, 2)]
                # у нас произошла смена 1 на 0, до смены единица шла 2 раза
                # (см последний элемент subranges) - проверяем, вдруг это
                # максимальная длина
                try:
                    last_ones_length = subranges[-1][1]
                    max_ones_length = max(last_ones_length, max_ones_length)
                except IndexError:
                    pass

                # а может если мы удалим один ноль между элементами 1 и 3,
                # то получится более длинная последовательность единиц?
                try:
                    gap_length = subranges[-2][1]
                    if gap_length == 1:
                        combined_ones_length = subranges[-1][1] + subranges[-3][1]
                        max_ones_length = max(combined_ones_length, max_ones_length)
                except IndexError:
                    pass

            # добавляем новый счётчик последовательности в subranges
            subranges.append((el, 1))

        else:
          	# увеличиваем счётчик последней последовательности на 1
            subranges[-1] = (el, subranges[-1][1]+1])

        last_el = el

    # костыль, граничное условие
    if len(subranges) == 2 and subranges[1][1] == 1:
        return subranges[0][1] - 1

    return max_ones_length

Ну что, Яндекс, ты доволен? Ты доволен?! Кто король алгоритмов?! Я король алгоритмов! Давай, удиви меня…

Задача 5

Даны даты заезда и отъезда каждого гостя. Для каждого гостя дата заезда строго раньше даты отъезда (то есть каждый гость останавливается хотя бы на одну ночь). В пределах одного дня считается, что сначала старые гости выезжают, а затем въезжают новые. Найти максимальное число постояльцев, которые одновременно проживали в гостинице (считаем, что измерение количества постояльцев происходит в конце дня).
sample = [ (1, 2), (1, 3), (2, 4), (2, 3), ]

Отлично, тут уже начинает появляться мир — ну там люди, отели, вдруг даже этот код реально где-то когда-то может пригодиться. Я прям вижу, как с каждой задачей будут появляться дороги, поезда, реки, горы и моря, металл, электричество, сервера и датацентры и блин задачи, которые будут работать в дата-центрах и серверах, ну хоть где-нибудь!

Ну ок, хотят проверить знание каких-то базовых вещей.

from collections import defaultdict

def max_num_guests(guests: List[tuple]) -> int:

    res = 0

    # для каждого дня посчитаем, сколько приехало и сколько отъехало
    arriving = defaultdict(int)
    leaving = defaultdict(int)

    for guest in guests:  # O(n)
        arriving[guest[0]] += 1
        leaving[guest[1]] += 1

    current = 0
    # едем по дням в порядке увеличения, добавлем приехавших и убавляем уехавших,
    # считаем сколько стало
    for day in sorted(set(arriving.keys()).union(set(leaving.keys()))):  # O(n*log(n)) + O(n)
        current -= leaving[day]
        current += arriving[day]

        if current > res:
            res = current

    return res

Не без подсказки интервьюера, но я написал это, и теперь менеджер, наверно, может эффективно узнать важную инфу. Круто. Пора прыгать на следующее собеседование (да, они шли одно за другим).

Интервью 3

Новый интервьюер; можно наблюдателя; можно писать заметки; да, я знаю, как работает ваш яндекс.блокнот лучше вас уже, давайте наконец

Задача 6

Sample Input [«eat», «tea», «tan», «ate», «nat», «bat»]
Sample Output [ [«ate», «eat», «tea»], [«nat», «tan»], [«bat»] ]
Т.е. сгруппировать слова по «общим буквам».

Смутное чувство дежавю посетило меня… Нет, показалось наверно. Ну ок, хотят проверить знание каких-то базовых вещей.

Эта задача простая, наверно хотят удостовериться, что пока я разруливал дела в отеле, я не забыл, как пользоваться словарём. Не лишено смысла! Давайте накидаем что-нибудь простое.

def group_words(words: List[str]) -> List[List[str]]:

    groups = defaultdict(list)

    for word in words:  # O(n)
        key = sorted(word)
        groups[key].append(word)

    return [sorted(words) for words in groups.values()]  # O(n*log(n))

Тут меня спросили «а какая сложность у сортировки», и я воспользовался лайфхаком. Дело в том, что все собеседования проводятся разными людьми, и они вообще не знают ваш контекст — например, о чём я говорил в предыдущих сериях и, например, кхм, сколько алгоритмических задач я прорешал до этого. На прошлом собеседовании меня спросили, какая сложность у сортировки, я не знал и мне сказали — и на этом собеседовании я уже ответил.

Задача 7

Слияние отрезков:
Вход: [1, 3] [100, 200] [2, 4]
Выход: [1, 4] [100, 200]

Честно говоря, где-то тут мне уже стало плевать на собеседование, Яндекс и все эти алгоритмы, и в реале я бы уже просто послал всех в /dev/null, но мне хотелось знать, что в конце всего этого, ведь конец должен быть? Будет задача, где я завалюсь, и это кончится. Что-то вроде эвтаназии, но в интервью.

Ну ок, хотят проверить знание каких-то базовых вещей.

def merge(ranges: List[Tuple[int, int]]) -> List[Tuple[int, int]]:

    if not ranges:
        return []

    result_ranges = []
    last_range = None  # последний отрезок, что мы видели

    for rng in sorted(ranges):  # обязательно сортируем

        if not last_range:
            last_range = rng
            continue

        # если начало текущего отрезка меньше конца предыдущего
        if rng[0] <= last_range[1]:
            # расширяем предыдущий отрезок на текущий
            last_range = (last_range[0], max(rng[1], last_range[1])

        # старый отрезок всё, начинаем новый
        else:
            result_ranges.append(last_range)
            last_range = rng

    else:
        # граничный случай для последнего элемента
        result_ranges.append(last_range)

    return result_ranges

Задача 8

Время собеседования подходит к концу, но всё-таки можно ещё поболтать про кодинг и поспрашивать практические вопросы, например по Django или SqlAlchemy:

Дан массив точек с целочисленными координатами (x, y). Определить, существует ли вертикальная прямая, делящая точки на 2 симметричных относительно этой прямой множества. Note: Для удобства точку можно представлять не как массив [x, y], а как объект {x, y}

Ну ок, хотят проверить знание каких-то базовых вещей.

Тут я как всегда пошёл куда-то не туда и написал вот что:

from statistics import mean

def is_vertical_symmetry(points: List[Point]) -> bool:

  	# сначала найдём вертикальную прямую в середине всех точек
    x_center = mean(p.x for p in points)

    # тут будем хранить точки, для которых пока не нашли пары:
    unmatched_points = defaultdict(int)
    
    for point in points:

        if point.x == x_center:  # если точка на прямой, то она сама себе пара
            continue

        # создадим "брата" - точку, которая симметрична текущей относительно вертикальной прямой
        brother = Point(
            x = x_center * 2 - point.x,
            y = point.y,
        )
        
        # если этот брат есть в unmatched_points, то достаём его оттуда и говорим, что текущая точка сматчилась
        if unmatched_points[brother]:
            unmatched_points[brother] -= 1
            
        # иначе добавляем эту точку в не-сматченные
        else:
            unmatched_points[point] += 1

    return not any(unmatched_points.values())

Здесь я прям видел, как интервьюер ожидал что-то другое, а получил меня. Ну бывает. Я тоже, знаете, ожидал собеседование.

Так, третье собеседование пройдено, и эти садисты сказали, что я прошёл дальше. Ну вот за что?

Интервью 4

Честно говоря, вот тут я потерялся, потому что я всё жду, когда начнётся собеседование, ну, человеческое собеседование имеется в виду, а пока вместо этого я превращаюсь в алгоритмэна.

По собственным ощущениям я добрался до какого-то мини-босса и на предстоящем интервью у меня должна была пройти какая-то битва на более общие вопросы. А рекрутер мне пишет: знаете, Яндекс настоятельно советует потренироваться на задачках с leetcode. А там опять алгоритмы. Ох, не к добру это…

Ну тут уж я сломился и решил таки глянуть, что там за задачки, раз мне так настойчиво намекают. Вообще там есть сложные, и над ними было прикольно подумать и порешать в уме, но я так и не понял, как это поможет в интервью. Задачек слишком много и, что более важно, они, блин, разные, и решив одну, я не решаю класс задач — я решаю одну задачу. Соответственно либо я решаю их все и зачем мне тогда ваш Яндекс после такого, либо… короче, я опять не готовился. Ответственный человек, помните?

Кстати, где-то в этот момент я узнал, что я юзаю что-то вроде тора, но для собеседований: я общаюсь с рекрутером, мой рекрутер общается с рекрутером Яндекса, а рекрутер Яндекса общается с собеседователями, а может цепочка ещё больше.2) в решениях, так может я у вас посчитаю длину цепочки от кандидата до собственно интервьюера и спрошу «а можно оптимальнее?!«

Итак, началась четвёртое (да, ей-Богу) интервью. Интервьюер спрашивает, на каком языке я буду решать задачки. На йоптаскрипте, разумеется. Кстати, по косвенным признакам я понял, что интервьюер больше в C, чем в питон, и это тоже здорово. Итак: после того как компания решила нанять сеньор питон разраба за 200к и сношала его 3 часа на долбанных задачках, она отправляет на собеседование сишника и спрашивает, на каком языке кандидат будет сношаться с долбанными задачками. Л — логика!

Итак, вот задачка от мини-босса:

Задание 9

Даны две строки.
Написать функцию, которая вернёт True, если из первой строки можно получить вторую, совершив не более 1 изменения (== удаление / замена символа).

Погодите, да это же… Ну ок, хотят проверить знание каких-то базовых вещей. Сссссуууу…пер.

Если вы хотите решить задачу не так, как хотел интервьюер, то смотрите:

def no_more_than_one_change(string1: str, string2: str) -> bool:
  
  	# string1: a b c d
    # string2: a b c

    max_length = max(len(string1), len(string2))  # наибольшая длина строк
    diff = abs(len(string1) - len(string2))  # разница в длине строк

    # дополняем строки до максимальной длины при помощи zip_longest,
    # то есть на место "недостающих" элементов ставим None, и строки
    # теперь одинаковой длины;
    #          ---->
    # string1: a b c d
    # string2: a b c None
    
    # идём слева направо по обеим строкам и сравниваем символы,
    # находим индекс, при котором строки начинают отличаться:
    change_left = None
    for i, (char1, char2) in enumerate(zip_longest(string1, string2)):  # O(n)
        if char1 != char2:
            change_left = i  # в нашем примере будет 3
            break
    else:
        # если мы такой индекс не нашли, то строки просто совпадают
        return True

    # теперь делаем то же, но идём справа налево:
    # string1:    a b c d
    # string2: None a b c
    #               <----
    change_right = None
    for j, (char1, char2) in enumerate(zip_longest(reversed(string1), reversed(string2))):  # O(n)
        if char1 != char2:
            # тут строки прям сразу отличаются, т.е. в индексе j=0;
            # но это у нас индекс в системе "справа налево",
            # а мы его переводим в индекс в системе "слева направо":
            i = max_length - j - 1 + diff
            break
    else:
        assert False, 'Я дебил и что-то не учёл'

    # ну а теперь смотрим, если строки отличаются в одном и том же месте 
    # при сканировании слева направо и справа налево, то это нам подходит
    return change_left == change_right

Внимательный читатель может заметить, что, по-моему, это даже на приведённом примере не работает 🙂 , хотя пофиксить несложно. Так или иначе, вот такие вещи как я написал лично мне тяжело гонять в голове, и интервьюеру тоже; интервьюер принял это как решение, прогнав несколько тестов в уме. Если хотите возвести это в абсолют, то пишите сразу на brainfucke и с умным видом объясняйте, почему оно будет работать. А вообще я просто тонко намекаю, что всё-таки компилятор/интерпретатор под рукой нужен.

Задание 10

Осталось совсем немного времени, и вот в довершение пара реально сложных заданий на понимание многопоточности и gil в python:

Дан список интов и число-цель.___[range(0,3)=range(0,2)+5=3, range(1,3)=range(1,2)+5=2, range(2,3)=5]
Не угадал, конечно — «а можно чтобы быстрее?». Но тут, к счастью, время вышло, и мой мозг не успел придумать ничего лучше.
>> Сейчас я нахожусь здесь <<
Прелесть ситуации в том, что я ещё не получил фидбек, то есть я кандидат Шрёдингера — я и прошёл (формально я все задачи решил), и не прошёл (== не всё угадал, где-то баги), и суперпозиция сколлапсирует, когда ответ пройдёт через всю цепочку рекрутеров ко мне. А пока я полностью беспристрастен, ведь 1) меня не отшили, то есть это не пост обиженного на компанию человека, и 2) мне плевать на результат, потому что мне и на текущей работе офигенно.
К чему всё это
Вообще это просто так тупо, что забавно, и я не мог с вами не поделиться. Никак не связанные люди тестируют меня на одном и том же типе задач, который максимально оторван от реальности, всё это длится много часов, сложность задач неупорядочена, проверяется всё в голове и никакого фидбека.
Сколько вопросов, блин, можно спросить про http, rest, django orm, sql, python, stdlib, docker, multithreading/multiprocessing/async, да про что угодно — что вы там в лавке делаете? — спросите про похмелье, но зачем 4 часа алгоритмов? Что это показывет — что я устойчив к тупости? Честно говоря, я уже не уверен.
Может кому-то пригодится разбор задачек, ну вдруг вы любитель такого, хотя я уже говорил о качестве решений 🙂
А если вам нужен вывод, то вот несколько, берите любой:
Тестировать кандидатов нужно на реальных задачах, а не синтетических
Нужно уважать время кандидатов
Кто-то в яндексе пересмотрел «день сурка»
Знаете, когда целое не равно сумме частей? Вот тут так же: люди тебя собеседуют хорошие и встречи приятные, а в целом всё гавно.
Открыто новое достижение: ругательство «да пошёл ты в яндекс!»
Большие компании ай-яй-яй
Какой-то чувак написал смешную статью
И да, если вы ищете работу на питоне — залетайте к нам. У нас не Яндекс.
интервью с разработчиком, который вернулся работать в Россию
В интернете много красивых историй о том, как разработчик в поисках возможностей для профессионального роста уехал работать в США или Европу. Вот вам красивая история наоборот: российский программист несколько лет работал за границей и принял решение вернуться в Россию.
Мы поговорили с Александром Дворниковым о том, чем он занимался в лондонском Facebook и почему решил вернуться и присоединиться к Яндексу.
Александр Дворников
старший разработчик в Яндекс.Почте
— Александр, расскажите, как вы оказались в Лондоне?
— Мне всегда было интересно узнать, каково это — жить и работать в другой стране. И вот в 2017 году появилась возможность переехать в США или Великобританию. В Штаты я проиграл визовую лотерею H-1B, поэтому мы с супругой выбрали Лондон. После успешного прохождения всех этапов интервью меня приняли в Facebook, где я продолжил заниматься мобильной разработкой. Если до этого я специализировался на iOS, то на новом месте начал работать над кроссплатформенным ядром React Native.
Переезжали с супругой, плюс кошка. Перед переездом нужно сдать тест IELTS по английскому языку, у меня подготовка заняла 1–2 месяца. Я сдал его до того, как прошёл собеседование — заранее рассматривал возможность переезда и решил немного облегчить себе задачу. Если бы я так не поступил, процесс мог бы затянуться.
С адаптацией в Лондоне проблем не было. Я бы не сказал, что у меня потрясающий английский, но мне его было достаточно, чтобы свободно общаться с коллегами.
— И вот вы оказались в Facebook и начали вливаться в рабочий процесс. Что можете рассказать про условия работы и атмосферу в компании?
— Из интересных вещей: шведский стол три раза в день, несколько кафе, парикмахер прямо на этаже, за счёт компании можно приобрести велосипед или абонемент в фитнес-центр. Все приводят своих друзей и родственников в гости. Правда, в лондонском офисе, например, не было спортивного зала, мне этого не хватало.
В Facebook сильно развита автономность: менеджер принимает участие в твоей работе, но скорее как консультант, а не как человек, который непосредственно ставит тебе цели и задачи. Индивидуальные цели достаточно гибкие — ты можешь поставить себе в начале одну цель, а дальше, уже по ходу полугодия, прийти к чему-то, возможно, совершенно другому, но не менее важному. Главное — измеримый результат.
Я попал в очень сильную команду — собрался коллектив разработчиков с разносторонним опытом. Кто-то до этого работал в Apple над ядром iOS, кто-то получил PhD, проводя исследования в области компиляторов. Я многому научился у коллег, за что им очень благодарен.
— А можете поподробнее рассказать про то, чему вы научились, работая в Facebook?
— Первая особенность Facebook, которая приходит на ум, — открытость и готовность к изменениям. В компании ты постоянно открываешь для себя новые, пока неизвестные тебе области знаний, технологии и задачи.
Эта особенность проявляется уже с первых дней. Для нового сотрудника работа в Facebook начинается с шестинедельного интенсива, цель которого — познакомить тебя с инфраструктурой компании и дать понять, как всё устроено внутри. Ты можешь прийти на должность разработчика, дата-инженера или менеджера, но в ходе интенсива тебе, возможно, придётся решать задачи, не связанные с твоей специализацией напрямую. Это здорово расширяет горизонты. Бывает, что после этих шести недель человек решает дальше работать в совершенно новой для него области — просто потому, что она его заинтересовала.
Главное тут — желание и умение быстро учиться. Более того, горизонтальные перемещения внутри компании всячески поощряются. Абсолютно нормально, когда по истечении четырёх лет у сотрудника за плечами есть опыт работы как над продуктами, так и над инфраструктурными задачами в бэкенде, вебе, на мобильных.
Проработав два года в Facebook, я на себе ощутил, насколько важна эта культура открытости и готовности к новому. Каждый из сотрудников обладает универсальным набором навыков, которые позволяют небольшими силами двигать с места достаточно объёмные и сложные задачи. Хотелось бы сохранить и продолжить развивать в себе эти качества.
— Судя по тому, что вы рассказываете, вам нравилось работать в Facebook. Почему тогда вы приняли решение уехать из Лондона?
— Лондон — интересный город, но через пару лет мы стали от него уставать. Это огромный, шумный и густонаселённый мегаполис, в котором мы с супругой чувствовали себя неуютно. Начали перебирать варианты: переехать в Штаты в рамках Facebook, посмотреть что-то ещё в Европе или вернуться в Россию. Я уже работал в Яндексе в 2013 году, ещё до переезда в Лондон, мне там нравилось, поэтому этот вариант был одним из очевидных.
Собеседования как в европейские компании, так и в Яндекс прошли успешно. В итоге мы приняли решение вернуться в Россию. Во-первых, здесь есть перспективы и возможности самореализации не только для меня, но и для моей супруги. Во-вторых, в России остались родные и близкие. В-третьих, в Яндекс.Почте мне предложили очень интересный проект. Мне понравилось, что задачи, которые предстояло решать в Яндексе, затрагивают множество технологий — они не ограничиваются только мобильными.
— Какие конкретно задачи вы решаете в Яндекс.Почте?
— Почтовый сервис — это достаточно понятный инструмент, к которому все давно привыкли. Но к моменту моего возвращения в Яндекс.Почте собрался дружный и сильный коллектив с интересными и смелыми идеями, как сделать продукт лучше.
Задач очень много. Есть задачи, традиционные для мобильных: например, ускорение перформанса и работа с пушами. Есть более специфичные штуки, которые связаны с технологиями Яндекса. К примеру, в Почте появился переводчик, совсем недавно добавили поддержку SpeechKit’а и технологий голосового ввода, прямо сейчас коллеги занимаются автоматизацией тестирования с применением ИИ и нечётких алгоритмов. Результаты необходимо посчитать и проверить, насколько подтвердилась та или иная гипотеза. Для этого мы используем A/B тестирование и мощные инструменты для работы с аналитикой. По сути, каждый разработчик в команде — немного data scientist.
Что касается меня, то я продолжаю заниматься тем, что меня так увлекло в Facebook, — инфраструктурными задачами на iOS и Android. Прямо сейчас мы с коллегами работаем над объединением логики ядра синхронизации на мобильных. Понятно, что нужно учесть особенности каждой из платформ. Задача усложняется тем, что необходимо поддержать все последние оптимизации, связанные с ускорением производительности приложения. А ещё не забыть про работу с офлайн-операциями, которые являются одной из ключевых особенностей мобильной почты. Для кроссплатформенности был предложен новый подход, который уже применяется для решения других задач, например в области автоматизации тестирования. Мы рассказывали о самой технологии на одном из предыдущих докладов Mobile Party и планируем в дальнейшем рассказать ещё.
Вы говорили, что в 2013 году, ещё до релокации в Лондон, уже работали в Яндексе. Как вам кажется, компания сильно изменилась с тех пор?
Безусловно, за эти годы компания очень выросла. Это касается многих вещей. Когда я присоединился к Яндексу в 2013 году, команда мобильной разработки была совсем небольшой. Сейчас мобильные технологии — одно из ключевых направлений для компании. Огромное количество людей из офисов Яндекса в разных частях России работают над несколькими десятками приложений, которые составляют единую экосистему. Подобному росту способствовало появление и развитие мощных инструментов внутренней инфраструктуры, аналитики, коммуникации и тестирования. Они ускоряют процесс разработки, делают его удобнее и открывают возможности для новых экспериментов.
Изменились и внутренние процессы. Сейчас новые разработчики в поисковом портале Яндекса проходят через Буткемп — интенсив, во многом схожий с тем, который внедрён в Facebook. Ребята в течение восьми недель пробуют себя в разных командах и узнают компанию изнутри, а потом выбирают, в каком коллективе и над какими задачами им хотелось бы работать в дальнейшем. Это отличная возможность расширить кругозор и познакомиться с разными людьми и подходами.
Вернувшись спустя два года в Россию, я был поражён тому, как глубоко Яндекс проник во все сферы жизни. Алиса, Еда, Драйв — за примерами далеко ходить не надо. Компания не боится экспериментировать и умеет использовать существующие технологии для создания новых сервисов, делающих жизнь удобнее. Это то, что делает Яндекс Яндексом. И это то, что не было бы возможно без людей в компании, которые, как и 6 лет назад, полны азарта и интереса к задачам, спорят и находят пути для их реализации.
— И Яндекс, и Facebook — компании, которые считаются престижными работодателями для разработчиков. У вас есть опыт успешного прохождения отбора в обе компании. Расскажите немного про то, как проходят собеседования и из каких этапов они состоят?
— Я успел посмотреть, как устроен процесс найма разработчиков в обеих компаниях и снаружи, и внутри. На мой взгляд, у собеседований в Яндекс и Facebook очень много общего. Процесс начинается с общения с сотрудником HR. За ним следует одно или несколько скрининг-интервью по Skype с написанием кода. Если всё прошло хорошо, то кандидату предлагают onsite-интервью, которое обычно состоит из 4–5 секций. На секциях обязательно будут как алгоритмические, так и архитектурные задачи.
Есть и небольшие отличия. У мобильного разработчика на собеседовании в Яндексе обязательно будет отдельная секция по платформе. На ней проверяют, насколько глубоко человек понимает язык, фреймворки и особенности iOS и Android. В Facebook уделяют внимание скорее общим познаниям в области Computer Science, но при этом есть отдельная секция Cultural Fit Interview — на ней задают вопросы о предыдущем опыте и роли в команде. В целом собеседования в обеих компаниях устроены очень похоже. Главный совет — хорошо готовиться и усердно тренировать решение алгоритмических задач.
Если сравнивать работу в обеих компаниях, есть ли что-то такое в Яндексе, чего вам раньше не хватало в Facebook?
Вернувшись в Яндекс, я осознал, насколько для меня, оказывается, важно, чтобы вся команда и коллеги находились рядом. В Facebook я участвовал в проекте, над которым мы работали совместно со смежными командами в США. Разница во времени между нами была 8 часов. Это создавало определённые сложности, связанные как с асинхронной работой и коммуникацией, так и с work-life balance. Наиболее тёплые воспоминания у меня связаны с теми моментами, когда мы приезжали друг к другу в гости в командировку. Трудясь бок о бок, удавалось в короткие сроки добиться гораздо большего.
Команда, в которой я сейчас работаю, находится в Санкт-Петербурге. Мы все сидим друг рядом с другом, рабочие вопросы решаются очень быстро. В коллективе сложилась особая атмосфера: очень дружные коллеги, все на одной волне. Мы часто встречаемся и за пределами работы, выезжаем за город. В конце августа все вместе ездили на неделю в сочинский офис. Мы не только продуктивно поработали, но и успели хорошо отдохнуть, увидеть горы, искупаться в море — было здорово!
1С-Битрикс — Агрегатор Яндекс.Доставка

1.3.13 (21.07.2021)
Добавили обработку сел и поселков при поиске вариантов доставки

1.3.12 (01.07.2021)
Исправление ошибки при открытии виджета

1.3.11 (18.06.2021)
Исправили ошибку сохранения результата расчета, когда профиль доставки был служебный
Переделали отправку комплектов
1.3.10 (10.06.2021)
Оптимизировали скорость получения вариантов доставки
Поправили js ошибки в списке заказов
Доработали работу со статусами
Правки для бета-версии модуля sale выше 21 версии
1.3.9 (26.05.2021)
Добавили обработку ошибки при изменении состава заказа или местоположения, из-за которых опция доставки становилась не доступна
Доработали вывод ошибок
Расширили выбор полей для артикула
Добавили возможность просмотра информации из ЛК Доставки на вкладке заказа и ручное обновление статуса заказа при запросе подробной информации
Доработали обработку статусов отправлений
1.3.8 (07.05.2021)
Исправили расчет размеров коробки при создании заказа
Добавили сохранение интервала времени доставки для курьеров
Исправили отправку артикула
1.3.7 (28.04.2021)
Если почта или пункт выдачи почта онлайн, оценочная стоимость 100%

Добавили сохранение трек номера в заказе

Исправили ошибку в списке заказов, если удалил отгрузку вручную

1.3.6 (20.04.2021)
Исправили запись логов виджета

Добавил кнопку «скопировать» в логах

Модификация хранения результата калькуляции

Исправили сохранение ограничения по типам пользователей

Изменили запрос поиска вариантов доставок

Обработка ошибок при оформлении заказа в Яндекс.Доставку

1.3.5 (31.03.2021)
Добавили в настройках модуля опцию: «Не показывать службы доставки, когда не нашли вариантов»

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

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

Исправили ошибку сохранения отгрузки и калькуляции отгрузки

1.3.4 (25.03.2021)
Добавили в журнал событий фильтр по типу события
Добавили открытия виджета при смене доставки
Исправили ошибку заполнения адреса самовывоза для некоторых браузеров
Исправили ошибку отправки письма о новом заказе
Исправили ошибку вызова виджета с дробным количеством товара
1.3.3 (16.03.2021)
Добавили возможность отмены заказа со статусом «черновик»

Добавили агента, для очистки служебных таблиц

Добавили возможность переходить в заказ в кабинете Яндекс.Доставке

1.3.2 (15.03.2021)
Исправлен запрос на поиск вариантов доставки с учётом оплаты

1.3.1 (09.03.2021)
Исправление ошибки с определением типа доставки

1.3.0 (04.03.2021)
Добавили упаковку в настройках службы доставки;

Добавили обработку платежных систем в настройках модуля;

Добавили сопоставление статусов Яндекс.Доставки со статусами заказа;

Исправили ошибку разбиение ФИО на раздельные поля;

Исправили определение города в виджете, если в местоположениях не заданы коды;

Добавили сохранение статуса и название ТК в свойства заказа;

Добавили агента для обновления статуса доставки.

1.2.10 (01.02.2021) Добавили сопоставление поля комментарий для отправки в Яндекс.Доставку
1.2.9 (01.02.2021) Добавили в настройках модуля сопоставление полей заказа на сайте с полями кабинета Яндекс.Доставки.
1.2.8 (23.01.2021) Доработали логику передачи типа оплаты
1.2.7 (21.01.2021) Правка ошибки связанная с номером заказа
1.2.6 (19.01.2021) Включили поддержку комплектов и наборов
1.2.5 (13.01.2021) Исправление ошибки на старых версий битрикса.
1.2.4 (12.01.2021)
Добавили обновление статуса заказа на агенте

Исключили адрес при создание черновика, если профиль доставки «самовывоз»

Автоматическое обновление трек номера заказа

1.2.3 (18.12.2020)
Исправлена проблема с кодировкой ответа расчета вариантов доставки в частных случаях
Исправлена проблема обновления статуса отгрузки по конкретным заказам
1.2.2 (17.12.2020)
Исправлено создание черновиков для предоплаченных заказов.
Исправлена редкая проблема кодировки адреса.
Удалено ограничение полей ответа от API при расчете вариантов доставки
1.2.1 (11.12.2020)
Исправление отправки полного адреса
1.2.0 (10.12.2020)
Оформление заказов в Яндекс.Доставка;

Печать ярлыков Яндекс.Доставка;

Расчёт коробки для заказа;

Добавили трек номер в отгрузке.

1.1.6 (02.12.2020)
Исправлена ошибка вывода кнопки «Создать черновик» в заказе;

Убрали вывод вкладки «Яндекс.Доставка» в заказе, если доставка не Яндекс.

1.1.5 (02.12.2020)
Убрали некорректную отправку размеров в черновиках;
Исправили выбор порта, на некоторых серверах выбирался неправильный порт;
Исправили округление размеров для расчета доставки;
Оценочная стоимость по умолчанию 100, если ничего не задано.
1.1.4 (25.11.2020)
исправлена ошибка при выборе службы доставки Курьер заполнялся адрес;

исправлена ошибка при смене профиля в доставке, выбирался не правильный профиль;

добавили в передачу товаров ставку НДС.

1.1.3 (19.11.2020)
Доработана отправка полного адреса в черновике;
1.1.2 (18.11.2020) В новой версии мы исправили:
Исправлена ошибка формирования URL при запросе токена на некоторых серверах;
Исправлен выбора чекбоксов в документа.
1.1.1 (13.11.2020) В новой версии мы исправили:
ошибку при выборе ПВЗ ;
ошибку при отправке черновиков.
Спасибо, что с нами!
Загрузка файла (PUT) — API. Руководство разработчика
Используйте метод PUT для загрузки файла на Яндекс.Диск.
В начале и в конце загрузки файла служба проверяет, превышает ли файл пространство, доступное пользователю на Диске. Если места недостаточно, служба возвращает ответ с кодом 507 Недостаточно места для хранения.
Поддержка предоставляется для передачи сжатых файлов ( Content-Encoding: gzip header) и файлов с фрагментами ( Transfer-Encoding: фрагментировано ).
Пользователи часто хотят загружать на Яндекс.Диск файлы, которые уже были загружены кем-то другим. В таких случаях Диск может просто скопировать нужный файл на сервер, не загружая его.
Файл идентифицируется по размеру файла, контрольной сумме MD5 и хешу SHA-256. Для их передачи используются следующие заголовки:
  Etag: <контрольная сумма md5>
Sha256: <хеш SHA-256>
Content-Length: <размер файла в байтах>  
При обнаружении дублирующего файла сервер отвечает кодом 201 Created .
Приложение загружает файл otpusk.avi в каталог / a / на Диске пользователя, указывая контрольную сумму и хэш для проверки дубликатов.
  PUT /a/otpusk.avi HTTP / 1.1
Хост: webdav.yandex.ru
Принимать: */*
Авторизация: OAuth 0c4181a7c2cf4521964a72ff57a34a07
Etag: 1bc29b36f623ba82aaf6724fd3b16718
Sha256: T8A8H6B407D7809569CA9ABCB0082E4F8D5651E46D3CDB762D02D0BF37C9E592
Ожидайте: 100-продолжение
Тип содержимого: приложение / двоичный
Content-Length: 103134024  
Если Яндекс.Диск обнаружил дубликат файла и ничего не нужно загружать, сервер отвечает кодом 201 Created .
Если дубликат не найден, сервер отвечает кодом 100 Continue , позволяя загрузить файл в теле следующего запроса. Когда файл был успешно загружен, сервер также отвечает кодом 201 Created .
Обзор. Руководство разработчика
Для доступа к API Яндекс.Переводчика по протоколу HTTPS можно использовать:
XML-интерфейс (ответ возвращается в виде XML-документа).
Интерфейс JSON (ответ возвращается как объекты JavaScript с теми же именами и семантикой, что и элементы XML).
Интерфейс JSONP (ответ возвращается в виде объектов JavaScript, заключенных в функцию обратного вызова с указанным именем).
Все интерфейсы имеют одинаковую функциональность и используют одинаковые входные параметры.
Вы можете использовать API Яндекс.Переводчика для перевода текста на следующие языки:
он
zh
Язык Код Язык Код
Азербайджанский az Малаялам мл
Албанский sq Мальтийский mt
Амхарский am Македонский mk
Английский язык en Maori mi
арабский ar маратхи mr
армянский hy мари mhr
африкаанс af монгольский mn
баскский немецкий eu de
Башкирский ba Непальский ne
Белорусский be Норвежский нет
Бенгальский млрд Пенджаби pa
Бирманский мой Papiamento pap
Болгарский bg Персидский fa
Боснийский bs Польский pl
Валлийский cy Португальский pt
Венгерский hu Румынский ro
Вьетнамский vi Русский ru
Гаитянский (креольский) ht Себуано ceb
Галицкий 9008 3 gl сербский sr
голландский nl сингальский si
Hill Mari mrj словацкий sk
греческий el словенский sl
Грузинский ka Суахили sw
Гуджарати gu Суданский su
Датский da Таджикский tg
Иврит Тайский th
Идиш yi Тагальский tl
Индонезийский id Тамильский ta
Ирландский ga Тартар tt
Итальянский 900 82
it телугу te
исландский is турецкий tr
испанский es удмуртский udm
казахский kk узбекский uz
Каннада kn Украинский uk
Каталонский ca Урду ur
Киргизский ky Финский fi
Китайский французский fr
корейский ko хинди привет
Xhosa xh хорватский hr
кхмерский km чешский cs
Лаосский 900 82
lo Шведский sv
Латинский la Шотландский gd
Латвийский lv Эстонский et
Литовский lt Эсперанто eo
Люксембург фунтов яванский jv
малагасийский мг японский ja
малайский ms
Безопасность | Стеклянная дверь
Мы получаем подозрительную активность от вас или кого-то, кто пользуется вашей интернет-сетью.Подождите, пока мы подтвердим, что вы настоящий человек. Ваш контент появится в ближайшее время.
Если вы продолжаете видеть это сообщение, напишите нам
чтобы сообщить нам, что у вас возникли проблемы.
Nous aider à garder Glassdoor sécurisée
Nous avons reçu des activités suspectes venant de quelqu’un utilisant votre réseau internet.
Подвеска Veuillez Patient que nous vérifions que vous êtes une vraie personne. Вотре содержание
apparaîtra bientôt. Si vous continuez à voir ce message, veuillez envoyer un
электронная почта à
pour nous informer du désagrément.
Unterstützen Sie uns beim Schutz von Glassdoor
Wir haben einige verdächtige Aktivitäten von Ihnen oder von jemandem, der in ihrem
Интернет-Netzwerk angemeldet ist, festgestellt. Bitte warten Sie, während wir
überprüfen, ob Sie ein Mensch und kein Bot sind. Ihr Inhalt wird в Kürze angezeigt.
Wenn Sie weiterhin diese Meldung erhalten, informieren Sie uns darüber bitte по электронной почте:
.
We hebben verdachte activiteiten waargenomen op Glassdoor van iemand of iemand die uw internet netwerk deelt.Een momentje geduld totdat, мы выяснили, что u daadwerkelijk een persoon bent. Uw bijdrage zal spoedig te zien zijn.
Als u deze melding blijft zien, электронная почта:
om ons te laten weten dat uw проблема zich nog steeds voordoet.
Hemos estado detectando actividad sospechosa tuya o de alguien con quien compare tu red de Internet. Эспера
mientras verificamos que eres una persona real. Tu contenido se mostrará en breve. Si Continúas recibiendo
este mensaje, envía un correo electrónico
a para informarnos de
que tienes problemas.
Hemos estado percibiendo actividad sospechosa de ti o de alguien con quien compare tu red de Internet. Эспера
mientras verificamos que eres una persona real. Tu contenido se mostrará en breve. Si Continúas recibiendo este
mensaje, envía un correo electrónico a
para hacernos saber que
estás teniendo problemas.
Temos Recebido algumas atividades suspeitas de voiceê ou de alguém que esteja usando a mesma rede. Aguarde enquanto
confirmamos que Você é Uma Pessoa de Verdade.Сеу контексто апаресера эм бреве. Caso продолжить Recebendo esta
mensagem, envie um email para
пункт нет
informar sobre o проблема.
Abbiamo notato alcune attività sospette da parte tua o di una persona che condivide la tua rete Internet.
Attendi mentre verifichiamo Che sei una persona reale. Il tuo contenuto verrà visualizzato a breve. Secontini
visualizzare questo messaggio, invia un’e-mail all’indirizzo
per informarci del
проблема.
Пожалуйста, включите куки и перезагрузите страницу.
Это автоматический процесс. Ваш браузер в ближайшее время перенаправит вас на запрошенный контент.
Подождите до 5 секунд…
Перенаправление…
Заводское обозначение: CF-102 / 6863d4116f56165a.
Яндекс.Карт в App Store
Найдите адрес или лучшие места поблизости как в Интернете, так и в автономном режиме. Яндекс.Карты предоставляют информацию об организациях и помогают добраться до места назначения на машине, общественном транспорте, велосипеде или пешком в зависимости от текущей дорожной обстановки.
Найдите и выберите местоположения:
• Самая большая база данных организации и фильтры для уточнения поиска.
• Подробная информация: контакты, режим работы, предоставляемые услуги, фотографии и отзывы.
• Поэтажные планы для знакомства с основными торговыми центрами Москвы.
• Поиск мест и адресов без подключения к Интернету (автономные карты).
• Просматривайте места, сохраненные на вашем смартфоне, планшете и ПК.
Пользовательские настройки карты:
• Местоположение автобусов, трамваев, троллейбусов и маршруток в реальном времени.
• Дорожные карты, показывающие текущую дорожную обстановку в городе.
• Парковочный слой с указанием места и стоимости служебной парковки.
• Панорамы улиц для любого адреса со стороны дороги.
• Выберите один из трех типов карты: дорожная карта, спутниковая и гибридная.
Общественный транспорт, автомобили, велосипеды и пешеходные маршруты:
• Пешеходная навигация: пути между зданиями, через парки, площади и другие пешеходные зоны.
• Велосипедная навигация: типы дорог, предпочтения подземных и эстакад, а также предупреждения о шоссе.
• Маршруты общественного транспорта с расписанием и примерным временем прибытия.
• Оптимальные маршруты движения, основанные на реальных условиях движения и вариантах вождения.
• Пошаговые инструкции с голосовой навигацией.
• Уведомления о камерах контроля скорости, ограничении скорости и превышении скорости.
• Обновления в режиме реального времени о дорожном движении, дорожно-транспортных происшествиях, радаре скорости и многом другом.
Офлайн-карты:
• Автомобильные маршруты и голосовая навигация.
• Загружаемые облегченные карты (минимальный объем памяти, например, карта Москвы составляет всего 187 МБ).
• База данных организаций с графиком работы, предоставленными услугами и др.
• Более 2000 городов в России, Армении, Беларуси, Грузии, Казахстане, Латвии, Турции, Украине и Эстонии.
Информация от пользователей:
• Отметьте дорожные события на карте и комментируйте сообщения пользователей.
• Регулярные обновления общедоступной карты информируют вас о вашем городе.
• Пишите обзоры, загружайте фотографии и обновляйте информацию об организациях.
На Яндекс.Картах есть приложение Apple Watch.Используйте его, чтобы:
• Перемещаться по карте.
• Просмотр ближайшей станции метро и остановок общественного транспорта.
• Узнайте, когда общественный транспорт прибудет на ближайшую остановку.
• Отслеживайте модели трафика на несколько часов раньше времени.
• Просмотр прогнозов погоды.
Practicum от Yandex Blog
По мере взлета вашей карьеры программиста вы, скорее всего (ну, определенно) столкнетесь с каким-нибудь новым, захватывающим (хотя и устрашающим) отраслевым жаргоном. Одна из самых распространенных фраз, с которыми вы столкнетесь, независимо от выбранной вами специальности, — это концепция, известная как проверка кода.Но что именно?
В этой статье мы разберем эту общую задачу программирования, чтобы вы знали, чего ожидать, когда вы пройдете практический курс или начнете свою первую работу.
Мы объясним, что такое ревью кода, почему это важно, кто этим занимается и как вы можете использовать его, чтобы стать лучшим разработчиком.
Поехали!
Что такое проверка кода?
Проверка кода — это процесс, при котором один разработчик проверяет код другого разработчика и предлагает предложения. Обычно старший разработчик просматривает код младшего разработчика. Помимо проверки того, что код работает и хорошо написан, проверка кода отражает ваши навыки совместной работы и способность получать отзывы.
На работе процесс проверки кода чем-то похож на редактирование, когда один человек предлагает свои предложения и отзывы.
На практическом курсе у вас будет углубленный анализ кода для вашей работы над каждым из важных этапных проектов.
В Practicum проверка кода — это место, где встречаются твердые и мягкие навыки.Получение большого опыта с подлинной проверкой кода — отличный способ подготовить вас не только к знаниям программирования, которые вам понадобятся для новой карьеры в программировании, но и к опыту получения отзывов и работы с коллегами.
Чтобы лучше понять, как выглядит процесс проверки кода на Практикуме, мы поговорили с Лерой Шелегиной, руководителем группы рекомендаций в Отделе данных Практикума.
Почему проверка кода имеет значение
Вы можете спросить: «Если я уже протестировал свой код и знаю, что он работает нормально, какое значение будет иметь процесс проверки кода?»
«Запуск кода почти ничего не значит, — говорит Шелегина, — это не доказывает, что код решает вопрос.”
В Practicum проверка кода касается качества кода и процесса разработки. «Даже отличный код может быть не таким эффективным или продвинутым, как мог бы». — говорит Шелегина.
Код предназначен для совместного использования, а это значит, что то, как вы его пишете, имеет большое значение в работе и при обучении.
«Он должен быть читаемым и написанным в форме, которая может быть использована в вашей работе», — говорит Шелегина, отмечая, что с хорошим кодом ваши коллеги «могут использовать его и передавать другим коллегам.”
Кто будет проверять ваш код?
Существует несколько различных типов проверки кода, но не все они одинаково эффективны.
Например, автоматическая проверка кода запустит набор автоматических тестов, чтобы проверить, хорошо ли работает то, что вы написали. Автоматизация полезна — особенно для выявления мелких ошибок, которые люди могут упустить из виду, — но она может упустить из виду более широкую картину. Люди должны быть частью любого хорошего ревью кода.
Другой вариант — коллегиальная проверка кода , когда коллега с аналогичным уровнем опыта просматривает ваш код.Как и в парном программировании, когда два программиста работают над проектом вместе, вы получаете выгоду от того, что на ваш код смотрят две пары глаз.
Но самый распространенный и ценный вид ручной проверки — это когда старший разработчик просматривает вашу работу.
«На работе рецензенты кода будут вашими коллегами — возможно, вашими старшими коллегами», — объясняет Шелегина. Это тип процесса проверки кода, который Практикум предлагает в конце каждого модуля.
Рецензенты практического кода являются экспертами в своей профессии.«Мы нанимаем специалистов по обработке данных, аналитиков данных и веб-разработчиков, которые уже некоторое время работают в этой области», — объясняет Шелегина. «Они знают стандарты».
Каких комментариев ожидать
Если вы новичок в рецензировании кода, вы, вероятно, задаетесь вопросом, чего ожидать. Вы только новичок — не собираются ли старшие разработчики разорвать ваш код в клочья?
Не о чем беспокоиться. Мы не можем говорить от лица каждого рецензента кода, но большинство из них хотят помочь вам стать лучшим программистом.
Здесь, в Practicum, наши рецензенты кода выступают в роли наставников, помогая вам найти лучшие решения и навыки. Большинство комментариев, которые вы увидите, попадают в одну из трех категорий.
Исправления ошибок
Исправления ошибок — это обязательный ремонт существующего кода. По сути, вам нужно будет внести изменения в код, чтобы ваша программа работала правильно и соответствовала требованиям проекта.
Многие новички думают, что это единственный важный комментарий при проверке кода — своего рода оценка «прошел или не прошел».Но есть гораздо больше, чем просто исправления ошибок!
Рекомендации
«Даже если вы напишете идеальный код с первой попытки, вы все равно сможете изучить советы и рекомендации, которые могут сделать его еще более эффективным и продвинутым», — говорит Шелегина.
Вот тут-то и пригодятся рекомендации. Каждое предлагаемое изменение — это возможность развить свои навыки и создать еще более впечатляющий проект, который улучшит ваше портфолио.
Ваш рецензент кода предложит следующие стандарты кодирования, написание чистого кода, улучшение читаемости или документации и многое другое.
Положительные комментарии
Проверка кода — это еще не все отрицательно! В рамках этого процесса разработчик Практикума всегда укажет вам, в чем вы преуспеваете.
Положительные отзывы нужны не только для повышения уверенности в себе — хотя, конечно, это всегда приветствуется! Это также поможет вам увидеть, в чем заключаются ваши сильные стороны, понять, какие типы мышления следует применить в следующем проекте, и получить немедленную обратную связь о ваших творческих идеях.
Как правильно выполнять анализ кода
Легко подумать, что все, что вам нужно для успешной карьеры разработчика, — это хорошие навыки программирования, но ничто не может быть дальше от истины.Хорошая работа с коллегами и руководителями команд не менее важна для успешного кодирования.
Вот почему проверка кода так важна в обучении, поскольку вы получите опыт работы с элементами, из которых состоит реальная работа по кодированию.
«Отправка работы может быть нервным процессом, — говорит Шелегина. «Вы делаете эту огромную бумагу, отправляете ее и ждете отзывов», — объясняет она. Но тебе не о чем беспокоиться. Рецензенты кода дружелюбны и представительны.
Лучший совет, как получить обратную связь от анализа кода, — отделиться от того, что вы написали.Как автору кода сложно увидеть объективный код, но помните, что критика относится к проекту, а не к вашим навыкам или потенциалу. Напротив, комментарии должны помочь вам стать лучше!
Какие проблемы встречаются чаще всего?
Подводя итоги, давайте рассмотрим некоторые из наиболее распространенных проблем, возникающих при проверке кода, чтобы вы могли понять, чего следует избегать.
Конечно, самая большая категория исправлений будет связана с проблемами, с которыми вы столкнулись с самим учебным материалом.Курс Practicum разработан, чтобы дать вам навыки, необходимые для должности младшего уровня, всего за десять месяцев, поэтому каждый проект будет расширять ваши навыки.
Но помимо этого, представление самого кода может быть сложным для понимания учащимися. «Эффективная проверка кода — это не только технические детали, — говорит Шелегина, — это еще и то, как вы представляете свой код. Это совершенно другой навык ».
Но помните — проверка кода помогает вам учиться. Чем больше вы узнаете из отзывов ваших рецензентов, тем меньше ошибок вы совершите в будущем!
Заключение
Проверка кода — важный опыт для любого нового программиста, и привыкание к получению и реализации обратной связи ценно для всех.
Вот почему курсы Практикума включают проверку кода после каждого углубленного модуля. Вы должны быть готовы к реальной карьере в сфере развития, и нет лучшего способа, чем работать с упражнениями, смоделированными по образцу того, что вы будете делать на работе.
«В рабочей среде у вас наверняка будут специалисты по проверке кода», — говорит Шелегина. А с курсами Practicum вы тренируетесь в этих мягких навыках, которым другие программы часто не учат.
Более того, зачастую именно эти упускаемые из виду навыки определяют успех вашей карьеры.«Проверка кода очень важна, — заключает Шелегина, — это совсем другая часть этой работы».
Примеры использования: Яндекс | Kotlin Multiplatform Mobile
Яндекс ↗ — технологическая компания, создающая интеллектуальные продукты и услуги на основе машинного обучения. Его цель — помочь потребителям и компаниям лучше ориентироваться в онлайн- и офлайн-мире. С 1997 года Яндекс предоставляет локально релевантные поисковые и информационные услуги мирового уровня. Кроме того, она разработала ведущие на рынке транспортные услуги по запросу, навигационные продукты и другие мобильные приложения для миллионов потребителей по всему миру.У Яндекса 30 офисов по всему миру, с 2011 года он котируется на NASDAQ.
Не могли бы вы сказать несколько слов о своей команде?
Яндекс.Диск создается командой, участники которой работают в Москве и Санкт-Петербурге, и является одним из самых популярных облачных сервисов в России для хранения файлов в облаке. Яндекс.Диск, запущенный 5 апреля 2012 года, предоставляет неограниченное пространство в облаке для хранения фотографий с мобильных устройств — вы можете включить автоматическую загрузку изображений с мобильного устройства в приложении.Он включает в себя умную фотогалерею, в которой представлены коллекции ваших самых красивых фотографий и лучших воспоминаний. Яндекс.Диск доступен как веб-версия, как клиент для Windows и macOS, а также как приложение для iOS и Android.
Как Kotlin Multiplatform Mobile используется в вашем продукте?
У нас в производстве есть несколько функций, написанных с помощью Kotlin Multiplatform Mobile. Сначала мы начали экспериментировать с KMM, реализовав сетевой уровень для наших приложений iOS и Android. Изначально мы думали об использовании Ktor, но он не соответствовал нашим требованиям, поэтому мы написали нашу собственную облегченную сетевую библиотеку, которая использует механизм ожидания / фактического под капотом и может выполнять простые запросы REST.
Мы сочли это успешным экспериментом, и следующей функцией, которую мы реализовали с помощью KMM, стали покупки из приложения. Мы реализовали многоплатформенную библиотеку, которая обертывает API для конкретных платформ (Google Play и Apple Store) с использованием ожидаемого / фактического, скрывает всю сложную обработку платежей и предоставляет универсальный интерфейс для работы с логикой покупки в приложениях iOS и Android.
Это тоже был успех, поэтому мы расширили нашу мультиплатформенную команду, и теперь у нас есть три инженера, работающих над KMM.Последней важной функцией, которую мы сделали с KMM, была синхронизация данных для фотоальбомов. Сеть, хранение и синхронизация данных реализованы на чистом Kotlin для обеих платформ. Нам часто приходится выполнять множество операций в фоновом режиме, и поскольку сопрограммы в настоящее время поддерживаются только в основном потоке, нам пришлось реализовать собственное решение для многопоточности. Для хранения данных мы использовали SQLDelight, который сэкономил нам много времени за счет создания безопасных типов Kotlin API для выполнения SQL-запросов.
Почему ваша команда решила использовать Kotlin Multiplatform и какие альтернативы вы рассматривали?
Мы все согласились в одном: повторное использование кода — это хорошо. В Яндексе мы много экспериментируем, чтобы избавить разработчиков от необходимости писать один и тот же код несколько раз для разных платформ. Kotlin Multiplatform Mobile — не единственное доступное решение, и каждая команда решает эту проблему по-своему. Я был удивлен, когда пришел в команду Яндекс.Диск и понял, что у этих людей есть собственный код для логики синхронизации для каждой платформы и, например, не используется C ++.Но они хотели попробовать KMM, и у меня был некоторый опыт в этом, так что это сработало очень хорошо.
Мы не верим в совместное использование уровня пользовательского интерфейса при разработке мобильных приложений. Такой подход почти всегда приводит к взломам кода и созданию более грубого, необработанного, запаздывающего пользовательского интерфейса, и ни разработчики, ни пользователи не довольны конечным результатом. Мы любим наших пользователей и хотим предоставить им лучший опыт, в том числе предоставить им ощущение и плавность нативного пользовательского интерфейса. Но нам очень интересно делиться бизнес-логикой: в Яндекс.Диск 20% нашей работы приходится на пользовательский интерфейс, а остальные 80% — на бизнес-логику — как собирать, синхронизировать и обрабатывать все данные пользователя, не разряжая аккумулятор телефона. Поэтому мы не рассматривали решения для совместного использования пользовательского интерфейса, такие как Flutter, React Native или Xamarin. Одной из альтернатив был C ++, но писать на С ++ сложно и дорого. Наши коллеги из Dropbox выяснили это на собственном горьком опыте, да и у нашей конкретной команды не было достаточного опыта в этом.
Использование C ++ для кроссплатформенной разработки также сопряжено с большими проблемами DX для разработчиков Android — JNI неудобно использовать и имеет множество ограничений.Так что для Android-части нашей команды использование Kotlin для кроссплатформенной разработки было огромным преимуществом. Конечно, для разработчиков iOS KMM имеет свой собственный набор проблем, поскольку, в конце концов, он вводит новый язык в кодовую базу, и с этим могут быть некоторые проблемы с DX. Но они не так серьезны, как проблемы с разработкой на C ++ для Android. Так что выбор для нас был очевиден, особенно с учетом того, что в нашей команде больше разработчиков Android, чем разработчиков iOS.
Какие достижения и трудности были для вас наиболее значительными?
Самым важным приобретением для меня стала возможность выступать с докладами на различных конференциях.Kotlin Multiplatform Mobile — довольно новая технология, и число разработчиков, заинтересованных в ней, растет как снежный ком. Рассказы о вашем опыте работы с КММ будут приветствоваться на любой конференции!
Но на самом деле основной выигрыш от использования KMM заключается в том, что вы можете написать свой код один раз, и он будет работать одинаково для всех кроссплатформенных решений. Дело не только в скорости разработки, по крайней мере, на начальном этапе. Когда мы впервые интегрировали KMM, мы потратили много времени на решение различных задач и попытки понять, как это должно работать.Теперь у нас больше опыта, и мы можем быстрее предоставлять новые функции. Но главный выигрыш заключается в том, что мы знаем, что наша логика одинаково работает как в приложениях iOS, так и в Android. Это означает, что мы можем протестировать наши функции один раз, и нам нужно только исправить ошибки в одном месте. Кроме того, единая кодовая база для бизнес-логики дает нам схожие оценки новых функций на обеих платформах, что значительно упрощает процесс планирования.
Конечно, использование KMM сопряжено с некоторыми трудностями. Мы надеемся, что большинство из них скоро будет решено, поскольку технологии развиваются и развиваются быстро.Мы начали использовать KMM, когда он был еще на «экспериментальной» стадии, и мы знали, чего ожидать.
Самой критической проблемой было отсутствие документации (как для Kotlin, так и для сторонних библиотек). Вначале мы потратили много времени, просто пытаясь понять, как выполнять простые задачи, такие как настройка проекта или добавление новых зависимостей.
Еще одна большая проблема — работа с параллелизмом в Kotlin / Native. Модель памяти Kotlin / Native непростая для понимания, и не было никаких руководств по работе с ней.Мы не знали, что делать, если что-то пошло не так, поэтому нам пришлось копаться в исходниках Kotlin / Native, чтобы понять проблему, и это было настоящей проблемой.
Наконец, DX для меня как разработчика iOS — настоящая боль. Отладка бизнес-логики с помощью приложения iOS обычно является плохой идеей — вам нужно запускать две IDE одновременно и переключаться между ними. Кроме того, у Kotlin / Native длительное время компиляции, что резко снижает скорость разработки. Итак, теперь, если мне нужно что-то отладить, я запускаю приложение для Android.Хорошее тестовое покрытие вашего общего кода может сэкономить вам много времени на отладку, потому что вам не нужно запускать приложения для iOS или Android, чтобы проверить, правильно ли работает ваш код. Использование KMM дает вам отличную мотивацию начать писать тесты в своем проекте, если вы еще этого не сделали.
У вас есть какие-нибудь советы или рекомендации, которыми вы хотели бы поделиться с нашими читателями?
Эксперимент — отличный способ понять, подходит ли технология вашим потребностям. Вы можете попробовать это на одной функции в небольшом проекте.Делая что-то маленькими шагами, вы сэкономите время в долгосрочной перспективе и получите много опыта. Активное сообщество в Slack компенсирует отсутствие документации, там всегда можно найти ответы на свои вопросы.
Хотели бы вы поделиться своей контактной информацией с нашими читателями?
Основное преимущество заключается в том, что мы знаем, что наша логика работает одинаково как в приложениях iOS, так и в Android. Это означает, что мы можем протестировать наши функции один раз, и нам нужно только исправить ошибки в одном месте.Кроме того, единая кодовая база для бизнес-логики дает нам схожие оценки новых функций на обеих платформах, что значительно упрощает процесс планирования.
Артем Ольков, мобильный разработчик Яндекс.Диск
Контакты
Артем Ольков, мобильный разработчик Яндекс [email protected]
Новый взгляд на документирование API и SDK в Яндекс. Лекция по Hyperbaton / Sudo Null IT News
Меня зовут Андрей Поляков, я руководитель группы документации API и SDK в Яндекс.Сегодня я хотел бы поделиться с вами отчетом, который я и моя коллега, Юлия Пивоварова, старший разработчик документации, прочитали несколько недель назад на 6-м Гипербатоне.

Светлана Каюшина, начальник отдела документации и локализации:
— Объем программного кода в мире сильно вырос за последние годы, продолжает расти, и это сказывается на работе технических писателей, которые придумывают все новые и новые задачи по разработке программной документации и документированию кода.Мы не могли обойти вниманием эту тему, мы посвятили ей целый раздел. Это три взаимосвязанных отчета, посвященных унификации разработки программной документации. Приглашаю наших специалистов по документированию программных интерфейсов и библиотек Андрея Полякова и Юлию Пивоварову. Скажите им слово.
— Здравствуйте! Сегодня мы с Юлей расскажем, как в Яндексе по-новому взглянули на документирование API и SDK. Отчет будет состоять из четырех частей, отчет часа мы обсудим и поговорим.
Давайте поговорим об унификации API и SDK, как мы пришли к этому, что мы там сделали. Мы поделимся опытом использования универсального генератора, одного для всех языков, и расскажем, почему он у нас не сработал, в чем были подводные камни и почему мы перешли на создание документации с помощью собственных генераторов.
Напоследок расскажем, как строились наши процессы.
Начнем с унификации. Все думают об объединении, когда в команде больше двух человек: все пишут по-разному, у каждого свои подходы, и это логично.Лучше все правила обсудить на берегу, прежде чем приступить к написанию документации, но не всем это удается.
Мы собрали группу экспертов для анализа нашей документации. Мы сделали это для систематизации наших подходов. Все пишут по-разному, и давайте договоримся писать в одном стиле. Это второй пункт, по которому мы собирались сделать документацию единообразной, чтобы у пользователя был единый пользовательский опыт во всей документации Яндекса, а именно технический.
Работа была разделена на три этапа.Мы составили описание тех технологий, которые есть у нас в Яндексе, которые мы используем, постарались выбрать из них те, которые мы можем как-то объединить. А также сделал общую структуру типовых документов и шаблонов.
Обратимся к описанию техники. Мы начали изучать, какие технологии используются в Яндекс. Их так много, что мы устали записывать их в какой-то тетрадь, и в итоге мы выбрали только самые основные, которые наиболее часто используются, чаще всего встречаются у технических писателей, и начали их описывать.
Что подразумевается под описанием технологии? Мы определили основные моменты и суть каждой технологии. Если мы говорим о языках программирования, то это описание таких сущностей, как класс, свойство, интерфейсы и т. Д. Если мы говорим о протоколах, то мы описываем методы HTTP, говоря о формате кода ошибки, кода ответа, и т. д. Мы составили глоссарий, который включает в себя: термины на русском языке, термины на английском языке, нюансы использования. Например, мы не говорим о каком-то SDK-методе, он ПОЗВОЛЯЕТ что-то делать.Он что-то ДЕЛАЕТ, если программист дергает за ручку, он дает какой-то ответ.
Помимо нюансов, описание также содержало стандартные структуры, стандартные речевые шаблоны, которые мы используем в документации, чтобы диктофон мог взять конкретную формулировку и использовать ее в дальнейшем.
Кроме того, технические писатели часто пишут фрагменты кода, фрагменты, образцы, и для этого мы также описали собственное руководство по стилю для каждой технологии. Мы обратились к разработчикам гайдов, которые есть в Яндекс.Обратил внимание на дизайн-код, описание комментариев, отступы и все такое. Мы делаем это для того, чтобы, когда технический писатель приходит к программисту с фрагментом кода или письменным образцом, программист смотрит на суть, а не на то, как она спроектирована, и это сокращает время. И когда технический писатель умеет писать на Яндексе руководствах по стилю, это очень круто, может, он захочет потом стать программистом. Предыдущий отчет был о различных обследованиях. Например, вы можете стать программистами.
Для технических писателей мы также разработали краткое руководство: как настроить среду разработки, когда он знакомится с новой технологией. Например, если технический специалист по SDK написан на C #, он входит, настраивает среду разработки, читает руководства, знакомится с терминологией. Мы также оставили ссылки на официальную документацию и RFC, если таковые имеются. Мы сделали точку входа для технических писателей, и это выглядит так.
Когда приходит технический писатель, он изучает новую технологию и начинает ее документировать.
После описания технологии мы перешли к описанию структуры HTTP API.
У нас много разных HTTP API, и все они описываются по-разному. Давай договоримся и сделаем то же самое!
Мы определили основные разделы, которые будут в каждом HTTP API:
«Обзор» или «Введение»: для чего нужен этот API, что он позволяет вам делать, с каким хостом вам нужно связаться, чтобы получить своего рода ответ.
«Быстрый старт», когда человек проходит несколько шагов и в конце получает успешный результат, чтобы понять, как работает этот API.
«Подключение / Авторизация». Для многих API требуется токен авторизации или ключ API. Это важный момент, поэтому мы решили, что это обязательная часть всех API.
«Лимиты / Лимиты», когда мы говорим об ограничениях на количество запросов или размер тела запроса и т. Д.
«Ссылка», ссылка. Очень большая часть, которая содержит все HTTP-дескрипторы, которые пользователь может извлечь и получить какой-то результат.
В результате у нас было много разных API, они описывались по-разному, сейчас мы пытаемся писать все одинаково.Такая прибыль.
Заглянув в каталоги, мы поняли, что дескриптор HTTP почти всегда один и тот же. Дёргаете, то есть делаете запрос, сервер возвращает ответ — вуаля. Попробуем его унифицировать. Мы написали шаблон, который постарался охватить все случаи. Технический писатель берет шаблон и, если у него есть запрос PUT, он оставляет необходимые части в шаблоне. Если у него есть запрос GET, он использует только те части, которые необходимы для запроса GET. Общий шаблон для всех запросов, которые можно использовать повторно.Теперь вам не нужно создавать структуру документа с нуля, а можно просто взять готовый шаблон.
Каждая ручка описывает, для чего она предназначена и для чего предназначена. Есть раздел «Формат запроса», который содержит параметры пути, параметры запроса, все, что входит в тело запроса, если оно отправлено. Еще мы выделили раздел «Формат ответа»: пишем, если есть тело ответа. Отдельным разделом мы выделили «коды ответа», потому что ответ от сервера приходит независимо от тела.И покинул раздел «Пример». Если мы поставляем SDK с этим API, мы говорим, что используйте SDK вот так, потяните за такой дескриптор, вызовите такой метод. Обычно мы оставляем пример с cURL, где пользователь просто вставляет свой токен. А если у нас есть тестовый стенд, то просто берет запрос и выполняет его. И получает какой-то результат.
Оказывается, ручек было много, они описывались по-разному, и теперь мы хотим привести все это к единому виду.
После того, как мы закончили работу с HTTP API, мы перешли на мобильный SDK.
Общая структура документа примерно такая же:
— «Введение», где мы говорим, что этот SDK используется для таких целей, интегрируйте его для таких целей, он будет работать для такой ОС, мы есть такие версии и т.к. d.
— «Связь». В отличие от HTTP API, мы не просто говорим о том, как получить ключ для использования SDK, если он вам нужен, мы говорим о том, как интегрировать библиотеку в ваш проект.
— «Примеры использования».Самый большой по объему раздел. Чаще всего разработчики хотят зайти в документацию и не читать много информации, они хотят скопировать кусок, вставить, и у них все заработает. Поэтому мы посчитали эту часть очень важной и сделали ее обязательной.
— «Справочник», справочник, но, в отличие от справочника HTTP API, мы не можем здесь все унифицировать, так как мы в основном генерируем справочники и об этом поговорим позже в отчете.
— «Релизы», или журнал изменений, журнал изменений. У мобильных SDK обычно короткий цикл выпуска, где-то около двух недель выходит новая версия. И пользователю было бы лучше рассказать о том, что изменилось, обновится он или нет.
При этом в API есть как обязательные разделы, которые мы видим, так и разделы, которые мы рекомендуем использовать. Если API часто обновляется, мы говорим, что затем вставьте себе также историю изменений, что изменилось в API. И часто у нас API редко обновляется, и в качестве обязательного раздела указывать его бессмысленно.
Итак, у нас было много SDK, которые описывались по-разному, мы пытались использовать один стиль. Естественно, есть дополнительные отличия, присущие только этому SDK или этому HTTP API. Здесь у нас есть свобода выбора. Мы не говорим, что кроме этих разделов никто ничего не может сделать. Конечно, можно, мы просто стараемся делать перечисленные разделы везде, чтобы было понятно, что если пользователь перешел в документацию для другого SDK, он знает, что будет описано в разделе «Подключение».
Итак, мы придумали шаблоны, сделали гайды, каков наш план действий сейчас? Мы решили, что если мы масштабируем изменения API, меняем ручки или меняем SDK, мы берем новые шаблоны, берем новую структуру и начинаем над ней работать.
Если мы пишем документацию с нуля, то, конечно, мы снова берем новую структуру, берем новые шаблоны и работаем над ними.
А если API устарел, редко обновляется или его никто не поддерживает, но он существует, то переделывать его немного ресурсоемко.Мы просто решили оставить это, пока так не будет, но потом, когда ресурсы появятся, мы обязательно к ним вернемся, все это сделаем хорошо и красиво.
В чем преимущества унификации? Они должны быть очевидны для всех:
«UX», мы думаем о том, чтобы пользователь чувствовал себя как дома в нашей документации. Пришел, знает, что описано в разделах, где можно найти авторизацию, примеры использования, описание ручки. Это великолепно.
Для технических писателей описание технологии позволяет определить определенную точку входа, откуда она приходит, и начинает знакомство с этой технологией, если он этого не знал, начинает разбираться в терминологии, погружаться в нее.
Следующий момент — взаимозаменяемость. Если технический писатель ушел в отпуск или просто перестал писать, то другой технический регистратор знает, как это работает внутри при вводе документа. Сразу понятно, что описано в подключении, где искать информацию по интеграции SDK. Понимание и внесение небольших изменений в документ становится проще. Понятно, что каждый проект имеет свою специфику, нельзя просто прийти и задокументировать проект, не зная его полностью.Но при этом структура, то есть навигация по файлам, будет примерно такой же.
И, конечно же, общая терминология. Мы согласовали с разработчиками и переводчиками терминологию, которую сделали для языков. Мы говорим, что у нас есть C #, есть такой термин, мы так его употребляем. Мы спросили разработчиков, какую терминологию они использовали и хотели бы добиться синхронизации в этом месте. У нас есть договоренности, и в следующий раз, когда мы приедем с документацией, разработчики знают, что мы с ними согласовали условия, руководства, мы используем эти шаблоны, мы учитываем нюансы их использования.А переводчики, в свою очередь, знают, что мы описываем SDK на C # или Objective-C, а значит, эта терминология будет соответствовать тому, что описано в руководстве.
Руководства были написаны на вики-страницах, поэтому, если есть обновление языков, технологий, протоколов, все это легко добавить в существующий документ. Идиллия.
Чем раньше вы начнете объединяться и вести переговоры, тем лучше. Лучше, чтобы позже не было унаследованной документации, написанной в другом стиле, который нарушает поток пользователя в документации.Лучше все сделать раньше.
Привлечь разработчиков. Это люди, для которых вы пишете документацию. Если вы сами написали какие-то руководства, им это может не понравиться. Лучше согласиться с ними, чтобы у вас было общее понимание терминологии: что вы пишете в документации, как вы это пишете.
А еще договаривайтесь с переводчиками, они все переводят. Если они переведут иначе, чем привыкли разработчики, снова возникнут конфликты. (Вот ссылка на фрагмент видео с вопросами и ответами — Ред.) Вперед, продолжать.
Юлия:
— Привет, меня зовут Юля, уже пять лет работаю в Яндексе и документирую API и SDK в группе Андрея. Обычно все говорят о хорошем опыте, о том, как все хорошо получается. Расскажу, как мы выбрали не совсем удачную стратегию. В то время она казалась успешной, но потом пришла суровая реальность, и нам немного не повезло.
Изначально у нас было несколько мобильных SDK, и они были написаны в основном на двух языках: Objective-C и Java.Мы писали им документацию вручную. Со временем классы, протоколы и интерфейсы росли. Их становилось все больше и больше, и мы поняли, что нам нужно автоматизировать этот бизнес, мы посмотрели, какие технологии есть.
На тот момент Doxygen нам понравился, он отвечал нашим потребностям, как нам казалось, и мы выбрали его как единый генератор. И нарисовали такую схему, которую рассчитывали получить, хотели как-то поработать.
Что у нас было? Технический писатель приступил к работе, получил исходный код от разработчика, начал писать свои комментарии, правки, после этого документацию нужно было отправить на наш сервер разработчиков, мы запустили Doxygen, получили формат XML, но он не подходил для нашего DITA XML стандарт.Мы знали об этом заранее, писали некий конвертер.
После того, как мы получили вывод от Doxygen, мы пропустили все это через конвертер и получили наш формат. Далее был подключен сборщик документации, и все это мы опубликовали на внешнем домене. Нам даже повезло с парой итераций, у нас все получилось, мы были в восторге. Но потом что-то пошло не так. Технический писатель тоже пошел работать, получил задания и исходники от разработчика, внес там свои правки.После этого он зашел на devserver, запустил Doxygen и возник пожар.
Решили разобраться, в чем дело. Потом мы поняли, что Doxygen не совсем подходит для всех языков. Нам пришлось проанализировать код, на который он наткнулся, мы обнаружили конструкции, которые Doxygen не поддерживал и не планировал поддерживать.
Мы решили, раз уж мы работаем по этой схеме, мы напишем сценарий предварительной обработки и каким-то образом заменим эти конструкции на то, что принимает Doxygen, или каким-то образом проигнорируем их.
Наш цикл стал выглядеть так. Мы получили исходный код, завершили его на сервере разработчика, затем подключили сценарий предварительной обработки, вырезали все дополнительные элементы из кода, а затем Doxygen, затем получили выходной формат Doxygen, также запустили конвертер, получили наши окончательные файлы DITA XML, затем подключился сборщик документации, и мы опубликовали документацию по внешнему домену. Вроде все хорошо. Добавил скрипт, что это? Изначально все было пустяком.В сценарии было три строки, затем пять, десять, и все выросло до сотен строк. Мы поняли, что начинаем тратить большую часть времени не на написание документации, а на анализ кода, поиск чего-то, что не сканирует, и просто добавление скрипта в бесконечные регулярные списки, сидя до отвлечения и думая, в чем дело.
Мы поняли, что нам нужно что-то изменить, чтобы как-то остановиться, пока не стало слишком поздно, и пока наш цикл выпуска полностью не рухнет.
Например, что-то вроде сценария предварительной обработки изначально выглядело и безвредно.
Почему мы изначально выбрали этот путь? Почему он казался хорошим?
Один генератор отличный, взял, один раз подключил, настроил и работает. Это казалось хорошим подходом. Кроме того, вы можете использовать один и тот же синтаксис комментариев для всех языков одновременно. Вы написали какое-то руководство, один раз примените, сразу вставьте все эти конструкции в код и сделайте свою работу, пишите комментарии, а не как-то зацикливайтесь на синтаксисе.
Но это оказалось одним из больших недостатков. Наш единый синтаксис не поддерживался разработчиками, они привыкли использовать свои IDE, уже есть нативные генераторы, и их синтаксис не совпадает с нашим. Это было камнем преткновения.
Кроме того, Doxygen плохо поддерживает новые языковые функции. У него избирательный подход, так как сам он написан на C ++, в основном поддерживает C-подобные языки, а все остальное по остаточному принципу. Но языки улучшаются, Doxygen отстает от них, и мы чувствуем себя очень неудобно.
Потом случилось совсем несчастье. К нам пришла новая команда и сказала, что мы пишем на Swift, а Doxygen совсем с ним не дружит. Мы поняли, что пора остановиться и изобрести что-то новое. Потом пришла еще пара команд, и мы поняли, что нашу схему вообще нельзя масштабировать. И мы постоянно что-то добавляем, таких скриптов у нас несколько, они живут в разных ветках и все. Мы поняли, что нужно смириться с тем, что нам не повезло, попробовать новые подходы и найти решения.О них вам расскажет Андрей.
— Мы поняли, что в нашем случае где-то подошел универсальный генератор, но по большей части, когда мы начали его масштабировать, план не сработал. Придумал круто, со всем договорился, давайте делать, но не вышло.
В результате мы начали изобретать новую схему. Она была с родными генераторами. Что у нас сейчас в схеме? Технический писатель тоже пришел на работу (его даже не уволили за такое), комментировал исходный код, но теперь он комментировал не только Objective-C и Java, но в целом все, что мы можем сгенерировать.
Все это произошло, потому что раньше у нас был сервер документации, настроенный только для DITA XML, мы хорошо его переводили, и в целом у нас было много аспектов, почему мы использовали XML. Здесь мы изменили инфраструктуру и научили наш центр документации принимать HTML, и это нам очень помогло. Теперь мы готовы работать с любым конвертером — JavaDoc, AppleDoc, Jazzy. Любой из них дает нам вывод HTML, в котором разработчики привыкли видеть документацию. Мы делаем небольшую пост-обработку HTML, чтобы он вписался в наш макет, дошел до нас.И часто многие генераторы можно настроить на этапе генерации, какой HTML-вывод вам нужен. Вы также можете настроить совок, который вы хотите забрать, какие файлы и функции HTML, которые он создает. И, минуя сборку XML, сразу публикуем документацию на внешнем домене.
Мы решили посмотреть на все преимущества относительно универсального генератора.
Первый плюс — мы документируем в собственном синтаксисе. Для Doxygen у нас был единый синтаксис, и здесь мы документируем синтаксис, который нравится разработчикам.Если Objective-C, у них свой синтаксис, своя Java и т. Д. Они готовы впустить нас в свой репозиторий, внести наши изменения в свою документацию в коде, и тогда вы уже можете увидеть эту документацию в IDE в виде подсказок, IntelliSense, это очень важный момент, хороший плюс для разработчиков, что они могут интегрировать нашу библиотеку, наш мобильный SDK, а затем просматривать документацию по методам, классам и т. д. в коде.
Если мы еще не хотим, чтобы наша документация публиковалась, но мы хотим передать ее другой команде внутри Яндекса, если SDK используется, скажем, другой командой, и они хотят интегрировать его в себя , мы можем просто передать им созданный локальный HTML-код.Его не будет в нашем макете, но как есть, но дерево уже есть, и все, что душе угодно, вы можете использовать в этой документации.
Все генераторы родные идут в ногу со временем. Если появляется новая языковая конструкция, если в языке что-то меняется, то большое сообщество быстро поддерживает все нововведения. Возникла проблема с XML, заключающаяся в том, что не все генераторы предоставляют XML на выходе. Doxygen умеет, но в то же время XML считается побочным форматом. Поэтому сообщество поддерживало HTML, а XML поддерживался по принципу остатков.В новой схеме этой проблемы не будет. Получается новая фича — мы готовы практически сразу ее поддержать.
И, как оказалось, постобработка намного проще, чем предобработка. Если наша предварительная обработка выросла до 1500 строк кода, то постобработка не такая большая: вам нужно исправить какой-то HTML, посмотреть CSS или настроить его в генераторе.
Все круто, но нужно поговорить с другими участниками процесса, которые задействованы в генерации.
Про генерацию прерывания и дискуссии. (Здесь ссылка на фрагмент видео с вопросами и ответами. — Ред.)
Давайте, Юля, как все мы, расскажет об организации процессов.
— Все решили и пошли со всеми договариваться. Для этого мы подготовили свои требования к тому, что мы хотели бы получить. Во-первых, мы хотели бы получить доступ к репозиторию разработчиков. Также нам нужны были общие руководства по написанию комментариев в коде и согласованная схема работы с репозиторием, а также независимость от загрузки переводчика.Зачем нам все эти точки? Поговорим о каждой детали.
Зачем нужен доступ к репозиторию? Во-первых, это погружение в проект, вы всегда будете на одной волне с разработчиками, в тренде, и в целом продукт проще описать, когда вы его понимаете.
Также доступ помогает нам отслеживать некоторые изменения в проекте, если произошло что-то новое или наоборот, изменилось. Доступ к репозиторию дает нам возможность редактировать и писать комментарии в коде.
Что дают общие руководства? Во-первых, единый стиль, писатель сразу берет и смотрит на наши страницы, о которых говорил Эндрю, берет эту структуру и занимается документацией.
Общее руководство позволяет снизить порог входа для нового технического писателя. Писателю не нужно много разбираться в нюансах, синтаксисе, он смотрит, как это расположить, проверяет разметку, и он пишет, обращает внимание на то, что делает этот класс или метод, и не увяз в синтаксисе комментариев.
Поскольку все это стандартизировано, все это хорошо сгенерировано и переведено. Есть определенный набор дескрипторов, который мы согласовали с командой разработчиков нашей системы перевода, и когда мы отправляем комментарии на перевод, сразу становится ясно, что эта конструкция пришла с такого языка, и ее нужно обрабатывать таким образом, а не другим.
Что делает схема сотрудничества? Самое главное — это защита исходного кода, у нас всегда есть чистый мастер, и это защищает писателя от непредвиденных ошибок, коммитов, подталкивания, случайных слияний с разработчиками.Это удобная система обзора. Поскольку мы работаем в gita и используем Bitbucket, для нас это выглядит примерно так. Например, комментируя pullrequest.
Автор отправляет pullrequest и немедленно вызывает разработчика, и вы можете прокомментировать каждую строку кода в диалоговом режиме. В дальнейшем все это сохраняется. Если у вас что-то пошло не так, возник какой-то конфликт, вы всегда можете сослаться на это все, все это хранится в репозитории, вся эта переписка, и понять, где вы отошли от темы, что сделали не так.Все это очень удобно просматривать, меняется, где что изменено, удалено, добавлено.
Еще один момент, который мы хотели получить, — это независимость от загрузки переводчика.
Наша основная цель — чтобы цикл выпуска SDK был коротким, одна-две недели, а переводчик один на несколько проектов, он просто физически может не успевать переводить. И на таком девелоперском английском обычно пишут разработчики хоть немного, и если вам срочно нужен релиз сегодня и сейчас, то мы выпустим библиотеку, соберем как есть, а потом передадим редактору или переводчику для пост-чтения. .
После этого мы решили определиться, у кого будут роли и сценарии. Выделили две команды. Первый — это разработчик, техник и переводчик, в данном случае это разные писатели с разными навыками.
Есть технический писатель, который пишет по-русски и может переводить с английского языка разработки на русский. Но сам на чистом английском писать не будет. Он в основном составе.
А есть вторая команда, где уже разработчик, регистратор и редактор, здесь регистратор пишет на английском, просматривает комментарии разработчиков, публикует документацию, а потом редактор периодически ее зачитывает.
В первой команде разработчик дает исходный код, ставит нам задачи и уже просматривает наши дальнейшие комментарии.
Техник переводит с английского на русский язык разработки. Если комментариев мало, он пишет их на русском языке. А потом отдает переводчику на перевод.
Второй вариант, когда техник пишет на английском, разработчик делает то же самое, дает исходный код, ставит задачи и уже просматривает наши правки.Технический писатель здесь выполняет немного другую работу. Если есть комментарии на английском языке, он исправляет их лингвистически на более нормальный английский язык и добавляет больше комментариев, если что-то описано не очень хорошо или плохо. А затем он переводит все свои английские комментарии на русский, чтобы появилась русская версия документации. Тут вместо переводчика уже идет редактор, он его зачитывает, а мы обновляем релиз.
Мы работаем с git, поэтому есть несколько вариантов работы там.
Это работа с вилками и ответвлениями. У нас есть команды, которым нравится и тот, и другой вариант. Но поскольку мы не диктатура, мы решили поддержать все эти варианты и договориться о том, как мы будем их использовать.
У нас есть два сценария, но мы их немного расширили, учитывая тот факт, что некоторые технические специалисты пишут на английском, а некоторые на русском. Мы рассматриваем схему с вилкой, когда писатели пишут по-русски, и схему с веткой, когда писатели пишут по-английски.
Есть dev от разработчиков, берем у него форк (fork-dev) и настраиваем синхронизацию, чтобы релизы приходили к нам. После этого делаем бранч с английским языком, назовите его doc-dev-en, как хотите. Если есть что сгенерировать, а калька не к чему, берем и сразу собираем англоязычную версию документации, которая идет из исходников.
После этого форкнем русскую ветку (doc-dev-ru) и ветку с номером проблемы из форка (fork-dev).Начинаем с ним работать, писать недостающие комментарии или вносить какие-то изменения. Сделаем это. После того, как мы готовы к финальному шагу, делаем pullrequest в нашей ветке doc-dev-ru, там вызываем разработчиков. Разработчики все это просматривают, смотрят, мы как-то обсуждаем с помощью того же pullrequest, и в итоге апрувят.
После слияния мы готовы собрать русскую версию документации. После слияния кода с правками в английскую ветку (doc-dev-en).Потом ставим пазл на переводчика, он переводит, сливаем в нашу английскую ветку (doc-dev-en), которая всегда существует, и собираем англоязычную документацию. После этого мы готовы к решающему шагу, и делаем forkquest в нашей вилке (dev-dev). Там мы призываем разработчиков убедиться, что нигде ничего не сломано, что мы только что исправили комментарии в коде и больше ничего не сломали. Разработчики все смотрят, апрувят, а мы делаем слияние. А потом поднимаемся на очень высокий уровень, делаем pull-quest в dev разработчикам.Смотрят, проверяют, тоже апрувят, а мы делаем.
После этого возвращаемся к нашему форку (fork-dev), и так как писатель пишет по русски, то у него русская основная ветка. Нам нужно сделать слияние из нашего форка (fork-dev), в котором есть английские комментарии, в нашу русскую ветку (doc-dev-en), где Russian. Именно на этом этапе у нас будут конфликты, и нам нужно будет принимать русские комментарии вместо английских, чтобы в следующем выпуске мы не зацикливались на наших правках, и приходили только новые комментарии от разработчиков.После этого нужно удалить, удаляем наши ветки с номерами задач.
Схема с вилкой, когда писатель пишет на английском, выглядит так. Есть дев, будет форк (dev-dev) с автосинхронизацией, русская (doc-dev-ru) и английская (doc-dev-en) ветка. Но теперь писатель будет работать в основном в английской ветке (doc-dev-en), а русская (doc-dev-ru) ветка будет побочной. И здесь мы вызываем редактора, а не переводчика.
В схеме бранча писатель будет писать на английском языке.У нас тоже есть dev от разработчиков, но теперь мы используем не ветку, а ветку (dev). Создаем из него бранч на русском языке (branch-dev-ru), а после этого создаем бранч на английском языке (branch-dev). В нем мы будем работать, потому что пишем по-английски. Собираем документацию из того, что есть. Если есть — ну, если нет — будет хоть какая-то калька, скелет, чтобы было видно, где какой метод используется, какие параметры у него есть.
Делаем из него бранч с номером задачи, редактируем, редактируем все.После того, как мы готовы, мы отправляем pullrequest в нашу основную ветку (dev-dev) и вызываем разработчика туда. Разработчик все это проверяет, просматривает и пересматривает в конце, а мы собираем документацию на английском языке и публикуем ее.
После этого мы готовы сделать pullrequest разработчикам. Сделали, посмотрели, все нормально, опять завели, улыбнулись. А потом можно будет поставить себе пазл для перевода.
Сливаем наши английские комментарии в русскую ветку (ветка-dev-ru), потом оперативно переводим в ветку с номером задачи, сливаем в русскую ветку (ветка-dev-ru), чтобы был перевод .Собираем русскую документацию.
Затем можно поставить задачу на чтение. Перешли на английский бранч (branch-dev), сделали бранч с номером проблемы и передали в редакцию. Редактор все прочитал, поправил и в целях защиты себя и редактора делаем pullrequest, вызываем туда разработчиков, они смотрят, все в порядке, извиняются, объединяем и забираем уже прочитанный англоязычный документ из редактора . После этого делаем pullrequest разработчикам, они смотрят, апрувы и делают.И после того, как мы завершили этот цикл выпуска, мы удаляем наши ветки с номерами задач.
Схема бранча, когда писатель пишет по-русски, выглядит примерно так же, но здесь приоритетной и основной ветвью для работы будет русский, английский будет второстепенным. Вместо редактора будет переводчик.
Как понять, что нужно, а что кому-то лучше? Разумеется, вам понадобится вилка, если вы используете git. Также, если вы хотите всегда иметь текущего мастера. Форк помогает с автосинхронизацией.В принципе, это всегда безболезненно, но если затронуты какие-либо серьезные модули, вам нужно будет вручную выполнить слияние с конфликтами. Но в основном там все идет само собой. Что ж, вы не любите решать конфликты, тогда это ваше дело.
И вам нужен бранч, если вы также используете git, вам нравится все контролировать, потому что, когда выйдет новый релиз, он не будет втягиваться в ваш основной бранч, вам нужно будет вручную загрузить его туда.
А вы любите решать конфликты, потому что их может быть больше.Эти схемы со стороны выглядят громоздко. Но стандартный цикл выпуска занимает около недели. И к такой схеме работы сразу привыкаешь быстро. И в целом наша визуализация выглядит так при работе с репозиторием, она красивая и выглядит как фейерверк.
— Каждая точка является фиксацией. Если есть ветка — это бранчи.
Мы переходим к основным выводам отчета. Объединение. Чем раньше вы начнете объединяться, тем лучше. Понятно, что если вы заранее договорились, вы все обсудили на берегу, то процесс пойдет намного быстрее, вам не придется возвращаться и думать о том, как исправить документацию, как перенести это в свой новый шаблон, и т.п.
Не забывайте, что серебряных пуль не бывает. Это касается и генератора. Не всегда универсальный генератор подходит для всего. То же относится и к некоторым процессам. Вы не можете думать об одном процессе, чтобы его можно было легко растянуть на что-либо в вашем отделе или группе.

1.3.13 (21.07.2021)	Добавили обработку сел и поселков при поиске вариантов доставки
1.3.12 (01.07.2021)	Исправление ошибки при открытии виджета
1.3.11 (18.06.2021)	Исправили ошибку сохранения результата расчета, когда профиль доставки был служебный Переделали отправку комплектов
1.3.10 (10.06.2021)	Оптимизировали скорость получения вариантов доставки Поправили js ошибки в списке заказов Доработали работу со статусами Правки для бета-версии модуля sale выше 21 версии
1.3.9 (26.05.2021)	Добавили обработку ошибки при изменении состава заказа или местоположения, из-за которых опция доставки становилась не доступна Доработали вывод ошибок Расширили выбор полей для артикула Добавили возможность просмотра информации из ЛК Доставки на вкладке заказа и ручное обновление статуса заказа при запросе подробной информации Доработали обработку статусов отправлений
1.3.8 (07.05.2021)	Исправили расчет размеров коробки при создании заказа Добавили сохранение интервала времени доставки для курьеров Исправили отправку артикула
1.3.7 (28.04.2021)	Если почта или пункт выдачи почта онлайн, оценочная стоимость 100% Добавили сохранение трек номера в заказе Исправили ошибку в списке заказов, если удалил отгрузку вручную
1.3.6 (20.04.2021)	Исправили запись логов виджета Добавил кнопку «скопировать» в логах Модификация хранения результата калькуляции Исправили сохранение ограничения по типам пользователей Изменили запрос поиска вариантов доставок Обработка ошибок при оформлении заказа в Яндекс.Доставку
1.3.5 (31.03.2021)	Добавили в настройках модуля опцию: «Не показывать службы доставки, когда не нашли вариантов» Исправили ошибку определения полного адреса при отправке заказа При использовании базовой упаковки товары не передаются отдельными позициями для обхода ограничения в 100 товаров Исправили ошибку сохранения отгрузки и калькуляции отгрузки
1.3.4 (25.03.2021)	Добавили в журнал событий фильтр по типу события Добавили открытия виджета при смене доставки Исправили ошибку заполнения адреса самовывоза для некоторых браузеров Исправили ошибку отправки письма о новом заказе Исправили ошибку вызова виджета с дробным количеством товара
1.3.3 (16.03.2021)	Добавили возможность отмены заказа со статусом «черновик» Добавили агента, для очистки служебных таблиц Добавили возможность переходить в заказ в кабинете Яндекс.Доставке
1.3.2 (15.03.2021)	Исправлен запрос на поиск вариантов доставки с учётом оплаты
1.3.1 (09.03.2021)	Исправление ошибки с определением типа доставки
1.3.0 (04.03.2021)	Добавили упаковку в настройках службы доставки; Добавили обработку платежных систем в настройках модуля; Добавили сопоставление статусов Яндекс.Доставки со статусами заказа; Исправили ошибку разбиение ФИО на раздельные поля; Исправили определение города в виджете, если в местоположениях не заданы коды; Добавили сохранение статуса и название ТК в свойства заказа; Добавили агента для обновления статуса доставки.
1.2.10 (01.02.2021)	Добавили сопоставление поля комментарий для отправки в Яндекс.Доставку
1.2.9 (01.02.2021)	Добавили в настройках модуля сопоставление полей заказа на сайте с полями кабинета Яндекс.Доставки.
1.2.8 (23.01.2021)	Доработали логику передачи типа оплаты
1.2.7 (21.01.2021)	Правка ошибки связанная с номером заказа
1.2.6 (19.01.2021)	Включили поддержку комплектов и наборов
1.2.5 (13.01.2021)	Исправление ошибки на старых версий битрикса.
1.2.4 (12.01.2021)	Добавили обновление статуса заказа на агенте Исключили адрес при создание черновика, если профиль доставки «самовывоз» Автоматическое обновление трек номера заказа
1.2.3 (18.12.2020)	Исправлена проблема с кодировкой ответа расчета вариантов доставки в частных случаях Исправлена проблема обновления статуса отгрузки по конкретным заказам
1.2.2 (17.12.2020)	Исправлено создание черновиков для предоплаченных заказов. Исправлена редкая проблема кодировки адреса. Удалено ограничение полей ответа от API при расчете вариантов доставки
1.2.1 (11.12.2020)	Исправление отправки полного адреса
1.2.0 (10.12.2020)	Оформление заказов в Яндекс.Доставка; Печать ярлыков Яндекс.Доставка; Расчёт коробки для заказа; Добавили трек номер в отгрузке.
1.1.6 (02.12.2020)	Исправлена ошибка вывода кнопки «Создать черновик» в заказе; Убрали вывод вкладки «Яндекс.Доставка» в заказе, если доставка не Яндекс.
1.1.5 (02.12.2020)	Убрали некорректную отправку размеров в черновиках; Исправили выбор порта, на некоторых серверах выбирался неправильный порт; Исправили округление размеров для расчета доставки; Оценочная стоимость по умолчанию 100, если ничего не задано.
1.1.4 (25.11.2020)	исправлена ошибка при выборе службы доставки Курьер заполнялся адрес; исправлена ошибка при смене профиля в доставке, выбирался не правильный профиль; добавили в передачу товаров ставку НДС.
1.1.3 (19.11.2020)	Доработана отправка полного адреса в черновике;
1.1.2 (18.11.2020)	В новой версии мы исправили: Исправлена ошибка формирования URL при запросе токена на некоторых серверах; Исправлен выбора чекбоксов в документа.
1.1.1 (13.11.2020)	В новой версии мы исправили: ошибку при выборе ПВЗ ; ошибку при отправке черновиков. Спасибо, что с нами!

Язык	Код	Язык	Код
Азербайджанский	az	Малаялам	мл
Албанский	sq	Мальтийский	mt
Амхарский	am	Македонский	mk
Английский язык	en	Maori	mi	арабский	ar	маратхи	mr
армянский	hy	мари	mhr
африкаанс	af	монгольский	mn
баскский	немецкий eu	de
Башкирский	ba	Непальский	ne
Белорусский	be	Норвежский	нет
Бенгальский	млрд	Пенджаби	pa
Бирманский мой	Papiamento	pap
Болгарский	bg	Персидский	fa
Боснийский	bs	Польский	pl
Валлийский	cy	Португальский	pt
Венгерский	hu	Румынский	ro
Вьетнамский	vi	Русский	ru
Гаитянский (креольский)	ht	Себуано	ceb
Галицкий 9008 3 gl	сербский	sr
голландский	nl	сингальский	si
Hill Mari	mrj	словацкий	sk
греческий	el	словенский	sl
Грузинский	ka	Суахили	sw
Гуджарати	gu	Суданский	su
Датский	da	Таджикский	tg
Иврит	Тайский	th
Идиш	yi	Тагальский	tl
Индонезийский	id	Тамильский	ta
Ирландский	ga	Тартар	tt
Итальянский 900 82	it	телугу	te
исландский	is	турецкий	tr
испанский	es	удмуртский	udm
казахский	kk	узбекский	uz
Каннада	kn	Украинский	uk
Каталонский	ca	Урду	ur
Киргизский	ky	Финский	fi
Китайский	французский	fr
корейский	ko	хинди	привет
Xhosa	xh	хорватский	hr
кхмерский	km	чешский	cs
Лаосский 900 82	lo	Шведский	sv
Латинский	la	Шотландский	gd
Латвийский	lv	Эстонский	et
Литовский	lt	Эсперанто	eo
Люксембург	фунтов	яванский	jv
малагасийский	мг	японский	ja
малайский	ms

Написать разработчикам яндекс: 404 — Яндекс.Почта

Техподдержка Яндекс Музыки, как написать в службу поддержки

О сервисе

Как написать в службу поддержки Яндекс Музыки?

Социальные сети

Какой телефон горячей линии Яндекс Музыки?

Для каких случаев предназначена служба поддержки?

В каком случае поддержка не сможет помочь?

Связь с техподдержкой через личный кабинет

Как написать жалобу?

Время работы

Служба поддержки Яндекс Маркет: телефоны, как написать жалобу?

О сервисе

Телефон горячей линии Яндекс Маркет

Адреса пунктов выдачи

Как написать в службу поддержки?

Социальные сети

Обращение в поддержку через личный кабинет

Для каких случаев нужна служба поддержки?

В каком случае поддержка не сможет помочь?

Как написать жалобу?

Время работы

Вакансии компании Яндекс — работа в Москве, Санкт-Петербурге, Екатеринбурге, Ростове-на-Дону

Контакт-центр: Яндекс.Чат

Как подключить канал Яндекс.Чат

Проверка от Яндекса

Как это работает

Собеседование в Яндекс: театр абсурда :/ / Хабр

Интервью 1

Задача 1

Задача 2

Задача 3

Интервью 2

Задача 4

Задача 5

Интервью 3

Задача 6

Задача 7

Задача 8

Интервью 4

Задание 9

Задание 10

>> Сейчас я нахожусь здесь <<

К чему всё это

интервью с разработчиком, который вернулся работать в Россию

старший разработчик в Яндекс.Почте

— Александр, расскажите, как вы оказались в Лондоне?

— И вот вы оказались в Facebook и начали вливаться в рабочий процесс. Что можете рассказать про условия работы и атмосферу в компании?

— А можете поподробнее рассказать про то, чему вы научились, работая в Facebook?

— Судя по тому, что вы рассказываете, вам нравилось работать в Facebook. Почему тогда вы приняли решение уехать из Лондона?

— Какие конкретно задачи вы решаете в Яндекс.Почте?

Вы говорили, что в 2013 году, ещё до релокации в Лондон, уже работали в Яндексе. Как вам кажется, компания сильно изменилась с тех пор?

Если сравнивать работу в обеих компаниях, есть ли что-то такое в Яндексе, чего вам раньше не хватало в Facebook?

1С-Битрикс — Агрегатор Яндекс.Доставка

Загрузка файла (PUT) — API. Руководство разработчика

Обзор. Руководство разработчика

Безопасность | Стеклянная дверь

Nous aider à garder Glassdoor sécurisée

Unterstützen Sie uns beim Schutz von Glassdoor

Яндекс.Карт в App Store

Practicum от Yandex Blog

Что такое проверка кода?

Почему проверка кода имеет значение

Кто будет проверять ваш код?

Каких комментариев ожидать

Исправления ошибок

Рекомендации

Положительные комментарии

Как правильно выполнять анализ кода

Какие проблемы встречаются чаще всего?

Заключение

Примеры использования: Яндекс | Kotlin Multiplatform Mobile

Не могли бы вы сказать несколько слов о своей команде?

Как Kotlin Multiplatform Mobile используется в вашем продукте?

Почему ваша команда решила использовать Kotlin Multiplatform и какие альтернативы вы рассматривали?

Какие достижения и трудности были для вас наиболее значительными?

У вас есть какие-нибудь советы или рекомендации, которыми вы хотели бы поделиться с нашими читателями?

Хотели бы вы поделиться своей контактной информацией с нашими читателями?

Контакты

Новый взгляд на документирование API и SDK в Яндекс. Лекция по Hyperbaton / Sudo Null IT News