Хочу быть в курсе событий

Сообщество веб-разработчиков начало подготовку к РИТ++ 2014, оставьте свою заявку, если Вы хотите получать новости о проекте.

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

  • 60 докладов
  • 2 полных
    дня
  • 800 участников
  • 12 секций

Ключевые докладчики, Санкт-ПетербургМосква

  • В этом докладе мы рассмотрим:

    - Что такое технический долг?
    - Причины, по которым он возникает
    - Всегда ли технический долг это плохо?
    - Как измерить объем технического долга?
    - 5 способов уменьшения технического долга

    Доклад построен на реальных событиях, произошедших с командой разработчиков, которой достался проект с "тяжелым" наследством из одной южной страны.

  • — Особенности подбора кадров и командной работы
    — Создание и внедрение коллективного код-гайда
    — Методики курирования профессионального роста не в ущерб текущим проектам
    — Подводные камни совместной работы над фронтэндом и способы уклонения от них
    — Книги, ресурсы и курсы для повышения квалификации

  • 1. Зачем нужны CM системы?
    2. Как выбирать CM систему
    3. Критерии отбора CM системы
    5. Сравнение CM систем по критериям отбора:
    5.1. Порог вхождения
    5.2 Начало использования
    5.3 Общая анатомия CM системы.
    5.4. Шаги по разворачиванию CM системы
    5.5 DSL
    5.6 Дружелюбность сообщества
    6. Уникальные особенности CM-систем
    6.1 Chef
    6.2 Puppet
    6.3 Salt
    6.4 Ansible
    7. Кейсы использования нами тех или иных CM систем
    8. Выводы

  • Проблема разработки способов хранения больших массивов конфиденциальных данных, позволяющих эффективно проводить операции над данными, актуальна уже не первый год. Особенно остро эта проблема стоит перед облачными базами данных (БД), так как потенциальный пользователь может не до конца доверять администрации облачного сервиса, а эффективность работы с такой БД, является одним из определяющих факторов привлекательности сервиса на рынке.
    Данный доклад представляет собой обзор подходов, разработанных в лаборатории НГУ-Parallels, позволяющих хранить данные в облачной БД в зашифрованном виде и проводить операции над зашифрованными данными без необходимости их дешифровки в БД. Подходы включают в себя использование различных алгоритмов шифрования (в том числе сохраняющих порядок, гомоморфных, полностью гомоморфных), использование разбиения данных в БД на различные подмножества, с последующим шифрованием различными ключами, и прочие.
    Обсуждаемые подходы позволяют хранить данные в облачной БД в зашифрованном виде, и проводить над этими данными следующие операции:
    - поиск (включая поиск по подмножествам и сравнение с другими данными)
    - арифметические операции (и как следствие практически любые другие математические операции)
    - JOIN’ы и ряд других специфических SQL операций
    При проведении этих операций, в облаке не производится дешифровка данных, дешифровка проводится только на клиентской машине, где дешифруется результат проведённых операций.

  • Константин Лихтер
    Intel Corporation
    Как мы сделали IDE для HTML5 на HTML5

    Несмотря на то, что сейчас достаточно разговоров о том, что JS -- чуть ли не язык последнего поколения, что за ним будущее, существует очень много мнений о том, что на него возложены слишком "большие обязанности", и, что, вполне возможно, не стоит выпускать этот язык с арены client-/server-side веб-разработки. В этом докладе я постараюсь показать, как мы разрушили этот миф.

    Это будет рассказ о том, как мы сделали Intel XDK --IDE для кроссплатформенной разработки мобильных приложений с помощью HTML5/JS. Как мы на HTML5 написали полноценное приложение, реализовав такие функции, про которые нельзя и подумать, что они могут быть реализованы на JS. Как мы, пропагандируя кросс-платформенную разработку сами сделали кросс-платформенный продукт с гигантской кодобазой, но, тем не менее, собираемый под несколько платформ всего в один клик.

  • В разработке высоконагруженных проектов, существующие решения не всегда приемлемы и приходится "изобретать велосипеды". В докладе будут освещены подходы и решения, которые проявились при разработке собственного key/value хранилища на базе API Sophia.

    API Sophia - разработка от команды mail.ru: http://sphia.org/, основанное на fractional cascading индексе. SophiaDb - это полноценное персистентное key/value хранилище, осуществляющее общение с клиентом по memcached протоколу.

    область применения: хранение больших объемов (500М+) малых порций (~256 байт) информации, возможно использование в рекламных и социальных сетях. В частности, очень хорошо подходит для хранения счетчиков и лайков.


Программа и тезисы:
  • Москва,
  • Санкт-Петербург
  • 1. Возможности систем в построении поиска и их ограничения
    1.1) Полнотекстовый поиск:
    a) внешняя система поиска с использованием Sphinx: возможности и ограничения, способы их преодоления;
    b) проблемные места полнотекстового поиска по полнотекстовому индексу MySQL и PostgreSQL и пути их обхода. Синонимы, стоп-слова, поиск "по звучанию".

    1.2) Параметрический поиск:
    a) быстрый параметрический поиск по БД с использованием Redis: практическое применение и "подводные камни": однопоточность (хотя об этом везде написано, почему-то этого никто не знает), медленные операции keys и их замена с использованием sets, резервное копирование Redis, кластеризация Redis;
    b) параметрический поиск средствами MySQL: как сделать его быстрее при часто меняющейся модели данных;
    c) параметрический поиск средствами PostgreSQL и GIST- и GIN-индексы по полям типа HStore;
    d) параметрический поиск по полнотекстовому индексу Sphinx: ограничения и преимущества. Лимит на число полей в поиске, лимит на размер индекса в памяти (2Гб), преимущества RT-индексов.

    2. Вопросы производительности и актуальности данных. Асинхронное обновление индекса как баланс между актуальностью и производительностью. Практические рекомендации по использованию очередей сообщений AMQP.

  • Заметки практикующих email-маркетологов Александр Орлов, Вячеслав Панкратов

    Кто-то говорит, что эра email-маркетинга уходит, пришла эра социальных сетей. Но у каждого из нас по-прежнему есть email, и мы по-прежнему каждый день читаем письма.

    Конечно, правила email-маркетинга меняются каждый год. В своем бизнесе мы перепробовали массу каналов продаж - социальные сети, рекламу на тематических порталах, продажи по телефону; мы задействовали и собственный отдел продаж. Ничто не работает так хорошо, как email-рассылки. За 2013 год продажи "Стратоплана" по рассылкам превысили $500K.

    В нашем докладе мы расскажем об идеологии сбора подписной базы и работы с ней, мы также объясним, какие практические механизмы работают, а какие не работают - в общем, мы собираемся сделать обобщение своего опыта в email-маркетинге за 7 лет.

  • Необходимость code review никогда не ставится под сомнение. Защита от ошибок, взаимное обучение – это понятно и приятно.

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

    У нас в команде разработки веб-интерфейсов в Яндекс.Деньгах весь код проходит code review дважды и публично. Я расскажу, чем была вызвана необходимость организовать процесс именно так, детально объясню, как проходят такие code review, и какие выгоды (а их немало!) мы получили в результате.

  • SVG: следующий уровень Илья Пухальский

    Давно известный и знакомый сердцу SVG в новых ипостасях: отзывчивый SVG, медиа-запросы, анимации и трансформации, JavaScript в SVG, SVG как отдельный модуль, SVG как разметка представления.

  • Как мы сделали IDE для HTML5 на HTML5 Константин Лихтер

    Несмотря на то, что сейчас достаточно разговоров о том, что JS -- чуть ли не язык последнего поколения, что за ним будущее, существует очень много мнений о том, что на него возложены слишком "большие обязанности", и, что, вполне возможно, не стоит выпускать этот язык с арены client-/server-side веб-разработки. В этом докладе я постараюсь показать, как мы разрушили этот миф.

    Это будет рассказ о том, как мы сделали Intel XDK --IDE для кроссплатформенной разработки мобильных приложений с помощью HTML5/JS. Как мы на HTML5 написали полноценное приложение, реализовав такие функции, про которые нельзя и подумать, что они могут быть реализованы на JS. Как мы, пропагандируя кросс-платформенную разработку сами сделали кросс-платформенный продукт с гигантской кодобазой, но, тем не менее, собираемый под несколько платформ всего в один клик.

  • Анатомия видеорекламы Артем Вольфтруб

    Видеореклама является сегодня самым быстрорастущим сегментом в интернет рекламе. Этому способствует ряд факторов:
    • Увеличение пропускной способности каналов передачи данных
    • Расширение аудитории, в том числе за счет увеличения доли
    мобильных устройств и распространением Smart TV.
    • Рост объемов видеоконтента в интернете, в том числе значительное увеличение объемов лицензионного контента
    • Ростом бюджета на интернет-рекламу (как известно, Яндекс уже обогнал Первый канал выручке от продаже рекламы)
    Все это привело к большому спросу на технологии, которые позволяют показывать рекламу в видео контенте и управлять.
    В своем докладе я бы хотел посмотреть на системы управления видеорекламой со стороны технологий, в частности остановиться на следующих вопросах:
    • Отличие подобных систем от «традиционных» баннерок
    • Сложности, которые возникают при работе с видеорекламой по
    сравнению с классическими форматами
    • Наиболее востребованные прикладные технологические задачи (в
    дополнении к основной – показу видео), а также то, что будет
    востребовано рынком в самое ближайшее время
    • Видеореклама и RTB

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

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

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

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

  • Хей! Буду рад поделиться опытом тестирования безопасности клиент-серверного API и о некотором чек-листе, проходя по которому удается иногда не просто найти парочку багов с инфодисклозом, а получить произвольное выполнение команд на целевом сервере. Немного deep-technical материала, наряду с простыми и очевидными, а порой и забавными моментами помогут в текущем или будущем проекте спасти ресурс от злых рук.

  • Оплата в один клик в Wamba Ярослав Сергеев

    Что такое РРС?

    Оплата в один клик (Pay Per Click, сокращенно - PPC) - это вид оплаты, когда платящий впервые пользователь подтверждает хранение данных платежа для последующего использования, и при последующих платежах происходит оплата без перехода на платежную систему и подтверждения списания денег.

    Каковы преимущества РРС перед традиционными способами оплаты?

    - Удобство для пользователя (не надо набирать SMS-текст и отправлять на короткие номера), не надо вводить по триста раз данные банковских карт);
    - повышает конверсию при импульсных платежах, так как последующие платежи не требуют подтверждения;
    - повышает конверсию при ошибках введения пользовательских данных.

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

    1. Пользователь открывает витрину покупки услуги, выбирает платежную систему, нажимает "Оплатить" и соглашается хранить данные платежа. После этого он либо заполняет форму оплаты, либо просто авторизуется на сайте платежной системы и возвращается на витрину оплаты.
    2. Платежная система сообщает статус платежа и токен, оказывается покупаемая услуга.
    3. При повторном использовании пользователь нажимает кнопку "Оплатить", мы передаем запрос на снятие денег и токен платежной системе, после чего происходит проведение платежа и оказание услуги.

    В Wamba оплата в один клик реализована:
    - при оплате с мобильного;
    - при оплате банковской картой.
    - Мы одними из первых реализовали оплату Яндекс.Деньгами.
    - Мы впервые в России стали применять PayPal и Webmoney.


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

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

  • В докладе будет произведен сравнительный анализ отказоусточивых распределенных файловых систем. Будет рассмотрено, как GlusterFS сможет помочь пользователю, и как PCS сможет решить существующие проблемы хостинг-провайдера.

  • OpenStack изнутри Евгений Потапов

    С тех пор, как мощные серверы с большим количеством "оперативки" в европейских хостингах стали невероятно дешевыми, очень многие компании (в том числе и наша) стали задумываться о том, чтобы взять сервер (а то и не один), поставить на него OpenStack и устроить себе собственный уютный аналог Amazon Web Services - как минимум для целей исследования и разработки, чтобы создавать экземпляры (instances), отключать и подключать диски, легко делать образы.

    В наш XXI век, когда люди не хотят ждать и когда половину действий можно совершить нажатием одной кнопки, многим кажется, что
    - OpenStack уже используют все, все о нем говорят;
    - OpenStack ставится в течение нескольких часов, после чего работает и не ломается, потому что это надежное и стабильное решение.

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

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

  • В разработке высоконагруженных проектов, существующие решения не всегда приемлемы и приходится "изобретать велосипеды". В докладе будут освещены подходы и решения, которые проявились при разработке собственного key/value хранилища на базе API Sophia.

    API Sophia - разработка от команды mail.ru: http://sphia.org/, основанное на fractional cascading индексе. SophiaDb - это полноценное персистентное key/value хранилище, осуществляющее общение с клиентом по memcached протоколу.

    область применения: хранение больших объемов (500М+) малых порций (~256 байт) информации, возможно использование в рекламных и социальных сетях. В частности, очень хорошо подходит для хранения счетчиков и лайков.


  • Tarantool 1.6 Primer Константин Осипов

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

    Tarantool - это, в первую очередь, lock-free база данных, обрабатывающая все транзакции последовательно в одном потоке. Tarantool 1.6 - это и ещё полноценный Lua Application Server с поддержкой кооперативной многозадачности, неблокирующего ввода-вывода, стандартных пакетов Lua и пакетов, созданных специально для Tarantool.

    Список новых возможностей самой БД, которая теперь стала одним из приложений, работающих в инфраструктуре Application Server:
    - MessagePack (компактное бинарное представление JSON) для хранения и передачи данных;
    - 2 движка хранения - 1) 100% в памяти и 2) дисковый;
    - master-master репликация;
    - средства шардинга;
    - zero-conf - все объекты базы могут быть созданы "на лету", без предварительной конфигурации или перезапуска (restart);
    - доступ к внешним базам - MySQL, PostgreSQL, MongoDB;
    - авторизация и привилегии.

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

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

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

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

  • БЭМ — норм Вадим Макеев

    Модульный подход к созданию с интерфейсов с помощью БЭМ и независимых блоков. История появления, практическая и архитектурная ценность, альтернативные точки зрения и совместимость с веб-стандартами и здравым смыслом.

    Полные тезисы позднее сегодня.

  • Технический доклад, основанный на живых примерах по работе с API Яндекс.Карт. Докладчик покажет и расскажет как решить различные пользовательские кейсы при помощи API. А также объяснит почему для счастья пользователей нам пришлось сломать обратную совместимость с версией 2.0, когда мы ее перестанем и перестанет ли поддерживать и о наших общих принципах развития продукта. Cлушатели смогут оценить популярные кейсы, уже выполненные с помощью API, а также услышат из первых уст об отличиях реализации в различных версиях API Яндекс.Карт 2.0 и 2.1.

  • Легализация доходов интернет-сервисов Зайченко Николай Михайлович

    Большая часть розничного рынка b2c ориентирована на интернет-продажи.
    Интернет-сервисы получают свои деньги от пользователей как путём продажи товаров (магазины) или услуг (сервисы, дропбоксы), так и путём организации заказов (курьерские службы, аукционы).
    Сюда же относятся freemium-схемы игровых и деловых порталов.

    80% сегодняшних сервисов получают свои деньги незаконно и должны быть закрыты полицей.

    Интернет-сервис нелегален, если у вас:
    - пользовательское соглашение скопировано из Яндекса или взято у западного аналога;
    - нет никаких договоров с пользователями, актов и первичных учётных документов;
    - для приема платежей используются только интернет-кошельки.

    Ваш сервис нелегально использует чужую интеллектуальную собственность (IP), если у вас:
    - не оформлены документы с разработчиками;
    - кто угодно помещает куда угодно чужой контент (тексты, видео, изображения, ПО и проч);
    - нет договоров с авторами/производителями контента, в которых прямо указано, что вся интеллектуальная собственность принадлежит проекту.

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

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

    Что теперь делать?
    Легализация интернет-бизнеса - это документальное оформление сделок и хозяйственных операций в соответствии с требованиями РФ или вывод бизнеса за рубеж, с более лояльным регулированием.

    Каждая продажа - это сделка, доход и расход по которой должен отражаться в учете.

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

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

    А в конце доклада мы опишем работающий алгоритм оформления первичных документов без бумаг.

  • Из моего доклада вы узнаете, как мы в компании Badoo используем Selenium. В начале я коротко расскажу, что такое Selenium, какой стек технологий объединен под этим названием, и для чего может пригодиться каждая из технологий... Далее последует рассказ о том, какие этапы тестирования у нас существуют, для каких из них и по какому flow мы используем Selenium-тесты. После этого речь пойдет о том, что мы тестируем при помощи этого замечательного продукта. Например, я расскажу, как мы тестируем JavaScript и WebApp и как мы не тестируем верстку. Также из доклада вы узнаете, когда те или иные функциональности покрываются тестами, как мы составляем кейcы для этих тестов. Тем не менее, основная часть доклада будет посвящена структуре наших тестов. Прослушав ее, вы узнаете, как мы однажды "переписали" все наши тесты на WebDriver менее чем за неделю, почему у нас возникла такая необходимость и как получилось так, что вместо 25 минут на 30 тестов мы стали тратить 10 минут на 300 тестов... Я расскажу о том, как мы интегрировали в Selenium специальный API, который позволяет нам подготавливать данные для теста менее чем за секунду и какие преимущества это нам дало. Также я поясню, как API облегчает жизнь при ручном тестировании, как он устроен изнутри, кто такой Alex и почему ему 32. В конце доклада я постараюсь максимально наглядно продемонстрировать все "плюсы" и "минусы" каждого из следующих этапов развития наших тестов - переход на WebDriver, распараллеливание тестов, внедрение API и переход на новый тип кейсов.

  • 1. Зачем нужны CM системы?
    2. Как выбирать CM систему
    3. Критерии отбора CM системы
    5. Сравнение CM систем по критериям отбора:
    5.1. Порог вхождения
    5.2 Начало использования
    5.3 Общая анатомия CM системы.
    5.4. Шаги по разворачиванию CM системы
    5.5 DSL
    5.6 Дружелюбность сообщества
    6. Уникальные особенности CM-систем
    6.1 Chef
    6.2 Puppet
    6.3 Salt
    6.4 Ansible
    7. Кейсы использования нами тех или иных CM систем
    8. Выводы

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

    И тогда пришла идея сделать сервис на котором участники смогут соревноваться друг с другом в реальном времени. Так появился кодобатл - обучающий сервис, в котором два участника одновременно пишут код на скорость. wddx.ru

    В процессе реализации стояло множество концептуальных вопросов:

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


    В докладе я постарюсь ответить на самые интересные вопросы/задачи. Расскажу почему и зачем в бекнде erlang, на фронтенде reactjs, в хроме extension. Для чего понадобилось подключать rabbitmq и redis. Как быстро развернуть инфраструктуру с помощью ansible (и выкинуть chef). И почему для исполнения кода стоит взять docker и немного go. А так же, как обеспечить отказоустойчивость и легкий деплой.

  • Получение дохода от продажи товаров или предоставления услуг - это важная составляющая любого стартапа. И если для начала хватает подключения одного платежного шлюза, то по мере роста аудитории, объёма транзакций и аппетитов продуктовой команды приём платежей превращается во все более нетривиальную задачу.
    В докладе я расскажу о следующих вещах.
    - Зачем Badoo (да и любому другом крупному интернет-проекту) целая команда, занимающаяся биллингом?
    - Зачем подключать так много способов оплаты, есть же кредитные карты?
    - Почему кредитные карты - это одновременно и просто, и сложно?
    - Как мы обеспечиваем надёжность и отказоустойчивость нашей системы?
    - Мониторинг, или как мы следим за тем, чтобы у нас и наших партнеров все работало?

  • Ты руководишь крупным проектом в TNS Russia, сотнями серверов, высокая нагрузка, ты размещаешься в дата-центрах. У тебя хороший деплой, внятный контроль внедрения, ты приводишь всё в состояние полного продакшена и наступает скукота. И тут случается неимоверное стечение обстоятельств: тебя приглашают в совершенно новый, только что построенный дата-центр SDN в Санкт-Петербурге, для развёртывания инфраструктуры ЦОД, создания с нуля проектов и, самое главное - создания с нуля собственного облака. Это было совершенно пнятно с первого дня, что управляя такими ресурсами, просто невозможно было это не сделать.
    О чём я готов рассказать:
    - как мы поднимали с нуля инфраструктуру ЦОД, делали 100% отказоустойчивость на всех уровнях - от двойного электропитания до двойного резервирования на коммутации внутри и во вне
    - как мы обеспечили молниеносный деплой нового оборудования, которое приходило и приходит отнюдь не единицами и не десятками серверов, и требует быстрого развёртывания с помошью bootstrap и kickstart
    - как мы придумали идею виртуального ЦОД для нашего нового облачного проекта Qlowd.com с помошью Mirantis Fuel и OpenStack, как тестировали, и что из этого всего вышло.

  • Можно ли быстро разработать сайт с нуля, если почти не знаешь ни HTML, ни CSS, ни JavaScript, ни Java, ни PHP, ни C#? Оказывается, можно! Волшебная таблетка называется Kotlin. Знание языка Kotlin, на котором легко написать и серверную, и клиентскую часть веб-приложения, помогает превратить идею в приложение в считанные часы. В докладе будет показано простое, но вполне живое веб-приложение, для разработки которого автору хватило Kotlin и начальных знаний в области баз данных. Правда, пришлось разобраться с двумя открытыми фреймворками для Kotlin - Kara и Exposed, о которых тоже будет рассказано в докладе. Будут показаны и некоторые тонкости работы с Jetty в IntelliJ IDEA.

  • Теория Ограничений (ТОС) – соблазнительная методология, обещающая быстрые результаты при правильном использовании. Казалось бы – надо скорее внедрять, причём, как требует теория, «сверху», на всю компанию сразу. Но как быть, если движение инициируется вами «снизу», а руководство осторожно даёт согласие только на «попробовать»? И что делать, если опыта использования ТОС у вас пока нет, и потому вы не готовы обещать 100% успех?

    Я расскажу, какой путь я прошла, внедряя ТОС в Яндекс.Деньгах, почти за полгода - начиная с «продажи» идеи, продолжая серией экспериментов и заканчивая получением большого ТОС-проекта в работу. Я покажу некоторые результаты и расскажу о неудачах.

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

  • Понятными словами, по сути, без воды и умных формулировок про новейшие web API, такие как:

    - classlist
    - dataset
    - fullscreen
    - pointerLock
    - vibration
    - battery
    - ambilentLight
    - deviceMotion
    - deviceOrientation
    - webAudio
    - visibilityChange
    и другие

    Немного о каждом API, странности, поддержка браузерами, полифилы, возможные способы использования
    Докдад нацелен на разъяснения сути каждого API и аспектов практического применения с обзором основным методов и архитектуры. Докладчик всячески избегает глубокого и скучного погружения в код :)

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

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

    * Чем технология WebSocket отличается от TCP socket?
    * Как пойдут пакеты? (Каналы, дуплекс и т.д.)
    * Нужна ли буферизация, и если нужна, то где?
    * А был ли разрыв?
    * Где это будет работать? (Текущий уровень и динамика поддержки браузерами, особенности WS TLS.)
    * А что, если не будет? (Fallback.)
    * Почему бы не взять готовое "из коробки"? (SockJS, Socket.IO, Engine.IO.)

    Мы обеспечили транспорт, но что по нему передавать?

    * Архитектура уровня данных, отталкиваемся от сообщений.
    * Чем полезны схемы данных?
    * Сериализация - из чего выбирать и как?
    * Чем могут быть полезны Web Workers?

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

    GitHub Flow - это модель ветвления, принятая в известной компании GitHub и призванная упорядочить процесс работы с ветками в git и позволяющая непрерывно вливать изменения в основную ветвь разработки.

    В своём докладе я расскажу о том, какие "подводные камни" вы можете обнаружить при внедрении процесса GitHub Flow, и объясню, как не сломать процесс, если изменения всё же хочется тестировать.

    Вы узнаете:
    — как устроен GitHub Flow;
    — с какими сложностями мы столкнулись при внедрении;
    — дополнительные соглашения, которым придётся следовать при работе с ветками;
    — что делать с тестированием и тестировщиками.

    Весь опыт работы с моделью получен при разработке Нового 2ГИС (http://2gis.ru).

  • Тестирование. Выходим за рамки. Микрюков Михаил Владимирович

    1. Кто такие тестировщики и каковы их обязанности - как они могут влиять на качество продукта? Если брать стандартно - проверка соответствия задач поставленным требованиям.
    2. Что, если этого мало? Какие есть способы и пути влияния на качество продукта? Выявляем основные и раскрываем в следующим пунктах.
    3. Принимаем участие в оценке сроков задач - у тестировщика свое "видение мира". Мышление построено немного иначе, нежели у программиста, аналитика или менеджера. Плюс, тестировщик зачастую знает лучше особенности функционала и бизнес-логики.
    4. Описываем логику и возможные кейсы для программистов. Таким образом начинаем тестирование задачи еще до написания кода - TDD. Заставляем прогаммистов писать юнит-тесты.
    5. Документируем - поддерживаем/описываем новый функционал. Таким образом кроме нас функционал знают и другие участники и команды.
    6. Переходим на темную сторону - тестируем уязвимости, инъекции, ломаем и выносим все, что не прикручено к полу.
    7. Проблемы - что делать, если ты один? Когда не хватает времени? Если начальство не идет на уступки.
    8. В итоге - влияем на разработку на всех стадиях ее процесса - от постановки до внедрения. Качество улучшается, а это уже экономическая выгода для продукта.

  • — Особенности подбора кадров и командной работы
    — Создание и внедрение коллективного код-гайда
    — Методики курирования профессионального роста не в ущерб текущим проектам
    — Подводные камни совместной работы над фронтэндом и способы уклонения от них
    — Книги, ресурсы и курсы для повышения квалификации

  • Как сделать Инстаграм в браузере Дудин Дмитрий Валерьевич

    Основные понятия (Фильтрация, наложение эффектов, анимированные эффекты, аппаратное ускорение)

    Возможные способы фильтрации изображений и контента в браузере, их достоинства и недостатки:
    - canvas (и готовые библиотеки)
    - webgl (и готовые библиотеки)
    - svg filters,
    - svg filters for html
    - css filter effects

    SVG фильтры - второе рождение.
    Почему мы выбрали именно SVG фильтры для реального production проекта.

    Неизведанный мир svg фильтрации, его продуманные до мелочей устои, синтаксис и правила.
    Описание возможностей (От черно-белого.... до нелинейных искаженией и градиентных карт) с примерами

    Для чего все может понадобиться в реальных проектах

  • Мы привыкли строить продуманную архитектуру для backend приложений. У нас есть много привычных фреймворков, работающих по паттерну MVC для различных языков программирования вроде PHP, Ruby, Python. Но как быть с frontend приложениями? На замену MVC js-фреймворки предлагают подход MVVM, но неожиданно для разработчика логика приложения получается сложной и запутанной.

    В связи с этим возникает два главных вопроса:
    — Как правильно разделить бизнес-логику приложения и логику отображения данных?
    — Где провести грань между модулями приложения, и как организовать связь между ними?

    В своем докладе я дам вам ответ на эти вопросы, но обо всем по-порядку.

    — Когда пора задуматься о модульной организации кода.
    — Модуль. От хелпера до самостоятельного приложения.
    — Организация взаимодействия модулей.
    — Как мы организовали модули в нашем приложении.
    — Процессы и инструменты. Как мы разрабатываем 2gis.ru и beta.2gis.ru.

  • Меня зовут Олег Балбеков, я основатель Evrone.ru
    Мы – разработчики интернет-проектов. Нас 36 человек, и мы раскиданы по всей стране.

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

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

  • Доклад начинается с истории разработки крупнейшего в стране приложения для поиска авиабилетов - search.aviasales.ru. Про то, каким образом оно работало раньше и каким мы его сделали, переведя на AngularJS.

    Отвечает на вопросы:
    - Почему именно AngularJS?
    - Какая архитектура, расположение файлов и виджетов наиболее оптимальна для разработки подобного приложения.
    - Как правильно готовить прототипное наследование?
    - Стратегия передачи параметров в функцию в стандарте ECMAScript (Javascript) и чем она может помочь.
    - Какие инструменты вам понадобятся, а какие лучше даже не пробовать.
    - Оптимизация и профилирование большого client-side приложения. Никакой теории, только конкретные числа и практические рекомендации.

  • Доклад будет посвящён практическому анализу защищённости крупных
    корпоративных систем и интернет проектов. Будет продемонстрированы
    различные подходы к такому анализу защищённости, и рассказано об их
    эффективности в зависимости от ситуации. О том как проще и эффективнее
    построить процесс безопасной разработки, как относится к уязвимостям
    от независимых исследователей ИБ, и стоит ли организовывать
    собственную bug- bounty программу. В процессе будет продемонстрированы
    новые и интересные виды уязвимостей.

  • За последние 15 лет веб сильно изменился и ускорился. Но большинство по-прежнему боится большого количества данных и сложной логики на клиенте. Потому что "тормозит".
    Я хочу сломать стереотипы и показать, как начать делать крутые штуки на client-side. Тысячи и сотни тысяч объектов, разные типы, зависимые вычисляемые свойства, агрегация, множество вариантов отображения. Все это в вашем браузере. Без тормозов, регистрации, смс.

  • В этом докладе мы рассмотрим:

    - Что такое технический долг?
    - Причины, по которым он возникает
    - Всегда ли технический долг это плохо?
    - Как измерить объем технического долга?
    - 5 способов уменьшения технического долга

    Доклад построен на реальных событиях, произошедших с командой разработчиков, которой достался проект с "тяжелым" наследством из одной южной страны.

  • Ноотропы RDF для BigData Леонид Юрьев

    Объем информации уже не является проблемой. Трудности начинаются с необходимости хранить и обрабатывать записи, разнообразие которых постоянно увеличивается и стремится к показателям реального мира (бесконечности). Рассмотрим проблему и вариант её решения.

    1. Иллюстрация на примерах: 1001 SQL-таблица (фиксация схемы данных), 10^13 чего-то в Mongo (отсутствие схемы данных).
    2. Попробуем решить задачу. А если не оказываться от схемы/структуры данных, но и не фиксировать её, позволить постоянно развиваться и итеративно выдавать value?
    3. Пара слов о RDF и OWL. Где здесь решение?
    4. Дескрипционная логика и reasoning, вывод фактов как средство анализа и индексирования BigData.
    5. Перспективы. Где искать специалистов?
    6. Какие трудности у "серебряной пули", чего не хватает. Анализ эмоциональной окраски как fail-пример.
    7. Дискретизация вероятности/уверенности как временное решение.
    8. Нечеткие знания (uncertain knowledge) и нечеткая логика (fuzzy logic). Что это дает?
    9. А если построить uncertain RDF-storage и попробовать Watson 2.0?..

  • Yii 2.0: обзор Александр Макаров

    - Что творится в мире PHP: тренды, инструменты и фреймворки.
    - Что такое Yii, кто его использует (Facebook, Vice и т.д.), почему он так хорош.

    Обзор сильных сторон новой версии фреймворка.

    - Обработка ошибок.
    - Отладчик.
    - Composer.
    - Автозагрузка.
    - Шаблоны приложений.
    - Query builder, AR, noSQL.
    - i18n и CLDR.
    - Расширения.
    - API.
    - Тестирование.
    - Инфраструктура.
    - Документация.

    - Переход 1.1 → 2.0. Как?
    - Как помочь разработке, и почему это важно.

  • Schema-less PostgreSQL 9.4 и другие новости Олег Бартунов, Александр Коротков

    MongoDB правит бал в мире слабоструктурированных данных. Привлеченные в MongoDB инвестиции часто затмевают разум (особенно начинающих и доверчивых) разработчиков, которые с радостью бросаются в океан возможностей, предоставляемых NoSQL (это же круто!). Энтузиазм затихает после осознания
    того факта, что бесплатно ничего не бывает, и надо писать своими руками то, что десятилетиями прекрасно работает в традиционных реляционных базах данных, которые прекрасно справляются с нагрузками и данными 99% проектов, и ваш проект не входит в оставшийся один процент.

    Уже больше 10 лет в PostgreSQL существует возможность работать со schema-less данными, используя расширение hstore. Hstore предлагает хранилище "ключ-значение" с сохранением всех реляционных возможностей, что сделало его самым используемым расширением PostgreSQL. Однако возникающие технологии, основанные на популярном стандарте JSON, требуют от баз данных встроенной поддержки иерархических структур.
    Мы расскажем о том, как шла разработка документориентированного хранилища, и о том, какие технологии стоят за новой функциональностью и производительностью нового JSON, а также о других интересных новых "фишках" PostgreSQL 9.4. Доклад рассчитан на хакеров и архитекторов.

  • Автоматизация или смерть! Антон Еремеев, Артём Пархоменко

    CSS-препроцессоры и минификация JS у всех давно на слуху, но это не единственные рутинные задачи, с которыми приходится сталкиваться. Управление зависимостями, сборка статического прототипа и даже старт нового проекта — всё это можно и нужно автоматизировать.
    Про инструменты для автоматизации — такие как Stylus, Assemble, Grunt, Karma и Bower — сказано уже много. Но основной упор мы хотим сделать не на их описании, а на том, как увязать весь этот стек в мощное средство борьбы с рутиной, как подстроить их под свой процесс.
    Мы расскажем, как мы используем инструменты в разработке финансовых приложений, зачем мы создаём статические прототипы, и как выполняем вайтлейблинг. А также поделимся опытом: с какими трудностями мы столкнулись, и как мы их решали (плагины, практики).

    • Почему и как мы пришли к статическим прототипам. Плюсы и минусы этого подхода. Как быстро и просто писать статический HTML. На примере незаслуженно обделённого вниманием Assemble.
    • Почему надо использовать препроцессоры CSS, и почему надо стараться выжимать из них максимум. На примере Stylus.
    • Как скафолдеры помогают сосредоточиться на ревью кода, а не на ревью соблюдения договорённостей. На примере Yo.
    • Автоматическое тестирование: юнит и функциональное. Что тестировать разработчикам, а что оставить QA. Почему нам хватает ng-scenario, и почему мы (пока?) не стремимся переходить на protractor. На примере Karma + Jasmine + ng-scenario.
    • Менеджеры пакетов: не только для опен-сорс библиотек, но и для своих модулей. На примере Bower.
    • Управление всем зоопарком: контракты на таски для CI, свои плагины и утилиты. На примере npm + Grunt.

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

  • При разработке собственного сервиса возникла задача:
    1) хранить за большое время статистические замеры (скорость на интерфейсах, пользователи онлайн и т.п.), представляемые в виде равномерных временных рядов (т.е. один замер в секунду)
    2) показывать графики с этими замерами с агрегациями по тэгам, «склеивая» аналогичные замеры с разных серверов;
    3) показывать это всё в реальном времени.

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

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

    Потом будет рассказ о нашем собственном, выложенном в Open Source сервере pulsedb, который умеет всё то, что описано выше, а также о том, как его встраивать в имеющуюся инфраструктуру. Сервер написан на Erlang, имеет собственный механизм хранения без каких-либо зависимостей. Графики во встроенном веб-интерфейсе — highcharts.

  • Проблема разработки способов хранения больших массивов конфиденциальных данных, позволяющих эффективно проводить операции над данными, актуальна уже не первый год. Особенно остро эта проблема стоит перед облачными базами данных (БД), так как потенциальный пользователь может не до конца доверять администрации облачного сервиса, а эффективность работы с такой БД, является одним из определяющих факторов привлекательности сервиса на рынке.
    Данный доклад представляет собой обзор подходов, разработанных в лаборатории НГУ-Parallels, позволяющих хранить данные в облачной БД в зашифрованном виде и проводить операции над зашифрованными данными без необходимости их дешифровки в БД. Подходы включают в себя использование различных алгоритмов шифрования (в том числе сохраняющих порядок, гомоморфных, полностью гомоморфных), использование разбиения данных в БД на различные подмножества, с последующим шифрованием различными ключами, и прочие.
    Обсуждаемые подходы позволяют хранить данные в облачной БД в зашифрованном виде, и проводить над этими данными следующие операции:
    - поиск (включая поиск по подмножествам и сравнение с другими данными)
    - арифметические операции (и как следствие практически любые другие математические операции)
    - JOIN’ы и ряд других специфических SQL операций
    При проведении этих операций, в облаке не производится дешифровка данных, дешифровка проводится только на клиентской машине, где дешифруется результат проведённых операций.

Расписание формируется

Генеральный интернет-партнёр

  • Mail.Ru Group

Серебряный спонсор

  • Вadoo

Серебряный спонсор

  • WarGaming

Серебряный спонсор

  • Webzilla

Серебряный спонсор

  • Microsoft

Серебряный спонсор

  • Coalla Agency

Технический партнёр

  • Филанко

Организационный партнёр

  • http://raec.ru/

HR-партнёр

  • SuperJob

HR-партнёр

  • HeadHunter

Информационная поддержка

  • SearchEngines.ru
  • REG.RU
  • 3DNews.ru
  • Internest
  • Интернет Хостинг Центр
  • Xakep.ru
  • CMS Magazine
  • CNews.ru
  • SpaceWeb
  • RUcenter
  • NetCat
  • GISMETEO / ГИСМЕТЕО
  • ООО «Юмисофт»
  • eScan
  • ExpoMap.ru
  • PeterHost
  • Joom
  • Cтудия веб-разработок Михаила Кечинова
  • Softline
  • LiveJournal
  • SQLInfo.ru
  • Element Group
  • bOombate
  • Бизнес-школа RMA
  • OpenQuality
  • Rusonyx
  • FL.ru
  • WebLancer
  • Prograbli
  • Valuehost
  • ImageCMS
  • RusBase
  • LiveBusiness
  • Манн, Иванов и Фербер
  • Свободная Пресса / Svobodnaya Pressa
  • PROFISPACE
  • Нетология
  • Альпина Паблишер
  • Plus / Плас
  • Агава
  • Хостинг-Центр
  • Макхост
  • Webnames.ru
  • PCWeek
  • Bugtraq.ru
  • Opennet
  • Moscow Business School
  • MTI
  • PR.Sape
  • TUT.BY / ТУТ.БАЙ
  • Системный администратор / System Administrator
  • ITMozg.ru
  • Retail and Loyalty
  • В-port
  • Setup.ru