- Все домашние задания задания сдаются строго в порядке их получения. Нельзя отправить на проверку сразу несколько работ за раз. Это связано с тем, что каждое следующее задание имеет более строгие требования при проверке.
- Категорически и полностью не приемлется списывание! При проверке очень видно кто и у кого что скопировал. Мне такие работы проверять не интересно.
- Все работы имеют мягкий дедлайн -- это время, когда я должен проверить работы. Если мягкий дедлайн пропустить, то время на проверку будет выделяться по возможности.
- Объём работы достаточно маленький, и мы будем фокусироваться не на качестве кода а на работе с тулами.
- Допускается совместная работа над проектом 2х студентов (нужно заранее согласовать в telegram), однако это совершенно точно не приведёт к уменьшению работы с 2а раза.
- Репозиторий, комментарии, описание задач, PR и всё остальное можно вести на русском или на английском языке (как пожелаете, только придерживайтесь единого подхода).
- Если будете делать мердж, не забывайте
--no-ff
, чтобы я видел откуда и куда пошли ветки (это не про первое задание, просто на будущее)
-
Определиться с темой.
Это должен быть маленький сервис (набор микросервисов) на любом языке и с использованием любых технологий, который будет принимать запрос, проводить какую-то работу и возвращать ответ. Список возможных вариантов (чтобы определить направление для идей) есть в конце этого документа.
Я рекомендую использовать максимальное количество плохо знакомых технологий чтобы ближе познакомиться с ними.
Дальше мы будем упаковывать этот сервис с Docker, но не в рамках 1-го задания.
-
Подготовить git-репозиторий.
Можно использовать любую систему -- Github, Bitbucket, Gitlab, Gitea, CodeCommit... Рекомендую использовать ту систему, с которой наименее знакомы.
В рамках подготовки репозитория нужно сделать один initial коммит (
README.md
,.gitignore
,LICENSE
) и после этого подготовить репозитория для работы по выбранному подходу:- Для
TBD
запретить прямые коммиты в веткуmain
- Для
git-flow
отmain
создатьdevelop
ветку, и запретить прямые коммиты в обе ветки
Это ограничение сильно упростит жизнь в будущем. Не все системы работы с git позволяют установить эти ограничения, по крайней мере на бесплатном тарифе.
На этом же шаге опционально можно повесить хуки с проверкой линтерами, если выбранный язык разработки это позволяет.
- Для
-
Подготовить
.gitconfig
в своём локальном окружении.Установить имя, e-mail и привязать граватар к e-mail.
-
Провести декомпозицию задачи.
По итогу, должно быть не менее 5 функциональных требований (пользовательских историй). Их нужно опубликовать в любой системе управления задачами (т.е. можно испозовать issues в GitHub, можно Trello, можно GoogleDoc).
-
Отправить задание мне на проверку
Перейти в репозиторий https://github.com/SemenMartynov/Software-Engineering-2022 и создать issue. Указать имя, группу и URL репозитория и выбранный подход для управления ветками:
TBD
илиgit-flow
.
Задание принято, если я закрыл issue. Мягкий дедлайн по этой работе -- 19 ноября. Тогда за 20 ноября я постараюсь всё проверить.
Тему и её детализацию можно выбрать самостоятельно, я просто предложу пару вариантов, чтоб задать вектор для дальнейших размышлений:
- конвертор из XML в YAML (на вход POST запросом отправляется XML файл, на выходе YAML)
- конвертор из YAML в JSON
- конвертор из JSON в ini
- конвертор из celsius degree в fahrenheit
- конвертор из USD в EUR (нужна интеграции со внешним сервисом, хотя бы с гуглом)
- конвертор из BTC в BTS
- получение среднего значения температуры воздуха в заданный день
- телеграмм бот с новостями, который отслеживает RSS feed какого-то сайта
- телеграмм бот, который получает ссылку на YouTube (+два таймстемпа), и возвращает gif-ку
- файл-сервер, который умеет получать файлы и складывать в локальной файловой системе
- ...