Телеграмм чат группы gogolang страница 20847

Size: a a a

Go-go!

2020 July 23

https://github.com/prometheus/client_golang/blob/master/examples/random/main.go
https://prometheus.io/docs/guides/go-application/

Спасибо

источник

16:54пожаловаться #1

ziggy lucid in Go-go!

подскажите, может встречал кто подобное
нужен гошный email-сервер только на прием почты и с возможностью доступа к полученным письмам
понятно, что можно через внешние протоколы работать, но с pop3 неудобно - хоть и просто, но фильтрации нет, а с imap - там сам черт ногу сломит, нет желания лезть в дебри ради простой задачи получения писем

источник

17:07пожаловаться #2

АУ

Артем Уткин... in Go-go!

Прошу прощения за нубский вопрос
Не могу никак понять, как перевести в апперкейс кириллицу?

Проверяю на букве "ё", обычный strings.ToUpper() ее просто выкидывает
Функция strings.ToUpperSpecial() как будто не воспринимает кириллицу в принципе
Или придется просто по массиву рун итерировать?

источник

17:09пожаловаться #3

Sergey in Go-go!

Артем Уткин

Ты чё-то не то делаешь, всё работает https://play.golang.org/p/WF5nxwdS3uZ

источник

17:14пожаловаться #4

АУ

Артем Уткин... in Go-go!

Земля мне пухом, я просто в регулярке до этого ё обрезал

источник

17:14пожаловаться #5

Evgeny Glyshko in Go-go!

ziggy lucid

https://github.com/davecgh/go-spew

Спасибо большое, это сработало)

источник

17:58пожаловаться #6

@mr_tron in Go-go!

Daniel Podolsky

да у меня тоже есть кеши 🙂

но я использую LRU

а чё? lru cache не надо инвалидировать?

источник

18:00пожаловаться #7

ВС

Владимир Столяров... in Go-go!

за lru не скажу, а вот ttl инвалидируется сам, но не сразу

источник

18:01пожаловаться #8

@mr_tron in Go-go!

угу. и то это проблема. а вот в lru какая-нибудь популярная запись может болтаться вечно

источник

18:01пожаловаться #9

Daniel Podolsky in Go-go!

@mr_tron

а чё? lru cache не надо инвалидировать?

дело не в lru, а в данных, которые туда попадают. их инвалидировать не надо

источник

18:02пожаловаться #10

@mr_tron in Go-go!

а. ну так бы и сказал что "у меня кэши которые нет необходимости инвалидировать"

источник

18:02пожаловаться #11

Sergey in Go-go!

@mr_tron

а. ну так бы и сказал что "у меня кэши которые нет необходимости инвалидировать"

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

источник

18:37пожаловаться #12

@mr_tron in Go-go!

мммм. и как вы предлагаете гарантировать, что после записи в базу произойдёт запись в кэш?

источник

18:41пожаловаться #13

Sergey in Go-go!

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

источник

18:47пожаловаться #14

pragus in Go-go!

сам придумал? как раз в го не самая лушая реализация мапы для кэша, от банального не thread safety, до нагрузки на GC
и когда у нас есть десяток решений со своими нюансами типа https://github.com/allegro/bigcache
может быть не такой уж и моветон заюзать уже масштабируемое решение redis?) особенно если инстансов больше одного

> от банального не thread safety

вот отсутствие thread safety - это как раз самый большой плюс.

источник

18:54пожаловаться #15

Je in Go-go!

большой плюс?)

источник

18:55пожаловаться #16

pragus in Go-go!

Мимо Проходящий

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

у вас просто маленькая мапа :)

источник

18:55пожаловаться #17

pragus in Go-go!

большой плюс?)

да. клиентский код лучше знает в какие моменты надо синхронизировать доступ.

источник

18:56пожаловаться #18

Je in Go-go!

и хорошо, если он это делает) что-то почти все реализации cache в памяти так или иначе thread safe делают, не полагаясь на клиентский код

источник

18:56пожаловаться #19

Je in Go-go!

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

источник

18:58пожаловаться #20