ненадолго, но на погонять точно хватит %)

и подумайте про конфигурацию

Конфигурация в виде yaml есть, пока не так много параметров, только основные

если понадобится — дам сервак на тесты

Спасибо)

А каким щас пакетменеджером все пользуются?

А каким щас пакетменеджером все пользуются?

https://github.com/avelino/awesome-go#package-management

А каким щас пакетменеджером все пользуются?

Звучит как реклама скайпа

Сори что неверно сформулировал :) Полтора года не использовал go, вот возвращаюсь. Раньше все сложно было, хотел узнать проще ли щас и есть ли стандарт де-факто

Судя по ответам - все так же :)

Сори что неверно сформулировал :) Полтора года не использовал go, вот возвращаюсь. Раньше все сложно было, хотел узнать проще ли щас и есть ли стандарт де-факто

Приходите в новом учебном году, в сентябре научится таким трюкам

?

Сори что неверно сформулировал :) Полтора года не использовал go, вот возвращаюсь. Раньше все сложно было, хотел узнать проще ли щас и есть ли стандарт де-факто

ничего не поменялось

в этом и суть го

В 1.11 будет менеджер из коробки

Сори что неверно сформулировал :) Полтора года не использовал go, вот возвращаюсь. Раньше все сложно было, хотел узнать проще ли щас и есть ли стандарт де-факто

я считаю, что всё как раз идет к упрощению

после релиза vgo в awesome-go прямо напишем, что лучше использовать официальное решение, а не велосипеды

Спасибо

не пытаться использовать цвета на винде

ты о чём?

да я тут мимо проходил

искать os.Exit()

значит бинды хреновые

почему tdlib юзаешь? чем другие либы не понравились? или pure-go клиента нет?

какую задачу ты пытаешься решить?

@toby3d есть там чо?

Все верно. Tdlib официальная либа с полным покрытием апи

естественно, что официальная

но это не говорит, что бинды на неё адекватные

Остальное старые наколенные имплементации мтпрото

Адекватные. Крутится два месяца без остановки демон, ни разу не упал

Просто не получилось )

никак, насколько помню

это не panic, а throw

Хм. В сях проблема. Напиши issue, исправят. Там автор чуть ли не 24 часа в сутки отвечает

Os.exec? Как вообще ты это юзаешь?

issue не забудь создать

Ребят, подскажите в какую сторону копать необходимо реализовать upnp сервер и транслировать по нему плейлист iptv

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

== как бы перехватить panic https://github.com/maruel/panicparse

== как бы перехватить panic https://github.com/maruel/panicparse

Прикольная штука, спасибо

@toby3d есть там чо?

Нет, я делал пакет для ботов, паспорта и логина телеги. tglib не трогал, но может доберусь когда-нибудь

TWIMC: вчерашняя проблема с listen оказалась очень странной: нельзя слишком часто открывать-закрывать unix сокеты. от этого что-то где-то ломается, и listen сокет закрывается надо бы багрепорт написать, но непонятно, куда

офигенно какжется я только что понял почему у меня кое-что не работает

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

Кто может посоветовать книги/статьи или готовые решения связанные с p2p сетью?

надо конкретизировать вопрос

Устройство p2p, пример любой p2p сети на go

https://github.com/meshbird/meshbird может?

Такое ещё было https://4gophers.ru/articles/vpn-eto-prosto/#.W3gpgmhn00M непонятно что конкретно надо

https://github.com/libp2p/go-libp2p

Устройство p2p, пример любой p2p сети на go

Тук. Забыл ответом написать :)

там в подкладке webrtc, которого на чистом go нет

там в подкладке webrtc, которого на чистом go нет

Разве нет?

предположим я хочу заимплементить в свое приложение выбор master/slave при этом https://github.com/rqlite/rqlite это слишком много (мне не нужна полноценная база данных на консенсусе) и https://github.com/hashicorp/raft это слишком мало (мне не хочется самому прописывать логику "что делать если потерялся мастер" и вообще девелопить отдельную либу, хочется продакшн-реди) что порекомендуете чисто для выбора мастера нецентрализованонго без сервис-дискавери (не через consul/redis/etcd/..., сервисы знают ip друг друга), такую себе либу "подключил и забыл"

Народ, когда твой сервис в http запросе возвращает json, обычно же, при ошибки на сервере, возвращают что-то типо status: "bad", и error:"someerror". А в случае успешного следует всегда возвращать status:"ok" или считается, что http статуса должно хватать?

Где вообще можно узнать про практики json ответов

http status должно хватать, можно в каждый ответ засовывать message с описанием

ERROR: S client not available

http://jsonapi.org/ это типа спецификаци

но имхо оверхед

О, спасибо

RESTful правил будет достаточно

http://jsonapi.org/ это типа спецификаци

выглядит (по гитхабу) как будто еще в 15-м году на эти спеки забыли

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

Где вообще можно узнать про практики json ответов

в целом формат ответов зависит от того как сервер общается с клиентом (если мы только про REST говорим), лучших практик нет есть только холивары ? я например нашел удобным дублировать http-ошибку в ответе и еще добавлять статускод (стандартных http-кодов обычно не хватает когда клиенту нужно обрабатывать дополнительные логики - например 401 Unauthorized может быть как "токен неправильный вообще" так и "токен истек" и тп) поэтому, ошибки выглядят у меня примерно так: { message: "human-readable error", status: http-status-code, code: "COMPUTER-READABLE-ERROR-CODE" } ответы на POST/PUT выглядят так: { success: true, id: "resource-created-id" } ответы на GET - любой JSON в рамках того что мы хотим отдать клиенту однако, вы захотите добавлять дополнительные данные - пейджинацию например, количество документов общее и тп: и тогда вы или будете их заголовками передавать, или заранее заложитесь на стандартный ответ (тут уже вам выбирать как удобнее, но лучше делать с запасом чтобы потом версию API не менять и разные не поддерживать): { data: { json-response }, total: total_amount_of_resources, next: "cursor-id-to-fetch-next-portion", ... }

но вообще, я думал тут все на gRPC фигачат? ?

в целом формат ответов зависит от того как сервер общается с клиентом (если мы только про REST говорим), лучших практик нет есть только холивары ? я например нашел удобным дублировать http-ошибку в ответе и еще добавлять статускод (стандартных http-кодов обычно не хватает когда клиенту нужно обрабатывать дополнительные логики - например 401 Unauthorized может быть как "токен неправильный вообще" так и "токен истек" и тп) поэтому, ошибки выглядят у меня примерно так: { message: "human-readable error", status: http-status-code, code: "COMPUTER-READABLE-ERROR-CODE" } ответы на POST/PUT выглядят так: { success: true, id: "resource-created-id" } ответы на GET - любой JSON в рамках того что мы хотим отдать клиенту однако, вы захотите добавлять дополнительные данные - пейджинацию например, количество документов общее и тп: и тогда вы или будете их заголовками передавать, или заранее заложитесь на стандартный ответ (тут уже вам выбирать как удобнее, но лучше делать с запасом чтобы потом версию API не менять и разные не поддерживать): { data: { json-response }, total: total_amount_of_resources, next: "cursor-id-to-fetch-next-portion", ... }

Ого, спасибо за подробный ответ

если вступаете на скользкую дорожку REST - сильно советую сразу начать правильно делать с использованием https://github.com/OAI/OpenAPI-Specification ?

тогда не придется вручную писать документы для клиентских разработчиков например, а можно будет заюзать автогенерацию: https://github.com/Rebilly/ReDoc

ну и в продвинутых техниках - валидация входящих/исходящих запросов через json schema без лишней логики на сервере ?

Ох, столько навалили, теперь надо во всём этом копаться ?

Спасибо

Народ, когда твой сервис в http запросе возвращает json, обычно же, при ошибки на сервере, возвращают что-то типо status: "bad", и error:"someerror". А в случае успешного следует всегда возвращать status:"ok" или считается, что http статуса должно хватать?

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

Народ, когда твой сервис в http запросе возвращает json, обычно же, при ошибки на сервере, возвращают что-то типо status: "bad", и error:"someerror". А в случае успешного следует всегда возвращать status:"ok" или считается, что http статуса должно хватать?

от фронтов зависит)) иногда им хочется всегда обрабатывать 200ОК, а в доп полях ошибки смотреть?

от фронтов зависит)) иногда им хочется всегда обрабатывать 200ОК, а в доп полях ошибки смотреть?

то есть?

тогда не придется вручную писать документы для клиентских разработчиков например, а можно будет заюзать автогенерацию: https://github.com/Rebilly/ReDoc

дизайн ферст наше все

а то один ленится доку писать, а потом вся команда в говно наступила

а то один ленится доку писать, а потом вся команда в говно наступила

обратите внимание на рекомендацию использовать openapi3.0 aka ex-swagger

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

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

тогда твоя фраза про генерацию доки из кода не верна?)

наоборот же

Спат

Нада

в целом формат ответов зависит от того как сервер общается с клиентом (если мы только про REST говорим), лучших практик нет есть только холивары ? я например нашел удобным дублировать http-ошибку в ответе и еще добавлять статускод (стандартных http-кодов обычно не хватает когда клиенту нужно обрабатывать дополнительные логики - например 401 Unauthorized может быть как "токен неправильный вообще" так и "токен истек" и тп) поэтому, ошибки выглядят у меня примерно так: { message: "human-readable error", status: http-status-code, code: "COMPUTER-READABLE-ERROR-CODE" } ответы на POST/PUT выглядят так: { success: true, id: "resource-created-id" } ответы на GET - любой JSON в рамках того что мы хотим отдать клиенту однако, вы захотите добавлять дополнительные данные - пейджинацию например, количество документов общее и тп: и тогда вы или будете их заголовками передавать, или заранее заложитесь на стандартный ответ (тут уже вам выбирать как удобнее, но лучше делать с запасом чтобы потом версию API не менять и разные не поддерживать): { data: { json-response }, total: total_amount_of_resources, next: "cursor-id-to-fetch-next-portion", ... }

Почему я так часто вижу, что возвращается абстрактное success поле, которое не несёт смысловой нагрузки

наоборот же

Ну в этой интерпретации - да, я сформулировал не так. Кодогенерацию не люблю поэтому юзаю спеку только для валидации и _генерации документации автоматически_