ребят, подскажите пожалуйста как заэкспортить структуру и заимпортить её в другом файле? (в моем кейсе модель) гуглил, не очень помогает

вопрос не ясен

любы типы, названия которых начинаются с заглавной буквы, экспортируются

в другом пакете к таким типам обращаются с указанием имени пакета

Плиз помогите например как обработать 1 млн запросов объясните

Всем доброго времени суток! Есть апи связанное с sqlitе. Для тестирования хендлеров, которые получают данные из бд или помещают их туда, нужно как то сфабриковать саму бд. То есть чтобы на уровне тестирования было понятно, что есть в бд и что в ней происходит. Данные у меня очень объемные и как-то нахожусь в растерянности, как тестировать это все. Поначалу думал, что можно создать так называемую test_db, закинуть туда руками данные и дальше с этим работать. Нет ли более оптимального метода для данной ситуации? Или все действительно так, ручками?

Плиз помогите например как обработать 1 млн запросов объясните

Можно последовательно, модно параллельно. Главное - по ошибки не забывать

Плиз помогите например как обработать 1 млн запросов объясните

Есть статья как делали такой сервер

С кодом и обьяснением

Можешь скинуть? пж

Если делать параллельно, то надо через диспетчер и воркеров

Окей

Спасибо вам !!

http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/

Еще от мейла на хабре статья есть

http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/

Спасибо!

Если хочешь могу скинуть свой пример реализации

Да скиньте !

Но я бы советовал статью почитать и разобраться

В лс кину

Ок

в другом пакете к таким типам обращаются с указанием имени пакета

это все понятно, предположим, я делаю пакет user, где описываю структуру модели User, в другом пакете импорчу, в виде: import user_model "path/to/package" доступ к ней будет по: user_model.User есть ли возможность как-то заимпортить, чтобы доступ был просто по User, без user_mode.User ?

Import . "/path/to/package"

Import . "/path/to/package"

линтер говорит, что should not use dot imports

Потому что это плохой стиль, но это то, что вы спросили

Потому что это плохой стиль, но это то, что вы спросили

в таком случае как сделать лучше и правильно?

если не сложно – посдкажите, пожалуйста

я вижу вариант объеденить все модели под 1 пакет, импортить его и использовать нужную структуру, типа: models.User

Или так, или эдак

Сделать пакет models, положить туда User, обращаться как models.User

ага, спасибо!

так и сделал на текущий момент

https://www.youtube.com/watch?v=ZbtB1Aqc41A

Ребята из Авито действительно странные ) Не совсем понял их "проблемы"

Они же сразу сказали... небыло экспертизы. Их коллеги (OLX) в Берлине, начинают писать на Котлине и еще PHP есть. Но они видимо не дружат между собой.

Подскажите пожалуйста такой вопрос, скачал проект, запустил dep ensure -v, оно создало vendor папку и включило мой проект туда. Почему это могло случиться и как это можно поправить?

Подскажите пожалуйста такой вопрос, скачал проект, запустил dep ensure -v, оно создало vendor папку и включило мой проект туда. Почему это могло случиться и как это можно поправить?

Урл проекта в зависимостях отличается от фактического где он лежит в gopath

Всем доброго времени суток! Есть апи связанное с sqlitе. Для тестирования хендлеров, которые получают данные из бд или помещают их туда, нужно как то сфабриковать саму бд. То есть чтобы на уровне тестирования было понятно, что есть в бд и что в ней происходит. Данные у меня очень объемные и как-то нахожусь в растерянности, как тестировать это все. Поначалу думал, что можно создать так называемую test_db, закинуть туда руками данные и дальше с этим работать. Нет ли более оптимального метода для данной ситуации? Или все действительно так, ручками?

Погугли такие слова: IoC, DI и Mocks

this won't compile because Go 1 doesn't currently support immutable types which are proposed here: https://github.com/romshark/Go-2-Proposal---Immutability#2101-simple-casting

Какой красавчик! Спасибо большое за документ!

Погугли такие слова: IoC, DI и Mocks

За такие слова в аду уже начали отдельный котёл готовить

За такие слова в аду уже начали отдельный котёл готовить

В практике тестирования нового еще ничего не придумали

Dependency rejection?

Property based testing?

Это все сектанство

ребята, у кого нибудь есть опыт по graphql на go? какие из этих двух либ сейчас наиболее удобные и удачные? https://github.com/graphql-go/graphql или https://github.com/graph-gophers/graphql-go

Тут недавно обсуждалось

Можно поискать

ребята, у кого нибудь есть опыт по graphql на go? какие из этих двух либ сейчас наиболее удобные и удачные? https://github.com/graphql-go/graphql или https://github.com/graph-gophers/graphql-go

вторая

ребята, у кого нибудь есть опыт по graphql на go? какие из этих двух либ сейчас наиболее удобные и удачные? https://github.com/graphql-go/graphql или https://github.com/graph-gophers/graphql-go

Это единственные 2 либы и вторая написана нормально, в отличие от первой

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

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

то есть?

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

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

Вообще я тут слышал, что у кого-то есть саксес-стори по внедрению graphql. Как оно?

то есть?

перефразирую. долго время клепая обычные json api на go и попробовав graphql даже с готовой либой, не сразу понимаешь что к чему. местами кажется запутанно, местами кажется что пытались впихнуть что-то динамическое в спокойный и тихий golang, но потом, взглянув на реализацию и на других языках, собственно приходит осознание, что graphql он сам по себе непривычный и местами непростой для легкого внедрения по крайне мере с первого раза.

перефразирую. долго время клепая обычные json api на go и попробовав graphql даже с готовой либой, не сразу понимаешь что к чему. местами кажется запутанно, местами кажется что пытались впихнуть что-то динамическое в спокойный и тихий golang, но потом, взглянув на реализацию и на других языках, собственно приходит осознание, что graphql он сам по себе непривычный и местами непростой для легкого внедрения по крайне мере с первого раза.

а, ну вот. То есть это не проблема go, а особенность grapqhl

в rest api ты делаешь эндпойнты с определенным респонсом, а в graphql делаешь ресолверы для каждого поля

Вообще я тут слышал, что у кого-то есть саксес-стори по внедрению graphql. Как оно?

збс, если нет проблем с нагрузкой

Ребят не холивар ради… JSON, YAML, TOML, упаси госпади INI Что бы вы посоветовали если бы писали приложения которое хранит свою конфигурацию в файлах перечисленных выше, при условии что там постоянно будут вноситься изменения админами? На мой взгляд TOML более прост (для админа) и в нем меньше шансов сделать ошибку

xml

YAML сойдёт

xml

вы серьезно?

вполне

Ребят не холивар ради… JSON, YAML, TOML, упаси госпади INI Что бы вы посоветовали если бы писали приложения которое хранит свою конфигурацию в файлах перечисленных выше, при условии что там постоянно будут вноситься изменения админами? На мой взгляд TOML более прост (для админа) и в нем меньше шансов сделать ошибку

yaml удобнее мне кажется

yaml удобнее мне кажется

С пробелами и табами думаю будут проблемы

ERROR: S client not available

С пробелами и табами думаю будут проблемы

Я думал все современные ide умеют заменять пробелы на табы, да и вообще форматировать код

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

Я думал все современные ide умеют заменять пробелы на табы, да и вообще форматировать код

Ты хорошо думаешь про современных админов

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

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

К томужу на WindowsServer

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

vi config.toml

vi config.toml

на винде

vi config.toml

google://how+to+quit+vi

на винде

start notepad "config.ini"

win + r -> notepad -> открыть файл -> config.txt

пуск -> блокнот -> запустить от имени администратора -> открыть файл -> config.txt

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

Кто сказал "консул"?

Кто сказал "консул"?

консул хорош для конфигов?

Да

Определенного рода конфигов

это хорошая новость, спасибо)

Для одного инстанса в консуле смысла нет

Но раздавать конфиги и их обновления на кластер - самое оно

это хорошая новость, спасибо)

Можно ещё новостей подкинуть. etcd, zookepeer (если не боитесь джявы) тоже неплохи для конфигов

vault?

Для одного инстанса в консуле смысла нет

ну меня интересует именно кластер

Можно ещё новостей подкинуть. etcd, zookepeer (если не боитесь джявы) тоже неплохи для конфигов

но консул лучше

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

так

он простой

даже тривиальный

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

вот с pub-sub на изменения конфига следует разобраться сразу, но там все просто

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