А ну и кстати да ^

можно даже не рандом а i подставить из цикла

Короче чтобы не мучать парня. ВОпрос: Ты знаешь разницу между указателем и объектом?

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

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

Я ее в цикл поставил

Я ее в цикл поставил

?

?

var blah Blah объявляется в цикле

Я ее в цикл поставил

не важно

указатель все на ту же переменную

А как тогда это фиксить?

Т.е. ты запихал один и тот же объект кучу раз в массив

make чототам

Чтобы это пофиксить тебе нужно пофиксить базовые свои знания

Т.е. ты запихал один и тот же объект кучу раз в массив

Понятно

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

Го так интересно устроен, что надо мерять. Я взял за правило использовать значения везде, где можно

почитайтур по гу с самого начала и до конца и узнай что такое указатель

Просто даже если мы тебе сейчас это поясним и поффиксим дырка в твоих щзнаниях не восполнится. А эта дырка очень важная

указатель все на ту же переменную

https://play.golang.org/p/9diQJOvdJpU

Просто даже если мы тебе сейчас это поясним и поффиксим дырка в твоих щзнаниях не восполнится. А эта дырка очень важная

Я знаю что такое указатель

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

Потому что хоть так хоть так работает

https://play.golang.org/p/9diQJOvdJpU

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

соответственно другая ситуация

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

неа, если со слов, то примерно такая же https://t.me/gogolang/105404

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

Не экономь на спичках. Ты пытаешься искать оптимизации там где это не нужно. Тут скорость ДАЖЕ если и разная то разница будет слишком маленькая чтобы ее заметить.

Указатели сложнее убирать сборщику мусора

используй то что логичнее. Используй тип который по там нужен там быть

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

1. Делаешь рандомизированные бенчмарки 2. Меряешь 3. Если выгода в контексте всего приложения больше чем 50% — переписываешь код

иначе даже не стоит и чесаться

Чаще всего по таким мелочам не стоит чесаться потому что выгода еще строится из времени написания самих бенчмарков)

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

а кстати нет

перенос var blah Blah в цикл фиксит, все норм в массив добавляется

перенос var blah Blah в цикл фиксит, все норм в массив добавляется

Я это прокоментировал выше

Я это прокоментировал выше

ну ладно

Из определения слайсов в гоу туре можно развеить все непонятки: Slices are like references to arrays A slice does not store any data, it just describes a section of an underlying array. https://tour.golang.org/moretypes/8 Cлайс сам по себе хранит ссылки на области памяти, где лежат значения. Если сделать []*Obj то тогда получается поинтер на поинтер, на практики буквально никогда не нужно юзать []*Obj и всегда можно удалить указатель из объявления и получать тот же самый результат

Из определения слайсов в гоу туре можно развеить все непонятки: Slices are like references to arrays A slice does not store any data, it just describes a section of an underlying array. https://tour.golang.org/moretypes/8 Cлайс сам по себе хранит ссылки на области памяти, где лежат значения. Если сделать []*Obj то тогда получается поинтер на поинтер, на практики буквально никогда не нужно юзать []*Obj и всегда можно удалить указатель из объявления и получать тот же самый результат

Иногда нужно хранить *Obj, если объекты выделяет другая часть проекта и она же иногда меняет данные в этом объекте

Вопрос 1 Север общается с клиентом. Как лучше присваивать статус оффлайн? Типа если клиент не обращается к северу N времени то сервер пишет в бд статус оффлайн. Или чтобы клиент сам информировал сервер об уходе в оффлайн? Вопрос 2 Нужно вывести статистику кто онлайн кто нет Надо вытаскивать из бд все структуры клиентов и циклом проходить? Это же дофига ресурсов займет если бд большая

А нельзя такое на вебсокетах делать? Типо отвалился клиент- оффлайн

А нельзя такое на вебсокетах делать? Типо отвалился клиент- оффлайн

Можно

Вопрос 1 Север общается с клиентом. Как лучше присваивать статус оффлайн? Типа если клиент не обращается к северу N времени то сервер пишет в бд статус оффлайн. Или чтобы клиент сам информировал сервер об уходе в оффлайн? Вопрос 2 Нужно вывести статистику кто онлайн кто нет Надо вытаскивать из бд все структуры клиентов и циклом проходить? Это же дофига ресурсов займет если бд большая

1. зависит от протокола. Гугли в сторону live ping и heartbeat 2. SQL может собирать простенькие статистики, типа посчитать количество офлайн пользователей

1. зависит от протокола. Гугли в сторону live ping и heartbeat 2. SQL может собирать простенькие статистики, типа посчитать количество офлайн пользователей

Я уже все сделал)

"SELECT * FROM Clients WHERE LastConnectionTime >= $1", GetCurrentTime().Add(-(time.Minute * 15))

Это норм? Не зашкварно?))

загквар :)

а если на mysql время не совпадает с приложением?

(или какой у вас сервер)

сделайте целиком на sql

там тоже есть функции работы с датой

а если на mysql время не совпадает с приложением?

Это sqlite

ERROR: S client not available

Бд просто рядом с бинарником пока

а если на mysql время не совпадает с приложением?

И как его синхронизировать? Юзать timestamp?

Митап в Москве вечером 14-ого мая: https://golang-moscow.timepad.ru/event/720881/

Сильное заявление, предоставлять аргументы я конечно же не буду. Вы пробовали писать бек этого незаконченного и сырого graphql?

Никаких там особо сложностей с реализацие под Го нет. Ну и да, хипсторам нравится, проще с ними договориться на чекпойнтах. GQL (на чтение, с мутациями сложнее) - писечка. Все сущности лежат по кучкам - контроллер+VM, и друг про друга не знают. А сбоку прикручен суперклей, позволяющий достать ровно то, что надо, в один запрос к серверу, да еще и к БД запросы сбатчить. Без GQL - либо делаем под каждый скрин по API-шке и VM-ке чтобы за раз все нужное достать - это боль и копипаста. Либо включаем режим "мне вообще похую на перформанс, плюс я ненавижу фронтендеров", и делаем канонический REST. Правда, я не видел нигде UI, сделанный поверх канонического REST API - видимо это физически невозможно, т.к. слабоумных фанатиков REST предостаточно.

Никаких там особо сложностей с реализацие под Го нет. Ну и да, хипсторам нравится, проще с ними договориться на чекпойнтах. GQL (на чтение, с мутациями сложнее) - писечка. Все сущности лежат по кучкам - контроллер+VM, и друг про друга не знают. А сбоку прикручен суперклей, позволяющий достать ровно то, что надо, в один запрос к серверу, да еще и к БД запросы сбатчить. Без GQL - либо делаем под каждый скрин по API-шке и VM-ке чтобы за раз все нужное достать - это боль и копипаста. Либо включаем режим "мне вообще похую на перформанс, плюс я ненавижу фронтендеров", и делаем канонический REST. Правда, я не видел нигде UI, сделанный поверх канонического REST API - видимо это физически невозможно, т.к. слабоумных фанатиков REST предостаточно.

графкуэль + applo на фронте = ваще агонь

> Правда, я не видел нигде UI, сделанный поверх канонического REST API - видимо это физически невозможно Одно "сильное заявление" поверх другого

ну, не видел — твоя проблема :)

Как это лучше делать? :/

Я сталкивался с похожим. В redis есть фича при создании записи указывать ttl. Они автоматом экспарятся. При новом запросе на сервер просто заново создавал запись с id в ключе. И когда надо было собрать живых — просто выбирал всё записи.

Но это если есть возможность юзать redis.

Но это если есть возможность юзать redis.

В монге тоже такая возможность есть

> Правда, я не видел нигде UI, сделанный поверх канонического REST API - видимо это физически невозможно Одно "сильное заявление" поверх другого

одно слабое заявление поверх другого

Вопрос 1 Север общается с клиентом. Как лучше присваивать статус оффлайн? Типа если клиент не обращается к северу N времени то сервер пишет в бд статус оффлайн. Или чтобы клиент сам информировал сервер об уходе в оффлайн? Вопрос 2 Нужно вывести статистику кто онлайн кто нет Надо вытаскивать из бд все структуры клиентов и циклом проходить? Это же дофига ресурсов займет если бд большая

IMHO 1) наверное имеет смысл делать и так, и так: пользователь может просто закрыть выкладку и т.д.; а может ещё разлогиниться (если только 1 сессия) 2) у редиса вроде есть ttl callback или какая то нотификация (это сказал быстрый гуглеж) или можно попробовать использовать heap, и сортировать по последнему времени активности + 15 мин. например ; и т.д. + завести счётчик количества онлайн пользователей

Вопрос 1 Север общается с клиентом. Как лучше присваивать статус оффлайн? Типа если клиент не обращается к северу N времени то сервер пишет в бд статус оффлайн. Или чтобы клиент сам информировал сервер об уходе в оффлайн? Вопрос 2 Нужно вывести статистику кто онлайн кто нет Надо вытаскивать из бд все структуры клиентов и циклом проходить? Это же дофига ресурсов займет если бд большая

стандартно - вебсокет, пинг-понг для проверки коннекта

Так на серваке можно отловить когда клиент подключился и когда отключился, с тем же сокет ио

товарищи. как в монгоколлекцию запихнуть массив структур?

товарищи. как в монгоколлекцию запихнуть массив структур?

если каждая структура - отдельный документ, то docs := []SomeThing{} collecrtion.Insert(docs...)

если каждая структура - отдельный документ, то docs := []SomeThing{} collecrtion.Insert(docs...)

да, проблема в том, что он в ответ на это говорит cannot use list (type []SomeThing) as type []interface {} in argument to collection.Insert

хм, покажи код как ты вставляешь

Мож адрес передать надо?

Интерфейсы по ссылке передаются

Мож адрес передать надо?

Нет, там жеж написано в ошибке, что он interface хочет, а не мой тип

Под интерфейс все попадает

вот тут похожая фигня https://stackoverflow.com/questions/12990338/cannot-convert-string-to-interface