Теперь понял что вы имели ввиду. Тогда по порядку.
Почему бы сразу не просить данные в готовые структуры на C#?
Честно скажу никогда не думал о том чтобы так делать в продакшен решении. Делал так в своих проектах, когда начинал изучать геймдев, по воспоминаниям это было скорее из-за не знаю и не умения хранить данные по другому (тогда хранил 30 000 строк данных в таком формате).
Сейчас могу предположить, что такой вариант хранения не очень удобный. Дело в том, что на проекте работают не только программисты, но и геймдизайнеры, тестировщики, художники, саппорт. Им иногда нужно корректировать конфиги, чтобы запустить игру в определённой ситуации. Чтобы они могли редактировать конфиги у них останется два варианта: - использовать гугл таблицу + парсер - изучать семантику c# языка, которая для не профильных специалистов может быть сложной (Даже с подсветкой вариантов заполнения от IDE, и то это потребует всем установить такой софт).
На мой взгляд такой вариант может создать лишние сложности, чем принести пользы.
даже немного сэкономмт время на загрузке клиента и сервера
У нас не так много данных, чтобы потребовалось задумываться об оптимизации чтения конфигов (думаю где-то 30-40к строк). Думаю их нужно несколько миллионов строк, чтобы почувствовать задержку, но и то для сервера это не так критично (т.к. он запускается и 2 недели работает без остановки).
Что если в таблице (а за ней - и в json) появилось какое-то новое поле, которого у экземпляра класса нет? ... Новое поле каким-то образом будет сгенерировано у нужного класса или мы получим ошибку при загрузке данных? Может, есть какая-то валидация в момент генерации json?
Первичной структурой данных является class в c# коде. Инструментов автоматического добавление полей в c# код нет (структуру определяет программист при разработки фичи).
Дизайнер может ошибиться двумя способами: 1. Опечатся(равносильно тому, что появляется лишнее поле)/Добавить лишнее поле. 2. Забыть ввести какое-то поле.
Проектный сериализатор берёт целевой class, через рефлексию смотрит какие существуют поля у этого класса и заполняет их исходя из значения json. Json это по сути Dictionary<string, object>, где ключ string - это название поля в json. Соответственно, когда происходит десериализация (из json в c# класс) в первую очередь ищутся известные поля (которые заданы в c# классе), если встретится неизвестное поле, то произойдёт краш при попытке десериализовать json.
P.S. Десериализация немного сложнее, чем я описал выше(Выше упрощённый вариант для понимания концепции). При десериализации не создаётся Dictionary<string, object> (чтобы не было генерации мусора в памяти) а происходит чтение json как текста по токенам (это всякие {,},[,],:,",.,,,") стремящееся к O(n) и сразу же создание экземпляра класса через класс System.Activator.
На проекте есть простая валидация в виде юнит тестов (запуск юнит тестов автоматизирован на CI/CD). Суть юнит теста в том, чтобы загрузить все имеющиеся конфиги. Ну и если что-то не получится загрузить, то тесты будут красные.
Что касается Ошибки. Забыть ввести какое-то поле. Если при десериализации какое-то поле отсутствует в json, то поле заполняется дефолтным значением в зависимости от типа данных (0, null, false и т.д.).
Я правильно понял, что вопрос почему мы не парсим таблицы в захардкоженный код? Чтобы из таблицы в код помещать сразу захардкоженные константы?
Что-то вроде этого?
class Event // Описание структуры
{
public string name;
public long price;
public float difficulty;
}
class Config
{
public Event[] events = // Заполнение данными
[
new Event
{
name = "Event10",
price = 1000,
difficulty = 0.5f
},
new Event
{
name = "Event11",
price = 1000,
difficulty = 0.5f
}
]
}
Но этот json, очевидно, сервер или клиент (или оба) должны прочитать чтобы эти данные использовать. И не просто прочитать, а наверное как-то распарсить по своим структурам
У нас json повторяет структуру класса в который данные будут загружены. Мы в коде не дописываем какую-то дополнительную логику заполнения структуры данными json. Наш сериализатор автоматически по имени поля и типу данных маппит данные, а затем создаёт экземпляр необходимого класса.
Я правильно понял, что в этой системе все данные линейные (т.е. однотипные например колонка arrayIndex, price, amount). Нет возможности сделать вложенность (точнее она есть, но её разбивает программист на несколько листов)? И появляются не удобства, что разное кол-во полей для json не сделать?
1. JSON в гите
Вопросы:
1) В итоге не совсем понял. Импортируете ли данные из json в гугл таблицы? 2) Если да, то как определяется в какой структуре должны отображаться импортируемые данные? Полностью линейно их сделать достаточно сложно (возможно, но сложно. Либо на листе куча колонок с пустотами, либо множество листов с уровнями и скорее всего больше, чем уровней) . 3) Как в таком случае геймдизайнеры работают с этими данными? Им скорее всего приходится достаточно сложные манипуляции делать, чтобы соединить их в удобном им виде. 4) И как они работают с возможностями гугл таблиц (построение графиков, расчёты и математическое рассуждения этих расчётов)? 5) Как в случае каких либо изменений в схеме данных сохраняются все применения формул и ссылки на данные (для графиков и т.д.)
Для меня обратный импорт сопровождается сложностью определения структуры внутри гугл таблицы. Эта структура одновременно должна быть удобной для геймдизайнеров (чтобы не усложнять им жизнь) и одновременно строго определённой, чтобы импорт смог сработать.
Я так понимаю геймдизайнеры достаточно сильно загнаны в определённые рамки? Как они к этой системе относятся?
Спасибо, за ссылку на Charon, ни разу не слышал о нём. Посмотрю что это такое. (Пока что показалось что это для Scriptable Object, у нас все конфиги на сервере в json файлах лежат)
Мы пытались найти инструменты, которые бы решили вопросы экспорта, но не нашли. Попадались решения у которых была слишком жёсткая схема (обязательно таблица, где столбцы заполняют всегда существующие поля, т.е. нет вариативности типов).
Несколько раз писали парсеры под фичу, где много данных (Скачивался Excel файл, и через тулзы вручную считывались захардкоженные ячейки из таблицы).
Да, у нас первоисточником всегда являются гугл файлы. Там все математические рассуждения, выводы и т.д. Json файлы это скорее слепок результата.
Дизайнеры добавляют json конфиги в проект через гит (когда хотят внести какие-то правки в баланс).
Да, действительно остаётся только экспорт. Когда добавляется/изменяется схема данных фичи, дизайнера уведомляют в pull request и он может скорректировать схему данных в гугл таблице (сразу сейчас или позже. Это не тормозит разработку)
Верное утверждение, что хранение схемы данных вместе с кодом - это гарантия совместимости схемы данных. Тут в первую очередь хотелось добиться гибкости именно на стороне источника данных (гугл таблиц).
Интересная мысль по поводу обратного импорта json только для редактирования. Никогда не задумывался об этом. Звучит немного как создать свою базу данных с описанием семантики восстановления, но идея интересная, спасибо. Вы импортируете данные обратно в гугл таблицы данные?
DNS это не так сложно. Хостинги DNS (AWS, Yandex Cloud) стоят не так дорого. К примеру в Yandex Cloud это примерно 44 рубля за зону(домен) в месяц и 38 рублей за 1 млн запросов к записям. Одного домена как правило достаточно.
Тут дело не в деньгах или сложности. Я не думаю что мне будет сложно поднять или настроить(скорее всего что-то поизучать всё равно придётся). Тут вопрос только профита от этого. Если это нужно только мне, то зачем усложнять.
Может получится как типичная история "программист тратит несколько часов на автоматизацию задачи, которую можно сделать вручную за 5 минут" :)
Да, это правильно. Но нужно ли? Получу ли я то преимущество ради которого делаю это? А если нет разницы, то мой ответ тут только один :) Когда понадобится, тогда и сделаю)
Но для подобного, если у вас инфраструктура больше пары хостов и прям уже надо не забыть ip адрес, достаточно развернуть внутренний dns и не мучаться, ибо снова - смена адреса = проблемы с вопросом - что это не работает ничего.
Если это нужно только мне, то я не вижу смысла заводить себе систему DNS. Ибо нет разницы, буду я менять его у себя локально или на dns сервере, который ещё поддерживать нужно будет.
Про отладку. В целом если знаешь как настроена своя рабочая машина, то проверка коннекта по прямому ip-адресу у меня будет стоять первым пунктом.
Но в любом случае, спасибо за совет.
Вы совершенно не верно описали принцип работы DNS со стороны как клиента, так и со стороны сервера
А можете скорректировать в чём я не прав? Я не стал её описывать подробно и упоминать кэши. Какие-нибудь пару пунктов, где я не верно говорю про принцип?
У меня как раз не было цели разворачивать DNS. Это настройка только моей рабочей машины, так чтобы мне было удобно работать.
То что я могу пересесть на другой компьютер, тоже в полне ожидаемое и возможно событие. Но речь в статье именно о том как сделать это для себя (без привлечения других людей и доп. инфраструктуры).
Про ssh config я уже увидел в нескольких комментария рекомендацию, спасибо.
За рекомендацию ansible тоже спасибо. Задачи на серверах менять конфигурацию достаточно редкая, но думаю полезно знать о тулзе.
Если не знаешь свою инфраструктуру, а серверов для подключения действительно много, то и в доменных именах будет путаница в итоге
Знать свою инфраструктуру не то же самое, что помнить наизусть все свои хосты. Как по мне, помнить все свои хосты в большинстве случаев будет мусорной информацией (здорово, если Вы их помните).
Путаница в доменных именах будет только если вы даёте плохой нейминг, либо не обновляете его по мере внесения изменений.
Да, могут быть ситуации, когда проще использовать ip, так в этом случае и стоит его использовать. Никто не запрещает пользоваться двумя вариантами. Есть например реплика сет базы данных состоящего из primary-реплики, secondary-реплики и арбитра. Так почему бы их не назвать так (да, primary и secondary могут поменяться. Они для этого и нужны), но они настраиваются с предпочтениями под конкретную задачу, так почему бы не использовать human-readable конструкции.
Вы писали что для подключений используете "гуи", так в большинстве приложений есть возможность нейминга подключений, по этому не совсем ясно для чего прописывать доменные имена
Я использую несколько вариантов. SSH консоль, SFTP чаще всего гуи. То что в гуи есть нейминг это верно, и я использую его. Но так во всех тулзах, которые Вы используете нужно будет пойти и поменять ip-адрес, а так у вас одна точка принятия решения.
Было бы смешно увидеть как человек с таким же успехом забывает какие он домены навыдумывал и лезет в хост каждый раз что бы вспомнить что там
Прикольно. Как-то никогда не задумывался о создании общий системы для фотографий, а тем более выстраивания их всех в перемешку на таймлайне. Сам храню фотки на внешнем SSD, и побаиваюсь что когда-нибудь он помрёт вместе с фотками.
Да, сейчас инструменты позволяют быть очень гибким. Я с трудом представляю каково это делать такую работу вручную.
Как-то в книге "Креативный программист" впервые встретил метод ведения заметок "Zettelkasten" для систематизации идей на бумаге, где каждая новая заметка записывается на карточке и имеет связный номер с предыдущей, если такая связь имеется (например, 1 - 1a - 1a2a). Благодаря этому методу Никласу Луману удалось опубликовать большое кол-во книг и статей.
Тоже интересный способ самоорганизации. Автор метода так же делал это без компьютеров, в результате чего образовывалась большая картотека состоящая из множества шкафов.
Табличка не так часто нужна. У меня просто вкладка в браузере запинена и никогда не закрывается (выше комментом гифка как подготавливаю шаблон, в начале гифки делаю закреп вкладки).
Я хоть и работаю за двумя мониторами, но постоянно на виду её не держу. Достаточно легко переключаюсь между закреплённой вкладкой.
Да, по началу сложно. Нужно ловить себя на мысли, что переключаюсь на другую задачу и вспомнить про существование журнала. По этому в статье упомянул, что требуется дисциплина и строгий подход.
И да, по началу может занимать много времени. Главное приучить себя использовать шорткаты и другие плюшки, а так же выработать навык заполнения до автоматизма.
Без этого сильно дольше.
У меня это происходит так: Предварительно нужно вставить "шаблон дня". Я вставляю сразу на версию вперёд (10 рабочих дней).
Шаблон дня - это набор строк, где добавлены регулярные события ("CP [Приход]", "CP [Начало обеда]", "CP [Конец обеда]", "CP [Уход]"), а между ними уже вставлены строки для заполнения, примерно по 10 штук. Шаблон дня подготовлен внизу гугл таблицы.
Клонирую шаблон где-то внизу документа (делаю именно там, чтобы не заменялись строки и не слетали сворачивания). Затем перемещаю наверх документа.
Я это делаю в начале версии и вставляю сразу на всю версию (10 рабочих дней). Лишние дни сворачиваю, чтобы не мешались.
Заполнение тоже стараюсь доводить до автоматизма.
клик мышкой в клетку со временем Ctrl+Shift+; вставляет текущее время
Tab и выбираю категорию с предварительным поиском
Tab и ввожу участников
Ещё несколько табов и ввожу название активности
Tab и ввожу более подробное описание активности, если нужно
Заполнение тоже стараюсь максимально довести до автоматизма. Например, есть разница куда жать при окончании ввода данных в ячейку (Tab или Enter).
Tab - переместит в следующую колонку на этой же строке
Enter - перемести в следующую строку в этой же колонке
Если делать мышкой, то сильно дольше. Ниже гифка с примером как я заполняю (P.S. может долго прогружаться).
Задача автоматизма становиться достаточно творческой :) Приходиться проявлять фантазию, чтобы ускорить процесс заполнения.
P.S. бесючая всплывашка при сворачивании строк "Данные в скрытых строках исключены из нескольких диаграмм" отключается если в диаграммах тыкнуть галочку "Включить скрытые или отфильтрованные данные"
Спасибо, что поделились опытом
Теперь понял что вы имели ввиду. Тогда по порядку.
Честно скажу никогда не думал о том чтобы так делать в продакшен решении. Делал так в своих проектах, когда начинал изучать геймдев, по воспоминаниям это было скорее из-за не знаю и не умения хранить данные по другому (тогда хранил 30 000 строк данных в таком формате).
Сейчас могу предположить, что такой вариант хранения не очень удобный. Дело в том, что на проекте работают не только программисты, но и геймдизайнеры, тестировщики, художники, саппорт. Им иногда нужно корректировать конфиги, чтобы запустить игру в определённой ситуации.
Чтобы они могли редактировать конфиги у них останется два варианта:
- использовать гугл таблицу + парсер
- изучать семантику c# языка, которая для не профильных специалистов может быть сложной (Даже с подсветкой вариантов заполнения от IDE, и то это потребует всем установить такой софт).
На мой взгляд такой вариант может создать лишние сложности, чем принести пользы.
У нас не так много данных, чтобы потребовалось задумываться об оптимизации чтения конфигов (думаю где-то 30-40к строк). Думаю их нужно несколько миллионов строк, чтобы почувствовать задержку, но и то для сервера это не так критично (т.к. он запускается и 2 недели работает без остановки).
Первичной структурой данных является class в c# коде. Инструментов автоматического добавление полей в c# код нет (структуру определяет программист при разработки фичи).
Дизайнер может ошибиться двумя способами:
1. Опечатся(равносильно тому, что появляется лишнее поле)/Добавить лишнее поле.
2. Забыть ввести какое-то поле.
Проектный сериализатор берёт целевой class, через рефлексию смотрит какие существуют поля у этого класса и заполняет их исходя из значения json. Json это по сути
Dictionary<string, object>, где ключ string - это название поля в json. Соответственно, когда происходит десериализация (из json в c# класс) в первую очередь ищутся известные поля (которые заданы в c# классе), если встретится неизвестное поле, то произойдёт краш при попытке десериализовать json.На проекте есть простая валидация в виде юнит тестов (запуск юнит тестов автоматизирован на CI/CD). Суть юнит теста в том, чтобы загрузить все имеющиеся конфиги. Ну и если что-то не получится загрузить, то тесты будут красные.
Что касается
Ошибки. Забыть ввести какое-то поле.Если при десериализации какое-то поле отсутствует в json, то поле заполняется дефолтным значением в зависимости от типа данных (0,null,falseи т.д.).Не совсем понимаю о чём речь.
Я правильно понял, что вопрос почему мы не парсим таблицы в захардкоженный код?
Чтобы из таблицы в код помещать сразу захардкоженные константы?
Что-то вроде этого?
У нас json повторяет структуру класса в который данные будут загружены. Мы в коде не дописываем какую-то дополнительную логику заполнения структуры данными json. Наш сериализатор автоматически по имени поля и типу данных маппит данные, а затем создаёт экземпляр необходимого класса.
Игра мультиплеерная (есть сервер и клиент).
Вы имете в виду почему мы напрямую не запрашиваем данные из гугл. таблиц при загрузки сервера?
Я правильно понял, что в этой системе все данные линейные (т.е. однотипные например колонка
arrayIndex, price, amount). Нет возможности сделать вложенность (точнее она есть, но её разбивает программист на несколько листов)?И появляются не удобства, что разное кол-во полей для json не сделать?
Вопросы:
1) В итоге не совсем понял. Импортируете ли данные из json в гугл таблицы?
2) Если да, то как определяется в какой структуре должны отображаться импортируемые данные?
Полностью линейно их сделать достаточно сложно (возможно, но сложно. Либо на листе куча колонок с пустотами, либо множество листов с уровнями и скорее всего больше, чем уровней) .
3) Как в таком случае геймдизайнеры работают с этими данными? Им скорее всего приходится достаточно сложные манипуляции делать, чтобы соединить их в удобном им виде.
4) И как они работают с возможностями гугл таблиц (построение графиков, расчёты и математическое рассуждения этих расчётов)?
5) Как в случае каких либо изменений в схеме данных сохраняются все применения формул и ссылки на данные (для графиков и т.д.)
Для меня обратный импорт сопровождается сложностью определения структуры внутри гугл таблицы. Эта структура одновременно должна быть удобной для геймдизайнеров (чтобы не усложнять им жизнь) и одновременно строго определённой, чтобы импорт смог сработать.
Я так понимаю геймдизайнеры достаточно сильно загнаны в определённые рамки? Как они к этой системе относятся?
Спасибо, за ссылку на Charon, ни разу не слышал о нём.
Посмотрю что это такое. (Пока что показалось что это для Scriptable Object, у нас все конфиги на сервере в json файлах лежат)
Мы пытались найти инструменты, которые бы решили вопросы экспорта, но не нашли.
Попадались решения у которых была слишком жёсткая схема (обязательно таблица, где столбцы заполняют всегда существующие поля, т.е. нет вариативности типов).
Несколько раз писали парсеры под фичу, где много данных (Скачивался Excel файл, и через тулзы вручную считывались захардкоженные ячейки из таблицы).
Да, у нас первоисточником всегда являются гугл файлы. Там все математические рассуждения, выводы и т.д. Json файлы это скорее слепок результата.
Дизайнеры добавляют json конфиги в проект через гит (когда хотят внести какие-то правки в баланс).
Да, действительно остаётся только экспорт. Когда добавляется/изменяется схема данных фичи, дизайнера уведомляют в pull request и он может скорректировать схему данных в гугл таблице (сразу сейчас или позже. Это не тормозит разработку)
Верное утверждение, что хранение схемы данных вместе с кодом - это гарантия совместимости схемы данных. Тут в первую очередь хотелось добиться гибкости именно на стороне источника данных (гугл таблиц).
Интересная мысль по поводу обратного импорта json только для редактирования. Никогда не задумывался об этом. Звучит немного как создать свою базу данных с описанием семантики восстановления, но идея интересная, спасибо.
Вы импортируете данные обратно в гугл таблицы данные?
мне кажется, только ленивый про него сегодня не написал)
Тут писали про поп-ап окна. Для меня это окна, которые вылетают в лицо в случайных местах. Вот интересно что имелось ввиду
Тут дело не в деньгах или сложности. Я не думаю что мне будет сложно поднять или настроить(скорее всего что-то поизучать всё равно придётся). Тут вопрос только профита от этого. Если это нужно только мне, то зачем усложнять.
Может получится как типичная история "программист тратит несколько часов на автоматизацию задачи, которую можно сделать вручную за 5 минут" :)
Да, это правильно. Но нужно ли? Получу ли я то преимущество ради которого делаю это? А если нет разницы, то мой ответ тут только один :) Когда понадобится, тогда и сделаю)
Это как выбирать монолит или микросервисы)
Если это нужно только мне, то я не вижу смысла заводить себе систему DNS. Ибо нет разницы, буду я менять его у себя локально или на dns сервере, который ещё поддерживать нужно будет.
Про отладку. В целом если знаешь как настроена своя рабочая машина, то проверка коннекта по прямому ip-адресу у меня будет стоять первым пунктом.
Но в любом случае, спасибо за совет.
А можете скорректировать в чём я не прав? Я не стал её описывать подробно и упоминать кэши. Какие-нибудь пару пунктов, где я не верно говорю про принцип?
У меня как раз не было цели разворачивать DNS. Это настройка только моей рабочей машины, так чтобы мне было удобно работать.
То что я могу пересесть на другой компьютер, тоже в полне ожидаемое и возможно событие. Но речь в статье именно о том как сделать это для себя (без привлечения других людей и доп. инфраструктуры).
Про ssh config я уже увидел в нескольких комментария рекомендацию, спасибо.
За рекомендацию ansible тоже спасибо. Задачи на серверах менять конфигурацию достаточно редкая, но думаю полезно знать о тулзе.
Спасибо, посмотрю
Ну тут я с Вами не соглашусь.
Знать свою инфраструктуру не то же самое, что помнить наизусть все свои хосты. Как по мне, помнить все свои хосты в большинстве случаев будет мусорной информацией (здорово, если Вы их помните).
Путаница в доменных именах будет только если вы даёте плохой нейминг, либо не обновляете его по мере внесения изменений.
Да, могут быть ситуации, когда проще использовать ip, так в этом случае и стоит его использовать. Никто не запрещает пользоваться двумя вариантами. Есть например реплика сет базы данных состоящего из primary-реплики, secondary-реплики и арбитра. Так почему бы их не назвать так (да, primary и secondary могут поменяться. Они для этого и нужны), но они настраиваются с предпочтениями под конкретную задачу, так почему бы не использовать human-readable конструкции.
Я использую несколько вариантов. SSH консоль, SFTP чаще всего гуи. То что в гуи есть нейминг это верно, и я использую его. Но так во всех тулзах, которые Вы используете нужно будет пойти и поменять ip-адрес, а так у вас одна точка принятия решения.
Это уже вопрос плохо нейминга и самоорганизации.
Звучит интересно, а про какие поп-ап окна речь и для чего это?
тоже хороший вариант, только не только в консоли это нужно)
Например, для перекидывания файликов через sftp использую гуишное приложение
Прикольно. Как-то никогда не задумывался о создании общий системы для фотографий, а тем более выстраивания их всех в перемешку на таймлайне.
Сам храню фотки на внешнем SSD, и побаиваюсь что когда-нибудь он помрёт вместе с фотками.
Да, сейчас инструменты позволяют быть очень гибким.
Я с трудом представляю каково это делать такую работу вручную.
Как-то в книге "Креативный программист" впервые встретил метод ведения заметок "Zettelkasten" для систематизации идей на бумаге, где каждая новая заметка записывается на карточке и имеет связный номер с предыдущей, если такая связь имеется (например, 1 - 1a - 1a2a). Благодаря этому методу Никласу Луману удалось опубликовать большое кол-во книг и статей.
Тоже интересный способ самоорганизации. Автор метода так же делал это без компьютеров, в результате чего образовывалась большая картотека состоящая из множества шкафов.
Табличка не так часто нужна. У меня просто вкладка в браузере запинена и никогда не закрывается (выше комментом гифка как подготавливаю шаблон, в начале гифки делаю закреп вкладки).
Я хоть и работаю за двумя мониторами, но постоянно на виду её не держу. Достаточно легко переключаюсь между закреплённой вкладкой.
Да, по началу сложно. Нужно ловить себя на мысли, что переключаюсь на другую задачу и вспомнить про существование журнала. По этому в статье упомянул, что требуется дисциплина и строгий подход.
И да, по началу может занимать много времени. Главное приучить себя использовать шорткаты и другие плюшки, а так же выработать навык заполнения до автоматизма.
Без этого сильно дольше.
У меня это происходит так:
Предварительно нужно вставить "шаблон дня".
Я вставляю сразу на версию вперёд (10 рабочих дней).
Шаблон дня - это набор строк, где добавлены регулярные события ("CP [Приход]", "CP [Начало обеда]", "CP [Конец обеда]", "CP [Уход]"), а между ними уже вставлены строки для заполнения, примерно по 10 штук. Шаблон дня подготовлен внизу гугл таблицы.
Клонирую шаблон где-то внизу документа (делаю именно там, чтобы не заменялись строки и не слетали сворачивания). Затем перемещаю наверх документа.
Я это делаю в начале версии и вставляю сразу на всю версию (10 рабочих дней). Лишние дни сворачиваю, чтобы не мешались.
Заполнение тоже стараюсь доводить до автоматизма.
клик мышкой в клетку со временем
Ctrl+Shift+;вставляет текущее времяTab и выбираю категорию с предварительным поиском
Tab и ввожу участников
Ещё несколько табов и ввожу название активности
Tab и ввожу более подробное описание активности, если нужно
Заполнение тоже стараюсь максимально довести до автоматизма.
Например, есть разница куда жать при окончании ввода данных в ячейку (Tab или Enter).
Tab - переместит в следующую колонку на этой же строке
Enter - перемести в следующую строку в этой же колонке
Если делать мышкой, то сильно дольше.
Ниже гифка с примером как я заполняю (P.S. может долго прогружаться).
Задача автоматизма становиться достаточно творческой :)
Приходиться проявлять фантазию, чтобы ускорить процесс заполнения.
P.S. бесючая всплывашка при сворачивании строк "Данные в скрытых строках исключены из нескольких диаграмм" отключается если в диаграммах тыкнуть галочку "Включить скрытые или отфильтрованные данные"