Виталий Чибриков Tully

И снова здравствуйте!

Мы продолжаем расширение тем, которые преподаются у нас. Вот теперь разработали и вывели курс «Product Owner». Автор курса Екатерина Марчук предлагает вам ознакомится со своей авторской статьёй и приглашает на открытый урок.

Как нам интерпретировать фидбек?

О customer development или развитии пользователей в последнее время говорят все кому не лень. И каждый, кто знаком с понятием, осознает, насколько это важно, а если говорить прямо — жизненно необходимо для успешного запуска продукта.

Customer develoment помогает понять ценность продукта, выявить скрытые мотивы потребителей, их реальные проблемы и потребности. И самое главное, custdev позволяет нам проверять гипотезы. Без проверки гипотез сложно вести проект в правильном направлении, потому что, как показывает практика, голые цифры, увы, не репрезентативны.

Но, как водится, на чисто теоретическом понимании всё и заканчивается. У нас же ни на что не хватает времени, в том числе — и на такие важные задачи.

Docker Compose обладает целым рядом нетривиальных способов применения, которые мы рассмотрим в этой заметке. Это очередной перевод статьи, которую мы разбирали при подготовке материалов нашего курса Python для Web-разработки.

Контроль порядка запуска

Docker Compose запускает контейнеры в порядке зависимостей, используя опцию depends_on, чтобы указывать, когда запускается сервис. Для определения порядка запуска Compose применяет depends_on, links, volumes_from и network_mode: «service: ...».

Если контейнер должен дождаться состояния “ready” другого контейнера, можно использовать инструменты wait-for-it или dockerize. Они будут проверять хосты и порты до тех пор, пока TCP соединение не будет подтверждено. Для включения принудительного ожидания в композицию необходимо добавить entrypoint:

version: '2'

services:
    web:
        build: .
        ports:
            - "80:8000"
        depends_on:
            - db
        entrypoint: "./wait-for-it.sh db:5432"
    db:
        image: postgres

Вы всегда можете самостоятельно написать скрипт-обёртку, если возникнет необходимость в усилении контроля.

При подготовке материала для курса, нам периодически попадаются интересные статьи, которыми хотелось бы поделиться с вами!

Автор Stefan Scherfke “Testing (asyncio) coroutines with pytest”



PyTest — отличный пакет для тестирования на Python, и с давних пор один из моих любимых пакетов в целом. Он значительно облегчает написание тестов и обладает широкими возможностями по составлению отчетов о непройденных тестах.

Тем не менее, на момент версии 2.7, он менее эффективен в тестировании (asyncio) подпрограмм. Поэтому не стоит пытаться их тестировать таким способом:

# tests/test_coros.py

import asyncio

def test_coro():
    loop = asyncio.get_event_loop()

    @asyncio.coroutine
    def do_test():
        yield from asyncio.sleep(0.1, loop=loop)
        assert 0  # onoes!

    loop.run_until_complete(do_test())

В таком методе много недостатков и излишеств. Единственные интересные строки — те, что содержат операторы yield from и assert.

Дэймон Эдвардс / 8 ноября, 2010

С того момента как Патрик Дебуа организовал первую конференцию DevOps Days и явил миру термин “DevOps” не может быть сомнений, что DevOps развился до уровня глобального движения.

Безусловно, DevOps движение имеет своих хулителей. Негативные мнения варьируются от ошибочных («DevOps — это новое название для сисадминов») и пренебрежительных («DevOps — это просто какие-то безумные разработчики (Devs), которые пытаются избавиться от админов (Ops)» или «DevOps — это какие-то безумные админы, которые хотят казаться разработчиками, чтобы их больше любили») до выражений обиды (как правило, с аргументами, не поддающимися логике).

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

DevOps это не проблема технологий.

Технологии играют ключевую роль в создании решений тех проблем, которые пытается решить DevOps. Однако, DevOps, по своему определению, является проблемой бизнеса.

Какое отношение бизнес имеет к DevOps?
Основополагающий бизнес-процесс в любой компании — взять идею от момента ее рождения в голове и донести ее туда, где она будет приносить деньги.

Нас тут частенько обвиняют в том, что мы пишем рекламные статьи, цель которых “опять пропиарить свои курсы”. Поэтому сегодня мы не будем говорить о том, что скоро стартанет курс “DevOps практики и инструменты” — нет.

Сегодня мы хотим поделиться с вами методом розыгрыша, который придумали наши преподаватели — инженеры компании Экспресс 42. Статьи про методы розыгрыша, как показывает статистика, тоже не все любят читать, но ирония судьбы (на последнем розыгрыше мест на курсе “WEB разработчик” оба победителя — читатели Хабра) просто требует, чтобы мы продолжали писать :)

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

Какие знания необходимы современному, а главное востребованному веб-разработчику?

За скобками остается базовое умение писать код и всё что связано с умением работать в команде и иные очевидные вещи. Для нашей программы курса «Web-Разработчик», который стартует 5 августа, мы очертили именно следующий круг знаний и скилов, считая их основополагающими в специальности:

Во-первых, код ревью: стоит писать такой код, чтобы он был повторно используем, понятен и прост, сюда относятся DRY, KISS, цикломатическая сложность, читаемость, преждевременная оптимизация, чистые функции, статический анализ, соблюдение style guide и инструменты для отслеживания всего этого. Это как дизайн или психология: каждый считает себя экспертом, но далеко не каждый таковым является на деле — тут важны чёткие принципы, системный подход конечно же практика.

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

Всем привет! У нас появился классный персонаж, который отлично иллюстрирует жизнь любого, причастного к миру IT…

Баталии за выкатки в прод по пятницам, костыльные решения и спешка перед дедлайном — стикеры для всех и для каждого!

Передать все что тебя переполняет одной картинкой — бесценно.



OTUS Coding Owl появилась в Telegram, чтобы выразить всю эту бурю эмоций! Добавляйте набор по ссылке — и наслаждайтесь!

В планах пополнение и дополнение набора!

Мы в OTUS снова рады открыть свои двери 30 июня и 1 июля в 20:00 по Москве для нового набора — теперь по курсу углубленного изучения Python.


Формат проведения — онлайн, подключайтесь из любой точки мира!

Давно ли вы участвовали в лотерее или розыгрыше? Приходилось ли вам самим их устраивать? Даже если ответы: никогда и нет, уверен, что вы знаете что это такое.

А какие у вас ассоциации от слов «лотерея» и «розыгрыш»? У меня — разноцветные шары с номерами и лотерейная машина, из которой разноцветные шары выпадают по одному и определяют победителя.

Вот и мне некоторое время назад понадобилось “определить” победителей розыгрыша бесплатных места на курс “Разработчик Java” в Otus.ru. Задача звучала просто: есть N email-ов, нужно выбрать среди них случайным образом M email-ов тех, кто будет учиться бесплатно.

Сложность задачи была в том, что это были email-ы всех, кто успешно прошел входное тестирование курса. То есть email-ы программистов. Я представил себе, как я “достаю из кармана” M email-ов и говорю: “Вот эти победили”. И… мне никто не верит. Даже если победители начинают радостно писать в общий чат: “Спасибо, как мы рады!”, мне все равно никто из оставшихся не поверит. Да я бы и сам не поверил, если бы мне просто сказали «победили эти».



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

Иллюстрация HttpSession в момент работы с куками
Эта статья обязана своим появлением новому требованию к курсу «Углублённое программирование на Java», который я веду в Технопарке Mail.Ru в МГТУ им. Баумана. Это требование было сформулировано в начале лета и звучало примерно так: «Ещё больше практики!».

В середине прошлого лета на программерскую рассылку отдела клиентских игр Mail.Ru Group пришло письмо – «Объявлен конкурс на позицию преподавателя курса Java в нашем совместном проекте с МГТУ им. Н. Э. Баумана». Как программист и сотрудник отдела я это письмо тоже получил. Как выпускник физтеха, а в прошлом преподаватель и научный работник, решил откликнуться.
Так для меня началась история работы преподавателем в Технопарке. Собственно об этом (о работе, о Технопарке, о своем курсе и о студентах) я и хочу вам рассказать.