https://t.me/golangjobfeed

а чат для флуда кажется создавался в другом го-чате

у вас так глупо

жсдебилизм только так и лечится

жсдебилизм только так и лечится

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

у вас так глупо

Лучше конечно не делать go path. Это конечно создатели go ступили

Надо было в кажом проекте делать go_modules размером 1 гигабайт

И гошные бинарники тоже туда заодно

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

Надо было в кажом проекте делать go_modules размером 1 гигабайт

Директорию vendor

Я если что пошутил так

То что у языка все либы в одной папке и выкачивать не надо - офигительный такой ускоритель для старта работы. В том числе благодаря этому (но не только этому) на го можно за 15-30 минут написать работающий проект

ну вариант с vendor (к которому идут) и godep как то лучше чем единый gopath

Я если что пошутил так

Ну я нет, dep так делает

То что у языка все либы в одной папке и выкачивать не надо - офигительный такой ускоритель для старта работы. В том числе благодаря этому (но не только этому) на го можно за 15-30 минут написать работающий проект

> выкачивать не надо Это как?

По-моему это наоборот та ещё помойка. Go dep добро

Это работает если проекты простейшие. Что делать если есть 100 500 зависимостей со 100 500 версиями, и непонятно как сделать так, чтобы ничего внезапно не поломалось и у всей команды работало одинаково без go dep — непонятно

> выкачивать не надо Это как?

Я вот например юзаю bar := pb.StartNew(numElements) ("gopkg.in/cheggaaa/pb.v1"). Поюзал в проекте - хорошо. Делаю второй - просто подключаю gopkg.in/cheggaaa/pb.v1 и всё - можно юзать

никаких тебе npm install

ну это короче не гибко и вендоринг рулит

никаких тебе npm install

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

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

Так же как в go dep

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

Не надо, если используешь yarn. А yarn используют все адекватные JSщики

yarn всё кеширует очень агрессивно. В итоге у меня щас node_modules наполняются сиюминутно, ибо 100 500 пакетов закешировалось

У npm ещё и lock-файлов нет. ??‍♂️

Опять про джс

Можно подчищать: https://github.com/tj/node-prune

Опять про джс

Простите, я остановился

У npm ещё и lock-файлов нет. ??‍♂️

есть же

есть же

Недавно что-ли добавили?

Я на yarn из-за lock файлов и перелез

Недавно что-ли добавили?

в 2013 уже было

Недавно что-ли добавили?

https://habrahabr.ru/post/206678/

раздел Фиксируем версии пакетов

https://habrahabr.ru/post/206678/

Ок, понятно. Но с yarn не слезу. Ладно, давай прекратим оффтоп про ЖС ?

в 2013 уже было

Эх, 2013 был как будто вчера. Вот время летит! ?

Друзья, такая проблема - использую пакет redigo от garyburd. Всё работает исправно, но допустим если приложение простоит час без использования, то запросы к Redis не проходят. Это может быть как-то связано с KeepAlive или Timeout?

Приходится рестартить контейнер

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

IdleTimeout и MaxIdle попробуй

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

А ты точно возвращает коннекты в пул редиго?

А ты точно возвращает коннекты в пул редиго?

Ноуп. Я не использую пул. Я создаю два коннекта к разным индексам дб и их использую.

А, ясно. Мой комментарий относился к пулу

Я так и понял.

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

Проходит ночь и приложение уже не отвечает.

Проходит ночь и приложение уже не отвечает.

шли пинги каждый час

по таймауту какому-нибудь обрубает

idle connections

Я попробовал снизить tcp-keepalive в конфиге редиса с 300 до 10.

redigo же сам отвечает на TCP ACKs?

так соединение реально отсутствует?

пинг нормальный вариант

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

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

Хорошо. Постараюсь сделать вот это.

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

Где приложение запущено?

90% что такие приколы у тебя на хероку

AWS

AWS

А нода какая?

В смысле?

ec2 есть много типов

ещё lambda есть

Я использую EC2, но какая разница какой именно тип сервера.

Я использую EC2, но какая разница какой именно тип сервера.

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

ERROR: S client not available

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

Разве? Почему?

Разве? Почему?

Думаю потому что экономят ресурсы своего кластера

Я не думаю, что aws что-то за тебя решает. Какие конфиги поставишь так и будет работать.

Я не думаю, что aws что-то за тебя решает. Какие конфиги поставишь так и будет работать.

То есть как нет?!

Я не думаю, что aws что-то за тебя решает. Какие конфиги поставишь так и будет работать.

AWS очень много за тебя решает

ты просто не видишь этого

AWS очень много за тебя решает

А можно подробностей? Можно в личку

А можно подробностей? Можно в личку

А можно тут? Просто интересно..

Подскажите, где можно почитать, как запилить, чтобы при компиляции компилятором 1.8 использовался один файл исходного кода, а с компилятором 1.9 - другой файл. Здесь https://golang.org/pkg/go/build расписано про варианты с разными ОС и архитектурами, но не с версиями Go...

https://habrahabr.ru/post/343576/

А можно тут? Просто интересно..

не написал

Подскажите, где можно почитать, как запилить, чтобы при компиляции компилятором 1.8 использовался один файл исходного кода, а с компилятором 1.9 - другой файл. Здесь https://golang.org/pkg/go/build расписано про варианты с разными ОС и архитектурами, но не с версиями Go...

как же не написано?

Подскажите, где можно почитать, как запилить, чтобы при компиляции компилятором 1.8 использовался один файл исходного кода, а с компилятором 1.9 - другой файл. Здесь https://golang.org/pkg/go/build расписано про варианты с разными ОС и архитектурами, но не с версиями Go...

в приведенной ссылке же про это написано: During a particular build, the following words are satisfied: - the target operating system, as spelled by runtime.GOOS - the target architecture, as spelled by runtime.GOARCH - the compiler being used, either "gc" or "gccgo" - "cgo", if ctxt.CgoEnabled is true - "go1.1", from Go version 1.1 onward - "go1.2", from Go version 1.2 onward - "go1.3", from Go version 1.3 onward - "go1.4", from Go version 1.4 onward - "go1.5", from Go version 1.5 onward - "go1.6", from Go version 1.6 onward - "go1.7", from Go version 1.7 onward - "go1.8", from Go version 1.8 onward - "go1.9", from Go version 1.9 onward

в приведенной ссылке же про это написано: During a particular build, the following words are satisfied: - the target operating system, as spelled by runtime.GOOS - the target architecture, as spelled by runtime.GOARCH - the compiler being used, either "gc" or "gccgo" - "cgo", if ctxt.CgoEnabled is true - "go1.1", from Go version 1.1 onward - "go1.2", from Go version 1.2 onward - "go1.3", from Go version 1.3 onward - "go1.4", from Go version 1.4 onward - "go1.5", from Go version 1.5 onward - "go1.6", from Go version 1.6 onward - "go1.7", from Go version 1.7 onward - "go1.8", from Go version 1.8 onward - "go1.9", from Go version 1.9 onward

В одном файле делаю // +build go1.8 Во втором // +build go1.9 В итоге компилятор берёт всё равно оба файла.

Возможно потому, что "onward" - "и выше", из-за чего под условия попадают оба файла...

Возможно потому, что "onward" - "и выше", из-за чего под условия попадают оба файла...

угу. юзай go1.9 и !go1.9

угу. юзай go1.9 и !go1.9

? то, что нужно, спасибо.

Пых 7.2 зарелизился! :))

Пых 7.2 зарелизился! :))

Офтоп! ?

Офтоп! ?

?

Привет парни

Есть под что-то черное проекты? Подскажите?

Не вирусню только, а под веб что нибудь

что есть "черное"?

Трояны? (посмотрите фамилию чувака, кек)

Потренькаться напишу

Хех

Говорю ж не вирусню

Под веб

что есть в вашем понятии "черное под веб"?