но я вот успешно пишу rpc на swagger, и не жужжу, хоть это и разрушает идеологию и концепцию

а, мы про теорию реста, а не про то, что все под ним понимают ?

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

но я вот успешно пишу rpc на swagger, и не жужжу, хоть это и разрушает идеологию и концепцию

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

читаешь и ощущаешь себя каким-то идиотом) первый раз слышу про swagger почитал, вроде интересно, но до этого ни разу не встречал((

но я вот успешно пишу rpc на swagger, и не жужжу, хоть это и разрушает идеологию и концепцию

справедливости ради, не смог добиться в swagger вывода массива из разных типов элементов, которые шли как зависимости к основному ответу (поэтому они и разного типа в массиве) по спеке jsonapi.org

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

1. нет поддержки спецификации версии 3. только 2, с некоторыми расширениями, которые были нужны автору 2. сообщения об ошибках маловнятные. ошибка синтаксиса в ямле может приводить к "я не шмог" без подробностей. дебажить приходится комментированием кусков. 3. код, который он генерит, далеко не оптимальный. 4. довольно запутанная система подключения хендлеров. 5. из хендлера можно вернуть не то. что описано, а все, что соответствует интерфейсу. приходится следить за собой и коллегами.

Потребность: прекрасный программист Golang. Проект: кроссплатформенный сервис стилизации изображений на нейросетях. Вилка: 180-250к для сеньора и 120-180к middle разработчикам. Условия: офис в Петербурге, гибкий график, оф.оформление.

@NastyaPreobrazh тут рядом группа для этого есть: https://t.me/golangjob

@NastyaPreobrazh тут рядом группа для этого есть: https://t.me/golangjob

Угу, знаю и надеюсь, эти 4 предложения тут не взбудоражат никого в минус, а может и сведут с тем, с кем по пути. Спасибо)

Настя, 4 предложения от каждого рекрутера и весь чат уже в "работе" :)

я понимаю все, но тут не формат

не, я про то, что и там и там примерно народ один и тот же сидит, а здесь ваше сообщение быстро затеряется

no offence intended, как грица

справедливости ради, не смог добиться в swagger вывода массива из разных типов элементов, которые шли как зависимости к основному ответу (поэтому они и разного типа в массиве) по спеке jsonapi.org

ну - да. когда api свой сочиняешь этоу херни можно избежать

Потребность: прекрасный программист Golang. Проект: кроссплатформенный сервис стилизации изображений на нейросетях. Вилка: 180-250к для сеньора и 120-180к middle разработчикам. Условия: офис в Петербурге, гибкий график, оф.оформление.

Клон призмы? Клиент (читай оффлайн) или сервер?

(disclaimer я сейчас не как отклик к вакансии, а обсудить идею - весёлая она)

обсудите с Анастасией в личке, а? там хорошая идея, но требующая проверки

Когда тебя попросили написать самую простую сортировку)

https://play.golang.org/p/BOpr1w8Gwqh

Когда тебя попросили написать самую простую сортировку)

process took too long

100 000 000 итераций) Лучше на компе запустить)

Это по этой теме - https://ru.wikipedia.org/wiki/Bogosort

20 элементов, 160 лет.

Компухтер железный он справится

Да, сортировка для тех, кто никуда не спешит)

Божественно.

почему бы не заюзать graphql вместо всего этого?

почему бы не заюзать graphql вместо всего этого?

Эти очереди типа реббита?

Эти очереди типа реббита?

Не. Это глупая хрень вроде апи

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

Зато позволяет жить с гулпыми проблемами по созданию этого апи

Графql не панацея, у неё своих проблем хватает на самом деле

Даже на самом сайте написано, что пока он развивается и не закончен

Не. Это глупая хрень вроде апи

Вот из-за таких как ты индустрия теряет сотни тысяч долларов на обслуживание архитектурных костылей. С т.з. "я сделал АПИ и мне срать кто и как им будет пользовать, пусть хоть сдохнут" - это да, глупая хрень. Если взять хоть раз в жизни и сделать самому нетривиальный фулстек микросервисный, то окажется что не такая уж она глупая хрень

Вот из-за таких как ты индустрия теряет сотни тысяч долларов на обслуживание архитектурных костылей. С т.з. "я сделал АПИ и мне срать кто и как им будет пользовать, пусть хоть сдохнут" - это да, глупая хрень. Если взять хоть раз в жизни и сделать самому нетривиальный фулстек микросервисный, то окажется что не такая уж она глупая хрень

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

Или топите за новые технологии просто так?

Я где-то год назад на Node.js + React с graphql работал. Вначале нравилось, а потом все ж разленился и опять скатился в рест.

вот только с нодой оно более или менее и дружит кое как

В графкюэль радовало то, что не надо было писать документацию к АПИ. Но дополнительные танцы на стороне бекэнда все ж присутствовали, но не очень страшные. Еще у этой технологии мне не нравилось то, что в мире реакта самым популярным решением был Apollo. А он добавлял много черной магии. И как всегда с магией, в случае нестандартных вещей, только проблемы появлялись. Т.е. по факту это технология, без которой точно можно жить :)

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

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

Ну сами клиенты об оффлайне тебе точно не расскажут

особенно если у них оффлайн внезапно начался

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

А зачем вытаскивать все? Почему в БД запросом не выбирать только то что нужно?

А зачем вытаскивать все? Почему в БД запросом не выбирать только то что нужно?

Ну так и сделаю да

Просто на эти операции много ресурсов

Запустить поток чтобы проверял у всех время последнего обращения и вешал оффлайны?

А тебе нужна в реальном времени информация?

А тебе нужна в реальном времени информация?

Ну можно и без

Типа будет собирать инфу при отрисовке html

Ну тогда поток ведь и не нужен. СОотстветсвеннои нагрузка будет не существенная же

Или сколько у тебя пользователей?

Или сколько у тебя пользователей?

Пока нисколько Но хочу сделать чтобы выдерживала большой объем

1) Это тогда преждевременная оптимизация. Оптимизировать можно бесконечно 2) Ну давай подумаем что ты подразумеваешь под большим объемом? Допустим 100 000 пользователей и эту страницу с онлайном будут вызывать ну допустим 1000 раз в минуту. Это не сильно большой объем. Обычный SQL запрос котоырй сам посчитает все если правилньо оптимизировать его он не нагрузит очень сильно

1) Это тогда преждевременная оптимизация. Оптимизировать можно бесконечно 2) Ну давай подумаем что ты подразумеваешь под большим объемом? Допустим 100 000 пользователей и эту страницу с онлайном будут вызывать ну допустим 1000 раз в минуту. Это не сильно большой объем. Обычный SQL запрос котоырй сам посчитает все если правилньо оптимизировать его он не нагрузит очень сильно

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

Да. Для начала создай готовый продукт. Ведь возможно это не будет узким местом твоей программы и по сути оно тебе и не нужно будет. А времнеи ты потратишь много

На счёт sql запроса Простой where status=online не катит?

ERROR: S client not available

Тебе даже проще можно делать

Можно так. А можно просто разницу во времени последнего запроса пользователя допустим смотреть. И если разница между текущим времени и последним больше N то он оффлайн и индекс не забывай

Можно так. А можно просто разницу во времени последнего запроса пользователя допустим смотреть. И если разница между текущим времени и последним больше N то он оффлайн и индекс не забывай

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

Вполне себе нормальное решение. Если станет узким местом тогда и сомтри как это дело оптимизировать

Окей, спс

Ну если есть возможность, можно просто процедуру написать, которая будет булевое значение проставлять и все, на самом деле можно много чего придумать, лучше конечно уже по обстоятельствам ориентироваться

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

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

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

Хм... и как приложение зарепортит, если у него сеть отвалилиась?

действительно - как же оно это сделает....

как у time.Time время поменять?

чтобы было time.Now() - 15 минут

add(duration) есть

а как отнять?

а как отнять?

да просто с минусом используй add(-duration)

да просто с минусом используй add(-duration)

лол

https://golang.org/pkg/time/#Time.Sub

https://golang.org/pkg/time/#Time.Sub

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

Действительно. ЧТо-то я немного не так понял вопроса :)

зато там написанно как юзать Add() To compute t-d for a duration d, use t.Add(-d)

один с указателями другой без

оба выводят одно и тоже

один с указателями другой без

этим и отличаются

этим и отличаются

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

Опять оптимизируешь?)

Разница в типах

там ты хранишь указатель а там структуру

логично?

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

А ты попробуй заменить например при присвоении эмаунт с константы на рандом например и увидишь разницу