Различия между версиями 7 и 8
Версия 7 от 2023-03-21 00:26:39
Размер: 13476
Редактор: FrBrGeorge
Комментарий:
Версия 8 от 2023-03-26 17:40:51
Размер: 14243
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 109: Строка 109:
<!> Обратите внимание на то, что это сравнительно невинное изменение меняет протокол работы с сервером: помимо «просто» сообщений из чата появляется сообщение-ответ на ''определённую'' команду-запрос. Самый простой способ не запутаться — это ввести уникальный номер запроса сопровождать ответ им. Например, простое сообщение всегда начинается на пробел, а ответ на команду — на номер поданной в данном сеансе команды.

Не только Git…

(повторение) Git: DVCS

  1. Версионирование
  2. Хранение
  3. Работа с историей изменений в виде орграфа (сети)
    • Ветки
    • Изменение истории
  4. Информационное пространство:
    • Описание процесса (коммит сообщения)

    • Маркировка отдельных точек (теги)
      • В т. ч. аннотированные и подписанные теги

Организация взаимодействия при совместной разработке

Запрос на объединение

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

Модели ведения репозитория

Классическая модель

  • Один публичный репозиторий, т. н. «апстрим»
  • Разработчики синхронизуются с ним
  • Запросом на объединение является электронное письмо с приложенным набором патчей

    • в git есть поддержка этого процесса (git send-email)

  • Майнтейнер публичного репозитория делает git am и ревью, и публикует результат

Открытая модель:

  • Апстрим — один публичный репозиторий (т. н. «Precious source»), в котором собирается работа всех участников

    • в этот репозиторий делается только pull и review

    • если майнтейнер precious source сам тоже ведёт разработку, то в отдельном репозитории (вариант послабее — в отдельной ветке)
  • Разработчики синхронизуются с precious source
  • Индивидуальные публичные репозитории всех участников
  • Решённые (под)задачи участники публикуют в индивидуальных публичных репозиториях
  • Запросом на объединение является оповещение о готовности индивидуального репозиотрия к merge-у со стороны исполнителя (ссылка на commit-ish — коммит, тег, ветку и т. п.)

  • Майнтейнер апстрима делает git merge и ревью, и публикует результат

Модель общего хостинга:

  • В плане использования GIT совпадает с открытой моделью

  • Все дополнительные инструменты разработки могут быть привязаны к git или даже управляться тегами, но в самом git отсутствуют
  • Запрос на объединение — отдельный информационный объект в движке хостинга («pull request» для GitHub или «merge request» для GitLab); движок обеспечивает (полу)автоматическую его обработку и информационное пространство (обсуждение, ссылки и т. п.)

    • Важно: понятие merge/pull request в самом git отсутствует, и у него нет чёткого определения
  • Предоставляет тематическую социальную сеть с привязкой к исходным текстам и информационным объектам процесса разработки
  • Предоставляет технологические ресурсы по сборке и тестированию

Централизованная модель:

  • Один репозиторий для всех
  • Чёткие конвенции для push и pull
  • Использование веток в т. ч. для индивидуальной разработки
    • Решённые (под)задачи участники публикуют в том же самом репозитории в специально выделенных личных ветках разработки
  • Важно: раздельных прав доступа на части репозитория в git нет, это или договорённости или дополнительные свойства площадки
  • (А ещё это сводит на нет все достоинства DVCS)
  • Тем не менее этот вариант эффективен для малых сообществ с единым управлением и большим количеством нецифрового общения (например, команда, целиком сидящая в офисе)
    • <!> Мы не будем использовать этот вариант в семестровых проектах (таково условие)

Пример параллельной разработки

TODO

Ветки и индивидуальные публичные репозитории — ортогональные сущности

  • Ветки — для эшелонирования работ (например, разработки новой функциональности или разделения на devel - testing - production)
  • Индивидуальные публичные репозитории — для разделения областей ответственности по исполнителям
  • В индивидуальном репозитории могут быть какие угодно ветки, например, один и тот же человек может
    1. заниматься разработкой новой фичи — иметь соответствующую ветку в своём публичном репозитории и слать pull-request-ы в ветку newfeature апстрима

    2. заниматься багфиксом релизов и слать pull-request-ы в ветку production апстрима

Работа с несколькими удалёнными репозиториями

git remote (ещё тут)

  • Общая история
  • Произвольная синхронизация
  • Но: нет встроенных инструментов уведомления
    • (actually, есть — email — но даже он требует инфраструктуры ≠ git: почтовых серверов, email-клиентов и т. п.)

Cmd и асинхронные сообщения

Проблема: ввод командной строки с помощью readline, подстановка в cmd и прочее — синхронные операции. Предположим, пользователь вводит команду, а в это время прилетает сообщение. Что делать?

Воспользоваться одновременно asyncio и синхронной обработкой ввода нельзя.

Решение: воспользуемся тем, что полученное сообщение надо просто вывести на экран.

  • Это можно делать в отдельном процессе (см. multiprocessing) или в отдельном потоке (см. threading). Оба варианта выводят текст на тот же stdout, что и основная программа.

  • Нам понадобится заново вывести

    1. Подсказку cmd (её можно взять из самой командной строки)

    2. Текст, который пользователь начал вводить в cmd, но ещё не нажал перевода строки. Этот текст доступен в буфере библиотеки readline ( /!\ на Windows может не работать)

   1 import cmd
   2 import threading
   3 import time
   4 import readline
   5 
   6 
   7 class simple(cmd.Cmd):
   8 
   9     def do_echo(self, arg):
  10         print(arg)
  11 
  12 
  13 def spam(cmdline, timeout, count):
  14     for i in range(count):
  15         time.sleep(timeout)
  16         print(f"\nI'm a message № {i}!\n{cmdline.prompt}{readline.get_line_buffer()}", end="", flush=True)
  17 
  18 
  19 cmdline = simple()
  20 timer = threading.Thread(target=spam, args=(cmdline, 3, 10))
  21 timer.start()
  22 cmdline.cmdloop()

Д/З

Основное задание

  1. Написать простой netcat-образный клиент для «коровьего чата» из задания по прошлой лекции. Достаточно модифицировать последний пример из лекции. Написать cmd-поддержку команд чата в клиенте и обеспечить completion по именам коров.

    • В login completion должен сначала выполнять cows на сервере, и предлагать результаты оттуда

    • Аналогично, в say completion должен сначала выполнять who на сервере, и предлагать результаты оттуда

  2. Разработку клиента вести согласно дисциплине оформления коммитов в подкаталоге 06_SocialProject отчётного репозитория по Д/З

<!> Обратите внимание на то, что это сравнительно невинное изменение меняет протокол работы с сервером: помимо «просто» сообщений из чата появляется сообщение-ответ на определённую команду-запрос. Самый простой способ не запутаться — это ввести уникальный номер запроса сопровождать ответ им. Например, простое сообщение всегда начинается на пробел, а ответ на команду — на номер поданной в данном сеансе команды.

Регистрация семестрового проекта

  1. Завести один «precious source» репозиторий для merge и публикации проекта и персональные — для разработки (лидеру проекта допустимо вести разработку в отдельной ветке, заводить ещё один репозиторий не надо)
  2. Разработать драфт проектного задания;
    • Постановка решаемой задачи: один абзац или список фич
    • Описание предполагаемых инструментов решения: какие сторонние модули будут использоваться, в рамках каких сервисов (если предполагаются)
    • Макет интерфейса (обратите внимание на то, что от проекта требуется локализация ⇒ какой-то интерфейс с человеком должен быть

      • GUI/TUI — общий вид окошек, что в целом они делаю и как попадают из одного в другое
      • Text — команды, диагностика (в общем плане — когда возникает и как посмотреть), режимы работы
      • Поместить проектное задание в README (или README.md) публичного репозитория
  3. Зарегистрировать публичный репозиторий проекта в качестве вашего персонального issue на странице репозитория PythonDevelopment2023. В issue указать:

    • Короткую формулировку сути проекта
    • Ссылку на публичный репозиторий проекта

    • Список участников проекта в виде:
      1. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
      2. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
  4. См. требования к защите проекта

LecturesCMC/PythonDevelopment2023/06_SocialProject (последним исправлял пользователь FrBrGeorge 2023-03-26 17:40:51)