Рейтинг@Mail.ru
Highload++ 2017 завершён. Ждем вас на Highload++ 2018!

Профессиональная конференция разработчиков высоконагруженных систем

СКОЛКОВО, Москва 7 и 8 ноября

11-я ежегодная конференция для разработчиков highload-систем, которая соберет   2 700 участников из разных регионов России и мира. Мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать многие тысячи и миллионы пользователей.

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

Правильные ручки и тимлиды на HighLoad++

Как работает магия сжатия в целом?

Как она работает более конкретно в очень разных продуктах: "просто базах" типа MySQL или Mongo; в поисковиках типа Lucene или Sphinx (или даже веб-поисках); в колоночных хранилищах типа Vertica или Clickhouse; в конце концов, внутри апдейтов Chrome?

Обсудим это в докладе Андрея Аксёнова, пробежимся по всем важным ключевым словам от замшелых Huffman до моднейших Snappy — и, важнее, по ещё паре десятков других ключевых слов. Подробно разберем несколько особо интересных методов и трюков про сжатие и прочую перепаковку данных. Посмотрим пример на 100 строк кода со сжатием в 6 раз и одновременным ускорением работы в 5 раз (читерством, конечно), причем успешно написанный не специально обученным монстром, а совершенно обычными разработчиками. Посмотрим на скорость разных готовых кодеков, попытаемся понять, когда какой можно применять, а где нельзя.

Бонус-трек в коридоре, если кому интересно, как устроено внутри сжатие картинок, видео и прочего такого. Условно прикинем на пальцах, как написать свой простенький игрушечный JPEG-декодер в сотню-другую строк; можно на JavaScript или Python. Или не JPEG!

Как развивать библиотеку компонентов, не ломая её

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

Вместе с Артуром Удаловым мы поговорим о том, как правильно и эффективно разрабатывать и поддерживать библиотеку компонентов при командной разработке и избегать проблем. Ведь в Сети об этом можно прочитать только вскользь, либо же найти ответы на какие-то отдельные вопросы на форумах и трекерах после долгих мучений. В его рассказе "Как развивать библиотеку компонентов, не ломая её" речь пойдёт не просто о каких-то готовых инструментах, которых в изобилии можно найти в сети, а о способах внедрения и использования популярного софта в реальном проекте, о неизбежных трудностях и их преодолении. Приходите!

P.S. Доклад будет ближе к поклонникам React, но мы абсолютно уверены, что вне зависимости от ваших предпочтений рассказ вам будет полезен, а идеи пригодятся в работе с любым фреймворком.



Это были два доклада про правильные руки, у нас ещё такие :)

Но есть ещё доклады об инструментах, процессах и навыках, с которыми должны работать тимлиды. Начнём с процессов, например:

Вся власть Советам или комитетная разработка в тестировании

Путь из небольшого, но очень быстро развивающегося стартапа до серьёзного игрока на рынке, чьё развитие и рост не могли не заинтересовать Alibaba, Lazada прошла всего за несколько лет. Не трудно представить, с какой скоростью создавались и менялись внутренние процессы. А если добавить сюда сложность крупного e-commerce проекта и множество нюансов азиатского бизнеса? Огонь? Мы расскажем вам, как можно созидать и развиваться в таких, казалось бы, совершенно непригодных для этого условиях.

В своём докладе "Вся власть Советам или комитетная разработка в тестировании" Нина Щеглова поделится секретами развития отдела тестирования из небольшой группы в Москве до команды, которая успешно справляется с языковыми барьерами, часовыми поясами, а ещё программирует и помогает делать несколько магазинов с десятками API.

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


Ну, и ещё про навыки и процессы. Да, мы нашли технического директора, у которого работает парная разработка. Мы были уверены, что это миф :)

Четыре кейса парной разработки

Вот в каких кейсах применялась Дмитрием Симоновым разработка в парах:

  1. Владелец кода и десять джуниоров;
  2. Команда “завтра-тим”: всё будет сделано, но завтра;
  3. Рефакторить нельзя писать с нуля;
  4. Год без результатов — когда команда уболтала дать ей "каникулы" на рефакторинг.

Интересно?

Нам — очень! Мы пишем следующий выпуск новостей, а вы — напомните руководителю (или самому себе) о покупке билетов :)

Подключайтесь!

Rambler's Top100