company_banner
  • Видеозаписи всех докладов с восьми конференций Онтико

      Ситуация с тем-самым-вирусом сильно бьёт по организаторам мероприятий. Людям, которые помогают сообществу разработчиков России, сейчас тяжело. Мы в AvitoTech хотим поддержать своих друзей из Онтико, и поэтому открываем доступ к видео с конференций, которые ещё не публиковались. Это доклады за 2019 год с Saint AppsConf, HighLoad++, DevOpsConf, FrontendConf, Product Fest и с последней TeamLead Conf.


      Инженеры Авито, которые выступали или были участниками конференций, вспомнили самые интересные доклады. Под катом — ссылки на плейлисты со всеми-всеми видео и наша субъективная подборка.


      UPD: добавили в статью плейлисты с UseData и GolangConf 2019.


      Читать дальше →
      • +48
      • 22,5k
      • 4
    • Хьюстон, у нас проблема. Дизайн систем на отказ

        В 1970 г. американские инженеры запустили аппарат Аполлон-13 к Луне. На борту три батареи топливных элементов, беспокоиться не о чем, всё надежно и многократно продублировано. Но никто не мог предположить, что взрыв кислородного баллона выведет из строя две батареи из трёх. Трагедия! Астронавты вернулись домой, о событии сняли художественный фильм с Томом Хэнксом, а фраза астронавта Джека Свигерта: «Хьюстон, у нас проблема!», вошла в историю.



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

        Для больших распределенных систем такое поведение нормально, это следствие эффекта масштаба и статистики. Именно поэтому Design for Failure (дизайн на отказ) — базовый принцип проектирования облачных сервисов AWS. Системы изначально строятся так, чтобы максимально быстро восстановить штатную работу и минимизировать ущерб от известных и ещё неизвестных сбоев. На HighLoad++ Василий Пантюхин на примерах реальных проблем с боевыми сервисами показал паттерны проектирования распределенных систем, которые используют разработчики AWS.
        Читать дальше →
        • +21
        • 5,2k
        • 1
      • Холистическое управление знаниями в IT-компании

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



          КРОК – большая IT-компания, которая живёт в экономике знаний. Компания много лет занимается управлением знаниями и продает знания своих сотрудников (консалтинг). Технологии, компетенции, языки, практики — всё так быстро меняется, что это не модный тренд, а гигиена бизнеса.

          Алексей Сидорин — руководитель направления «Управление знаниями и корпоративными коммуникациями» в КРОК, евангелист больших данных, управления знаниями и цифровой экономики. На KnowledgeConf Алексей представил хронологию становления системы управления знаниями в КРОК с примерами и скриншотами. Читайте текстовую версию его доклада, чтобы узнать, как построить самоуправляемую базу знаний и геймифицировать управление знаниями.
          Читать дальше →
          • +21
          • 5,1k
          • 2
        • Могут ли контейнеры быть безопасными?

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

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


            О спикере: Александр Хаёров (allexx) 10 лет занимается разработкой, в основном веб-проектами, связанными с инфраструктурой, а сейчас руководит разработкой в Chainstack. В этой должности приходится примерять на себя самые разные роли и заниматься всем: от классической разработки до принятия технических решений и управления людьми. Это позволяет исследовать разные темы, в том числе ту, о которой пойдет речь в статье — далее от первого лица.
            Читать дальше →
          • Что может квантовый компьютер

              Квантовая физика родилась в 1900 году, когда Макс Планк предположил, что энергия поглощается не непрерывно, а отдельными порциями — квантами. Его идея получила дальнейшее развитие: фотоэлектрический эффект Эйнштейна, теория атома Бора, Резерфорд опытным путем показал, как выглядит ядро атома, Луи де Бройль стер границу между волнами и материей, Гейзенберг и Шрёдингер разработали квантовую механику.

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

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


              Анатолий Дымарский (Сколтех) — физик-теоретик, работает в области физики квантовых систем. Анатолий расскажет, чем квантовый компьютер отличается от обычного и что сулят его возможности IT-индустрии.
              Читать дальше →
            • Базы, карты, чек-листы, или Зачем бизнесу управляющий знаниями

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



                Позже Гарри Клейн опрашивал командира, чтобы собрать материал для книги и ему удалось разобрать его интуитивное решение на части: огонь на кухне был слабым, но при этом слишком много жара и дыма для такого пламени. Командир почувствовал, что ситуация опасная и вывел команду. Это пример «неявного знания», которое спрятано так глубоко, что оно проявляется только в реальной ситуации.

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

                  В HTTP/2 появилась компрессия стандартных заголовков, но тело URI, Cookie, значения User-Agent по-прежнему могут составлять десятки килобайт и требуют токенизации, поиска и сравнения подстрок. Задача становится критичной, если HTTP-парсер должен обрабатывать интенсивный злонамеренный трафик. Стандартные библиотеки предоставляют обширный инструментарий обработки строк, но у HTTP-строки есть своя специфика. Именно для этой специфики разработан HTTP-парсер Tempesta FW. Его производительность в несколько раз выше по сравнению с современными Open Source решениями и превосходит быстрейшие из них.


                  Александр Крижановский (krizhanovsky) основатель и системный архитектор Tempesta Technologies, эксперт в области высокопроизводительных вычислений в Linux/x86-64. Александр расскажет об особенностях структуры HTTP-строк, объяснит, почему стандартные библиотеки плохо подходят для их обработки, и представит решение Tempesta FW.

                  Под катом: как HTTP Flood превращает ваш HTTP-парсер в узкое место, проблемы x86-64 с branch mispredictions, кэшированием и не выровненной памятью на типичных задачах HTTP-парсера, сравнение FSM с прямыми переходами, оптимизация GCC, автовекторизация, strspn()- и strcasecmp()-like алгоритмы для HTTP-строк, SSE, AVX2 и фильтрация инъекционных атак с использованием AVX2.
                  Читать дальше →
                • Методы борьбы с legacy-кодом на примере GitLab

                    Можно бесконечно холиварить о том, является ли GitLab хорошим продуктом. Лучше посмотреть на цифры: по итогам раунда инвестирования оценка GitLab составила 2,7 млрд долларов, в то время как предыдущая оценка была $1,1 млрд. Это означает бурный рост и то, что компания будет нанимать все больше и больше фронтенд-разработчиков.

                    Так выглядит история появления фронтенда в GitLab.



                    Это график количества фронтендеров в GitLab, начиная с 2016 года, когда их не было вообще, и заканчивая 2019-м, когда их стало уже несколько десятков. Но сам GitLab существует 7 лет. Значит, до 2017 года основной код на фронтенде писали бэкенд-разработчики, хуже того, бэкенд-разработчики на Ruby on Rails (ни в коем случае никого не хотим обидеть и ниже поясним, о чем идет речь).

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

                    Читать дальше →
                    • +33
                    • 7,8k
                    • 5
                  • Чего боятся тимлиды и почему им пора перестать это делать

                      Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.

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


                      Читать дальше →
                    • «Больше интерактива!» или Как прошел TeamLead Conf 2020

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

                        Месяц назад отгремел московский TeamLead Сonf 2020, пробив потолок в количестве тимлидов на кв.м — 1500 участников слетелись на площадку ЦМТ. Зачем их собрали и что с ними делали на конференции — расскажем тут. Если кратко: «Бог гРома» повелел смотреть доклады, участвовать в воркшопах и заниматься священным нетворкингом.


                        Читать дальше →
                      • Тестируем на проде: Canary Deployment

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



                          Подобная практика нашла себя и в IT. Например, в стандартной задаче деплоя новой версии сервиса или приложения на продакшн с тестированием перед этим. Тестовое окружение может быть слишком дорогим, автоматизированные тесты не покрывают все, что хотелось бы, а не тестировать и жертвовать качеством рискованно. Как раз в таких случаях помогает подход Canary Deployment, когда немного настоящего продакшн-трафика пускается на новую версию. Подход помогает безопасно проверить новую версию на продакшн, жертвуя малым ради большой цели. Подробнее, как работает подход, чем полезен и как его реализовать, расскажет Андрей Маркелов (Andrey_V_Markelov), на примере реализации в компании Infobip.
                          Читать дальше →
                          • +22
                          • 4,5k
                          • 6
                        • NoVerify: PHP-линтер, который работает быстро

                            Для PHP есть хорошие утилиты статического анализа: PHPStan, Psalm, Phan, Exakat. Линтеры хорошо выполняют свою работу, но очень медленно, потому что почти все написаны на PHP (или Java). Для личного использования или небольшого проекта это нормально, но для сайта с миллионами пользователей — критический фактор. Медленный линтер замедляет CI pipeline и не даёт возможности использовать его в качестве решения, интегрируемого в текстовый редактор или IDE.



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

                            Подходящих линтеров на рынке нет, поэтому Юрий Насретдинов (youROCK) из ВКонтакте написал свой в помощь командам разработки — NoVerify. Это линтер для PHP, который написан на Go. Он работает в 10-30 раз быстрее аналогов, может находить то, о чем не предупредит PhpStorm, легко расширяется и хорошо интегрируется в проекты, в которых раньше не слышали о статическом анализе. 

                            Об этом линтере расскажет Искандер Шарипов. Под катом:как выбирали линтер и предпочли написать свой, почему NoVerify такой быстрый и как устроен изнутри, почему написан на Go, что может находить и как расширяется, на какие компромиссы пришлось пойти ради него и что можно построить на его базе.
                            Читать дальше →
                            • +33
                            • 5,9k
                            • 7
                          • Без управления знаниями больно: 5 основных последствий отсутствия системы

                              Toyota — мировой лидер автомобилестроения, один из самых дорогих автомобильных брендов и синоним слова «качество». Toyota известна своей сложной производственной системой, благодаря которой она стала мировым лидером. На её описание потребовалось 10 лет и 20 версий, в итоге появился документ «Философия Toyota 2001». Часть принципов из этой книги — кайдзен и канбан — используются в IT. Но эти принципы лишь часть системы постоянного обучения и непрерывного совершенствования, которая плотно интегрирована во все процессы корпорации.



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

                              История Toyota — отличный пример управления знаниями. Но что будет, если знаниями не управлять, а систему не выстраивать? Велосипеды, сломанные конвейеры, автобусы, «сжигание» денег на онбординге и legacy — все это случается с компаниями, когда они не задумываются об управлении знаниями.
                              Читать дальше →
                            • Кто такой техлид и почему он нужен команде

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

                                Но в нашей индустрии даже градация должностей junior/middle/senior колоссально отличается от компании к компании. Что уж говорить о техлиде, который и вовсе не должность, а роль. Поэтому решили разобраться, что вкладывают в это понятие чаще всего. Заодно очертить зоны ответственности, сформулировать ключевые навыки техлида и понять, наконец, чем техлид отличается от тимлида (Спойлер: тимлид — это тоже роль, поэтому один человек может одновременно быть и техлидом, и тимлидом. А может и не быть).

                                Читать дальше →
                                • +28
                                • 11,2k
                                • 3
                              • Как писать безопасный Python-код. Отвечает Кушал Дас

                                  Here is the original English version of this interview.

                                  В этом году компания спикеров Moscow Python Conf++ подобралась что надо (то есть как, подобралась — Программный комитет подобрал). Но кому интересно изучать достижения, куда интереснее, что спикер думает по поводу волнующих нас самих вопросов. Чтобы это узнать, получить инсайдерскую информацию или совет более опытного разработчика, и нужно общаться на конференциях. Но я воспользовался положением и взял небольшое интервью у нашего докладчика Кашала Даса (Kushal Das).

                                  Отличительная черта выступлений Кушала в том, что он регулярно обнародует «секретные» способы сломать Python-код и в противовес показывает, как написать код так, чтобы АНБ не смогло его взломать. На нашей конференции Кушал расскажет, как безопасно разрабатывать и деплоить Python-код, поэтому о безопасности я его и расспрашивал.

                                  Читать дальше →
                                • Истории аварий с Patroni, или Как уронить PostgreSQL-кластер

                                    В PostgreSQL нет High Availability из коробки. Чтобы добиться HA, нужно что-то поставить, настроить — приложить усилия. Есть несколько инструментов, которые помогут повысить доступность PostgreSQL, и один из них — Patroni.

                                    На первый взгляд, поставив Patroni в тестовой среде, можно увидеть, какой это прекрасный инструмент и как он легко обрабатывает наши попытки развалить кластер. Но на практике в production-среде не всегда всё происходит так красиво и элегантно. Data Egret начали использовать Patroni еще в конце 2018 года и накопили определенный опыт: как его диагностировать, настраивать, а когда вовсе не полагаться на автофейловер.

                                    На HighLoad++ Алексей Лесовский обстоятельно, на примерах и с разбором логов рассказал о типовых проблемах, возникающих при работе с Patroni, и best practice для их преодоления.


                                    В статье не будет: инструкций по установке Patroni и примеров конфигураций; проблем за пределами Patroni и PostgreSQL; историй, основанных на чужом опыте, а только те проблемы, с которыми в Data Egret разобрались сами.
                                    Читать дальше →
                                    • +18
                                    • 5,1k
                                    • 1
                                  • Инструменты Domain Driven Design

                                      Синий кит — отличный пример того, как проектирование сложного проекта пошло не по плану. Кит внешне похож на рыбу, но он млекопитающее: кормит детенышей молоком, у него есть шерсть, а в плавниках до сих пор сохранились кости предплечья и кистей с пальцами, как у сухопутных. Он живет в океанах, но не может дышать под водой, поэтому регулярно поднимается на поверхность глотнуть воздуха, даже когда спит. Кит самое большое животное в мире, длиной с девятиэтажный дом, а массой как 75 автомобилей Volkswagen Touareg, но при этом не хищник, а питается планктоном.

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



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

                                      Что такое DDD и какие инструменты в нем есть, мы расскажем в статье на основе доклада Артема Малышева. Подход DDD в Python, инструменты, подводные камни, контрактное программирование и проектирование продукта вокруг решаемой проблемы, а не используемого фреймворка — все это под катом.
                                      Читать дальше →
                                    • Естественное развитие: как перейти от e-learning к управлению знаниями

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



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

                                        Как получать максимум от «инвестиций» и создать e-learning курс, который будет использоваться много раз и работать как база знаний, развиваться, дополняться и формировать вокруг себя активное сообщество, расскажет Елена Тихомирова. Елена — CEO eLearning Center, архитектор систем обучения, педагогический дизайнер, автор книги «Живое обучение: как заставить e-learning работать» о стратегии внедрения и развития электронного обучения.
                                        Читать дальше →
                                        • +17
                                        • 2,9k
                                        • 1
                                      • Долой техдолг! На TechLead Conf 2020 расскажем как


                                          Привет!


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


                                          Но нашу команду поджидали две серьезные проблемы.

                                          Читать дальше →
                                        • Как заставить машину написать тесты из кода за тебя

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

                                            Юлия Волкова хочет проверить идею в реальности и пробует переложить на машину создание тестов на основе кода, причем без использования дополнительных инструкций или контрактов. О том, какие открытия приносит путешествие в мир метапрограммирования, AST, синтаксического анализа и токенизации, и чего это все позволило добиться в автогенерации тестов, Юлия расскажет на Moscow Python Conf++. А пока я расспросил, откуда появилась сама идея — автоматизировать тестирование, что лежит в основе прототипа и с чем еще предстоит справиться.
                                            Читать дальше →
                                            • +22
                                            • 7,7k
                                            • 8

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