в общем - да, норм.

идя туда надо серьезно подумать над суммой, индексации у них нет

а где она есть? знаю одно место только, да и там 5-6%

Привет, кто работал с go + golang.org/x/crypto/ssh? Я хочу сделать sudo su - и выполнить несколько команд после этого в рутовом окружении. Но не знаю как это сделать

Всем привет, я тут в субботу спрашивал почему вставка в базу тормозит - никто не посмотрел случайно ?

я обещал, но не сделал

посмотрю вечером

Если кто принимал попытки прошариться в kuberenetes да и просто о нем наслышан, будет интересно попробовать ui с дополнительным функционалом к kubernetes, софтина open source, написана на go) contributing, звезды и issues приветствуются⭐ https://github.com/containerum/containerum

Передавать опции методу запроса типа database.Query(ctx, query) через context.Context рассматривается нормальной практикой?

Мапа ведь по поинтеру передается?)

Мапа ведь по поинтеру передается?)

мапа - это ссылочный тип, как следствие передается ссылка

Передавать опции методу запроса типа database.Query(ctx, query) через context.Context рассматривается нормальной практикой?

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

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

но если опции являются частью запроса, то почему бы нет

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

https://godoc.org/github.com/arangodb/go-driver#WithQueryBatchSize

WithBatchID WithConfigured WithDBServerID WithDetails WithEndpoint WithEnforceReplicationFactor WithFollowLeaderRedirect WithIgnoreRevisions WithImportDetails WithIsRestore WithIsSystem WithJobIDResponse WithKeepNull WithMergeObjects WithQueryBatchSize WithQueryCache WithQueryCount WithQueryFullCount WithQueryMemoryLimit WithQuerySatelliteSyncWait WithQueryStream WithQueryTTL WithRawResponse WithResponse WithReturnNew WithReturnOld WithRevision WithRevisions WithSilent WithWaitForSync

ну если ты её юзаешь, то пожалуйста

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

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

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

https://golang.org/pkg/context/ Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions. как-то так

context'ы это же сплошная динамика, указатель на указатель на указатель...... в то время как структуру можно сделать очень дешёвой с точки зрения потребления ресурсов, например type QueryOptions struct { WithBatchID bool // false by default WithDBServerIDs []string // nil by default WithQueryBatchSize int64 // -1 = unset by default }

и в конце концов это: arango.db.Query(ctx, `query`, nil, arango.QueryOptions { WithBatchID: true, WithQueryBatchSize: 64, }) выглядит гораздо приятнее нежели: ctx = arango.WithBatchID(context.Background(), true) ctx = arango.WithQueryBatchSize(ctx, 64) arango.db.Query(ctx, `query`, nil)

я прав или я прав?

https://golang.org/pkg/context/ Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions. как-то так

ну вот, тем более

короче пойду я issue писать.. который они скорее всего никогда не реализуют, но... надо Федя, надо!

короче пойду я issue писать.. который они скорее всего никогда не реализуют, но... надо Федя, надо!

Шалом! Я смотрю, вы неоднократно контрибутили в гитхаб? Я сам ни разу ничего такого не делал, и мне интересно, с чего лучше/легче начать участвовать в open source сообществе?

Шалом! Я смотрю, вы неоднократно контрибутили в гитхаб? Я сам ни разу ничего такого не делал, и мне интересно, с чего лучше/легче начать участвовать в open source сообществе?

берешь и начинаешь

Шалом! Я смотрю, вы неоднократно контрибутили в гитхаб? Я сам ни разу ничего такого не делал, и мне интересно, с чего лучше/легче начать участвовать в open source сообществе?

open source это про колаборацию команд/людей/компаний с целью решения общих проблем. вы сможете участвовать в open source движении, когда проблемы которые приходится решать вам пересекаются с проблемами других разработчиков. У вас есть эдакие?

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

Шалом! Я смотрю, вы неоднократно контрибутили в гитхаб? Я сам ни разу ничего такого не делал, и мне интересно, с чего лучше/легче начать участвовать в open source сообществе?

выбираешь проект, который нравится тебе (желательно его использовать где-нибудь у себя), выбираешь фичу или проблему (например из issues), делаешь форк, фиксишь/добавляешь, отправляешь PR

общаешься с разработчиком и т.п.

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

Привет, кто работал с go + golang.org/x/crypto/ssh? Я хочу сделать sudo su - и выполнить несколько команд после этого в рутовом окружении. Но не знаю как это сделать

не уверен, что так получится, можно сделать несколько команд просто с sudo, или sudo bash -c 'command1; command2'

не уверен, что так получится, можно сделать несколько команд просто с sudo, или sudo bash -c 'command1; command2'

Они же через &&, разве нет?

&& используется, когда нужно прервать выполнение следующих команд, если текущая не выполнилась. ; соответственно, чтобы все комнады подряд выполнились

&& или в .sh файл инструкции, а потом его выполняй

коллеги, давайте без содомии

&& - это обрабатывается шеллом. надо ли его запускать в этом раскладе?

&& - это обрабатывается шеллом. надо ли его запускать в этом раскладе?

да мы вообще не знаем расклад:)

sudo su -, впрочем, предполагает запуск шелла, потому как su - - это имитация логина рутом.

но нужен ли тут su -?

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

https://golang.org/pkg/context/ Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions. как-то так

хмм, а существуют оффициальные рекомандации по передаче опциональных параметров?

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

да, но не в доках

существует рекоммендация не использовать для передачи параметров контекст

в докладах всяких говорят об этом

вообще где-то видел, что рекомендуют передавать всё явно: есть 10 опциональых параметров - функция принимает 10 аргументов

существует рекоммендация не использовать для передачи параметров контекст

это мы уже поняли, но существуют ли рекомендации как в таком случае лучше передавать опциональные параметры? Т.е. мне нужен ресурс, на который можно сослаться а не выдавать сиё за "своё мнение"

моё мнение на данный момент мало кого интересует, к сожалению)) пока ...ещё..)

вообще где-то видел, что рекомендуют передавать всё явно: есть 10 опциональых параметров - функция принимает 10 аргументов

да, но когда у тебя их 20, то это уже не вариант, да и даже с 10 я бы перевёл параметры второстепенной важности в отдельный struct

да, но когда у тебя их 20, то это уже не вариант, да и даже с 10 я бы перевёл параметры второстепенной важности в отдельный struct

на это есть ответ: если у вас функция делает 20 разных дел, значит это 20 разных функций

это мы уже поняли, но существуют ли рекомендации как в таком случае лучше передавать опциональные параметры? Т.е. мне нужен ресурс, на который можно сослаться а не выдавать сиё за "своё мнение"

понятно. помочь не могу :)

на это есть ответ: если у вас функция делает 20 разных дел, значит это 20 разных функций

не всегда подходит, например в случае database.Query - это мышление не подходит. Оно может делать 1 вущь в 20*20 разных вариантах

понятно. помочь не могу :)

ну ладно, буду сам искать))

не всегда подходит, например в случае database.Query - это мышление не подходит. Оно может делать 1 вущь в 20*20 разных вариантах

вообще-то нет. вообще-то как раз запрос к базе правильно оформлять максимально специфично

to не пишется?

Да

вообще-то нет. вообще-то как раз запрос к базе правильно оформлять максимально специфично

я соглашусь с тем, что некоторые опц. параметры можно было бы убрать и взамен описать функции, типа WithWaitForSync который можно бы было превратить в database.QuerySync() однако тут присутствует куча малых модификаторов типа WithReturnOld, WithQueryCache, WithImportDetails и т.д. для которых делать отдельные функции по моему мнению - непрактично, их легче передать в опциональной структуре передаваемой фунции

еще как практично. 1. сразу видно, что именно запрашивается. легче читать. 2. проще менять логику запроса к базе не затрагивая логику запроса от пользователя. легче писать. 3. сложнее забыть передать что-нибудь важное, что влияет на выборку. легче отлаживаться

еще как практично. 1. сразу видно, что именно запрашивается. легче читать. 2. проще менять логику запроса к базе не затрагивая логику запроса от пользователя. легче писать. 3. сложнее забыть передать что-нибудь важное, что влияет на выборку. легче отлаживаться

непрактичено в том плане, что невозможно комбинировать опции, понимаешь? это как например в данной ситуации: log.New(log.DateTime | log.System | log.User) комбинаций может быть дохера, на все комбинации отдельные функции не напишешь - непрактично

20 опций == 400 комбинаций // true

не все 400 реально нужны

я, короче, разные выборки всегда оборачиваю в разные функции

и всем рекомендую

(и на всех языках так делал)

ну это уже разработчику библиотеки виднее, что реально нужно а что нет, тут сложно что-либо сказать. Но вопрос скорее о том, "как передавать опциональные параметры", а не "когда их лучше избежать"

я, короче, разные выборки всегда оборачиваю в разные функции

ну вот как ты например решишь проблему с конструктором логера где дохера опций?

ну явно-ж не так: log.New(true, false, true, false, false, false, true, false, false, false, true, false, true) да и не так тоже: log.NewWithDateTimeAndUserAndSystemAndLocalTime()

очевидно же что флаги типа: log.New(log.DateTime | log.System | log.User) для данной проблемы передачи опциональных параметров - в самый раз

логгер - не база

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

да и в query мы тоже передаем опции, конечно же. например - userID, etc

но есть граница.

логгер - не база

я не знаю эту базу настолько хорошо, насколько её знают разработчики. Мне сложно сказать, нужны ли здесь реально эти опциональные параметры или нет. Я исхожу из той ситуации, что они (опциональные параметры) есть - но реализованы через жопу вопреки рекомендациям и здравой логике ответственного разработчика. Моя задача написать убедительный issue и предложить вариант(ы) решения ?

бл@ть такое чувство что JavaScript'ер над этой библиотекой работал: // WithQueryCount is used to configure a context that will set the Count of a query request, // If value is not given it defaults to true. func WithQueryCount(parent context.Context, value ...bool) context.Context { v := true if len(value) > 0 { v = value[0] } return context.WithValue(contextOrBackground(parent), keyQueryCount, v) } накой ху@ столько динамики? накой ху@ абъюзать variadic parameters в качестве опциональных параметров?! опциональный параметр в конструкторе опционального параметра Карл! ну ёпамать!!

при этом ещё для каждого опционального параметра, для каждого запроса создавать context.Context, которые все потом мусоросборщику собирать.. блеееаааа

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

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

А юзает кто Goland? Как включить автоформат или лучше импортс кода при сохранении?

вроде в гуглах есть ифна о насторйках, но они куда-то пропали в новой версии похоже

в настройках есть поиск по настройкам

вбей там import

и посмотри

вбил

прости но ты разбил мне сердце

Скажите, а есть какая-то возможность разделить $GOPATH/src и $GOPATH/bin на разные разделы? пишу под виндой и gopath у меня на сетевой шаре, с которой запуск экзешников почему-то запрещён несмотря на все мои танцы с бубном. соответственно всё что собирается в exe - не запускается оно бы и хрен с ним, потому что целевая ось — линух, там всё работает ок. но всякие линтеры и прочее хочется чтобы работало

тут можно тупые вопросы задавать?

а го тур пройден?

а го тур пройден?

я читаю golang-book.ru и не понял код оттуда, может кто сможет пояснить