по сути этим занимается твоя функция InitDB, которая возвращает указатель на переменную типа Config, в которой есть ненулевой указатель на DB

go не скриптовый язык)

ясно, спасибо

если оформляю методом - то присвоение идет как надо в структуре

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

все верно, на то он и метод

https://tour.golang.org/methods/1

пройди тур по гоу

Тут небольшая проблема, если гоу процесс решил "хотрелод" сделать, он отвалит клиентов с 504 (вернее он пошлет сначало nginx, который пошлет клиентов)

рестарует соотвественно через дефолтный http сервер

но он сразу сокет не положит, приходится еще ждать секунды 3

можно конечно балансер прослойку влепить

https://medium.com/@social_57971/how-to-add-a-gui-to-your-golang-app-in-5-easy-steps-c25c99d4d8e0

Как можно отсортировать массив структур пикселей color.Color по светлоте?

а в каком формате цвет?

0-255, я полагаю

а в каком формате цвет?

color.Color. Можно конвертнуть в RGBA, например

https://gobyexample.com/sorting-by-functions

например так

https://golang.org/pkg/sort/#Slice

или вот так

color.Color. Можно конвертнуть в RGBA, например

конверть RGBA в grayscale и чекай

или вот так

NO!

Как можно отсортировать массив структур пикселей color.Color по светлоте?

вот вам немного алгоритмов - http://qaru.site/questions/21183/formula-to-determine-brightness-of-rgb-color

@ruelephant почему нет?

@ruelephant почему нет?

ну во первых чб уже будет немного не точный результат

во вторых двойное конвертирование

можно высчитать сразу

дык как он будет определять "светлость" пикслей это его дело

вопрос то был как отсортировать...

https://golang.org/pkg/sort/ в помощь

я думал вопрос таки "как определить светлость пикселя"

сортировку на основании светлости изи

я думал вопрос таки "как определить светлость пикселя"

ну либо он неправильно задал вопрос, либо ты ответил на другой)

сортировку на основании светлости изи

Именно. У меня 4 пикселя: color.YCbCr{Y:0x40, Cb:0x9a, Cr:0x65} color.YCbCr{Y:0x59, Cb:0xa1, Cr:0x51} color.YCbCr{Y:0x5a, Cb:0x5a, Cr:0xf0} color.YCbCr{Y:0x7a, Cb:0xa7, Cr:0x3b} Мне нужно рассортировать их по светлоте как если бы я юзал HSL.

там выше давал ссылочку

как вывести светимость

в смысле яркость

Вот сижу и пробую у себя, спасибо

чорд

унес http хердлеры в отдельный пакет, и все больше и больше зависимостей перетягивается из application

хотя вроде application это прослойка уровня "управление вебсервером", а не хендлерами

что бы прямо от нее брать структур

не тащить же application в зависимости к handler?

как считаете

я делал структуру application которая хранила базу и прочие шарящиеся штуки

а хендлеры у меня были методы application

а хедлеры где объявлены были?

внутри application?

если application это субпакет то да

ну меня application лежит пока в main

в main() что-то такое

config := Config{} config.load(configPath); control := make(chan int) go func() { for { err := watchFile(configPath) if err != nil { log.Print("Config load failed " + err.Error()) } log.Print("Config has been changed") newConfig := new(Config) newConfig.load(configPath); config = *newConfig control <- APP_RESTART } }() app, err := createapp(&config) for { select { case command := <-control: switch command { case APP_START: app.Start() case APP_RESTART: err := app.Restart() if err != nil { log.Fatal("Failed restart application: &s", err.Error()) break; } case APP_STOP: app.Stop() } } }

ага, вы правильно поняли, веб сервер может быть погашен/запущен при живом процесс

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

ага, вы правильно поняли, веб сервер может быть погашен/запущен при живом процесс

главное останавливать его с помощью context'а и канала остановки, ибо graceful shutdown

кстати у меня вопрос по GraphQL, как на нём реализовать binary file upload? можно конечно через base64 энкодировать данные и посылать в качестве graphql параметра прямо в поле, но это лишний нагружает клиент, сервер, сеть

кстати у меня вопрос по GraphQL, как на нём реализовать binary file upload? можно конечно через base64 энкодировать данные и посылать в качестве graphql параметра прямо в поле, но это лишний нагружает клиент, сервер, сеть

гугл что говорит?

вообще лучше хранить картинки на диске, а в базе ссылки на них

гугл что говорит?

Гугл пока предложил только два варианта: 1. base64 2. upload через отдельный протокол, например HTTP в первом варианте очевиден overhead, но второй вариант неприемлем по причине согласованности например операция создания аккаунта пользователя.. если например что-то пойдёт не так, или параметры были неверные, или ещё что либо, то профиль не создастся, а файл останется на сервере (hello garbage collection!) и как гарантировать что аватарка вообще отправлена? ждать пока она загрузится на HTTP интерфейсе и если timeout то оборвать GraphQL запрос? звучит как-то не очень... согласованность, вот в чём вопрос

если только у тебя нету специализированного под картинки хранилища

даже если сделать добавление картинки / загрузку какого-либо файла отдельной мутацией, всё-равно нужно как-то синхронизировать, согласовать базу данных с HTTP интерфейсом загрузки на том же API сервере, чтоб БД знала что такой файл есть и он действительно существует на файл сервере, во избежание dead link'ов

https://medium.com/@social_57971/how-to-add-a-gui-to-your-golang-app-in-5-easy-steps-c25c99d4d8e0

напомнило книгу "резистор. сложно о простом"

ERROR: S client not available

И нужно ли их тестировать? Там функция получается в две строчки - открытие файла и проверка ошибки

Не надо, 100% покрытие не нужно. Надо тестировать те функции, которые в файл пишут, а им давать уже на вход io.Writer

кто смотрел уже? https://www.amazon.com/Learning-Functional-Programming-applications-programming-ebook/dp/B0725B8MYW

совсем наркомания или просто полная жесть?

Есть в го нормальный валидатор для Rest API, который по схеме может проверить map и вернуть map с ошибками?

И вообще как принято хэндлить валидацию?

Есть в го нормальный валидатор для Rest API, который по схеме может проверить map и вернуть map с ошибками?

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

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

или не морочиться с graphql, а просто гонять типизированные структуры

или не морочиться с graphql, а просто гонять типизированные структуры

это ты сейчас про что? кодировать данные в бинарку типа https://msgpack.org?

это ты сейчас про что? кодировать данные в бинарку типа https://msgpack.org?

не, это я просто про явный маппинг json в структуры, а не в map[interface{}]interface{}

плюс валидация поверх этого

но вообще да, msgpack тоже неплох. Просто для http он как-то не очень

мне просто концепция graphql не нравится

честно говоря я бы не стал изобретать колесо, ибо валидация это не просто "соответствует/не соответствует" а так-же error reporting и прочее, GQL помимо типизирования ещё много дополнительных преимуществ даст

честно говоря я бы не стал изобретать колесо, ибо валидация это не просто "соответствует/не соответствует" а так-же error reporting и прочее, GQL помимо типизирования ещё много дополнительных преимуществ даст

типизацию go и так дает, gql там не особо причем

а для особых случаев есть всякие там jsonschema

gql - это когда ты хочешь дать возможность фронтенду достать одним запросом тебе полбазы

зачем если это всё по умолчанию встроено в GQL причём с правильным error репортингом?

то есть примерно никогда

зачем если это всё по умолчанию встроено в GQL причём с правильным error репортингом?

что "это все"? есть примеры?

gql - это когда ты хочешь дать возможность фронтенду достать одним запросом тебе полбазы

не хочу начинать спор, но.... ? GQL это по сути REST 2.0 или "API design done right", кто с ним уже успел поработать меня поймёт

не хочу начинать спор, но.... ? GQL это по сути REST 2.0 или "API design done right", кто с ним уже успел поработать меня поймёт

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

рест - концепция так себе, но большой вопрос насчет gql - он решает больше проблем или создает

не надо фронтенду давать гибкости больше, чем он заслуживает

рест - концепция так себе, но большой вопрос насчет gql - он решает больше проблем или создает

- request aggregation - strong typing - type error reporting - no overfetching - no underfetching just to name a few features.. Не так давно кстати писал: https://medium.com/@romanscharkov/its-not-about-transport-multiplexing-but-rather-dataset-relations-a80928aa3423

- request aggregation - strong typing - type error reporting - no overfetching - no underfetching just to name a few features.. Не так давно кстати писал: https://medium.com/@romanscharkov/its-not-about-transport-multiplexing-but-rather-dataset-relations-a80928aa3423

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

а когда будет http pipelining - будет еще меньше нужен

а когда будет http pipelining - будет еще меньше нужен

прям как-будто для тебя писал свою публикацию на medium'е ? почитай, там всего ничего)

не надо фронтенду давать гибкости больше, чем он заслуживает

если власть у бекендеров, на фронтенде практически гарантирован адъ графкуэль - хорошо когда про неё ничего не знаешь вообще, и она работает себе через appolo js, иначе это костыль тот ещё

прям как-будто для тебя писал свою публикацию на medium'е ? почитай, там всего ничего)

я прочитал :) вижу много восторга на пустом месте

если власть у бекендеров, на фронтенде практически гарантирован адъ графкуэль - хорошо когда про неё ничего не знаешь вообще, и она работает себе через appolo js, иначе это костыль тот ещё

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

я прочитал :) вижу много восторга на пустом месте

видимо невнимательно читал) ох ладно, нет времени дебатировать, кому надо тот поймёт)