У подкаста RadioDotNet тоже есть подробный и структурированный журнал аудита. Изначально это была просто метаинформация на основе которой предполагалось строить сайт подкаста. Поэтому располагался он тоже в репозитории Site. Но собираемая информация достаточно полезная, полная и актуальная чтобы стать частью базы знаний DotNetRu.
Посему, следует перенести все сведения о подкасте в репозиторий Аудита. Дабы у сторонних сервисов был единый источник правды об активностях организации. Сейчас сами файлы перенесены, но формат всё-ещё находится в оригинальном состоянии.
Нерешённые задачи
Перед переносом нужно обратить внимание на некоторые аспекты, описанные ниже.
Формат
Стандартный формат для всего Аудита это XML. По историческим причинам, Radio ведёт свой журнал в Markdown с обильным использованием YAML.
Кажется нецелесообразным приводить Аудит к ситуации в которой он будет хранить документы разных форматов. Это усложнит реализацию инструментария (потребителей, генераторов, валидаторов). А так же внесёт сумятицу и разброд в глаза любого читателя.
Дабы следовать принципу наименьшего удивления, данные следует представлять в едином формате. XML является явным фаворитом, ибо в нём сейчас хранится большая часть данных, он имеет более строгую, продуманную и гибкую семантику. Посему, перед миграцией нужно будет сконвертировать все данные RadioDotNet в новый XML формат.
Инфраструктура
Информация о текущих выпусках подкаста используется для интеграции с множеством сервисов (Trello, VK, YouTube, Twitter и т.д.). В случае смены формата на XML (см. пункт Формат), весь этот инструментарий придёт в негодность.
Дабы не сломать отлаженный процесс выпуска подкастов, необходимо сначала добавить поддержку нового формата данных в инструментарий.
Структура
Сейчас структура Аудита следует определённым неформальным правилам (надо бы их записать в wiki после окончательной формализации):
- Все документы лежат в Коллекциях (папках первого уровня)
- Все Коллекции называются во множественном числе и в camelCase (и фактически состоят из одного слова)
- Внутри Коллекций содержатся Документы (листовые сущности с данными)
- Документы бывают двух типов:
- Простые XML файлы. Этот тип используется когда весь документ можно описать в одном файле.
- Папки. Этот тип нужен для сущностей имеющих в своей нагрузке вспомогательные файлы (фотографии, логотипы, картинки)
- В одной коллекции могут храниться только документы одного типа. Но этот тип может меняться со временем. Поэтому авторам интеграций рекомендуется не хардкодить эту информацию, а выяснять по факту.
- Документы (обоих типов) называются по уникальному индексу. Дабы иметь возможность производить быстрый поиск.
- У всех документов индекс уникален в пределах всего хранилища. Эта особенность не ставилась как цель, но тот факт что это случилось говорит о том, что это свойство соблюсти нетрудно. А технически на нём можно строить интересные решения
В связи с выше изложенным, получаем для Radio следующую структуру:
- Коллекция
podcasts
- Документы второго типа (папки), ибо нужно хранить обложки
- Название папок (индекс) формата
RadioDotNet-{Number}
Целостность
Сейчас весь репозиторий Аудита целостен. Т.е. у него все документы связаны друг с другом. И если есть какой-то недостижимый документ, то это смело можно считать ошибкой. Это удобное свойство для проверки непротиворечивости всего хранилища.
С приходом Radio, это свойство нарушается. Мы получаем новую коллекцию никак не связанную с остальными. Наверное это не проблема, ибо такой цели и не ставилось. Но в инструментах валидации всё-таки хочется оставить свойство полноты, как минимум для Митапов.
На самом деле, всё немного хуже. На текущий момент в Radio есть связь с документом Speaker из Аудита. Мы используем имена людей участвующих в подкасте (ведущие, гости, режиссёры и т.д.) для поиска их социальной сети (для указания её в анонсе). Социальные сети есть у Speaker'ов. Но если весь остальной Аудит использует для подобной связи Id сущности, Radio использует поле Name. Причина кроется в том, что не все наши участники делали доклады в Сообществах (т.е. попали в коллекцию Speakers). И для таких людей нам нужно просто Имя. Держать оба поля (Id для ссылки если повезло и Name если нет) выглядит слишком избыточно. Вот эту дилемму нужно будет решить перед миграцией.
Статус
Данная задача находится в процессе осмысления и обсуждения. Как только будут найдены достойные решения на все возникшие вопросы, можно будет переходить к реализации.
У подкаста RadioDotNet тоже есть подробный и структурированный журнал аудита. Изначально это была просто метаинформация на основе которой предполагалось строить сайт подкаста. Поэтому располагался он тоже в репозитории Site. Но собираемая информация достаточно полезная, полная и актуальная чтобы стать частью базы знаний DotNetRu.
Посему, следует перенести все сведения о подкасте в репозиторий Аудита. Дабы у сторонних сервисов был единый источник правды об активностях организации. Сейчас сами файлы перенесены, но формат всё-ещё находится в оригинальном состоянии.
Нерешённые задачи
Перед переносом нужно обратить внимание на некоторые аспекты, описанные ниже.
Формат
Стандартный формат для всего Аудита это XML. По историческим причинам, Radio ведёт свой журнал в Markdown с обильным использованием YAML.
Кажется нецелесообразным приводить Аудит к ситуации в которой он будет хранить документы разных форматов. Это усложнит реализацию инструментария (потребителей, генераторов, валидаторов). А так же внесёт сумятицу и разброд в глаза любого читателя.
Дабы следовать принципу наименьшего удивления, данные следует представлять в едином формате. XML является явным фаворитом, ибо в нём сейчас хранится большая часть данных, он имеет более строгую, продуманную и гибкую семантику. Посему, перед миграцией нужно будет сконвертировать все данные RadioDotNet в новый XML формат.
Инфраструктура
Информация о текущих выпусках подкаста используется для интеграции с множеством сервисов (Trello, VK, YouTube, Twitter и т.д.). В случае смены формата на XML (см. пункт Формат), весь этот инструментарий придёт в негодность.
Дабы не сломать отлаженный процесс выпуска подкастов, необходимо сначала добавить поддержку нового формата данных в инструментарий.
Структура
Сейчас структура Аудита следует определённым неформальным правилам (надо бы их записать в wiki после окончательной формализации):
В связи с выше изложенным, получаем для Radio следующую структуру:
podcastsRadioDotNet-{Number}Целостность
Сейчас весь репозиторий Аудита целостен. Т.е. у него все документы связаны друг с другом. И если есть какой-то недостижимый документ, то это смело можно считать ошибкой. Это удобное свойство для проверки непротиворечивости всего хранилища.
С приходом Radio, это свойство нарушается. Мы получаем новую коллекцию никак не связанную с остальными. Наверное это не проблема, ибо такой цели и не ставилось. Но в инструментах валидации всё-таки хочется оставить свойство полноты, как минимум для Митапов.
На самом деле, всё немного хуже. На текущий момент в Radio есть связь с документом Speaker из Аудита. Мы используем имена людей участвующих в подкасте (ведущие, гости, режиссёры и т.д.) для поиска их социальной сети (для указания её в анонсе). Социальные сети есть у Speaker'ов. Но если весь остальной Аудит использует для подобной связи
Idсущности, Radio использует полеName. Причина кроется в том, что не все наши участники делали доклады в Сообществах (т.е. попали в коллекцию Speakers). И для таких людей нам нужно просто Имя. Держать оба поля (Idдля ссылки если повезло иNameесли нет) выглядит слишком избыточно. Вот эту дилемму нужно будет решить перед миграцией.Статус
Данная задача находится в процессе осмысления и обсуждения. Как только будут найдены достойные решения на все возникшие вопросы, можно будет переходить к реализации.