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

исправим позже, если вдруг идея появится. а не появится - ну ок, в одном месте будет snake_case

ребятки, а как вы именуете переменные, которые нужно конвертнуть в другой тип? Допустим, мне приходит в URL запросе ID - это строка. А мне нужно число. Я делаю переменную idStr, и потом уже из неё получаю число, которое назову id.

42

Вечный вопрос о именовании переменных в программировании

Это не сильно важно. Важно чтобы оно было читаемо. Ну назови ParamID или как-то так. чтобы было понятно происхождение

и все

ясно, я думал может есть какая-то рекомендация на такой кейс. спасибо.

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

ребятки, а как вы именуете переменные, которые нужно конвертнуть в другой тип? Допустим, мне приходит в URL запросе ID - это строка. А мне нужно число. Я делаю переменную idStr, и потом уже из неё получаю число, которое назову id.

rawId, dirtyId

rawId, dirtyId

аналогично

Это не сильно важно. Важно чтобы оно было читаемо. Ну назови ParamID или как-то так. чтобы было понятно происхождение

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

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

вы такой капризный, надоело читать — не читайте.

чат про go, обсуждают naming conventions в go, т.ч. все по теме.

это не очень гошный нейминг конвеншн, а вообще общепрограммистский

про такое обычно пишут во всяких хороших общепрограммистских книгах 🙂

И пишут там «следует называть переменные хорошо»

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

дада, теберь ты будешь долго и нудно рассказывать как это важно и нужно обсуждать как назвать переменную. нет никоакой специфич. naming conventions в go, чушь это. есть несколько простых правил, этого всем нормльным людям достаточно, а прокрастинирующим нодо ещё что-то как обычно

ребятки, а как вы именуете переменные, которые нужно конвертнуть в другой тип? Допустим, мне приходит в URL запросе ID - это строка. А мне нужно число. Я делаю переменную idStr, и потом уже из неё получаю число, которое назову id.

не вижу проблемы. Главное потом понять что там.

@onokonem А можно подробное, что бы вы использовали для написания этого классического форума? Пусть это будет PostgreSQL, три таблицы: пользователи, посты и комменты. Из дополнительных требований: - должны писаться логи в файлы, т.е. если какая-то была ошибка, она должна быть записана в файл - должна сессия пользователя сохраняться при перезапуске приложения. Например я у себя в ноде для этого использую редис, а что использовали бы вы? - после перезапуска браузера пользователь должен остаться залогиненым, т.е. храним что-то в куке Использовали ли вы что-то кроме стандартной библиотеки?

Ну iris (щитай замена экспресса). Сессии в redis. Если сессий много (сотни тысяч, миллионы) - то JWT Генерировать шаблоны любым шаблонизиатором (но я бы сделал go+react - можно стильно быстро молодёжно, быстрый форум наше всё). Стандартная библиотека - не решение всех проблем. Если она существует - не означает, что запрещается использовать чтото ещё. Алсо, начинать архитектуру надо не постов и комментов, а с ACL и уведомлений, это самая нагрузосоздающая часть - глядишь, и база поменялась, и от постгре отошли. Следующий момент - спамеры. Если думаете, что от спамеров можно отмахнуться, то нет, проект может умереть. Вот пример форума на Go - https://github.com/kjk/fofou - автор сдался перед спамерами. Вот пример второго форума: https://github.com/go-tango/wego НИчем подход от ноды не отличается ни-чем. К ноде гораздо ближе чем к PHP.

И очень важный момент - на go можно писать форум, но сложно движок форума

скажите пока-пока плагинам, как в phpbb, wordpress и так далее - go это компилятор

.so есть, но для линукса

Идеально - познать счастье в связке REST+React

и REST делать на swagger

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

только оно ни хера не rest будет

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

rest - это утопия

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

rest - это утопия

rest - это для crud

если у нас не crud - у нас не будет rest, а будет rpc

но ведь и с помощью rpc можно сделать crud

но я вот успешно пишу 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 лет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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