Когда оборачиваешь доступ к апи в объект, то можно сделать сперва методы, которые соотносятся с эндпоинтами самого апи 1 к 1. А уже потом, используя эти методы создавать публичные методы удобные для всего остального кода.

Я раньше так и делал, но неосознанно, а сейчас явно прочитал, что это нормальная идея у Фаулера:
Sometimes a good strategy is to build the Gateway in terms of more than one object. The obvious form is to use two objects: a back end and a front end. The back end acts as a minimal overlay to the external resource and doesn’t simplify the resource’s API at all. The front end then transforms the awkward API into a more convenient one for your application to use. This approach is good if the wrapping of the external service and the adaptation to your needs are reasonably complicated, because each responsibility is handled by a single class. Conversely, if the wrapping of the external service is simple, one class can handle that and any adaptation that’s needed.

Не нравятся каналы, где отключены негативные реакции. Слабаки...

(Накидайте какашек)

🤣🤣🤣

Батя: сынок, ты в каком классе?
Мама:

#книги
Vlad Khononov - Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy
01.07.2023 - 23.07.2023
Хотя по факту я читал ее дольше т.к. начинал и на середине остановился из-за того, что понял, что надо читать делая заметки, а читал тогда еще с телефона.

Книга хорошая. Отличный рейтинг на амазоне, считаю, что ее хорошо читать, как первую книгу в DDD.

Вообще в DDD есть 2 главные книги, это:
1. Синяя Eric Evans - Domain-Driven Design - классика DDD
2. Красная Vaughn Vernon - Implementing domain-driven design

Когда я разбирался, что читать, то видел совет начинать с красной т.к. она более прикладная, а не чистая теория, как в синей. Совершенно бесполезный совет. Красная книга читается плохо, дак еще и использует термины, определения которых нет в книге (конечно нет, они в синей находятся). Синюю я тоже читать не хотел т.к. и рейтинг тоже не самый высокий и еще большая. И я наткнулся на текущую книгу с огромным рейтингом и отличными отзывами. Ее и начал, а синюю запланировал на потом.

Самое полезное, что узнал:
1. Как можно делить то, чем занимается компания на домены. Выделяется три домена Core, Generic и Supporting. И это открывает глаза, когда пробуешь определить, где в компаниях какой домен и в каком домене работаешь сам (оказалось, что я в supporting домене). Супер понравился такой способ классификации. В зависимости от него еще софт пишется по-разному, а где-то лучше вообще не писать, а купить или взять готовое решение (в Generic домене)
2. Наконец-то прочитал определения паттернов Aggregates, Entities, Value Object и т.д. Я в целом их и так знал, но в каждой книге то, что уже знаешь открывается по-новому. Еще это добавило понимания некоторых элементов чистой архитектуры - тот же слой Entities образован от названия паттерна.
3. Глава про архитектуру Layered и Hexagonal заставила наконец-то разобраться с кашей терминов, которые используются для названия слоев итд. Теперь у меня есть отличное понимание, где какой и какой как называется.
4. Ну и конечно наполнил свой obsidian конспектом и иногда просто короткими заметками, чтобы определенные темы мог найти поиском и разобраться в теме более подробно используя такие заметки из разных книг

Такую киновселенную я бы посмотрел)

Аптайм моего домашнего компа.
Линукс класс! Просто работает и все. И никаких автообновлений

В прошлом, когда облигации были на бумаге, каждый купон был отрывным листком, который содержал информацию о купонной выплате (обычно в процентном соотношении к номинальной стоимости) и дате, когда эта выплата должна была быть произведена. Купонные выплаты обычно осуществлялись периодически, например, каждые шесть месяцев.

Владелец облигации мог отрывать каждый купон и обналичивать его в банке или другом финансовом учреждении для получения процентной выплаты. Таким образом, термин "купон" возник из практики отрывать эти листки от облигации, как купоны, чтобы получить доход от инвестиции.

Очень много нового. Дженерики наконец-то начинают приносить пользу стандартной либе

Релиз Go 1.21

Вот и состоялся релиз новой версии Go. Кроме того, что указано здесь, у нас так-же появились:

- Довольной большой пакет slices: среди прочего содержит функции Min / Max, функцию сортировки и функцию поиска в сортированном слайсе. И больше не нужно писать страшные блоки вставки и удаления элементов из слайса.
- Пакет maps: по сравнению со слайсами как-то бедновато, но есть удобная функция копирования.
- Пакет cmp: содержит обьявление всех сравниваемых по порядку типов и две базовые функции для работы с ними. Нужно скорее для пакетов maps и slices, а так-же разработчикам библиотек с коллекциями.
- Profile-guide optimization (PGO - оптимизация основанная на данных профилировки) вышла из превью и теперь применяется всегда если присутствует файл default.pgo в директории main пакета. Говорят, что благодаря ей удалось ускорить компилятор примерно на 6%.
- Улучшение пакета context: теперь можно вешать функцию на отмену контекста (удобно когда вам нужно закрыть канал или прекратить чтение из сокета) и отвязать дочерний контекст от отмены родителя.
- При выводе очень глубоких стеков теперь показывают 50 самых верхних и 50 самых нижних фреймов (названий функции) вместо 100 самых верхних как это было ранее. Должно помочь с отладкой паник в рекурсивных функциях.

гугл фото оказывается рисуют классную тепловую карту, где сделаны фото (следят за мной)

Читаю исходный код Go.

Как же нечитаемо написано. Имена переменных из одной буквы совершенно не помогают понять, что происходит. Еще экономия на переменных, результат которой вот такое в одну строчку. Функция mapaccess1:
b := (*bmap)(add(h.buckets, (hash&m)*uintptr(t.bucketsize)))
тут происходит:
1. hash&m Вычисление остатка от деления - номер бакета мапы.
2. (hash&m)*uintptr(t.bucketsize) Вычисление относительного адреса ячейки памяти (а-ля сдвиг ячейки памяти, этого бакета)
3. add(h.buckets, (hash&m)*uintptr(t.bucketsize)) Вычисление абсолютного адреса ячейки памяти по сдвигу
4. (*bmap) каст ансейф указателя к обычному.

Я пока разбирался написал вот так:
bucketNumber := hash & mask

bucketSizeInBits := uintptr(t.bucketsize)

bucketOffset := bucketNumber * bucketSizeInBits

bucketAddress := (*bmap)(add(h.buckets, bucketOffset))


Но уже в функции mapassign сделано вот так:
bucket := hash & bucketMask(h.B)


На ревью я бы такое не пропустил...)

Отличный график

NASA: июль был самым жарким месяцем в истории Земли

Ученые Института космических исследований Годдарда (GISS) НАСА в Нью-Йорке официально подтвердили, что в июле 2023 года была самая высокая глобальная температура за всю историю.

В течение месяца температурные рекорды были побиты в некоторых частях Южной Америки, Северной Африки, Северной Америки и Антарктического полуострова. В этих регионах наблюдалось повышение температуры примерно на 7,2 F (4 C) выше среднего. Еще один интересный факт: пять самых жарких июлей с 1880 года произошли за последние пять лет.

Изменение климата в первую очередь вызвано увеличением содержания парниковых газов в атмосфере Земли, которые удерживают тепло и приводят к чрезмерному нагреванию планеты.

На диаграмме показаны аномалии глобальной температуры для каждого июля с 1880-х годов, основанные на анализе NASA GISTEMP. Аномалии отражают, насколько глобальная температура была выше или ниже нормы 1951-1980 годов для июля.

Absolutely wrong)

Какой же это шедевр, а не технология)
(На графике распределение количества элементов в бакетах мапы, которую я пишу)