Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019corehard_by
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
Облегчаем процесс разработки с помощью статического анализа кода: Наш опытAndrey Karpov
Статический анализ кода является очень полезным DevOps-средством, помогающим программистам при разработке крупных (и не только) проектов. К сожалению, с ним знакомы далеко не все программисты, а те, кто знаком — часто вспоминают их как «старые добрые lint'еры».
В своем докладе автор покажет, на что на самом деле способен современный статический анализ, а также расскажет о опыте внедрения анализатора в процесс разработки Unreal Engine 4.
Доклад будет полезен программистам всех уровней, руководителям, а также DevOps-специалистам, желающим повысить качество их проектов.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
SECON'2016. Бартунов Олег, Карьера в Open SourceSECON
Я расскажу про то, как устроен современный Open Source на примере проекта PostgreSQL и про те возможности, которые дает Open Source разработчику, в частности, в реализации себя как творческой личности и карьерного роста, а также достижения свободы и независимости. Open Source в условиях цифрового равенства позволяет разработчику жить и работать в привычных условиях без обязательного перемещения в неудобный для жизни мегаполис, и при этом быть членом большого международного сообщества, принимать участие в его жизни и влиять на развитие проекта.
Забытые проблемы разработки 64-битных программTatyanazaxarova
Хотя история развития 64-битных систем составляет более десятилетия, появление 64-битных версий операционной системы Windows поставило перед разработчиками новые задачи в области разработки и тестирования программных решений. В статье рассмотрены некоторые ошибки связанные с разработкой 64-битного Си/Си++ кода под операционную систему Windows. Объяснены причины, по которым данные ошибки не нашли отражения в статьях, посвященных задачам миграции и неудовлетворительно выявляются большинством статических анализаторов.
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019corehard_by
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
Облегчаем процесс разработки с помощью статического анализа кода: Наш опытAndrey Karpov
Статический анализ кода является очень полезным DevOps-средством, помогающим программистам при разработке крупных (и не только) проектов. К сожалению, с ним знакомы далеко не все программисты, а те, кто знаком — часто вспоминают их как «старые добрые lint'еры».
В своем докладе автор покажет, на что на самом деле способен современный статический анализ, а также расскажет о опыте внедрения анализатора в процесс разработки Unreal Engine 4.
Доклад будет полезен программистам всех уровней, руководителям, а также DevOps-специалистам, желающим повысить качество их проектов.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
SECON'2016. Бартунов Олег, Карьера в Open SourceSECON
Я расскажу про то, как устроен современный Open Source на примере проекта PostgreSQL и про те возможности, которые дает Open Source разработчику, в частности, в реализации себя как творческой личности и карьерного роста, а также достижения свободы и независимости. Open Source в условиях цифрового равенства позволяет разработчику жить и работать в привычных условиях без обязательного перемещения в неудобный для жизни мегаполис, и при этом быть членом большого международного сообщества, принимать участие в его жизни и влиять на развитие проекта.
Забытые проблемы разработки 64-битных программTatyanazaxarova
Хотя история развития 64-битных систем составляет более десятилетия, появление 64-битных версий операционной системы Windows поставило перед разработчиками новые задачи в области разработки и тестирования программных решений. В статье рассмотрены некоторые ошибки связанные с разработкой 64-битного Си/Си++ кода под операционную систему Windows. Объяснены причины, по которым данные ошибки не нашли отражения в статьях, посвященных задачам миграции и неудовлетворительно выявляются большинством статических анализаторов.
Мифы о DevOps / Александр Титов, Иван Евтухович (Экспресс 42)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 10:00
Тезисы:
http://rootconf.ru/2017/abstracts/2830.html
Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.
Мы не хотим рассказывать, что такое DevOps, а расскажем о мифах, которые вредят пониманию. Их не так много, но важно о них знать, потому что эти мифы для вас будут маркерами неправильных управленческих и инженерных решений:
1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.
...
"Разработка документации на программные интерфейсы". Светлана Каюшина, ЯндексYandex
В докладе речь пойдёт об организации процесса и инструментах разработки технической документации в Яндексе. Поговорим о локализации объёмных документов и сложной локализационной разметке исходных текстов, а также о технических средствах, применяемых для перевода. Главным же станет рассказ о подготовке примеров для программной документации. Также будет представлена новая песочница для RESTful API.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Как не подавиться большим старым проектомAndrey Karpov
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Rust позволяет писать быстрые и надёжные программы. Особенно когда они многопоточные. Это делает его хорошим выбором для написания серверной части разнообразных веб-приложений.
Но что для этого нужно? Зачем терпеть все эти длиннющие ошибки от borrow checker'а? Что с продуктивностью разработки? Где взять библиотеки? А что если библиотеки нет? Какой веб-фреймворк выбрать? Как отлаживать и профилировать код?
В своём докладе я отвечу на эти и другие вопросы. Ещё я расскажу, что нужно делать, чтобы обойти проблемные места, которые у Rust, конечно, тоже есть.
Всё это — на примере кода инфраструктурного сервера, обеспечивающего «всегда зелёный master» (commit gatekeeper, аналог homu и zuul).
Инструмент ChangelogBuilder для автоматической подготовки Release NotesPositive Hack Days
1. Основные понятия и определения: продукт, пакет, связи между ними.
2. Как узнать, какие изменения произошли в продукте?
3. Проблемы changelog и release note.
4. Решение: инструмент ChangelogBuilder для автоматической подготовки Release Notes
В докладе мы рассмотрим создание переносимого дистрибутива Python для любых нужд и операционных систем (Windows & Linux). Познакомимся с существующими и альтернативными решениями. Сравним их достоинства и недостатки.
Докладчик: Григорий Кареев (Odin)
Видео: https://www.youtube.com/watch?v=fvBJG_IKvaQ
Юрий Василевский «Автоматизация в XCode»
Yandex Mobile Camp в Санкт-Петербурге 2012
http://events.yandex.ru/events/yamobcamp/spb-may-2012/
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач. Мы обсудим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Yandex Mobile Camp в Санкт-Петербурге, 30 мая 2012
Юрий Василевский, ведущий разработчик EPAM Systems, Mobile Solutions
Тема: Автоматизация в XCode
Тезисы:
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач.
Мы рассмотрим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться.
Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).
Мифы о DevOps / Александр Титов, Иван Евтухович (Экспресс 42)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 10:00
Тезисы:
http://rootconf.ru/2017/abstracts/2830.html
Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.
Мы не хотим рассказывать, что такое DevOps, а расскажем о мифах, которые вредят пониманию. Их не так много, но важно о них знать, потому что эти мифы для вас будут маркерами неправильных управленческих и инженерных решений:
1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.
...
"Разработка документации на программные интерфейсы". Светлана Каюшина, ЯндексYandex
В докладе речь пойдёт об организации процесса и инструментах разработки технической документации в Яндексе. Поговорим о локализации объёмных документов и сложной локализационной разметке исходных текстов, а также о технических средствах, применяемых для перевода. Главным же станет рассказ о подготовке примеров для программной документации. Также будет представлена новая песочница для RESTful API.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Как не подавиться большим старым проектомAndrey Karpov
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
Rust позволяет писать быстрые и надёжные программы. Особенно когда они многопоточные. Это делает его хорошим выбором для написания серверной части разнообразных веб-приложений.
Но что для этого нужно? Зачем терпеть все эти длиннющие ошибки от borrow checker'а? Что с продуктивностью разработки? Где взять библиотеки? А что если библиотеки нет? Какой веб-фреймворк выбрать? Как отлаживать и профилировать код?
В своём докладе я отвечу на эти и другие вопросы. Ещё я расскажу, что нужно делать, чтобы обойти проблемные места, которые у Rust, конечно, тоже есть.
Всё это — на примере кода инфраструктурного сервера, обеспечивающего «всегда зелёный master» (commit gatekeeper, аналог homu и zuul).
Инструмент ChangelogBuilder для автоматической подготовки Release NotesPositive Hack Days
1. Основные понятия и определения: продукт, пакет, связи между ними.
2. Как узнать, какие изменения произошли в продукте?
3. Проблемы changelog и release note.
4. Решение: инструмент ChangelogBuilder для автоматической подготовки Release Notes
В докладе мы рассмотрим создание переносимого дистрибутива Python для любых нужд и операционных систем (Windows & Linux). Познакомимся с существующими и альтернативными решениями. Сравним их достоинства и недостатки.
Докладчик: Григорий Кареев (Odin)
Видео: https://www.youtube.com/watch?v=fvBJG_IKvaQ
Юрий Василевский «Автоматизация в XCode»
Yandex Mobile Camp в Санкт-Петербурге 2012
http://events.yandex.ru/events/yamobcamp/spb-may-2012/
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач. Мы обсудим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Yandex Mobile Camp в Санкт-Петербурге, 30 мая 2012
Юрий Василевский, ведущий разработчик EPAM Systems, Mobile Solutions
Тема: Автоматизация в XCode
Тезисы:
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач.
Мы рассмотрим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться.
Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).
Как мы собираем проекты в выделенном окружении в Windows DockerPositive Hack Days
1. Обзор Windows Docker (кратко)
2. Как мы построили систему билда приложений в Docker (Visual Studio\Mongo\Posgresql\etc)
3. Примеры Dockerfile (выложенные на github)
4. Отличия процессов DockerWindows от DockerLinux (Долгий билд, баги, remote-регистр.)
Алексей Лустин. Непрерывная проверка качества кода.ScrumTrek
Я расскажу о нашем двухлетнем опыте использования инженерной практики «Continious Inspection» и платформы SonarQube при организации кросс-языковой разработки в процессе «непрерывной поставки» (CI-CD для языков Java, C#, JavaScript, typeScript и Gherkin) при автоматизированном code-review.
2. IT Talk #32
IT Talk #
17 октября 2014
Колодяжный Иван
2
Управление зависимостями в
Python:
почему универсального решения
нет и как мы с этим боремся
3. IT Talk #32
• Доклад построен на реальном опыте. Все
совпадения с реальными проектами считаются
случайностями. При подготовке доклада ни один
пакет не пострадал ;)
3
4. IT Talk #32
О чем поговорим?
• Проблема:
– разные компоненты требуют разные версии
зависимостей
4
5. IT Talk #32
О чем поговорим?
• Проблема:
– разные компоненты требуют разные версии
зависимостей:
– Сервис А: SQLAlchemy<=0.8.99
– Сервис Б: SQLAlchemy>=0.9.7
5
6. IT Talk #32
О чем поговорим?
• Проблема:
– разные компоненты требуют разные версии
зависимостей
– управление пакетами: установка, обновление и
удаление
6
7. IT Talk #32
О чем поговорим?
• Проблема:
– разные компоненты требуют разные версии
зависимостей
– управление пакетами: установка, обновление и
удаление
• Решение:
– изоляция компонентов
– управление зависимостями
7
8. IT Talk #32
А также:
• Pip vs RPM/DEB
– Разработчики vs админы
• Virtualenv - не панацея,
Docker - тем более
VM - overhead!
• Серебряной пули нет!
8
11. IT Talk #32
Изоляция зависимостей
• Virtualenv
• Docker
• VMs
• Dev/Test/Stage
• Production
11
12. IT Talk #32
Начинаем изолировать код
• Сначала Virtualenv
– изолируем python-код
12
13. IT Talk #32
Начинаем изолировать код
• Сначала Virtualenv
– изолируем python-код
• Потом Docker
– изоляция C-ых расширений и библиотек
13
14. IT Talk #32
Начинаем изолировать код
• Сначала Virtualenv
– изолируем python-код
• Потом Docker
– изоляция C-ых расширений и библиотек
• Потом Virtual Machine
– а если нам нужно другое ядро?
14
15. IT Talk #32
Virtualenv: без фанатизма
• Отлично работает в dev-окружении
• (ну не считая моей проблемы на mac:( )
15
16. IT Talk #32
Virtualenv: без фанатизма
• Отлично работает в dev-окружении
• (ну не считая моей проблемы на mac:( )
• успешно работает в production на проектах
разных размеров
16
17. IT Talk #32
Virtualenv: без фанатизма
• Отлично работает в dev-окружении
• (ну не считая моей проблемы на mac:( )
• успешно работает в production на проектах
разных размеров
• 1) не решает проблему с зависимостями
• 2) прячет ее на потом
• 3) потом может не наступить
• если “потом” наступило - см №1 :)
17
18. IT Talk #32
Docker
• “Полноценная” ОС с минимумом накладных
расходов
• С-расширения разных версий
– а нужно ли?
• разные версии системных библиотек
18
19. IT Talk #32
VM
• Крайний случай, очень редко когда нужно
– контейнеров хватает в 80%
19
20. IT Talk #32
VM
• Крайний случай, очень редко когда нужно
– контейнеров хватает в 80%
• Docker++
– теперь у нас может быть другая ОС и другое
ядро
20
24. IT Talk #32
Python vs OS package
1. Религия
2. Постоянные споры разработчиков и
администраторов
• разработчики используют pip
• админы yum/aptitude/и т.д.
24
25. IT Talk #32
Python packages: что под
капотом?
• setup.py
• setup.cfg
• PEP-314, PEP-426
• код и другие файлы
• все.
25
33. IT Talk #32
requirements.txt
• Список зависимостей с указанием версий
– порядок имеет значение!
• Зеркало с пакетами
• Поддержка Git/Mercurial/SVN
• Архивы и директории
33
35. IT Talk #32
• Пакеты зависят от определенных версий
библиотек
35
36. IT Talk #32
• Пакеты зависят от определенных версий
библиотек
• Установить 2 версии можно, но
36
37. IT Talk #32
• Пакеты зависят от определенных версий
библиотек
• Установить 2 версии можно, но
• С этим нужно уметь и работать
• А уже есть много написанного кода…
37
38. IT Talk #32
• Пакеты зависят от определенных версий
библиотек
• Установить 2 версии можно, но
• С этим нужно уметь и работать
• А уже есть много написанного кода…
• Иногда, пакеты удаляют…
38
39. IT Talk #32
RPM/DEB: за и против
• Привычный способ для админов
устанавливать что-либо
• Поддержка из коробки Puppet/Chef
– есть официальный рецепт для pip
39
40. IT Talk #32
RPM/DEB: за и против
• Привычный способ для админов
устанавливать что-либо
• Поддержка из коробки Puppet/Chef
– есть официальный рецепт для pip
• Полный контроль за установленными
файлами
40
41. IT Talk #32
RPM/DEB: за и против
• Полный контроль за установленными
файлами
– конфликты при установке
– “корректное” обновление
– нет проблем с удаленными зависимостями
– каждый файл принадлежит конкретному пакету
41
42. IT Talk #32
RPM/DEB: за и против
• Публичные репозитории не содержат
актуальных версий пакетов
• приходится держать свои зеркала
• собрать пакет == собрать все зависимости
– зависимостей может быть много
– их нужно правильно прописать
– тестирование
42
43. IT Talk #32
RPM и python
• работает из коробки
– python setup.py bdist_rpm
– поддержка pre-/post-build events
– почти все, что можно в SPEC
43
44. IT Talk #32
DEB и python
• не работает из коробки
– есть несколько пакетов на PyPI, но все
достаточно старые
44
45. IT Talk #32
Подводя итог…
• PIP - простой и удобный способ, но все еще
достаточно сырой
45
46. IT Talk #32
Подводя итог…
• PIP - простой и удобный способ, но все еще
достаточно сырой
• RPM/DEB-пакеты - часто получается очень
долго и дорого
46
47. IT Talk #32
Подводя итог…
• PIP - простой и удобный способ, но все еще
достаточно сырой
• RPM/DEB-пакеты - часто получается очень
долго и дорого
• virtualenv - выглядит хорошим комормисом
47
48. IT Talk #32
Немного ссылок
• http://stackoverflow.com/questions/6344076/
differences-between-distribute-distutils-
setuptools-and-distutils2
• https://pip.readthedocs.org/en/latest/
• http://legacy.python.org/dev/peps/pep-0314/
• http://legacy.python.org/dev/peps/pep-0426/
• http://google.com
48