👣 Собственная функция sleep

Итак, задача: написать свою фукнцию sleep
🟡Первое, что может прийти в голову — использовать time.After, вот так:

package main

import (
    "log"
    "time"
)

func sleep(d time.Duration) {
    select {
    case <-time.After(d):
    }
}

func CallSleep() {
    log.Println("Do something")
    sleep(5 * time.Second)
    log.Println("Something else")
}

Но выглядит как-то громоздко, да и вообще.

🟡Второй вариант — сделать так:

func sleep2(d time.Duration) time.Time {
    ticker := time.Tick(d)
    for done := range ticker {
        return done
    }
    return time.Now()
}

🟡А можно вообще сделать так:

func sleep(d time.Duration) {
    <-time.After(d)
}

Ну вот, то, что нужно

@Golang_google

👣 Golang HTTP синхронизация

▶️Кейс: пишем Restful сервер с использованием патернов network_api -> data(UseCase->Repository).

Так как все http хендлеры обрабатываются параллельно, то каким образом корректно протянуть зависимости репозиториев и use_case объектов в слой network_api? То есть это будут синглтоны или же их нужно создавать для каждого отдельного request?
Что насчёт доступа к общим ресурсам?
Например, use_case при загрузке читает json-конфигурацию и в дальнейшем к ней обращается по многим путям из слоя nwtwork_api.

Есть какие нибудь best practices?


▶️Здесь всё зависит от того, какие требования предъявляются к нашим данным (т.е именно модель данных диктует требования к архитектуре).
Если наши данные терпимы к параллельному одновременному доступу — тогда можно не замарачиваться. Если же нельзя одновременно из нескольких потоков обращаться к менеджеру данных — тогда стоит ввести глобальную блокировку. Фактически, такой глобальной блокировкой будет являться единственное соединение к базе данных.
Вот и всё, пожалуй

@golang_interview

👣 Go, Allure и HTTP, или как тестировать HTTP-сервисы на Go

Держите полезную статью о тестировании Go-приложений
Что внутри?

⏩В статье рассматривается создание библиотеки CUTE для упрощения тестирования HTTP-сервисов на языке Go.

⏩Библиотека CUTE облегчает создание автотестов и упрощает переход на Go, предоставляя возможности для создания HTTP-тестов и реализации проверок.

⏩Ранее в компании Ozon не было подходящих инструментов для тестирования HTTP-сервисов, и библиотека CUTE была создана для решения этой проблемы.

⏩В статье описывается процесс создания теста, начиная с подготовки сервиса и инициализации билдера.

⏩Библиотека предоставляет возможности для информирования о тесте, подготовки дополнительных шагов и создания запросов.

⏩В библиотеке доступны готовые ассерты для проверки кода ответа, JSON-схем и полной проверки ответа.

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

⏩Для создания теста необходимо вызвать ExecuteTest, передавая контекст и testing.TB или provider.T

📎 Статья

@golang_interview

👣 Как проверить, имплементирует ли переменная интерфейс?

⏩В Go, реализация интерфейса является неявной, поэтому используется конструкция вида
var _ myInterface = &myImplementation{}:

type T struct{}
var _ I = T{}       // Проверка, что T имплеменирует I.
var _ I = (*T)(nil) // Проверка, что *T имплеменирует I.

Обычно это указывают, чтобы ошибки были выявлены уже во время компиляции.

@golang_interview