mayton2019

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

Можно начать просто с централизованного сбора логов. Мне кажется это проще
чем строить кафку. Кроме того логгирование работает всегда, пока есть файловая
система. А Кафка может быть недоступна какое-то количество минут или секунд в году.
И вам надо будет думать что делать с событиями которые не ушли в Кафку. Блокировать.
Дропать события. Или искать резервное мето куда форварднуть.

Вариант

$ oggdec file_example_OOG_5MG.ogg file_example_OOG_5MG.wav
$ lame file_example_OOG_5MG.wav

И из Go соотвественно надо вызвать внешний процесс

exec.Command(".....")

Скорее всего - специфика Go-задач.

Дело в том что область применения ORM обычно ограничивается CRUD приложениями.
И если мы заходим в область утилит для ETL и BigData то там оказывается что ORM вообще не нужен.
Там работают во первых диалекты SQL, (Spark-SQL, Hive-SQL, MS U-SQL). Во вторых дизайн
entities очень громоздкий (по 500-1000 колонок). И эти колонки еще и двигаются во времени
следуя schema evolution на ходу. Тоесть добавляя новые колонки и расширяя типы от узких к широким.
Представить себе ORM в таких условиях просто невозможно. Кроме того ORM кеширует объекты
в коллекциях языка а это, сами понимаете не вопрос Bigdata и аналитики.

Вообще ORM - это пугало, которым пугают на собеседованиях новичков. Для java-junior знание ORM - уже
приравнивается к знанию сопромата и философии Конфуция. Знаешь ORM - получи должность
в банке и сиди себе с умным видом на митинге.

С моей точки зрения ORM ограничивает сильно в оптимизации запросов. Хинт уже так просто не поставить.

Кроме ORM (Object-Relational-Mapping) есть и другая философия. Не от объектов к реляциям а наоборот.
От базе к объектам. (Фреймворк MyBatis например). В нем причинно-следственная связь перевернута.
Сначала таблицы и хранимые процедуры существовали в БД и уже потом, a posteriori, разработчик
описывает для них мапппинги в обратном направлении.

Существует также миф о том что ORM позволяет лихо прыгать по разным базам. Ни разу я для себя этот
миф не подтвердил. Чем крупнее система - тем плотнее она сидит на лицензии от DBMS, и тем глубже
она использует фичи этой DBMS (язык хранимых процедур особые режимы таблиц и партишенинга)
и совершенно нет никакой надежды что миграция произойдет в один мышко-клик. Скорее наоборот.
Миграция - это боль и слёзы и крупные платежи сектору разработки и облачным провайдерам.
Баги и просадки перформанса в самых неожиданных местах БД.

Хотя для вашего pet-project ORM вполне удобен особенно когда вы тестируете например веб-приложуху
на H2 в перспективе с переходом на Postgres.

неприлично долго думаю над тем что нужно вынеси в отдельный пакет, а что достаточно вынести в отдельную структуру

Такая-же проблема и у меня. Я тоже долго думаю над дизайном. Но суть в том что в большинстве задач
ты и бизнес не всегда знаете куда пойдет проект дальше. И поэтому нарисовать идельный дизайн нельзя.
Я-бы даже сказал что попытка сопровождать идеальный дизайн - может затянуть внедрение проекта.

Поэтому просто откажись от декомпозиции. Пиши сначала прототип в олимпиадном стиле. Тоесть функция
main - и погнал писать как чукча. Что вижу то и пою.

И после того как ты напишешь 1000 строк например к тебе придет понимание как следует декомпозировать.
И к этому моменту у тебя будут ДОКАЗАТЕЛЬСТВА выгодности твоего дизана. И теоретические споры можно
уже исключить.

Если ты начинающий - то лучше написать работающее приложение. А архитектура должна быть мотивированной.
Вот в книжках по шаблонам проектирования так и пишут дескыть motivation.

А если на пустом hello world делать архитектуру - то оно выглядит как-то странно. И принцип KISS/Yagni
никто не отменял. И бритву Оккама.

Когда-то давным давно использовали logrotate. Эта утилита просто дробила лог на дневные и часовые
и прочие доли. Это позволяло искать быстрее. Если ты заранее знаешь что событие произошло например
за последние сутки а не за последние 10 лет к примеру. Но logrotate может не работать под Windows.

Коробочного решения для твоего вопроса я не знаю. Кроме Elastic ничего не приходит в голову.

Есть еще программный продукт Splunk. Но я его никогда не использовал поэтому советовать не буду. Почитай сам.

Вообще тебе нужен разработчик. Я думаю что дешевле всего трекать отдельные логи по событию event:login к примеру. Я так делал для сужения поиска. Для библиотек log4j это конфигурируется на уровне приложения.
Там как-то добавляется appender + rule.

Тут пишут https://go.dev/tour/methods/9 весьма сухо.

Interfaces
An interface type is defined as a set of method signatures.
A value of interface type can hold any value that implements those methods.

Судя по всему Google не особо заинтересован описывать детали реализации интерфейса.
Возможно на реализацию нет спеки. И Google планирует в будущем ее изменять.

А попробуй замени это
{{$projectID := .Note.ProjectID}}
на константу
{{$projectID := "00000011112222" }

Для exe-шников еще в 90-е создавались не архиваторы а всякие "упаковщики". Из таковых я помню UPX https://upx.github.io/

Не знаю как в Го-шке. Но в сях есть два базовых подхода к работе с текстовой графикой.
Первое - это печатать управляющией символы (backspace) чтоб стирать предыдущие.
Так например работает текстовый архиватор Rar пока печатает прогресс. Все это на уровне STDOUT.

Второе - это использовать библиотеки наподобие ncurses. Это такая Rich-графика в тексте.
Можно делать красивые цветные текстовые таблицы наподобие TurboVision. И даже интерактивность.
Диалоговые окна. Edit boxes e.t.c.

Поскольку речь идет об .exe то скорее всего автор хочет запускать без command-shell окошка.

Вот так.
start /B программа.exe
Ну и цикл там сделать внутри.

Я-бы предложил для начала уйти от этого странного способа описанию деревьев к инверсному списку
По сути - добавить еще одну колонку которая указывает на родителя.

id name     path  parent
-----------------------
1  Беларусь 1     null
2  Россия   2     null
3  Минск    1.3   1
4  Москва   2.4   2
5  СПБ      2.5   2
6  Невский  2.5.6 5

Ну а дальше - select... connect prior и получим ранжированый курсор по дереву. Там-же будет
доступно виртуальное поле level. И обходом этого курсора можно сделать JSON документ.
Если level растет - то увеличиваем indentation и открываем вложенный элемент соотв.

Если go-lang поддерживает stremable json writers то даже лучше.

Попробуй замени any на bytes.
map<string,bytes> property = 1;

Читай не по строкам а по символам.

Обычно там где танцует Go - там рядышком docker/kubernetes. Тоесть не проблема очень быстро поднять тестовую БД, наполнить ее данными и сразу прогнать все тесты по DAO.

Иного способа протестировать DAO я думаю не существут. Смысл DAO - доступаться к внешним источникам данных. Если его мокать - то это уже не тестирование DAO а тестирование логики следующего уровня. Бизнес-логики и прочее.

Ты переусложняешь. Сделай просто массив строк.

{
    "data": ["string"]
}

Это покрывает все твои кейсы с 1 строкой и с null. И маппинг упрощается.