ну, у меня проблем не было

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

спасибо за комментарий попробую учесть

ну, у меня проблем не было

Сложность избыточная, мне кажется. Нужно же быть проще

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

go generate - это некоторое соглашение об описании внешних тулзов в тексте go-проекта. специального вида комментарий. и программа, которая обходит дерево сорцов и вызывает, что сказано это что сказано может делать что угодно, но идея в том, что оно генерит сорцы для go, которые потом компиляются а проект например - ресурсы так можно в свой проект включать, с помощью go-bindata. из файлов генерится go-файлик, в котором эти файлы присутствуют в виде []byte ну или вот у нас есть в проекте такой набор комментов: //go:generate bash -c "printf 'package main\n\n' > version.go" //go:generate bash -c "printf 'const globalVersionString=\"%s\"\n' git rev-parse HEAD >> version.go" //go:generate bash -c "printf 'const globalVersionUint32=0x%7.7s\n' git log --pretty=format:'%h' -n 1 >> version.go" //go:generate bash -c "printf 'const globalVersionTimestamp=%d\n' git log -1 --format=%ct >> version.go"

Go к этому располагает

go generate - это некоторое соглашение об описании внешних тулзов в тексте go-проекта. специального вида комментарий. и программа, которая обходит дерево сорцов и вызывает, что сказано это что сказано может делать что угодно, но идея в том, что оно генерит сорцы для go, которые потом компиляются а проект например - ресурсы так можно в свой проект включать, с помощью go-bindata. из файлов генерится go-файлик, в котором эти файлы присутствуют в виде []byte ну или вот у нас есть в проекте такой набор комментов: //go:generate bash -c "printf 'package main\n\n' > version.go" //go:generate bash -c "printf 'const globalVersionString=\"%s\"\n' git rev-parse HEAD >> version.go" //go:generate bash -c "printf 'const globalVersionUint32=0x%7.7s\n' git log --pretty=format:'%h' -n 1 >> version.go" //go:generate bash -c "printf 'const globalVersionTimestamp=%d\n' git log -1 --format=%ct >> version.go"

Зачем если есть makefile?

нету никакого makefile

Вызывать будет нужно либо go generate либо make build либо что то еще

Если так, то все проще описывать сборку где то вне исходников на го

go generate у меня, очевидно, есть - он из базовой поставки go

а вот make|gmake у меня может и не быть

мы кстати для версии используем -ldflags "-X main.version=$version"

нахера еще один тулчейн втаскивать в экосистему

нахера еще один тулчейн втаскивать в экосистему

1. Он гибкий 2. Есть почти везде, а вот го не везде

правда оно кажется не сработает при const version, только при var version

1. Он гибкий 2. Есть почти везде, а вот го не везде

а зачем тебе makefile, генерящий .go, если там нет go?

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

go generate - это некоторое соглашение об описании внешних тулзов в тексте go-проекта. специального вида комментарий. и программа, которая обходит дерево сорцов и вызывает, что сказано это что сказано может делать что угодно, но идея в том, что оно генерит сорцы для go, которые потом компиляются а проект например - ресурсы так можно в свой проект включать, с помощью go-bindata. из файлов генерится go-файлик, в котором эти файлы присутствуют в виде []byte ну или вот у нас есть в проекте такой набор комментов: //go:generate bash -c "printf 'package main\n\n' > version.go" //go:generate bash -c "printf 'const globalVersionString=\"%s\"\n' git rev-parse HEAD >> version.go" //go:generate bash -c "printf 'const globalVersionUint32=0x%7.7s\n' git log --pretty=format:'%h' -n 1 >> version.go" //go:generate bash -c "printf 'const globalVersionTimestamp=%d\n' git log -1 --format=%ct >> version.go"

А. Дошло. Всё, мгновенно всё сложилось. Да, прикольно... Спасибо

а что такое - правильно

best practics

эмм

у нас проекту полгода

я уже раза 4 перекраивал его структуру

и в пятый не перекраиваю только потому, что настала пора его полностью переписать :)

и в пятый не перекраиваю только потому, что настала пора его полностью переписать :)

намек понял )))

просто хотелось взглянуть, как грамотные этом плане, люди это делают

на самом деле - можно поглядеть в telegraf, который от influxdb

я уже раза 4 перекраивал его структуру

ну кстати история перекроя тоже интересная штука. это риторическое утверждение с моей стороны. однако.

там оправданно сложная структура

но сам influx такое дерьмо, что возникают сомнения в грамотности этих людей

даи telegraf задуман прикольно, а реалиован как обычно местами

но сам influx такое дерьмо, что возникают сомнения в грамотности этих людей

понятно, что все мы - всего лишь люди

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

По описанию на формат jsonshema походит, только писать ручками json-то ещё веселье.

json не годится для конфигов - в нем нет комментов

json не годится для конфигов - в нем нет комментов

есть, но в виде костылей

вида свойство объекта __comment

yaml, правда, тоже счастье то еще - в нем пробельные символы синтаксической значимостью обладают

json не годится для конфигов - в нем нет комментов

И структура не очень удобная Toml и ini имхо - самое то

@onokonem в обучном json каментов нет, в формате jsonshema - можно указать описание поля: { "$schema": "http://json-schema.org/draft-04/schema#", "title": "Product", "description": "A product from Acme's catalog", "type": "object", "properties": { "id": { "description": "The unique identifier for a product", "type": "integer" } }, "required": ["id"] }

И структура не очень удобная Toml и ini имхо - самое то

+

Т.е. в json хранится не сам конфиг, а его структура

сам конфиг уже из этой структуры генерится

описание конфига в yaml (или в xml)

вот про это имел ввиду

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

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

Типа boltdb

скорее consul

ну вот у нас все равно ароспайк - в него и сложили мы конфиг.

Стесняюсь спросить. Никита, а что еще ты делал три года?

Я не особо в опенсорс контрибьютил

Привет Никита, я от тебя овета жду уже вторую неделю :(

Ты везде. Я надеялся что все вопросы решились без меня. Я тут ботов для тг писал

Не решились :(

А объясните плиз принцип работы этой конструкции

s := []int{2, 3, 5, 7, 11, 13}

s = s[:0]

s = s[:4]

ну инициализация среза я понял в переменную s

получается s и s[] разные конструкции да?

Одинаковые.

Слайсы.

ну мне после руби немного нелогично)

в s литерал слайса

s = s[:0] урезаем до 0

срез пустой

s = s[:4] расширяем до 4х элементов

теперь там снова данные

почти магия

Кассандра инициализируешь, то это уже слайс, а потом слайс от слайса.

ERROR: S client not available

получается s = []int{2, 3, 5, 7, 11, 13}

s ссылается на литерал []int{2, 3, 5, 7, 11, 13}

которые ничерта не меняется

и даже если я напишу s2 := s[:4]

и дальше s3 := s[2:]

я буду получать срезы из лиетала?)

Вообще надо запомнить, что слайс это просто ссылка на диапазон массива.

ок

это я уже осознал

это надо вкурить хорошенько

Фактически просто с одним и тем же масмивом работаешь и все.

а если я добавлю туда элементы

А вот это надо попробовать. )

никуя не просто)

https://blog.golang.org/go-slices-usage-and-internals

с картинками стало понятней)

а если я добавлю туда элементы

append возвращает новый слайс

Мне только стало жутко интересно почему в английской статье вот это - x := [3]string{"Лайка", "Белка", "Стрелка"}

append возвращает новый слайс

я так понимаю не всегда.

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

я так понимаю не всегда.

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

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

ой. да. всё. надо больше кофе пить. чушь конечно я смолол. я конечно имел ввиду новый массив

ой как интересно

Перезаписывается элемент массива при добавлении в слайс.

packages = s[:0] main import ( "fmt" ) func main() { s := []int{2, 3, 5, 7, 11, 13} s = s[:0] s = s[:4] s = append(s, 5) s = s[:6] fmt.Printf("%v",s) }

если добавить к урезанному слайсу оно влезет перед урезанными элементами

[2 3 5 7 5 13]

хм

заменяет

len=6 cap=6 [2 3 5 7 11 13] len=0 cap=6 [] len=4 cap=6 [2 3 5 7] len=6 cap=6 [2 3 5 7 100 13] len=6 cap=6 [2 3 5 7 100 13]

Получается расширило слайс в массиве и перезаписало соответствующий элемент.

Если еще пару раз добавить, то расширит массив.