Привет! Меня зовут Дмитрий Пугачев, я помогаю развивать музей Яндекса, в котором наша команда собирает редкие и интересные экземпляры вычислительной техники. Недавно мы приглашали читателей Хабра посетить наш музей в рамках акции «Ночь музеев». Честно говоря, мы не ожидали, что из желающих зайти к нам в гости выстроится очередь «как за новым айфоном», а два геймпада и вовсе отправятся на ремонт после турнира по Mortal Kombat. И это вдохновило нас!

Сегодня я расскажу о нашей новой инициативе, ориентированной на сообщество любителей ретро-игр, — о конкурсе по разработке игр для легендарного ZX Spectrum. Насколько это актуально? В чём особенности именно этого устройства? Предлагаю вспомнить и обсудить.

Толока — крупнейший источник размеченных людьми данных для задач машинного обучения. Каждый день в Толоке десятки тысяч исполнителей производят более 5 миллионов оценок. Для любых исследований и экспериментов, связанных с машинным обучением, необходимы большие объёмы качественных данных. Поэтому мы начинаем публиковать открытые датасеты для академических исследований в разных предметных областях.

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

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

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

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

Поэтому я не буду публиковать разборы всех 24 задач. Вместо этого я разберу шесть задач одного из квалификационных вариантов: другие решаются похожим образом.

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

Пользователи ClickHouse знают, что его главное преимущество — высокая скорость обработки аналитических запросов. Но как мы можем выдвигать такие утверждения? Это должно подтверждаться тестами производительности, которым можно доверять. О них мы сегодня и поговорим.



Такие тесты мы начали проводить в 2013 году, задолго до того, как продукт стал доступным в опенсорсе. Как и сейчас, тогда нас больше всего интересовала скорость работы данных сервиса Яндекс.Метрика. Мы уже хранили данные в ClickHouse с января 2009 года. Часть данных записывалась в базу с 2012 года, а часть — была переконвертирована из OLAPServer и Metrage — структур данных, которые использовались в Яндекс.Метрике раньше. Поэтому для тестов мы взяли первое попавшееся подмножество из 1 миллиарда данных о просмотрах страниц. Запросов в Метрике ещё не было, и мы придумали запросы, больше всего интересные нам самим (всевозможные виды фильтрации, агрегации и сортировки).

ClickHouse тестировался в сравнении с похожими системами, например, Vertica и MonetDB. Для честности тестирования его проводил сотрудник, который до этого не был разработчиком ClickHouse, а частные случаи в коде не оптимизировались до получения результатов. Похожим образом мы получили набор данных и для функциональных тестов.

После того, как ClickHouse вышел в опенсорс в 2016 году, к тестам стало больше вопросов.

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

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

Всем привет. Коллеги недавно писали в этом блоге, что открылась регистрация в следующую Школу разработки интерфейсов в Москве. Я очень рад новому набору, ведь я был одним из тех, кто придумал Школу в 2012 году, и с тех пор постоянно ей занимаюсь. Она эволюционировала. Из неё вышло целое мини-поколение разработчиков с широчайшим кругозором и способностью взять на себя в проектах вообще всё, что связано с фронтендом. Кто-то из выпускников работает в Яндексе, кто-то нет.



ШРИ — как сервис: тоже требует разных форматов взаимодействия, автоматизации и экспериментов. Вот об этом и поговорим сегодня на Хабре. Будут и полезные ссылки для кандидатов.

При локализации сервиса важно внимательно отнестись к согласованию переводов между собой. Руководитель группы клиентской Android-разработки Яндекс.Такси Александр Бонель рассказал, какие практики и инструменты упрощают локализацию. Во второй части доклада Саша поделился опытом поддержки языка RTL в приложении: что хорошо, а что не совсем работает у Андроида из коробки, какие проблемы возникают из-за поддержки RTL и как их минимизировать в будущем.


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

Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.

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

Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.

Привет, меня зовут Василий Богонатов. Я один из тех, кто приложил руку и голову и вложил свою душу в сервис распределённых персистентных очередей сообщений Yandex Message Queue. Сервис вышел в общий доступ в конце мая, но внутри Яндекса он уже давно и активно используется в разных продуктах.

Сегодня я хочу рассказать читателям Хабра об очередях сообщений вообще и о Yandex Message Queue в частности. Сначала я хочу объяснить, что такое «распределённая персистентная очередь сообщений» и зачем она нужна. Показать её практическую ценность, механику работы с сообщениями, поговорить про API и удобство использования. Во второй половине материала мы посмотрим на техническую сторону: как в наших очередях используется Yandex Database (это надежный фундамент нашего сервиса), как выглядят наивный и улучшенный подход к построению архитектуры, какие проблемы вызывает распределённость и как их можно решить.

В мобильных приложениях всё чаще используются deep links. Это ссылки, которые позволяют не просто перейти в приложение извне, а попасть на конкретный экран. Android-разработчик из Яндекс.Еды Владислав Кожушко объяснил, почему мы для реализации deep links внедрили навигацию из Jetpack, с какими проблемами столкнулись, как их решили и что получилось в итоге.


— Всем привет! Меня зовут Влад. Android-разработкой я интересуюсь с 2013 года, в Яндекс.Еде работаю с лета прошлого года. Я расскажу про наш путь внедрения библиотеки Navigation Components в боевое приложение.

Привет! Меня зовут Кристина lapkina Кочерина, я тестировщик в Яндекс.Маркете. Еще полгода назад у меня был статус адвоката и большая юридическая практика, вечера я проводила в СИЗО. Но в какой-то момент решила, что пришло время заниматься тем, что приносит удовольствие, а не только деньги. И кардинально сменила профессию.

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

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

Когда-то я был младшим разработчиком и ужасно не любил слово «процессы». Все эти регулярные встречи и прочее общение казались глупостями, отвлекающими от содержательной работы (написания кода, конечно). Думаю, такой этап случался в жизни у каждого, кто занимался разработкой; но такому этапу полезно повторяться регулярно: любую деятельность можно оптимизировать (например, вообще отменив), и иногда ощущение бессмысленности происходящего оказывает поистине целебное действие.

Мы решили посвятить процессам разработки наш следующий Team Leader Meetup, который пройдёт вечером 17 июня в московском офисе Яндекса. Регистрация открыта!

Нашими экспертами согласились быть:

• Анатолий anatolix Орлов, CTO, Ozon
• Алексей Катаев deusdeorum, Head of Software Development, SkyEng
• Александр Гутман, CTO, JoomPay
• Евгений Парамонов, руководитель разработки поисковых подмешиваний, Яндекс
• Андрей Плахов yafinder, руководитель отдела функциональности поиска, Яндекс

Сегодня они отвечают на некоторые вопросы, чтобы подготовить будущую дискуссию:

1. На какой основе построены процессы у вас в компании?
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»

Под катом — много огня, сарказм в адрес авторов вопросов, максимально различные мнения и, конечно, страшные истории.

Сегодня открылся новый набор в Школу разработки интерфейсов Яндекса в Москве. С 7 сентября по 25 октября пройдёт первый этап обучения. Студенты из других городов смогут в нём поучаствовать дистанционно или очно — компания оплатит дорогу и проживание в хостеле. Второй, он же финальный этап продлится до 3 декабря, его можно пройти только очно.

Меня зовут Юлия Середич, этот пост мы написали вместе с Сергеем Казаковым. Мы оба разработчики интерфейсов в минском офисе Яндекса и выпускники ШРИ прошлых лет.



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

В большом проекте может возникнуть задача идентификации изменений для конечного пользователя по отличиям в коде фронтенда приложения. Разработчик из Яндекс.Маркета Никита Сидоров @nickshevr рассказал, как мы решали эту проблему при помощи библиотеки Diffector, о построении и анализе графа модулей в Node.js-приложениях и о поиске дефектов в коде до его запуска.



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

Меня зовут Артём Несмиянов, я фулстек-разработчик в Яндекс.Практикуме, занимаюсь в основном фронтендом. Мы верим в то, что учиться программированию, дата-аналитике и другим цифровым ремёслам можно и нужно с удовольствием. И начинать учиться, и продолжать. Любой не махнувший на себя рукой разработчик — всегда «продолжающий». Мы тоже. Поэтому рабочие задачи воспринимаем в том числе как формат учёбы. И одна из недавних помогла мне и ребятам лучше понять, в какую сторону развивать наш фронтенд-стек.

Кем и из чего сделан Практикум

Команда разработки у нас предельно компактная. На бэкенде вообще всего два человека, на фронтенде — четыре, считая меня, фулстека. Периодически к нам в усиление присоединяются ребята из Яндекс.Учебника. Работаем мы по Scrum с двухнедельными спринтами.

Как работать с изображениями на клиенте, сохраняя плавность UI? Разработчик интерфейсов Павел Смирнов рассказал об этом на основе опыта разработки поиска по фотографиям на Маркете. Из доклада можно узнать, как правильно использовать Web Workers и OffscreenCanvas.



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

Мы верим, что в будущем люди будут управлять своим домом с помощью голоса, а не кнопок. Поэтому сегодня Яндекс представляет платформу умного дома, которая позволит зажечь свет, убавить температуру на кондиционере, переключить телевизор на другой канал или даже сварить кофе — с помощью Алисы.

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

При выполнении запросов в ClickHouse можно обратить внимание, что в профайлере на одном из первых мест часто видна функция LZ_decompress_fast. Почему так происходит? Этот вопрос стал поводом для целого исследования по выбору лучшего алгоритма разжатия. Здесь я публикую исследование целиком, а короткую версию можно узнать из моего доклада на HighLoad++ Siberia.

Данные в ClickHouse хранятся в сжатом виде. А во время выполнения запросов ClickHouse старается почти ничего не делать — использовать минимум ресурсов CPU. Бывает, что все вычисления, на которые могло тратиться время, уже хорошо оптимизированы, да и запрос хорошо написан пользователем. Тогда остаётся выполнить разжатие.



Вопрос — почему разжатие LZ4 может быть узким местом? Казалось бы, LZ4 — очень лёгкий алгоритм: скорость разжатия, в зависимости от данных, обычно составляет от 1 до 3 ГБ/с на одно процессорное ядро. Это уже существенно больше скорости работы дисковой подсистемы. Более того, мы используем все доступные ядра, а разжатие линейно масштабируется по всем физическим ядрам.

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

В этом году мы присоединяемся к всероссийской акции «Ночь музеев» и приглашаем читателей Хабра в гости. В ночь с 18 на 19 мая, каждые полчаса с 20:00 до 5:30, мы будем водить экскурсии по постоянной экспозиции. Сотрудники Яндекса, профессионально занимающиеся или просто фанатично преданные ретротехнике, расскажут об экспонатах и буднях программистов прошлого.

Под катом коротко расскажем про некоторые наши ретрокомпьютеры и забавные факты из их истории. А ещё вы узнаете про другие активности, которые мы подготовили для наших гостей. В том числе для тех, кто помнит Mortal Kombat 3.