Привет, Хабр! Представляю вашему вниманию перевод статьи "Bookmark this if you are new to Python (especially if you self-learn Python)" в двух частях (1, 2) c простыми, но полезными советами и трюками в Python.

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

Уточнение: в настоящее время я использую Python 3.8. Если вы столкнулись с какими-либо проблемами во время запуска моих примеров, пожалуйста, проверьте, не связано ли это с вашей версией Python.

Ну что, как там ваши планы на изоляцию? Зимние вещи убрали? Желанные киношки посмотрели? Пылящиеся книжки прочитали? А до полезностей, как всегда, нет времени. Да ладно, не оправдывайтесь — для тех, кто никак не выкроит часок для просмотра видео с нашего канала на Ютубе, мы сделали быстроусвояемую статью. Имейте совесть, всего-то 15 минут вместо 60:)


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

Заключительная часть о том, как концепция Jobs-to-be-Done меняет принципы создания и улучшения IT-продукта. Третья часть перевода книги «Intercom про Jobs-to-be-Done». Главы с седьмой по девятую.

Первая часть
Вторая часть

Всем привет! Приглашаем QA-инженеров на наш первый митап по тестированию, посвящённый автоматизации.

Программа

«Автотесты, объединяющие подходы, платформы и сердца», Михаил Чирков, ivi.ru

Преимущества и недостатки кроссплатформенных автотестов (в нашем случае речь о платформах android и web), сложности реализации и пути решения проблем при выстраивании автотестирования from scratch, screenplay vs pageobject. А может быть выбирать и не нужно?

Доклад будет интересен как тем, кто только стоит перед выбором писать моноплатформенные тесты или кроссплатформенные, так и тем, кто уже определился с выбором.

Всем привет! Меня зовут Женя Суворов, я руководитель команды мобильной архитектуры в Авито. 4 апреля на нашем ютуб-канале и в социальных сетях мы проведем прямой эфир и обсудим, как в iOS-разработке удержать качество продукта на высоком уровне даже при сильном масштабировании проекта и команды.

Поговорим на разные темы: как понять, что твой проект вырос, и нужно менять подходы к разработке, какие сложности возникают, как правильно организовать командную работу, коснемся архитектуры и кодовой базы, сравним метрики разработки в маленьких и крупных проектах, а дальше — библиотеки, фреймворки, языки — глубже и интереснее. Сами не знаем, куда заведёт разговор. В дискуссии будут участвовать эксперты из Яндекса, Сбербанка, HeadHunter, OK.RU и Авито.

Под катом — примерные темы, которые планируем обсуждать (и предлагаем вам дополнить этот список), а также пароли и явки для тех, кто захочет присоединиться к трансляции. Добавляйте пост в закладки: после встречи обновим его и выложим видео.

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

Дано:

• вы разрабатываете и поддерживает сложный программный продукт, работающий на нескольких клиентах;
  
• у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;
  
• у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;
  
• ваши инженерные команды функциональны, то есть они не выделены на отдельные продуктовые направления, а решают задачи всех юнитов сразу, обслуживая определённую часть технологического стека;
  
• и, конечно, вы используете Jira!
  

Retrofit2 мне, как Android разработчику, нравится, но как на счет того, чтобы попробовать к качестве HTTP клиента Ktor? На мой взгляд, для Android разработки он не хуже и не лучше, просто один из вариантов, хотя если всё немного обернуть, то может получиться очень неплохо. Я рассмотрю базовые возможности с которыми можно будет начать пользоваться Ktor как HTTP клиентом — это создание запросов разных видов, получение raw ответов и ответов в виде текста, десериализация json в классы через конвертеры, логирование.

Как и обещали — мы все записали. Смотрим доклады и фотографии с QA митапа, который прошел в офисе роботов 25 сентября.

Если вы работаете в IT-компании, то, скорее всего, ваши процессы построены вокруг известного продукта Atlassian — Jira. На рынке есть множество таск-трекеров для решения тех же задач, в том числе open-source-решения (Trac, Redmine, Bugzilla), но, пожалуй, именно Jira имеет сегодня самое широкое распространение.

Меня зовут Дмитрий Семенихин, я тимлид в компании Badoo. В небольшом цикле статей я расскажу, как именно мы используем Jira, как настраивали её под свои процессы, что хорошего «прикрутили» сверху и как тем самым превратили issue-трекер в единый центр коммуникаций по задаче и упростили себе жизнь. В этой статье вы увидите наш флоу изнутри, узнаете, как можно «докрутить» свою Jira, и прочтёте о дополнительных возможностях инструмента, о которых могли не знать.

Статья ориентирована прежде всего на тех, кто уже использует Jira, но, возможно, испытывает сложности с интеграцией её стандартных возможностей в существующие в компании процессы. Также статья может быть полезна компаниям, которые используют другие таск-трекеры, но столкнулись с некоторыми ограничениями и подумывают о смене решения. Статья построена не по принципу «проблема — решение», в ней я описываю сложившийся инструментарий и фичи, построенные нами вокруг Jira, а также технологии, которые мы использовали для их реализации.

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

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



В третий выпуск Run Loop — подкаста про тех, кто делает продукты своими собственными руками — ведущие решили никого не звать. А рассказать о себе, потому что они тоже делают полезные и крутые вещи.

Роман Бусыгин ведущий разработчик Яндекс музыки для iOS.

Илья Царев Head of iOS в Альфа-банке.

Алексей Милеев Android разработчик App in the Air.

Оригинальная статья является размышления на тему почему документация в мире микросервисов критично необходима и как ее можно создавать и публиковать используя swagger. Пошаговой инструкцией по настройке она точно не является.

Когда нужно сделать несколько запросов к HTTP API, разработчик обычно берет свой привычный язык/фреймворк и быстро пишет аналог curl в коде: HTTP-запрос, минимальный контроль ошибок, query- или json-аргументы, парсинг json body с названиями полей в виде строк. Все это замечательно работает, пока проект не начинает расти и несколько вызовов не превращаются в несколько десятков, а куски низкоуровневого кода не начинают размножаться копипастой. А дальше — стандартный набор багов, рожденных копипастой, которые начинают понемногу есть время у разработчика.

Swagger/OpenAPI — один из «комбайнов» для работы с HTTP API. Это язык описания API (недавно произошло объединение проектов генератора и спеки), генераторы серверного и клиентского кода, документации, тестов — много всяких полезных штук. Под катом я покажу, как по «человеческому» описанию API на сайте компании в несколько строк кода составить OpenAPI-описание и сгенерировать клиент на Python. И чем такой клиент будет лучше, чем вручную написанный код.

11 августа в нашем офисе прошел Avito Mobile Testing Meetup — митап, полностью посвященный тестированию приложений на платформах iOS и Android. Говорили о качестве мобильного приложения — как понять, что оно работает должным образом, о нативных UI-тестах в iOS — что тестировать и какие инструменты помогут их улучшить. Обсуждали, что лучше использовать в тестировании Android-приложений — Appium или Espresso, и в end-to-end тестах — можно ли их организовать в больших мобильных проектах, и не только.

Кроме того, коллеги из Яндекса рассказывали о своём инструменте тестирования производительности мобильных телефонов, а мы представили телеграм-бота Гошу, который присматривал за всеми из-за угла, провели целых две викторины и наградили участников, приехавших на митап из Волгограда и Воронежа. В общем, получился настоящий фестиваль мобильного тестирования.

Под катом делимся впечатлениями, фото, видео, презентациями со встречи и отзывами слушателей.

У любого желающего писать программы для продукции фирмы Apple в жизни наступает такой момент, когда ему приходиться изучить новый язык программирования — Objective-C. Когда-то этот счастливый момент постиг и меня. А чтобы лучше запомнить основные особенности этого языка, решил законспектировать свои мысли во время осмысления его документации, которыми и делюсь с вами.

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

Систему сбора и анализа событий можно обобщённо назвать кликстримом. Расскажу о технической стороне кликстрима в Авито: устройство событий, их отправка и доставка, аналитика, отчёты. Почему хочется своё, если есть Google Analytics и Яндекс.Метрика, кому портят жизнь разработчики кликстримов и почему go-кодеры не могут забыть php.

Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы

Введение

Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.

Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.

Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Преподаватели курса Project management in IT — менеджеры из «МегаФона», OneTwoTrip, Redmadrobot составили список книг на лето, которые пригодятся каждому проджекту. Узнайте, зачем современному менеджеру древний военный трактат, что общего между котами и разработчиками и где ошибались CEO General Motors и Zappos.

24 января 2018 года в Яндексе прошёл первый Team Leader meetup. Мероприятие посетили в общей сложности порядка семидесяти руководителей разработки из различных компаний.

Мы хотели, чтобы участники встречи были активно вовлечены в дискуссию, поэтому сразу выбрали в качестве основного формат панельной дискуссии в противовес стандартным презентациям. Таким образом, в разговоре участвовали сразу несколько экспертов из ведущих IT-компаний: Яндекса, Mail.Ru, Skolkovo Foundation, Phillips Innivation Labs RUS, 1C GAMES STUDIO. У слушателей в зале была возможность реагировать на высказывания экспертов при помощи специального бота, который демонстрировал их эмоции в реальном времени на специальном экране, расположенном прямо в зале.

Также для нас было важным, чтобы встреча была интересна представителем самых разных специализаций, с этим связан и выбор темы. Наши эксперты занимаются бекенд- и фронтенд-разработкой, разработкой игр, исследованиями и так далее.

С момента первой встречи прошло уже несколько месяцев, и мы, наконец, готовы поделиться её результатами.

Я все еще не до конца понял, как так получилось, но в прошлом году я слово за слово подписался прочитать курс по Deep Learning и вот, на удивление, прочитал. Обещал — выкладываю!

Курс не претендует на полноту, скорее это способ поиграться руками с основными областями, где deep learning устоялся как практический инструмент, и получить достаточную базу, чтобы свободно читать и понимать современные статьи.

Материалы курса были опробованы на студентах кафедры АФТИ Новосибирского Государственного Университета, поэтому есть шанс, что по ним действительно можно чему-то научиться.