Home

ZLP-Library - проект социально-ориентированной библиотеки

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

После задания определённых характеристик, объект, который выглядит как небольшая прямоугольная карточка с названием, будет автоматически помещаться в список, соответствующий какой-то характеристике книги (например, жанр). Характеристики, по которым создаются списки, можно будет менять. То есть, можно будет менять принцип сортировки; например, с жанров на локальную оценку. В случае смены критерия сортировки карточек по спискам, карточки остаются абсолютно такими же, какими и были до смены критерия; разница лишь в списках и их наполнении.

Пример: ранее существовало 2 списка: 1) Романтика, 2) Ужасы. В первом списке были карточки-книги: А) "Государство" Платона, Б) "Три товарища" Ремарка, так как им были присвоены жанры "Романтика". Во втором списке были карточки-книги В) "Критика чистого разума" Канта и Г) "Сияние" Кинга. Пользователь сменил критерий сортировки карточек с жанров на локальную оценку, и теперь списков стало 3: 1) 10*, 2) 8*, 3) 6*. В списке 1) теперь находятся книги А) и В), в списке 2) книга Б), а в списке 3) книга Г). Таким образом, карточки, олицетворяющие книги, остались теми же самыми, а списки и их наполнение поменялись.

Основная идея в том, чтобы какая-то группа друзей или коллег могла иметь общую доску, на которой все объекты создаются только участниками доски. В таком случае участники доски могут между собой обмениваться опытом прочтения какой-либо книги, а также запросто одалживать их друг у друга (так как в характеристиках объекта будет указываться местоположение книги (в случае, если у создающего объект пользователя есть бумажная версия) и личность её владельца).

Следует вопрос: а зачем нужно наше приложение, когда есть таск-менеджеры, имеющие схожий функционал?

Недостатки таск-менеджеров в контексте Электронной библиотеки:

• У карточек нет личных для каждого пользователя настроек.
• При большом количестве книг, для выбора той, которую хочется прочитать, придётся потребить слишком много информации об оценках других пользователей доски.
• У доски нет личных для каждого пользователя настроек.
• Вложенные картинки получаются слишком большими.
• Слишком много лишнего функционала, не касающегося книг.

Решения:

• Можно реализовать возможность добавлять книгу в закладки и просматривать закладки (допустим, как на сайтах-читалках). Закладки причем можно сделать общими для всех досок, чтобы пользователь, находящийся сразу на нескольких досках, мог просматривать закладки с каждой единомоментно, на одной странице.
• Можно реализовать локальную систему рейтинга книг внутри конкретной доски. Допустим, оцениваться книги будут от 1 до 10, и сортировать книги внутри доски можно будет тоже по этим оценкам. Также хотелось бы видеть какие конкретно пользователи оценили данную книгу и как именно.
• Можно реализовать настройку интерфейса для каждого пользователя: например, сортировка книг по жанрам, по авторам, по владельцам, по средней оценке. Также настройку фона доски и т.п.
• Реализовать удобный интерфейс взаимодействия с вложенными изображениями.
• Обеспечить приложению максимально подстроенную под нашу конкретную идею функциональность.

UseCase диаграмма

Представление БД

Распределение ролей

• Игорь: Backend developer, Team Lead
• Даниил: Backend developer
• Вадим: Designer, Frontend developer, testing
• Роман: Frontend developer, testing
• Ярослав: documentation, testing

Cтруктура репозитория

Ветка main дает начало ветке общей разработки develop, из которой отходят как ветки как отдельных фич, обратно сливающихся с develop по мере готовности, так и ветка beta, предназначенная для тестирования кандидатов на релиз перед самим релизом и хотфиксов релизов. Ветки feat. предназначены для проработки крупных или ломающих изменений перед вливанием в основную ветку разработки, часто на них работает один человек

За слияние веток ответственны:

• beta в main : Team Lead и тестировщики
• develop в beta : Team Lead (как проект-менеджер) и другие участники проекта по результатам работы
• develop в feat. : Team Lead, разработчики
• feat. в develop : Team Lead, разработчики
• commits cherry-picking в beta: разработчики