mayton2019

Если у тебя будет 100 нод-получателей то полюбому хотя-бы одна из них будет недоступна в момент отправки.
Такова природа вещей. И не стоит требовать от сетей перфекционизма. Сети работают как погода. Как дождь
или снег. Надо это учитывать.

Поэтому брокер сообщений на базе Kafka или Apache Pulsar или Rabbit будет вполне себе реальным решением.

Ты пишешь про p2p. Но какой ценой этот p2p ты собираешся поддержать на продюсере? Ты создашь 100 сокетов
и 100 буферов отправки сообщений?

Потому что другого выхода у тебя на самом деле нет. Или у тебя просто не пройдет транзакция я гарантирую
это.

В данном задании непонятно насколько остро стоит необходимость именно в 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 а тестирование логики следующего уровня. Бизнес-логики и прочее.