Юра  

Текс, всем привет, народ, просто инфопост. Грядет Шикарный (по моему мнению) материал про сборку мусора в Го, перелопатил кучу материала, ждите!

Для погружения в enum в языке GO для начала нужно узнать про перечисления в принципе.

"iota" - это ключевое слово в языке программирования Go, которое используется для генерации последовательности int'овых констант. Оно автоматически увеличивается на единицу для каждой последующей константы в блоке const, если не указано явное значение.

const (

       Red = iota // 0

       Green // 1

       Blue    // 2

)

const (

        _ = iota // пропуск первого значения

       KB = 1 << (10*iota) // 1 << (10*1) = 1024

       MB                           // 1 << (10*2) = 1048576

       GB                            // 1 << (10*3) = 1073741824

       TB                            // 1 << (10*4) = 1099511627776

)

const (

      Sunday = iota       // 0

      Monday                 // 1

      Tuesday =  5        // 5

      Wednesday          // 6

      Thursday             // 7

Микросервисная архитектура стала одним из самых популярных подходов в разработке ПО. Ее главным преимуществом является гибкость и масштабируемость, которые достигаются за счет разбиения большой системы на небольшие, независимые и легко модифицируемые сервисы. Однако, несмотря на все ее преимущества, Микросервисы не являются серебряной пулей, и в этой статье мы рассмотрим их плюсы и минусы, а также почему они не всегда являются оптимальным выбором.

Гибкость: микросервисная архитектура позволяет разрабатывать и масштабировать каждый сервис независимо друг от друга, что облегчает управление сложными приложениями.

Скорость разработки: Разработчики могут разрабатывать и тестировать каждый сервис отдельно, что ускоряет процесс разработки.

Надежность: Если один сервис выходит из строя, это не приводит к полной остановке системы, поскольку другие сервисы продолжают работу.

Легкость замены: Сервисы можно легко заменять, если они перестают соответствовать требованиям системы.

Сложность управления: Управление большим количеством небольших сервисов требует множества инструментов и умения управлять ими.

Сложность отладки: Отладка большого количества сервисов, которые могут работать на разных серверах, требует дополнительного времени и ресурсов.

Необходимость поддержки: Каждый сервис требует своей поддержки и тестирования, что может быть дорого и затруднительно.

Сложность интеграции: Интеграция между сервисами может быть сложной, и требует дополнительного времени и ресурсов.

Микросервисы - это мощный и гибкий подход, который может помочь разработчикам создавать сложные системы. Однако он не является оптимальным выбором для всех проектов. Разработчики должны тщательно оценивать преимущества и недостатки MSA перед его использованием.

ACID (Atomicity, Consistency, Isolation, and Durability) — это набор свойств, гарантирующих надежность и непротиворечивость транзакций в базах данных. Вот несколько реальных примеров, как транзакции ACID работают в базах данных:

1) Атомарность:

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

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

2) Консистентность (непротиворечивость)

Непротиворечивость гарантирует, что транзакция переводит базу данных из одного допустимого состояния в другое. Другими словами, данные всегда должны быть непротиворечивыми и соответствовать правилам и ограничениям, определенным в схеме базы данных.

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

3) Изоляция:

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

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

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

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

CAP теорема, она же теорема Брюера - одна из фундаментальных концепцией в распределенных системах. Эта концепция часто используется для проектирования распределенных баз данных. Давайте разберемся что это такое и с чем это едят.

CAP theorem гласит: в распределенной системе невозможно одновременно достичь всех трех следующих свойств:

1) C (consistency) — согласованность. Каждое чтение даст вам самую последнюю запись или ошибку.

2) A (availability) — доступность. Каждый не упавший узел всегда успешно отвечает на все операции чтения и записи при этом в адекватные сроки.

3) P (partition tolerance) — устойчивость к распределению. Система продолжает даже в случае потери связи между некоторыми узлами.

Короче говоря нельзя достичь всех трех описанных свойств, что-то да пойдет не так. Но почему? Давайте попробуем ответить на этот вопрос.

Запомните, дальше consistency - согласованность, availability - доступность, partition tolerance - устойчивость к распределению.

Противоречия между этими свойствами можно разделить на такие категории:

1) Согласованность и доступность:

- Чтение данных из системы должно всегда возвращать последнее записанное значение, чтобы достичь согласованности. Хотя, для обновления данных в системе требуется время на распространение информации между узлами и это может снизить доступность.

- Изменение данных в одном узле не дает гарантии, что данные будут сразу доступны в других узлах. Это может привести к несогласованности данных и потере доступности при обращении к данным. (проблема доступности)

-- Заходим на https://go.dev/tour/welcome/1 и изучаем все, что у нас под подписью basic, flow control, more types, methods and interfaces

-- Подробнее гуглим про область видимости, что это такое и как работает.

-- Решаем все задачки которые нам даются там, в целом ничего сложного, для начала этого хватит вполне.

Чек лист структур данных которые изучили:

1) Массивы и слайсы

2) Мапы

3) Структуры

-- Дополнительно смотрим про указатели видосик

https://www.youtube.com/watch?v=Gvf6b3ayaUo

1) Написать калькулятор который умеет в базовые операции +/-/*. Он должен быть бесконечным. То есть написал программа написала ответ и началась заново

Изучать ООП на примере го достаточно глупо. Это не представитель "настоящих" ООП языков поэтому смотрим вот этот видосик:

https://www.youtube.com/watch?v=W2V1ZUceKBk