130 метров? что же там такое ?

130 метров? что же там такое ?

"Программист-прагматик"

"Программист-прагматик"

он с квартирой там?

он с квартирой там?

Нет, просто сканы страниц )

он с квартирой там?

бгггг))

Нет, просто сканы страниц )

для таких вещей http://www.djvu.org/ хорошо подходит

для таких вещей http://www.djvu.org/ хорошо подходит

Да, согласен. Но мопед не мой (с)

по чём купил по том продал

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

А можно на примерах? Право я запутался о каком уровне мы говорим (ну тут в чатике говорили)

@rvasily , а насколько сейчас модно следовать Clean Architecture в проектах на Go? Пишу тестовый проект для собеса, хочу выпендриться

@rvasily , а насколько сейчас модно следовать Clean Architecture в проектах на Go? Пишу тестовый проект для собеса, хочу выпендриться

не модно

в смысле без фрейворков?

или я не в теме

не в теме

спс

Всем привет .Кто видел гит проект с микросервиса с мин 2 сервисами на голанг?

@rvasily , а насколько сейчас модно следовать Clean Architecture в проектах на Go? Пишу тестовый проект для собеса, хочу выпендриться

Главное чтобы смузи был (для модности)

@rvasily , а насколько сейчас модно следовать Clean Architecture в проектах на Go? Пишу тестовый проект для собеса, хочу выпендриться

минусом не будет, по крайней мере код будет тестируемый

@rvasily , а насколько сейчас модно следовать Clean Architecture в проектах на Go? Пишу тестовый проект для собеса, хочу выпендриться

пишите так, словно ваш код будет ревьювить склонный к насилию психопат, который знает где вы живёте

а мне заходит CA..

пишите так, словно ваш код будет ревьювить склонный к насилию психопат, который знает где вы живёте

Изначально вроде было про поддерживать ?

Не, я про изначальную формулировку этой фразы. Это вроде Макконнелл

Всем привет, интересует такой овпрос, в 2 словах, как лучше организовать роли пользователя в api, например есть база данных и в ней каждый пользователь после аутонтефикации может получать доступ только к своим данным, как это рализуется вообще интересует(какие то отдельные поля в таблице, отдельная таблица или еще что). Мне нужен именн толчек в правельном направлении, там разберусь

Интересный вопрос, я такой видел несколько лет назад. На Perl в частности Mojolicious предлагалось ограничивать пользователей через роуты. С удовольствием послушаю гоферский вариант.

погодите

в чем вопрос-тио?

authentication - тема большая и сложная

про фреймворки вопрос, помоему ?

про фреймворки нзна ничего

ну приходят люди из джанг/что там у пыхеров, и хотят чтобы было уже что-то

решений много готовых, разной степени готовности

искать по golang auth middleware

authentication - тема большая и сложная

Там не просто аутентификация, тама ещё и раздельный доступ. Что бы не писать везде: if userID == vasya { // позволяем } else { // это не vasya }

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

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

Да, роли. Авторы, модераторы, админ к примеру.

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

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

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

Например вместо этого type User struct{ Id int Name string } Писать так type User struct{ Id *int Name *string }

это еще вариант как при сериализации в json получить null на пустых значениях

память на 1 экземпляре не экономите

Точно, спасибо

Там не просто аутентификация, тама ещё и раздельный доступ. Что бы не писать везде: if userID == vasya { // позволяем } else { // это не vasya }

Можно еще open policy agent глянуть: на каждый чих спрашиваем сервис "этому вот это можно?" по ответу решаем прекращать запрос или дальше обслуживать

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

На GC нагрузки больше

На GC нагрузки больше

указатели обычно же на хипе аллоцируются ?

Вот именно, а значит их GC собирать придется.

указатели обычно же на хипе аллоцируются ?

google golang escape analysis

google golang escape analysis

Да, спасибо, читал про это )

google golang escape analysis

И? Значение поля структуре гарантированно не попадет в GC, указатель _может_ не попасть в GC

И? Значение поля структуре гарантированно не попадет в GC, указатель _может_ не попасть в GC

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

Вы этот escape analysis видели? Он ш, чахлый, чуть что сразу в хип сует

Так что обычно да, в хипе

Насколько помню не всегда, может и на стеке

Если переменная никуда не передается из функции

Если переменная никуда не передается из функции

Вопрос то про тип поля в создаваемой структуре. Если структуру создаем, то уж почти всегда ее куда то передаем

Вопрос то про тип поля в создаваемой структуре. Если структуру создаем, то уж почти всегда ее куда то передаем

В моём случае да

Вобщем, value types сила, нечего джаву тут разводить и по указателю на значение держать :)

Например вместо этого type User struct{ Id int Name string } Писать так type User struct{ Id *int Name *string }

вот конкретно так как у вас написано никогда не надо делать. Id должен быть всегда интом потому, что это значение, а не объект. Если не знаете разницу, рекомкндую загуглить.

вот конкретно так как у вас написано никогда не надо делать. Id должен быть всегда интом потому, что это значение, а не объект. Если не знаете разницу, рекомкндую загуглить.

Разницу между значением и указателем я понимаю. Вероятность схватить nil при сериализации подсказали, в чем проблема еще ?

Разницу между значением и указателем я понимаю. Вероятность схватить nil при сериализации подсказали, в чем проблема еще ?

между значением и объектом. указатель как правило предназначен для объектов в ООПшном смысле проблемы две, и они оч досадные 1) доп. бойлерплейт на копирование 2) перед дереференсом при использовании надо тестить на nil. В данном конкретном случае, который вы привели, никаких бонусов нет, по этому оно не нужно

между значением и объектом. указатель как правило предназначен для объектов в ООПшном смысле проблемы две, и они оч досадные 1) доп. бойлерплейт на копирование 2) перед дереференсом при использовании надо тестить на nil. В данном конкретном случае, который вы привели, никаких бонусов нет, по этому оно не нужно

Иногда полезно иметь состояние "не указано", указатель может удобнее, чем отдельный флаг для такого

Иногда полезно иметь состояние "не указано", указатель может удобнее, чем отдельный флаг для такого

для этого удобнее типы на подобие sql.NullString, sql.NullInt64 и тэ пэ

ERROR: S client not available

но опять таки - это всё относится к значениям и не относится объектам Для объектов - указатели

Нормально ли использовать такую конструкцию для десереализации ? или есть варианты изящнее ? var curRequest struct{ Query string `json:"query"` } На каждый запрос предопределенными структурами не напасешься , а map[string]interface{} с рефлектом то еще удовольствие

какую задачу решаете?

Нормально ли использовать такую конструкцию для десереализации ? или есть варианты изящнее ? var curRequest struct{ Query string `json:"query"` } На каждый запрос предопределенными структурами не напасешься , а map[string]interface{} с рефлектом то еще удовольствие

Я делаю структуры на каждый запрос

Это громоздко, зато надёжно

какую задачу решаете?

Принимаю запрос с фронтенда, десереализую и бывают кастомные поля, в структуру модели эти кастомные поля тащить не хочеться. PS это не вы делали доклад на хайлоаде PostgreSQL vs MySQL ? )

Я делаю структуры на каждый запрос

Разница получается только в том, что я объявляю структуру не через type , и в локальном скоупе функции

Принимаю запрос с фронтенда, десереализую и бывают кастомные поля, в структуру модели эти кастомные поля тащить не хочеться. PS это не вы делали доклад на хайлоаде PostgreSQL vs MySQL ? )

Кастомные поля можно сделать опциональными с помощью указателей

Кастомные поля можно сделать опциональными с помощью указателей

Т.е. если значения нет, то nil не будет занимать памяти в отличии от default value?

Нормально ли использовать такую конструкцию для десереализации ? или есть варианты изящнее ? var curRequest struct{ Query string `json:"query"` } На каждый запрос предопределенными структурами не напасешься , а map[string]interface{} с рефлектом то еще удовольствие

что смущает?

что смущает?

После скриптовых языков такие кульбиты )

Разница получается только в том, что я объявляю структуру не через type , и в локальном скоупе функции

можно объявить type в скоупе функции

Т.е. если значения нет, то nil не будет занимать памяти в отличии от default value?

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

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

Хочется узнать best practice , чтобы потом не переделывать в случае чего

Хочется узнать best practice , чтобы потом не переделывать в случае чего

Лучше всего — запилить модели на все случаи, и использовать указатели только для опциональных полей

Коллеги, подскажите, пожалуйста. Как в Golang сделать map с глобальной областью видимости (за пределами функции main)? Насколько я понял, ее (map)нельзя объявить без инициализации. А инициализировать вне функции нельзя.

Или как вернуть map из функции?

Коллеги, подскажите, пожалуйста. Как в Golang сделать map с глобальной областью видимости (за пределами функции main)? Насколько я понял, ее (map)нельзя объявить без инициализации. А инициализировать вне функции нельзя.

https://tour.golang.org/moretypes/19

https://tour.golang.org/moretypes/19

Спасибо, догадывался что уже туго соображаю)

Принимаю запрос с фронтенда, десереализую и бывают кастомные поля, в структуру модели эти кастомные поля тащить не хочеться. PS это не вы делали доклад на хайлоаде PostgreSQL vs MySQL ? )

мы с чистяковым, да

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

Как раз хочу

господа, два вопроса: есть ли какая-то вероятность, что тикер перестанет тикать, или начнет это делать слишком часто/слишком редко? и второй вопрос: если тикер тикает, а приложение где-то запаниковало и сделало recover, тикер сохраняет временной интервал, когда была паника? не начнет ли он заново отсчет?

Коллеги, подскажите, пожалуйста. Как в Golang сделать map с глобальной областью видимости (за пределами функции main)? Насколько я понял, ее (map)нельзя объявить без инициализации. А инициализировать вне функции нельзя.

Можно и за пределами функции: var m = map[string]interface{}{}

господа, два вопроса: есть ли какая-то вероятность, что тикер перестанет тикать, или начнет это делать слишком часто/слишком редко? и второй вопрос: если тикер тикает, а приложение где-то запаниковало и сделало recover, тикер сохраняет временной интервал, когда была паника? не начнет ли он заново отсчет?

Если не создавался новый то все остаётся как прежде

Если не создавался новый то все остаётся как прежде

благодарю

господа, два вопроса: есть ли какая-то вероятность, что тикер перестанет тикать, или начнет это делать слишком часто/слишком редко? и второй вопрос: если тикер тикает, а приложение где-то запаниковало и сделало recover, тикер сохраняет временной интервал, когда была паника? не начнет ли он заново отсчет?

В теории ограничений нет. Можно тикать хоть каждую наносекнду. На практике зависить от железа. Если не будет успевать, то будет гонка. Если паника отловлена, и она случилась не в горутине тикера, то на тикер никак не повлияет.

Мне нужно делать одну и ту же задачу как по крону каждый час.

Но стабильно и регулярно.

Вот думаю, тикер присобачить, или цикл и time.Sleep.

Вот думаю, тикер присобачить, или цикл и time.Sleep.

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

Все в одной горутине планировал сделать, просто for { ... time.Sleep(time.Minute * 60)}