На примере дейтинга Алексей Стрелков
(GetPure, inc) рассказывает на чем не только модно, но и удобно тестировать высоконагруженные проекты с нетривиальными сценариями взаимодействия с пользователями. И все это не отрываясь от любимого питона.
Написание юнит-тестов большинству представляется занятием скучным и до некоторой степени бесполезным. Мое мнение — это всё оттого, что сама "классическая" схема юнит-тестов подразумевает непродуктивное написание унылого линейного кода.
В докладе я расскажу о том, как с помощью pytest начать писать тесты, которые приятно читать и поддерживать, почему setUp и tearDown — это прошлый век, как с помощью правильной организации fixtures ускорить исполнение тестов, а также какие ещё уловки могут помочь вам в вашей нелегкой борьбе с рутиной.
Распространено мнение, что навык пакетирования своих наработок необходим только гуру в Open Source. Стас развенчал этот миф и показал несколько практических задач, решаемых при помощи пакетирования кода.
Применение behave+webdriver для тестирования Web-проектовPyNSK
Докладчик:
Иван Гребенщиков
Описание:
Современные веб-проекты представляют из себя совсем не набор статических страниц, что повышает сложность их функционального тестирования.
В докладе будет рассмотрена связка инструментов behave+webdriver, способе их применения, возможные проблемы и пути их решения.
В докладе мы рассмотрим создание переносимого дистрибутива Python для любых нужд и операционных систем (Windows & Linux). Познакомимся с существующими и альтернативными решениями. Сравним их достоинства и недостатки.
Докладчик: Григорий Кареев (Odin)
Видео: https://www.youtube.com/watch?v=fvBJG_IKvaQ
Stack Overflow как повседневный инструмент разработчикаGrigory Petrov
Николай Чабановский (Stack Exchange): в докладе будут освещены ответы на следующие вопросы: Зачем нужен Stack Overflow современному программисту? Как использовать Stack Overflow в повседневной деятельности? Как задавать вопросы на Stack Overflow, чтобы получить ответ? Каким образом сделать интернет лучше с помощью Stack Overflow?
Дмитрий Крюков (Parallels): Мы привыкли к тому, что джанга это фулстек фреймворк, который диктует нам достаточно четкую проектную структуру, однако мы же всё же попробуем разрушить этот миф. Поиздеваемся над Django? Превратим его во бутылеподобный фреймворк (Flask, Bottle)? Даешь велосипеды!!!
Написание юнит-тестов большинству представляется занятием скучным и до некоторой степени бесполезным. Мое мнение — это всё оттого, что сама "классическая" схема юнит-тестов подразумевает непродуктивное написание унылого линейного кода.
В докладе я расскажу о том, как с помощью pytest начать писать тесты, которые приятно читать и поддерживать, почему setUp и tearDown — это прошлый век, как с помощью правильной организации fixtures ускорить исполнение тестов, а также какие ещё уловки могут помочь вам в вашей нелегкой борьбе с рутиной.
Распространено мнение, что навык пакетирования своих наработок необходим только гуру в Open Source. Стас развенчал этот миф и показал несколько практических задач, решаемых при помощи пакетирования кода.
Применение behave+webdriver для тестирования Web-проектовPyNSK
Докладчик:
Иван Гребенщиков
Описание:
Современные веб-проекты представляют из себя совсем не набор статических страниц, что повышает сложность их функционального тестирования.
В докладе будет рассмотрена связка инструментов behave+webdriver, способе их применения, возможные проблемы и пути их решения.
В докладе мы рассмотрим создание переносимого дистрибутива Python для любых нужд и операционных систем (Windows & Linux). Познакомимся с существующими и альтернативными решениями. Сравним их достоинства и недостатки.
Докладчик: Григорий Кареев (Odin)
Видео: https://www.youtube.com/watch?v=fvBJG_IKvaQ
Stack Overflow как повседневный инструмент разработчикаGrigory Petrov
Николай Чабановский (Stack Exchange): в докладе будут освещены ответы на следующие вопросы: Зачем нужен Stack Overflow современному программисту? Как использовать Stack Overflow в повседневной деятельности? Как задавать вопросы на Stack Overflow, чтобы получить ответ? Каким образом сделать интернет лучше с помощью Stack Overflow?
Дмитрий Крюков (Parallels): Мы привыкли к тому, что джанга это фулстек фреймворк, который диктует нам достаточно четкую проектную структуру, однако мы же всё же попробуем разрушить этот миф. Поиздеваемся над Django? Превратим его во бутылеподобный фреймворк (Flask, Bottle)? Даешь велосипеды!!!
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
Мир мобильных телефонов очень сильно изменил нашу жизнь. В наше время невозможно представить современного человека, без этого чудо устройства. На рынке появляется все больше устройств и приложений. И чтобы удобнее пользоваться этими приложениями пользователи выбирают “умные” телефоны, или как их еще принято называть смартфоны. В своем докладе я хочу поделиться своим опытом автоматизации приложений под Android и iOS. Я расскажу о том, какие инструменты автоматизации я использовал. Поговорим о недостатках этих инструментов и какие из них стоит использовать у себя на проекте.
Докладчик:
Александр Сапронов
Описание:
Мы рассмотрим популярные библиотеки для функционального программирования на Python — fn.py, functools, itertools, funcy, hask, Toolz. Узнаем возможности каждой из библиотеки, а также как в динамическом язык имитировать мощную систему типов. Затронем характеристики функционального программирования и проверим помогают ли библиотеки выполнить.
Рано или поздно возникает необходимость в собственных инструментах по разным причинам: либо не хватает готовых, либо есть какая-то особенность в проекте. Разработка инструментов, работающих в браузере, является непростой задачей. Самое сложное — чтобы они умели работать удаленно, вне страницы. Это многих пугает — нужно много сделать и во многом разобраться. Но если большая часть проблем уже решена, и можно сосредоточиться лишь на основной функции инструмента? Что если такие инструменты смогут работать в произвольном WebView, будь оно встроено в браузер, редактор или другое приложение на любом устройстве? Доклад про удалённые инструменты: какие есть сложности и как их обойти, как перестать бояться и начать делать инструменты под свои задачи и технологический стек.
37. Сухой остаток
• Все тесты пишутся на питоне
• Удобный веб-интерфейс (можно не использовать)
• Все опенсорсное и хакабельное
• Легко масштабировать
• Вы сами определяете, что считать ошибкой
• Смоук-тесты нахаляву :3
38. Недостатки
• monkey-patching для записи статистики ramp-up
периода
• ловит не все ошибки (например из on_start() ), но
все есть в stdout
• интервалы между тасками равны интервалам
TaskSet.wait()
• мелкие баги (запуск с неправильным
протоколом)
39. Полезные ссылки
• locust.io – сайт Locust
• https://github.com/locustio/ - репозиторий
Locust
• getpure.org - Pure, уже на iOS, скоро Android
(записывайтесь в бета-тестеры!)
• theuntitled.net - присылайте ваш стартап на
рассмотрение (info@theuntitled.net)