company_banner
  • Базы, карты, чек-листы, или Зачем бизнесу управляющий знаниями

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



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

      Вытягивать «неявные знания», которые особенно помогают в экстренных ситуациях — одна из задач менеджера по управлению знаниями. Например, упал продакшн, серверы отказываются работать, но никто не знает почему. При этом полгода назад случалось что-то подобное и проблему решил Петя: «подшаманил», подкрутил и все заработало. Правда, Петя ушел в другую компанию, а ретроспективу не проводили, в базу знаний происшествие и решение не добавляли, потому что и базы-то никакой нет. Но если бы в команде был управляющий знаниями, возможно, последствий было бы меньше, а проблема бы решилась быстрее.
      Читать дальше →
    • Алгоритмы быстрой обработки 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.
        Читать дальше →
        • +37
        • 6,4k
        • 1
      • Методы борьбы с legacy-кодом на примере GitLab

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

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



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

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

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

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

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


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

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

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


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

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



                Подобная практика нашла себя и в IT. Например, в стандартной задаче деплоя новой версии сервиса или приложения на продакшн с тестированием перед этим. Тестовое окружение может быть слишком дорогим, автоматизированные тесты не покрывают все, что хотелось бы, а не тестировать и жертвовать качеством рискованно. Как раз в таких случаях помогает подход Canary Deployment, когда немного настоящего продакшн-трафика пускается на новую версию. Подход помогает безопасно проверить новую версию на продакшн, жертвуя малым ради большой цели. Подробнее, как работает подход, чем полезен и как его реализовать, расскажет Андрей Маркелов (Andrey_V_Markelov), на примере реализации в компании Infobip.
                Читать дальше →
                • +22
                • 8,3k
                • 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
                  • 8,3k
                  • 9
                • Без управления знаниями больно: 5 основных последствий отсутствия системы

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



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

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

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

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

                      Читать дальше →
                      • +28
                      • 22,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
                          • 9,6k
                          • 1
                        • Инструменты Domain Driven Design

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

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



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

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

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



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

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


                                Привет!


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


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

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

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

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

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


                                    Здесь и далее кадры из сериала «Рик и Морти». Авторы Джастин Ройланд и Дэн Хармон.

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

                                    Кирилл Борисов 12 лет в индустрии, за эти годы прошел долгий путь по костылям, битому коду и гниющим каркасам старых систем: от монолитных учетных систем до микросервисов авторизации. Путешествие наградило его опытом и историями, которыми он поделится в виде ценных советов.
                                    Читать дальше →
                                    • +20
                                    • 5,9k
                                    • 6
                                  • Взгляд изнутри на надёжность сервисов Facebook

                                      Когда Facebook «лежит», люди думают, что это из-за хакеров или DDoS-атак, но это не так. Все «падения» за последние несколько лет были вызваны внутренними изменениями или поломками. Чтобы учить новых сотрудников не ломать Facebook на примерах, всем большим инцидентам дают имена, например, «Call the Cops» или «CAPSLOCK». Первый так назвали из-за того, что когда однажды соцсеть упала, в полицию Лос-Анджелеса звонили пользователи и просили его починить, а шериф в отчаянии в Твиттере просил не беспокоить их по этому поводу. Во время второго инцидента на кэш-машинах опустился и не поднялся сетевой интерфейс, и все машины перезапускали руками.

                                      Элина Лобанова работает в Facebook последние 4 года в команде Web Foundation. Участники команды зовутся продакшн-инженерами и следят за надежностью и производительностью всего бэкенда, тушат Facebook, когда он горит, пишут мониторинг и автоматизацию, чтобы облегчить жизнь себе и другим.



                                      В статье, основанной на докладе Элины на HighLoad++ 2019, расскажем, как продакшн-инженеры следят за бэкендом Facebook, какие инструменты используют, из-за чего возникают крупные сбои и как с ними справиться.
                                      Читать дальше →
                                      • +39
                                      • 13,4k
                                      • 5
                                    • Что мы узнали о SRE, когда обработали первые 150 тысяч продакшн-инцидентов

                                        Абсолютной надежности приложения или сервиса нельзя достичь. Пользователи этого не заметят из-за сбоев посредников — сотовых сетей или провайдеров, но при этом останутся без новых функций, потому что все разработчики будут заняты поддержанием стабильности. Но можно достичь того уровня надежности, которого будет достаточно, чтобы были довольны клиенты, бизнес и инженеры с разработчиками. В этом помогает концепция Site Reliability Engineering, которую ввел Google в 2003 году. Основная ее задача — предотвратить «футбол» с багами между разработкой и эксплуатацией.



                                        Концепция SRE содержит много «странных вещей». В SRE разработчики не только пишут код, но и следят за тем, как он работает в продакшне. Доступность и надежность приложений и сайтов начинается с измерения доступности в виде четких показателей и установки показателей надежности. Еще в SRE есть «право на ошибку» или Error Budget. Когда это «право» исчерпано, команда занимается повышением надежности. Если нет — работает над новыми функциями.

                                        Обо всем этом расскажет Матвей Кукуй. SLI, SLO и Error Budget, источники инцидентов и их особенности, инструкция по наведению порядка в мониторинге — об этом под катом через кейсы из реальной жизни.

                                        Читать дальше →
                                      • Android insets: разбираемся со страхами и готовимся к Android Q

                                          Android Q — это десятая версия Android с 29-м уровнем API. Одна из главных идей новой версии это концепция edge-to-edge, когда приложения занимают весь экран, от нижней рамки до верхней. Это значит, что Status Bar и Navigation Bar должны быть прозрачными. Но, если они прозрачны, то системный UI нет — он перекрывает интерактивные компоненты приложения. Эта проблема решается с помощью insets.

                                          Мобильные разработчики избегают insets, они вызывают у них страх. Но в Android Q обойти insets не удастся — придется их изучить и применять. На самом деле, в insets нет ничего сложного: они показывают, какие элементы экрана пересекаются с системным интерфейсом, и подсказывают, как переместить элемент, чтобы он не конфликтовал с системным UI. О том, как работают insets и чем они полезны, расскажет Константин Цховребов.

                                          Читать дальше →
                                          • +20
                                          • 21,4k
                                          • 8
                                        • На Moscow Python Conf++ приходите поговорить с разработчиками языка

                                            Мы строили-строили, и наконец построили: расписание Moscow Python Conf++ собрано, проверено, перепроверено и опубликовано. Не то чтобы работа Программного комитета на этом заканчивалась (за два-то месяца до конференции, ну-ну), но 10 месяцев явно потрачено не зря, и я с нетерпением жду результата, заложив все возможное для общения разработчиков друг с другом.

                                            Сейчас расскажу, какой получилась программа конференции, и выбора у нас просто не останется. На площадке в центре Москвы будет: 3 потока докладов, поток воркшопов и митапов, 4 Core-разработчика (я до сих пор не знаю, считать ли Python Core-разработчиком заведующего разработкой Pytest и Hypothesis), 6 зарубежных спикеров с нетривиальным опытом, доклады от Microsoft, Wargaming, JetBrains, Parallels, EPAM, Booking.com, Tinkoff и других не менее интересных компаний. Ни одной проходной темы, я проверил. Каждый докладчик по-своему интересен, и каждая тема точно найдет тех, кому есть что обсудить со спикером. В этой статье я максимально кратко расскажу обо всех наших гостях: акцент на спикерах, по темам вы и сами сориентируетесь.


                                            Читать дальше →
                                            • +15
                                            • 2,8k
                                            • 1

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