company_banner

«Эволюция разработки» // Доклады с Форума технологий Mail.Ru 2011: текст доклада, видео, презентации

    Докладом «Эволюция разработки» открываю серию расшифровок с Форума Технологий Mail.Ru 2011. Данная расшифровка была получена в день мероприятия, 16 ноября 2011 года. Подробности о том, как работает система расшифровки докладов — см. в статье «Изнанка» Форума технологий Mail.Ru: Хай-тек в event-management


    (Скачать видеоверсию для мобильных устройств – iOS/Android H.264 480x368, размер 204 Mb, видеобитрейт 500 кбит/с, аудио — 64 кбит/с )
    (Скачать видеоверсию большего разрешения H.264 624x480, размер 610 Mb, видеобитрейт 1500 кбит/с, аудио — 128 кбит)
    (Скачать слайды презентации, 2Mb)

    Вступление вице-президента Mail.Ru Group, технического директора Габриеляна Владимира
    — Коллеги, я надеюсь, что вам понравился обед. Сытые, добрые, довольные. Напишите в «Твиттер». На самом деле я хочу представить нашего следующего докладчика. Знаете, в каждой компании есть человек, которого можно назвать «Мистер «Я знаю как», человек, который находится в курсе всех технологий, человек, который имеет очень правильное визионерское мышление, и он во многом определяет нашу технологическую политику в «Mail.ru Group». Это Игорь Ермаков, заместитель технического директора, то есть меня. Игорь сегодня расскажет нам о том, как мы эволюционировали в наших технологиях на протяжении 13 лет, и, если вы внимательно будете слушать этот доклад, он на самом деле поможет вам перескочить те этапы развития, которые мы уже прошли, и сразу перейти к тем технологиям, которые мы используем в Mail.Ru. Игорь!





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



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



    Экскурс в историю. 98-й год, начало Mail.Ru, классический LAMP-проект, Perl, C, Apache 1.3., куда же без него, классика, и mod_perl. Храним данные в MySQL, умные слова: Nginx, NoSQL — таких тогда еще не было. Большинство веб-проектов строилось на базе указанных технологий.

    На скриншотиках — наши первые дизайны. Может быть, помнит кто-нибудь? Даже вот дизайн с нашим осьминогом. Да, первый дизайн с осьминогом.



    ХРАНЕНИЕ ДАННЫХ



    MySQL, почему MySQL? Мы не говорим о других хранилищах, потому что классический веб-проект строился тогда на MySQL. Безусловно, почта имеет свой сервис для хранения писем, первые версии были написаны еще в то время. Данные писем хранить в базе крайне неэффективно. Я знал один такой почтовый сервис, он очень плохо кончил. Они хранили все письма в базе. Все помнят его плюсы — дешевизна, простота, по сравнению, конечно, с большими корпоративными решениями, для обычного веб-девелопера — бесплатный, было довольно много документации. Тем не менее он был привычный, потому что он строился на каком-то подножии MySQL. Все помнят, что MySQL на плоских табличках показывал довольно высокую производительность, большое ему спасибо. Но тем не менее был набор минусов. Как раз хочу поговорить о части минусов — это неуправляемый кэш, это сброс Query-кэша при обновлении таблиц.



    И казалось бы, когда у нас есть проблема с базой данных и хорошо бы сейчас отменить жесткие диски и положить все в HEAP. Но реализация HEAP-таблиц была просто ужасна в MySQL, и остается очень медленной. Соответственно, решение, которое было тогда у всех в голове — положить все в память, появляется memcached. Что он нам дает? Он дает очень эффективное кэширование, очень быстрое хранение и доступ к данным в памяти. Очень простой и выполняет всего лишь одну функцию. И довольно часто, несмотря на то что memcached — это все-таки хэш, и он не обязан хранить данные, memcached начинает использоваться как некое хранилище данных. Это плохо, поскольку memcached — это не хранилище данных. Он не обязан помнить то, что вы в него положили, он может в любой момент удалить ключ, даже если он не прокэшировался. Самое главное — все в памяти. Если у вас что-то случилось с данными, с машиной, все — вы данные потеряли, и где их брать — неизвестно, откатиться некуда. Безусловно, хорошее решение — было бы просто взять и получить, с одной стороны, хоть какую-нибудь надежность данных уровня MySQL и скорострельность уровня memcached. Помню был такой проект MemcacheDB, ужасно медленный, все тормозило, не тянул. В итоге появляются несколько решений, которые мы называем: NoSQL.



    NoSQL. Они принесли нам производительность, отсутствие лишнего функционала, которым были обременены реализационные базы данных. Некоторые из них уже предлагают решения «из коробки» для масштабируемости, для автоматической масштабируемости, ну и богатство выбора. Костя рассказывал о нашем «Тарантуле», наверняка сравнивал с Redis-ом, многие знают Apache Cassandra, MongoDB, это всевозможные NoSQL-решения, которые покрывают те или иные проблемы.

    Мы, соответственно, используем в основном, не в почте даже, а в портале, Tarantool/BOX, нашу разработку, Костя об этом много рассказывал.

    ЯЗЫКИ РАЗРАБОТКИ: SERVER-SIDE



    Поговорим о языках разработки. Обратно в прошлое — у нас С++ , Perl, где-то в окружающей среде используется С#, Java, PHP, ASP.NET, все технологии прекрасны, хороши, со временем появляются новые языки Python и Ruby.



    Хотя, сказать что только появляются  — это несколько обмануть, потому что, Python, если мне не изменяет память  — это 1990-й год, Ruby — это 1995-й, по-моему. Но набирают они свою популярность, если мы говорим о России, скорее благодаря фрэймворкам, которые написаны на них, и позволяют быстро и эффективно разрабатывать ваши аппликэйшены, Python — это Django, Ruby — это Ruby-on-Rails.



    Самое интересное в фреймворках — то, что они вовлекают разработчиков в работу над этими самыми фреймворками, и тем самым разработчики начинают улучшать, улучшать, то есть такой снежный ком.

    Что в итоге, к чему мы приходим сейчас в Mail.Ru? Сейчас Mail.Ru — это языки, компилируемые: C++, безусловно это Perl, у нас очень много кода на Perl, мы его продолжаем поддерживать, это Java, Роман сейчас рассказывал — у нас есть код на Java. Мы пишем C#, мы пишем на Python, мы пишем на Ruby, Objective C мы тоже используем, если кто спрашивал Костю в кулуарах, он наверно рассказывал, почему мы в Tarantool используем Objective C.



    С одной стороны, кажется, что это зоопарк технологий, кажется, что у нас очень много решений и нет какой-то единой стратегии. Но, с другой стороны, я хочу вам сказать, что каждая из этих технологий оправдана. Каждая из них решает какую-то свою задачу и довольно идеальна в применении. И в развитии нашей компании произошло некоторое изменение при наборе новых кадров, у нас теперь требования к программисту… Мы очень не любим некого «холивара», когда приходят разработчики и говорят: «Вы знаете, я не люблю PHP, потому что это „отстой“, а Python это круто, потому что это модно». И вот в этот момент у нас на собеседовании загорается такая некая лампочка, говорящая о том, что, наверное, с этим человеком есть проблемы, потому что есть набор инструментов, который нужно использовать в нужный момент в нужное время, и мы относимся к языкам программирования именно как к инструментам: давайте их использовать именно там, где они нужны, а не потому, что они нам нравятся.



    РАЗРАБОТКА НА «КЛИЕНТЕ»



    Девяносто первый год, появление HTTP, текстовые страницы, первый браузер, первый HTTP-запрос. На экране — мой самый любимый вопрос на собеседовании с веб-разработчиком: напишите мне простейший HTTP-запрос. Очень часто разработчики начинают мне писать что-то из HTTP 1.1, из HTTP 1.0 с кучей всяческих заголовков. Я всего лишь прошу пять символов и перевод строки. В общем-то все современные веб-серверы, которые я знаю, они все отлично поддерживают 0.9 протокол. Девяносто второй год, появление одного из текстовых браузеров Lynx, а чуть позже это Netscape Navigator 3 и Internet Explorer 3. Может быть, кто помнит, это уже были мощные графические браузеры, которые позволяли показывать тот самый HTML 3.0.



    Конец девяностых — это как раз появление Mail.Ru, это уже HTML, Dynamic HTML, JavaScript, IFrame, который нам приносит первую возможность асинхронной работы с клиентом на клиент-стороне.



    То есть, мы получаем в свои руки технологию, которая позволяет не перегружать страницу, обновлять данные, не перегружая страницу. Microsoft, кстати, впервые использовал ее, если я  правильно помню, для обновления котировок акций на одном из своих сервисов. Чуть позже в IE5 появляется XMLHTTP Control. Спасибо большое Microsoft, они нам проторили дорожку AJAX-у. Опять же, нарастает популярность Flash. Flash приносит некую простоту и богатство в отображение на клиенте. Ну и переломный момент — появление каскадных таблиц стилей, который Наводит некий порядок в том, как разрабатываются новые веб-сайты.



    Середина 2000-x — это уже новейшая история, появление WebKit, спасибо Apple. Они радеют за HTML5. WebKit приносит нам Canvas-элемент, это в общем-то начало HTML5. Это уже во всю AJAX со всеми его плюшками и полезностями. Появление, наконец-то, Mozilla Firefox, который рождался на движке Gecko, и принес нам популярную сейчас технологию плагинов в браузере, FireBug, который позволил существенно ускорить веб-девелопмент. Я знаю, многие из вас работают не только с Firebug, есть и Developer Tools всевозможные. Появляются JS Frameworks. Вот о JS Frameworks и java-скриптах хочу поговорить отдельно. Изначально, как работает клиент-программист? Он получает макет в виде PSD или JPG файла, нарезает его, обворачивает HTML-обвязкой, может быть таблицы, если особо повезет, будут какие-нибудь дивы, все будет хорошо. Сначала мы начинаем JavaScript — это какие-то формы, это обработка форм, это их проверка. И постепенно, в какой-то момент JavaScript настолько усложняется, и становится понятно, что аппликейшн на стороне клиента зачастую гораздо больше, чем серверная сторона.



    Хорошо помню тот переломный момент, когда появились отдельные JavaScript-разработчики, отдельно вакансии людей, которые работают только над аппликейшном на стороне клиента. Опять же повторюсь, зачастую этот апликейшен, он гораздо сложнее, чем серверная сторона, которая подчас просто сохраняет какие-то данные на сервере, отдает их. Что мы имеем сейчас? Сейчас в общем-то не все так хорошо, как бы хотелось нам, как веб-разработчикам — стало больше браузеров, пять браузеров. Безусловно, для пользователя это здорово, каждый пользователь выбирает лучший браузер. Сейчас мы переживаем битву HTML 5 против Flash, в неком ее виде, не знаю кто победит, наверное, каждый из нас там болеет за кого-то, можно так сказать.



    Опять же расцвет JS-библиотек: Prototype, jQuery. Берите чего хотите и используйте. Наверное, на каждом втором сайте сейчас вы найдете какую-то одну из популярных библиотек. Вот. И продолжая дискуссию о JavaScript разработчиках, появляется довольно интересное явление: попытка поработать на JavaScript на серверной стороне. Появляется некая технология, под названием NodeJS, наверняка вы все о ней слышали, она позволяет строить сервера, писать на JavaScript. Что это нам дает? Кроссплатформенный код, мы можем писать на одном и том же языке и на клиентской, и на серверной стороне библиотеки, которые есть для клиента, какую то часть из них, мы можем использовать на сервере. Отличный объектный язык с простым синтаксисом, довольно понятным. Пример кода на JavaScript взятый с сайта NodeJS, который отдает некие реализации веб-сервера из семи строк.



    Технология довольно интересная, перспективная, по нашим тестам на наши производительности она не тянет, есть много проблем в движке, пока не получается на наших нагрузках. На чуть более меньших, может быть, еще живет, на наших — не живет. За эти десять лет довольно интересный результат: мы начинали с LAMP-проекта и за десять лет получается так, что весь пласт технологий меняется.



    Мы сейчас делаем новый проект, на нем мы не используем старых технологий вообще. Мы используем там событийный движок. Мы не стали брать MySQL, там его нет, там все базируется на NoSQL-базах. По нашим тестам, по нашим прогонам мы видим, что оно живет и работает, и строить сервис получается гораздо быстрее, чем даже мы предполагали.

    МОБИЛЬНАЯ РАЗРАБОТКА



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



    Странен он был тем, что никогда нельзя было угадать этом множестве телефонов, кто что поддерживает. Кто умеет картинки показывать, кто не умеет. Какого типа картинки умеет показывать, какого типа — не умеет. Поддерживается ли отправка форм или нет. Почему в какой-то минорной версии оно поддерживает, а в следующей перестало. При слабой возможности телефонов браузер был совсем никакой, процессоры были никакие, все было очень медленно и печально. Со временем появляется XHTML — он начинает поддерживаться встроенными браузерами. Довольно большой шажок от Microsoft в Windows Mobile. Это Internet Explorer, который худо-бедно парсит странички, парсит HTML, предлагает хоть какую-то поддержку JavaScript. Nokia со своей платформой 60. Opera сделала на этом рынке очень много. Они влезали и продолжают влезать во все мобильные устройства. Наверное, все помнят и знают сервис который до сих пор рендерит большие сайты на серверной стороне под маленькие клиенты.

    На мой взгляд, в какой-то момент происходит некий перелом, благодаря известной компании Apple, которая приносит нам iPhone со своим Safari, и идея даже не в том, что там полноценный браузер, который отлично рендерит, отлично поддерживает, по сравнению со своим предшественником JavaScript, они приносят довольно интересную идею. Они приносят отличное usability-решение для скейлинга страниц и у вас теперь нет проблем с тем, как заскейлить, перемотать вот эту большую страницу, как ее показать маленькой, потом большой, потом опять маленькой.



    Все ближайшие конкуренты и последователи тут же это подхватывают, Android со своим WebView, с доступом из API, с отличным JavaScipt-движком и с поддержкой Flash.

    Что хочется сказать отдельно про Android? Спасибо им, поддержка из API отличная, можно писать браузеры, садиться и писать прямо сейчас, на основе того, что уже есть из коробки. Это позволяет делать интересные решения, это позволяет писать web-based application, когда у вас нативное предложение является всего лишь некой оснасткой вокруг WebView, а содержимое этого WebView вы уже контролируете со стороны сервера. То есть вам не нужно писать какой-то свой рендер. Опять же iPad со своим очередным мобильным браузером, Samsung со своей Bada, и Windows Phone с Internet Explorer, который основывается на IE.

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



    ЗАКЛЮЧЕНИЕ



    В общем, для вас у меня плохие новости. Всего за десять лет у нас полностью поменялись все технологии. Если вы сейчас садитесь писать веб-сервис, вы его пишете, вы используете совсем другие технологии. Это означает, что вам нужно продолжать учиться, вам нужно продолжать ходить на конференции, читать книги, читать форумы слушать доклады, потому что постоянно появляется что-то новое. Высокопроизводительные сервисы, они довольно требовательны к выбору, и богатство технологий, которые появляется, зачастую не решают проблему, а создают ее. У вас слишком много выбора и легко ошибиться, легко выбрать не то, не то, что действительно решает вашу проблему. Минимальный набор сегодняшнего типичного веб-сервиса, он вырос. Если раньше, говорим на примере веб-сервера, если раньше вы брали Apachе, и он у вас там сервил все: и картинки, и скрипты и все-все-все, то теперь это у вас отдельный Apache, опять же, если это Apache, отдельный Apache, который сервит приложения ваши, который напишет на скриптовом языке, отдельный веб-сервер, который будет отдавать статику, вы  обязательно поставите тот же самый NGINX, который будет стоять перед Apache, который будет снижать нагрузку. Кирпичиков, из которых мы строим сервис, становится все больше, и они становятся все более специализированы.

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

    Повторюсь, катастрофически расширился список устройств, разрешений, браузеров, движков, рендеринг в каждом из них работает по-другому. По поводу разрешения вообще интересная история, если вы помните, старый веб начинается с 640*480, потом это 800*600 довольно долгое время, 1024, после 1024 — целый зоопарк разрешений. И самое интересное, что сейчас мы постепенно возвращаемя к 640*480 и к 800*600, благодаря нашим новым телефонам, которые отлично рендерят странички. Поэтому возвращаемся к предыдущим разрешениям и пониманиям о том, как нам в том или ином виде показать страничку. Самая главная проблема, имейте ввиду, что если вы планируете ваш сервис как успешный в течение нескольких лет, то в среднем, раз в 3 года вы его будете полностью переписывать. На примере той же почты могу сказать, что мы переписали клиент, существенно, полностью переписали раза три. И это не обусловлено дизайном, это обусловлено появлением новых технологий.

    Новые технологии дают новые требования к скорости, и у пользователя расширяются каналы, ваш медленный сервис уже не может быть оправдан тем, что у пользователя модем. Не важно, что вы страничку на сервере собираете за одну секунду, он ее будет качать пять. Сейчас пол-секунды — это уже чувствительно, за пол-секунды будьте любезны, но отдайте страничку. Соответственно, вам постоянно нужно участвовать в этой гонке, постоянно ускоряться и ускоряться. Плюс, новые технологии — они очень хорошая обратная связь. Новые технологии, тот же AJAX, например, предлагает новые IT-решения. Но для того, чтобы вам внедрить этот AJAX, который по сути просто меняет клиент сайт, у вас не перегружается страничка, но вот казалось бы, что плохого, не перегружается страничка, очень здорово, минимум данных гоняется по сети. Но для того, чтобы написать нормально, вам нужна нормальная поддержка AJAX на серверной стороне. Это значит, что вы идете и фактически полностью рефакторите код серверной стороны. В общем, готовьтесь, что вы будете переписывать ваши сервисы, где-то в среднем, раз в три года, если скорость эта не увеличиться.



    Спасибо большое, давайте ваши вопросы.

    ВОПРОСЫ ИЗ ЗАЛА



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


    Ок, попробую ответить, понял ваш вопрос. Не то, чтобы мы сидим и придумали классную вещь, но для того, чтобы, приведу космический пример, считать раковые клетки, но было бы здорово, если бы батарейка была бы у вас классная на вашем сервисе, тогда мы будет все вместе считать раковые клетки, полностью загружать CPU, но давайте подождем пока у вас будет маленький ядерный реактор в телефоне, чтобы это было, всю жизнь. Мы так не делаем. Мы работаем с производителями, с производителями «железа», производителями «софта», с большими производителями, тот же Samsung, та же Nokia. Они делятся с нами какими-то своими наработками, мы обсуждаем как следующие версии наших продуктов будут на них работать, поэтому мы их знаем несколько больше.

    Добрый день, меня зовут Илья Пятин, компания «Лайн Медиа». Мы сейчас услышали, по сути, некую историю развития интернет-технологий, но доклад то ведь называется «Эволюция разработки », правильно? А разработка, она ведь состоит не только из технологий? Это есть разработчики, команды какие-то у вас, да, deploy, контроль версий и так далее. Можно услышать про то, как это все развивалось? Потому что, во многих случаях это даже важнее, чем технологии, которые используются, как-то об этом не было ничего сказано. И какие из технологий указанных все-таки предпочитаете вы, хотя бы не за весь период истории, а сейчас… Вы использовали вообще все, что было перечислено или все-таки приоритеты какие-то отдавали? Спасибо.


    Смотрите, по поводу технологий, которые мы предпочитаем. Вот, видимо, плохо выразил свою мысль. Мы любим инструменты в своем применении, поэтому… А так как сервисов у нас много, то нельзя одну и ту же технологию использовать, чтобы хранить почту, чтобы показывать социальную сеть и чтобы обеспечить VoIP-связь между двумя вашими абонентами мессенджера. Поэтому одной технологии нет. Мы долго эволюционировали и наконец вырастили и вот теперь она у нас везде используется нет, мы вместе с вами, с коллегами из других компаний эволюционируем, смотрим на все разработки, которые есть на рынке, где-то пытаемся их применить, где-то даже не пытаемся, видим, что шансов нет для нас и они к нам никак не применимы. И одной технологии нету. Если говорить о deploy, мониторинге и эксплуатационных вещах это очень длинная дискуссия должна быть. Я не хотел совсем об этом говорить, потому что это отдельная дискуссия о том, как мы эволюционировали в мониторинге нашем, как мы эволюционировали в deploy нашем, как мы чего применяем, где не применяем, какие мы используем правила там выкладок, правила применения коммитов и патчей. Это очень долгая дискуссия, можем отдельно с Вами поговорить.

    Игорь, здравствуйте. Меня зовут Алексей Шишкин. У меня есть к вам следующий вопрос. По вашему мнению, чего не хватает в расширенной реальности, для того чтобы она полностью вышло на рынок. В свое время вышел iPhone с Сафари, стало возможно смотреть с мобильных устройств сайты. Что не хватает для расширенной реальности, по вашему мнению? Спасибо?


    А можете мне чуть подробнее рассказать про эту технологию?

    Расширенная реальность – это отображение на экранах, допустим телефонов, объектов, которые не присутствуют в реальном мире, а генерируются за счет данных, полученных на положении клиента, в приложении.


    Вы знаете, я понял о чем вы. Мне кажется, надо чуть-чуть подождать. Железо не готово еще.

    Разрешите вопрос задать? Если бы у меня попросили оценить ваш доклад, с точки зрения 5-ти бальной системы, я бы не стал оценивать, а написал блестяще!


    Спасибо.

    Вот почему. Потому что историю надо знать. И вот то, что вы сказали по поводу собеседования, это меня даже немного морально поддержало, поскольку я иногда принимал экзамены у студентов, и подходил к ответу с таким же подходом. Когда надо аргументировать какие-то варианты. Но, действительно, терминология все время меняется, иногда не успеваешь все узнать. Но вернемся к базам данных. Вокруг чего все и крутиться в основном. Дело в том, что и перед вами Константин тоже выступал, говорил что, реализационные базы данных все равно будут иметь свою нишу, их никто не отменяет, но еще есть и новый SQL. Теперь я бы вас попросил как-то с определениями определиться, возможно уже можно поменять. Потому что, насколько Вы помните, реляционные базы данных, реляционная модель данных победила в свое время, как-то вот превалировала, эволюционировала перед иерархической сетевой. Но есть, появилось два как бы определения: простое, когда имелось в виду, что эволюционная база данных взаимодействует с плоскими таблицами, и более математическое, что реляционный от слова relation отношения. Это вот поскольку мы моделируем объекты реального мира, которые между собой взаимодействуют. Во-первых по поводу вот этого relation и второе язык SQL тоже имеет свою богатую историю развития и когда… Известно, что язык SQL состоит из нескольких подязыков, которые определяют основную работу с базой данных. Вот определитесь, пожалуйста.


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

    У меня к Вам два вопроса. Первый: изменилась ли у вас как-то методология разработки и на что это повлияло? просто в докладе об этом не было сказано, интересно. Ну и какая методология разработки сейчас?


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

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


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

    Здравствуйте, Игорь. Меня зовут Борис. Компания «Консультант-плюс». Вы просто обмолвились, у меня короткий вопрос, вы обмолвились, что тоже используете WinBаse-движок, который не есть noSQL, а можно узнать, это часть Тарантула или что? Что это за движок?


    Это один из движков, написанных на Python

    То есть с ваш собственный какой-то?


    Нет

    А , все понятно.


    А вот, был основной постулат, что технологии сменились за 10-ть лет. Так почему же, до сих-пор, mail.ru очень активно ищет Perl-программистов.


    Я же об этом сказал. У нас очень много кодов написано....

    Но помимо этого у нас очень много стратапов, которые под крылом mail.ru, они тоже ищут программистов в стиле модерн-Perl.


    Довольно долгая тема для дискуссий, я отвечу коротко. Я пишу много-много лет на Perl. Иногда в голове простые вопросы: «Зачем мне что-то еще, я же успешно делаю проект на языке Perl». Поэтому, иногда, эти самые стартапы, они на Perl, это неплохо, это прекрасно. Здорово, язык не стоит на месте.

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


    Мы его сразу наймем. Человек, который к нам придет и скажет...

    Но технологии появляются постоянно, каждый день, вы же не все рассматриваете. Какой-то определенный процесс есть в этом направлении?


    Происходит по разному. Вот, смотрите, например Tarantool. Tarantool появился у нас внутри. Это хороший пример, Tarantool. У нас была проблема и мы очень долго искали решение и его не было. Я не зря упоминал memcached, memcachedb, это как раз наши предшественники Tarantool, мы очень долго возились с кодами memcached, пробовали коды memcachedb в другом проекте, мы долго искали возможность того, как можно эффективно, с одной стороны, положить и забрать из памяти. Мы пробовали Redis, он не работал на тот момент вообще никак, был чудовищен тогда. Поэтому в этом смысле процесс принятия решения такой: у нас есть проблема мы ищем, мы копаем, мы… Tarantool это не мы сели, а давайте напишем Tarantool!, вот пять человек сядет, закроется в темной комнате и через полгода принесет нам Tarantool.

    Tarantool, он появился как некий эволюционный процесс, ему предшествовало, чтобы вас не обмануть, восемь или десять реализаций собственных демонов, которые хранили те или иные данные, прежде чем мы выкристаллизовали Tarantool в том виде, в котором он есть сейчас. Поэтому в этом смысле процесс принятия решения такой. В другом аспекте процесс принятия решений следующий: ребята, нам нужно сделать такой сервис, который будет, не знаю, хранить учетные данные пользователи и обновляться будет не часто. Давайте возьмем MySQL. Давайте. У кого-нибудь возражения есть? нет. Все, берем MySQL и пошли копать. То есть даже не обсуждается там. Смотрите, вы не можете протестировать все. Мы, конечно, тестируем. Опять же, возвращаясь к Тарантулу, там чертовски много было положено исследований, измерений, медленно, быстро, пакеты в секунду, сколько пакетов в секунду тянет оно в принципе, почему, Тарантул, который по идее должен жрать ЦПУ, на самом деле не жрет ЦПУ и так далее… Очень много, очень много исследований. Но иногда у вас есть ответ на вопрос и не надо доказывать, что прыгнуть с 9 этажа это больно. Что MySQL все-таки умеет хранить данные и на каких-то неких входных характеристках он прекрасно работает. Опять же некий экспиеренс работы. Сейчас если кто-то придет и спросит, а чего «Тарантул» вытянет или не вытянет, у меня тысяча запросов в секунду, никто не будет тестировать сейчас. Потому что тестирование проведено до. Вот она история, вот эволюция, мы базируемся на нашем опыте.

    Здравствуйте, Игорь. Меня зовут Гогилев Роман. У меня вопрос. Вы рассказывали про эволюцию технологий, в частности, мобильных. Такой вопрос, вы их все еще поддерживаете? Сможет ли ваш мобильный сайт отдать WML, как-то подстроиться под размер экрана.


    Зависит от популярности и это решение принимается однажды и навсегда. Все, WML-версия больше не живет, пользователи нам такие больше не интересны. Выключаем. У нас не осталось WML-подержки, специально смотрел, нет у нас WML, XHTML только.

    Игорь! Добрый день. Вопрос. Вот вы сказали, что для нас, для всех, плохие новости. Много чего происходит, много новых технологий, постоянно что-то меняется. И, мой вопрос связан, что с этим делать. Понятно, что в основном, с моей точки зрения задача, это как-то развивать людей. То есть, как у вас для этого менеджмент построен. То есть, что вы делаете? Выделяете время на развитие, выделяете время на свои проекты, 20%. Я понимаю, что это не одно какое-то решение, это системный подход. Просто скажите какие у вас основные направления. Как дальше-то жить?


    Плохо слушали. Ходить надо на конференции, читать больше, изучать.

    Нет, это понятно, но вы считаете, что этого достаточно? Или еще что-то нужно?


    Смотрите, по поводу «пипл-менеджмента», как устроен процесс, вот Tarantool — наш open-source проект, один из примеров того, что в какой-то момент мы поняли, что нам нужно «копать» в некие свои собственные разработки, которыми мы хотим поделиться. Поэтому была команда отделена от некой такой продуктовой разработки, open-source разработки, которая, так скажем, в первом круге не приносит ничего в компанию.

    То есть, получается, что ваше решение инвестировалось в какие-то новые технологии и при этом вы инвестируете в людей?


    Не инвестируем?

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


    Да, в определенном смысле, безусловно так.

    Меня зовут Антон, компания «Ксимат». У меня к вам три вопроса. Можно я их сразу задам?


    А давайте один, можно? Самый лучший?

    Самый лучший? Вы говорили про NodeJS, что вы его пробовали использовать и он не потянул нагрузку. А помимо нагрузки вас не смущают технические ограничения на то, что он использует только свой веб-сервер, его можно «запихнуть» в сам NGINX, но это «костыльное». Выходят, постоянно новые версии API, код постоянно переписывать приходится, обратной совместимости у него нет.


    Вот, вы сейчас говорили какие-то вещи, «постоянно выходят новые версии», «API появляются», что его «можно засунуть только под NGINX», а я вот могу сразу вспомнить кучу технологий, которые популярны сейчас, у которых, постоянно выходят новые API и которые несовместимы с предыдущими, которые, как Вы говорите, надо засовывать под Nginx, потому что по-другому оно не живет, ну вот… В этом смысле, не смущает

    Ну вот то есть в реалиях Mail.Ru это нормальное решение, что сейчас сделать проект на NodeJS и возможно придется с ним геморроиться в переписываниях кода под новую версию? Или вы не будете переписывать его под новую версию?


    Что-то Вы меня троллите, по-моему, честное слово. Назовите мне технологию, с которой не придется, Вы мне гарантируете. что не придется переписывать под новую версию?

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


    Я Вам не верю, ну что значит не переписывают никогда? Куча проблем, что-то не работает, что-то не так, вышла новая версия, в которой, допустим, поменялся API, вызов какой-то функции. Или функция стала deprecated по тем или иным причинам. Тоже самое происходит с PHP.

    Просто как бы ну JS у нее нету ветки стабильной. Точнее, нет, стабильные ветки есть, нету порога какого-то.


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

    Вот, вы сейчас говорите про NodeJS, вспомните про Java 1.0. Что писалось на 1.0 и что потом случилось с кодом, который был написан Java 1.0 и все поменялось до 6-й версии, ну вот, вообще всё! И что, в этом смысле не надо было писать на Java? Сколько ждать? У меня к вам встречный вопрос, сколько ждать? Когда, вам кажется? Когда разработчики говорят: «это новый релиз», когда разработчики меняют мажорную версию? Это не тот порог, нет какого-то формального порога в этом смысле. Вам никто не скажет сверху: «всё, отлично». Только пока вы сами не попробуете в вашем новом проекте, вы не поймёте, что оно для вас хорошо.

    Последний вопрос товарищи, последний.

    Я тут, меня Константин зовут. Тут такой наболевший у меня лично вопрос.

    Обычно, процесс строится так, есть эксплуататоры, есть разработчики. И проблему ведут эксплуататоры, а устранять нужно это разработчикам. Кто «притаскивает» новые технологии в вашу компанию? Вот у вас есть проблема и уборщица говорит: «смотрите-ка, а NodeJS появился, давайте сделаем». То есть, кто источник новых технологий? У всех есть, как в Гугле, те самые 20% времени, когда они могут почитать «Хабру» и найти что-нибудь новенькое и вот, кто «притаскивает» новые технологии?


    Во-первых, быстрый простой ответ, команда. Команда источник новых технологий. Есть эксплуататоры, есть не эксплуататоры, у нас такие суровые эксплуататоры, что они умеют «пропатчить» код, они могут понять где проблема, на одном языке разговаривают с разработчиками. Вот они вместе сидят и читают core dump, не просто его «тупо» сцепили, отдали и бог его знает что оно там делает, они вместе его читают.

    Я про новые технологии, не о проблемах старых.


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

    Там сервера ломаются, простаивают.


    Это они ломаются, потому что разработчики плохо пишут, разработчики хорошо пишут они реже ломаются.

    Спасибо.


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

    Игорь, спасибо большое.








    Данный текст является расшифровкой доклада Ермакова Игоря на Форуме технологий Mail.Ru 2011, проходившем 16 ноября в центре Инфопространство. Подробности о технологии создания текстов докладов по видеозаписям см. здесь: «Изнанка» Форума технологий Mail.Ru: Хай-тек в event-management. Видеоверсии прочих докладов (включая версии для мобильных устройств) доступны на сайте Форума – techforum.mail.ru. Текстовые варианты докладов будут публиковаться здесь и на сайте Форума каждую неделю или немного пореже в похожем формате. Пожалуйста, сообщайте в «личку» об опечатках в тексте.
    Метки:
    Mail.Ru Group 826,15
    Строим Интернет
    Поделиться публикацией
    Комментарии 12
    • 0
      А нельзя ли разместить видео в нормальном разрешении или обязательно нужно ломать глаза при просмотре этого?
      • 0
        Ну у всех разные каналы, видео в бОльшем разрешении будет доступно минут через 10-15. Проапдейчу пост.
        • 0
          Разместил. Под презентацией ссылка. На видеохостинге будет минут через 30.
        • 0
          Доклад неплохой, но вы вычитывали текст, перед тем как его опубликовать?
          Бедные реляционные базы данных как только в тексте не обзываются и реализационными и революционными.
          • 0
            спасибо, пропустили значит. Поправим сейчас
            • 0
              поправили, спасибо
            • 0
              Для «форума технологий» доклад слишком общий и поверхностный, ожидал больше подробностей об опыте использования различных технических решений в Mail.Ru
              • –1
                Он не только общий и поверхностный, он сумбурный очень. Докладчики парой из разговоров противоречут друг другу — это и базы данных, и языки програмирование.
                • +1
                  Конкретно этот доклад действительно очень общий, обзорный, на него собирались те, кому он интересен. Всего почти 20 докладов, там есть гораздо более специальные. Будем по одному в неделю-две публиковать.
                  • 0
                    я ходил на ваш форум:) наверно это единственный доклад ни о чем в первом потоке
                    • 0
                      Вы знаете на яте то же было много обзорных докладов, они были куда интереснее.
                      Надеюсь в 3 раз вы соберетесь с силами и сделаете интересно.
                      Еще я заметил, что надо сделать больше времени на вопросы — ответ (почти на всех конфах эта проблема), людей потом после доклада вообще не выцепить.

                      Еще непонятно — что с аудиторией. Откуда эти люди задающие вопросы про outlook и глюки? и другие не тех специалисты?

                      Ну и последние, надеюсь что мониторинг системы mail.ru попадет все же в открытый доступ.
                      Хороших и открытых систем мониторинга очень мало.
                  • 0
                    Ну вот… меня меил.ру тролем назвали =(

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

                    Самое читаемое