Ждали Go-meetup?

Уже завтра состоится конференция Ural Digital Weekend! До встречи в Перми!

Где-то в закладках уже давно лежит полезная и до сих пор актуальная статья о способах реализации пагинации в Postgres.

Обязательно к прочтению backend-разработчикам)

#postgres

СОВЕТ ДЛЯ УСПЕШНОГО ПРОХОЖДЕНИЯ СЕКЦИИ SYSTEM DESIGN НА СОБЕСЕДОВАНИИ

Одна из моих любимых секций в собеседовании разработчиков - System Design. Что мне в ней нравится? Тут нет правильного ответа, который можно заучить. Тут важно именно рассуждения кандидата, его опыт, знания технологий, то как он подходит к задаче.

Ошибка большинства разработчиков при выборе технологий/СУБД: взять что-то универсальное или только то, с чем работал на работе.
Пример: проектируется социальная сеть aka VK/Facebook. Нужно выбрать БД для сообщений, пользователей, друзей. Большинство разработчиков выбирают для этой задачи Postgres/MySQL объясняя это тем, что данные хорошо ложатся в реляционную модель. Действительно, фишка Postgres/MySQL в том, что это СУБД универсальные, позволяющие решать многие задачи (но не всегда эффективно).

В 2024 году важно не то, как данные можно представить, а то как вы их используете! Т.е. необходимо отталкиваться от кейсов использования данных, от нагрузок и т д. Пример: какой смысл использовать реляционную БД для хранения чатов и сообщений, если 99% процентов запросов будут по первичному ключу чата? Для этого больше подойдут NoSQL решения (KV/WideColumn/Column).
К тому же очень важно понимать как та или иная технология может масштабироваться. Это очень важно при проектировании системы. Лучше выбрать 1 раз хорошую технологию и горизонтально ее масштабировать, чем каждый раз внедрять костыли и переходить с одной технологии на другую.

Оставил шпаргалку с СУБД и их классификацией:)
Всем хороших выходных!

РАЗБИРАЕМСЯ С ИТЕРАЦИЯМИ ПО СЛАЙСАМ В GO

В Go есть всеми знакомая конструкция для итерации по всем элементам слайса/массива:

for i, v := range slice {
   // ...
}

i - текущий индекс элемента
v - копия текущего элемента слайса (slice[i])

И индекс, и значение мы можем опускать если не используем, с помощью _. Но зачем разработчики языка Go дали нам 2 разные возможности итерации по слайсам? И какой способ в итоге лучше использовать?

Рассмотрим пример:

s := []int{1, 2, 3}
for _, v := range s {
 v++
}
fmt.Println(s)

Данный код выведет нам в консоль [1, 2, 3]. Почему так? В переменную v кладется копия элемента слайса и v никак не ссылается на элемент. В итоге изменение переменной v не приводит к изменению элементов слайса.

Обратный пример:

s := []int{1, 2, 3}
for i := range s {
 s[i]++
}
fmt.Println(s)

Здесь уже программа нам выведет [2, 3, 4], поскольку конструкция s[i] получается неявной ссылкой на элемент слайса и тут уже нет никакого копирования, мы применяем оператор инкремента (++) непосредственно к самому элементу.

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

Допустим у нас элементы слайса не int, а большая структура:

type BigStruct struct { // size=1032 bytes
 _     [1024]byte
 Field int64
}

Попробуем проитерироваться по слайсу больших структур по индексу и по значению, сравнив оба подхода в бенчмарке:

func Benchmark(b *testing.B) {
 const elems = 1000
 s := make([]BigStruct, elems)
 tmps := make([]int64, elems) // need to avoid compiler optimizations for loops

 b.ResetTimer()

 b.Run("iterate slice of structs by index", func(b *testing.B) {
  for i := 0; i < b.N; i++ {
   for idx := range s {
    tmps[idx] += s[idx].Field
   }
  }
 })

 b.Run("iterate slice of structs by value", func(b *testing.B) {
  for i := 0; i < b.N; i++ {
   for idx, v := range s {
    tmps[idx] += v.Field
   }
  }
 })
}

Результат бенчмарка будет следующий:

Benchmark/iterate_slice_of_structs_by_index-10           1626810        735.2 ns/op        0 B/op        0 allocs/op
Benchmark/iterate_slice_of_structs_by_value-10             60226      19841 ns/op        0 B/op        0 allocs/op

Тут мы видим, что в данном случае итерация по индексу в РАЗЫ быстрее. Почему? Потому что Go при итерации по значению вынужден при каждой итерации копировать большую структуру в переменную. Чем больше объект, тем больше стоит его копирование. Если посмотреть такой код в профилировщике, то вы увидите, что работает runtime.duffcopy. Если такое встретится у вас, смело переходите на итерацию по индексу.

А если у нас слайс указателей?

s := make([]*BigStruct, elems)

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


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

Надеюсь эти правила помогут вам с code review 😉

#golang

Ozon Tech Community TeamLead Meetup

21 августа | 18:30 мск | офлайн и трансляция

Такое событие в календаре — первый тимлидский митап в Ozon! Прокачай софты в компании экспертов Ozon комьюнити и других бигтехов.

В программе: два доклада, панельная дискуссия, угощения и время для неформального нетворкинга.

📌 Доклад 1: «Как окунуться в новую предметную область и не утонуть»
Юлия Лукина, старший менеджер проектов, поможет сориентироваться на новом месте — погрузиться в неизведанную область и справиться с синдромом самозванца.

📌 Доклад 2: «(Хороший_инженер) != (Хороший_тимлид)»
Иван Миронов, руководитель отдела разработки, объяснит, на какие характеристики будущих руководителей нужно опираться при найме.

🗯 Дискуссия: «Быть или не быть: тимлид или эксперт?»
Обсудим горизонтальное и вертикальное развитие, метрики эффективности и подходы к принятию технологических вызовов.

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

2. Билдеры (Builder Pattern)

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

type House struct {
    floors int
    color  string
    garage bool
}

type HouseBuilder struct {
    house *House
}

func NewHouseBuilder() *HouseBuilder {
    return &HouseBuilder{house: &House{}}
}

func (b *HouseBuilder) SetFloors(floors int) *HouseBuilder {
    b.house.floors = floors
    return b
}

func (b *HouseBuilder) SetColor(color string) *HouseBuilder {
    b.house.color = color
    return b
}

func (b *HouseBuilder) SetGarage(garage bool) *HouseBuilder {
    b.house.garage = garage
    return b
}

func (b *HouseBuilder) Build() *House {
    return b.house
}

func main() {
    builder := NewHouseBuilder().
        SetFloors(2).
        SetColor("blue").
        SetGarage(true)
    
    house := builder.Build()
    fmt.Printf("House: %+v\n", house)
}

Сегодня закончил четырехдневный курс ораторского мастерства (естественно с отличием, а как иначе). Теперь мои доклады должны стать еще лучше!😅

А вообще словил невероятный кайф от оффлайн обучения, знакомств и курса в целом.

Поделитесь в комментариях, какой последний курс проходили, или какую книгу читали, для прокачивания своих скилов?