Таймеры, события и GitHub

Таймер в эмуляции событийного подхода через mainloop() на самом деле не так просто сделать.

GitHub

При разработке проекта необходимо выстраивать информационное пространство

На примере GitHub

Ведение совместного репозитория:

  1. «merge»-схема (классическая)

    • Каждый участник проекта ведёт свой публичный репозиторий, которой он синхронизует с проектом
    • Один из этих репозиториев считается финальным. Доступ на push в этот репозиторий (как и в любой другой при этой схеме) имеет либо вообще один человек (т. н. выпускающий), либо очень небольшая команда (в основном, на замену выпускающему)

      • Выпускающий часто сопровождает и второй — линейный — репозиторий, в котором он ведёт свою часть разработки

      • GutHub рассылает уведомления об обновлениях в основном репозитории

    • Когда приходит пора, разработчик ставит в известность выпускающего, что его опубликованный код (обычно по определённому тегу) пора помержить (GitHub: pull request, часто — почтой, иногда какая-то автоматика конкретного портала, например, специально оформленный тег)

    • Выпускающий изучает соответствующий код, попутно исправляя и/или обсуждая с автором недочёты, и по по окончании процесса пуллит его.
  2. «push»-схема (историческая)

    • Работа ведётся в общем репозитории, доступ на push в который имеют все разработчики

    • Для параллельной разработке используются ветки, одна из которых объявляется основной
    • Когда приходит пора синхронизации, разработчик мержится с основной веткой, после чего пушит результат обратно в неё
    • GutHub рассылает уведомления об обновлениях

Merge-схема

Push-схема

ДЗ

Семестровый проект

Семестровый проект — это git-репозиторий с кодом на Python3,

  • который я могу установить (любым предложенным вами кроссплатформенным способом) и запустить

    • предпочтительно wheel

  • в котором есть более одного участника, и я могу посмотреть статистику участия (оба предложенных ниже измерения неидеальны, я это знаю)
    • по количество коммитов
    • по объёму кода
  • в котором flake8 (или pylint) находит не больше 5 ошибок (некоторые требования можно запрещать в config-файле)

  • в котором есть немножко тестов (с использованием любого тест-фреймворка, годится встроенный питоний)
    • должны быть покрыты модульными тестами все функции и классы, не использующие интерактивные возможности (т. е не GUI, не сетевое взаимодействие и т. п.)
    • таких функций/классов должно быть не менее 5
  • в котором есть немножко документации
    • описание проекта в README (в случае GitHub — README.md) и постановка задачи на GH

      • В случае GUI — проект интерфейса
        • не обязательно полностью совпадающий с тем, что получилось
        • достаточно детальный, чтобы было понятно, какой блок виджетов из чего состоит и за что отвечает
        • можно в виде картинки с исходниками из какого-то диаграммера, а можно и просто фоточки нарисованного от руки
    • /!\ (по возможности) программной (с использованием любого фреймворка, годится встроенный питоний, но можно и sphinx)

    • /!\ (по возможности) пользовательской (либо sphinx, либо прямо на GH)

  • в котором есть немножко локализации (с теми же оговорками по части фреймворков)
    • с использованием gettext или babel
    • обратите внимание на то, что, например, -.mo файлы надо сгенерировать и положить в дистрибутив вашего проекта (например, в wheel, как в лекциях)

Немножко — это реально немножко, чтобы я видел, что работа проделана. Например, если вы задумали какое-то приложение из реал лайфа, и в нём довольно много логики, обмазать всю её тестами будет долго. Но пяток должен быть.

Как начать

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

В репозитории уже должен быть файл README.md с постановкой задачи и (в случае GUI) проект интерфейса с коротенькими подписями, какой блок виджетов за то отвечает.

Если вы не знаете, какую задачу вам решать, или с кем скооперироваться, оформляете issue с просьбой выдать вам учебно-тренировочную задачу и/или подобрать товарища по команде.

Внимание!

Выдача задания и особенно подбор партнёра — случайный процесс, который может не привести к появлению команды/решаемой задачи!

LecturesCMC/PythonDevelopment2019/07_TimersAndGhtHub (last edited 2019-04-08 06:19:24 by FrBrGeorge)