логика то в основном на ней

она конечно обернута в обертку, но по факту

rows, err := removeDbConnect.GetAnyRows() if len(rows) == 0 { removeDbConnect.AnyAction() }

если юнит-тест нельзя написать - его не надо писать

дест с реальной базой - это интеграциолнный, не юнит

ну можно замокать всю обертку

только что это даст не понятно ?

если это можно сделать - это нужно сделать

а простите что я проверю? как IF корректно работают?

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

важно, чтобы код мока не был сложнее кода запроса

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

много-мало это оценочно

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

просто три-пять IF

которые на любой чих пых валят фатал/панику

*инфраструктуры ?

я не уверен, что правильно валить фатал и панику внутри функций, которые не main()

кто сказал что это не внутри main? ?

main() можно не тестировать:)

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

"добавить зебр" "выпустить львов" ?

IF !все зебры сожраны { log.Fatal("Ой что-то не так") }

в го нет наследования

а вот и есть

а вот и есть

есть встраивание

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

я, правда, не понял, какое отношение этот пул имеет к каналам

очень прямое. Если в синк-пул класть данные, которые используются, то будут непредсказуемые последствия. Что я и наблюдаю.

погоди

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

Смотрите. У меня файлики заливаются через rsync. Потом я откидываю в сторону в архив и обрабатываю. Что-то я не соображу, как перекинуть файл, когда rsync уже залил его. ну какой-нибудь flock и... и что?

а рсинк же льет во временный, а потом переименовывает

как файл появился - так он и готов

А ой

Я делаю совершенно линейные задачи в go, потому что компиляция, сериализация и удобные либы для xml/json

Главное, временный файл не подхватить:)

Я делаю совершенно линейные задачи в go, потому что компиляция, сериализация и удобные либы для xml/json

напиши перед линейной задачей go и делай нелинейные! потом запускай с -race и правь рейс кондишены! без регистрации и смс

возвращать unexported типы из exported функции норм вообще?

Да

подскажите нормально ли юзать go build -ldflags "-s -w" main.go для уменьшения бинарника и после сжать upx ?

возвращать unexported типы из exported функции норм вообще?

Возвращай пустой интерфейс с unexported типом, пусть гадают, что там:)

Возвращай пустой интерфейс с unexported типом, пусть гадают, что там:)

зачем?!

я спрашиваю потому-что golint на это ругается: headedServer.go:75:44: exported method SessionRegistry returns unexported type *webwire.sessionRegistry, which can be annoying to use

я это делаю намерено, не должно быть у пользователя библиотеки возможности создать instance типа SessionRegistry, но у того инстанса который я возвращаю пользователю есть exported methods которые могут быть полезны

зачем?!

Чтобы никто не догадался:) А по хорошему лучше интерфейс экспортед возвращать. Наверно.

я конечно могу превратить SessionRegistry в exported, но это как то будет неправильно ибо он по сути пользователю не нужен и зачем засорять API нерелевантными типами

однако проблемно может быть такое: var registry *webwire.SessionRegistry registry = server.SessionRegistry() это нескомпилится, ибо тип не exported

возвращать interface{} не вижу смысла.. ибо для использования нужно его будет превратить в тип *sessionRegistry а он не exported, т.е. exported методами даже не воспользуешься

возвращать interface{} не вижу смысла.. ибо для использования нужно его будет превратить в тип *sessionRegistry а он не exported, т.е. exported методами даже не воспользуешься

Я имел в виду потом уже экспортед интерфейс с экспортед методами)

Я имел в виду потом уже экспортед интерфейс с экспортед методами)

аа, пфф, сори, неправильно понял

хммм

можно и так, да

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

да, верно

так и сделаю, мерси!

TELETYPE в Атоме кто-нить юзал?

Интерфейсы возвращать не по гошному

Конструкторы всегда должны возвращать указатель. Если линтер ругается, то это косяк линтера. Подход с неэкспортируемыми объектами довольно распространенный.

а?!

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

чтобы что?

Потому что Го спроектирован таким

ERROR: S client not available

нельзя ли поподробнее

Интерфейс должен определяться по месту требования,

и?

А не там, где объект создаётся

указатель-то при чем?

А, ну можно и просто объект вернуть, но никак не интерфейс

тем не менее - некторые стандарные либы возвращают именно интерфейсы

Стандартная либа вообще не всегда идеал. Любопытства ради можно пример?

error - это интерфейс :)

в io много что возвращает интерфейсы

Мы же про конструкторы вроде говорили

Наверное имеется в виду interface абстрактный

Потому что если ты передашь структуру как интерфейс то логично что интерфейс и вернется

https://golang.org/pkg/math/rand/#NewSource

много где, я сейчас и не упомню.

никакого табу на возврат интерфейса нет

Табу нет. Но идеоматически интерфейс должен быть на принимающей стороне

А не на создающей

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

так?

Технически очень сильно отличается

и чем же?

если в реализацию не лезть

Интерфейс - это просто контракт, объект может быть любым, если подходит под контракт

Спасибо, кэп

На самом деле - разница есть, и связана она с тем, что в go типизованный nil

На самом деле - разница есть, и связана она с тем, что в go типизованный nil

Обещали исправить в го2

Который выйдет хз когда

можно как-то получить ID выполняющей горутины? (для дебагинга)

ру_девопс ?