Tikhon
Но по большей части я здесь задавал вопросы по поводу архитектуры и структуры приложения, потому что вариантов слишком много, глаза разбегаются
Tikhon
The Go Programming Language
Брайан Керниган
Обязательно почитаю, как со своей программой закончу
Andrey
твой вопрос не просто "гуглится" а это основа всего Айти, и не понимание указателей и ссылок, это считай огромный косяк.
Филипп
Alexey
Понял, значит всегда предпочтительней передавать через указатель
"в принципе встречается микс следующих правил:
- по умолчанию неуказатель
- если мы хотим поменять значение, то указатель
- если структура слишком жирная, то указатель (чтобы не копировать)
- но если мы специально хотим подчеркнуть неизменяемость, то неуказатель (чтобы, наоборот, копировать)
- если мы не хотим особо думать и плодить в нашем коде разыменования *v или операции взятия адреса &v, то аргумент функции соответствует тому, что ожидается на вход (значение/указатель)"
коммунист-революционер
коммунист-революционер
коммунист-революционер
Можно чуть подробнее, либо ссылочку на материалы где об этом можно почитать? Спасибо заранее
Andrey
"в принципе встречается микс следующих правил:
- по умолчанию неуказатель
- если мы хотим поменять значение, то указатель
- если структура слишком жирная, то указатель (чтобы не копировать)
- но если мы специально хотим подчеркнуть неизменяемость, то неуказатель (чтобы, наоборот, копировать)
- если мы не хотим особо думать и плодить в нашем коде разыменования *v или операции взятия адреса &v, то аргумент функции соответствует тому, что ожидается на вход (значение/указатель)"
ага, а теперь самый популярный вопрос из собесов, почему у интерфейсов не пишут указатели, или можно их писать, и почему так ведет себя язык
коммунист-революционер
Принял, спасибо, сейчас почитаю про деревья
коммунист-революционер
м?
Andrey
да не, все хорошо. можешь читать)))
коммунист-революционер
Andrey
ахахах
Andrey
сейчас правильнее же маанг
Null
Maks
Опять будет какая нить не интересная хуйня не применимая на практике в наших случаях)
Grigorij
100%
🇷🇺 Vladimir
Alexander
В Москве? Нелогично же
Ron Mount
Почему нелогично?
Alexander
Питерская же компания
John
Маилрушная же компания, мск
Alexander
Всё равно, неправильно всё это
Tikhon
Вопрос по интерфейсам. Интерфейсы можно объявлять там где они используются или реализуются(первое предпочтительнее). Но насколько плохой практикой будет объявить все интерфейсы программы в каком-нибудь core.go ? Прошу объяснить существенные минусы третьего варианта, если они имеются
Valery
В отдельном пакете приемлемо определять все интерфейсы проекта
Grigorij
зачем их сваливать в одно место
Valery
Хороший вопрос
Valery
Но подход такой есть и он не является бед практис
Null
🦾 Использование каналов в Golang
Читать
@Golang_google
Maks
Бля, как же спасает агрегация когда надо что то реюзать. Гораздо лучше чем наследование
Tikhon
Подскажите пожалуйста, буду очень благодарен. Пытаюсь реализовать чистую архитектуру, на подобии той, что сделана здесь https://github.com/zhashkevych/todo-app/blob/master/server.go , с одной оговоркой - вместо gin использую fiber
Проблема заключается в том, что в приведённом примере gin имплементирует http, а fiber fasthttp не имплементирует, либо я как-то неправильно ищу.
Например, в fiber метод запуска сервера это Listen(), а в fasthttp - ListenAndServe()
Тут уже без обёртки(адаптера) над fiber не обойтись ?
Если я ошибаюсь - скиньте пожалуйста простенький пример, где мы сервер на fasthttp описываем, далее через него пробрасываем fiber, и уже в хендлере с fiber работаем
Уже несколько часов никак не могу с этим разобраться
Ron Mount
Ron Mount
ёбаный бред
Vadim
А как же 2020 и позже? :)
Alexey
а там в базе были разве записи 202% ?
Vadim
В тестовых базах мы же не знаем что лежало
Alexey
ну хоть так (на решение не повлияло бы)
я думаю они там все старые были
Vadim
ну хоть так (на решение не повлияло бы)
я думаю они там все старые были
У меня были такие же запросы только без лайка, 3/4 в обеих задачах
Alexey
🤔
Alexey
Alexey
Alexey
хотя тут ладно, count не по тому полю. хотя это запрос с 3/4
De͢͢͢nιs
🦾 Использование каналов в Golang
Читать
@Golang_google
В то время, как Яндекс.Дзен позволяет вставлять код вот так, некоторые программисты вставляют его в виде картинок. Зачем?!
Denis Pershin
Поэтому и "извините, у нас все упало"
Alexey
всмысле?
Denis Pershin
Так вопросы и ответы может и не озон делал
Khikmat
Всем салют ребят, есть кто скачивал файл через grpc c aws ?
Alexey
недоборе
Alexey
по идее оно туда пролезть не должно. тип то дата, туда что угодно не запихнешь. 9999-12-31 максимум
Tikhon
Tikhon
Проще говоря, объявления структуры внутри структуры
Andrey
Tikhon
Tikhon
Tikhon
В первом случае пишет мол, expected ';', found '{'syntax
Tikhon
Во втором я соответственно обращаюсь к методу
Andrey
ну правильно он тебе пишет
Andrey
у тебя типа такого нет, а то что ты сделал в своей струтуре, это просто embedded объявление
Andrey
переменной можешь присваивать тип, а твое AccountRequest.SignUp не является явным типом
Tikhon
Понял, спасибо. Как посоветуете поступить в таком случае ? Не хочется создавать отдельные структуры SignIn и SignUp вне структуры AccountRequest
Tikhon
Не очень понял что вы тут имеете ввиду
Andrey
применяй просто правило для начала - к каждому РЕСТу своя структура, а только потом думай об улучшении и объединении
Andrey
создается ощущение, что твоя структура делает все сразу, и авторизацию, и регитсрацию и еще много чего. и ты от заполненности полей только понимаешь, что у тебя происходит
Tikhon
Я несколько дней назад здесь спрашивал про организацию структур в проекте, описывающих запросы - мне только один человек в лс свой пример скинул, причём довольно странный
Tikhon
применяй просто правило для начала - к каждому РЕСТу своя структура, а только потом думай об улучшении и объединении
А разве я их не разделил ? AccountRequest, TicketRequest, вроде для каждого реквеста своя структура
Andrey
ну я вижу что у тебя SingIn SignUp это одна сущность, хотя подразумевается разные действия
Tikhon
А, теперь понял о чём вы говорите
Tikhon
ну я вижу что у тебя SingIn SignUp это одна сущность, хотя подразумевается разные действия
Да, понимаю, просто хотел их как-то объединить в общую структуру, которая например содержит в себе запросы к аккаунту
Tikhon
Могу их конечно объявить сначала вне этой общей структуры, но этот вариант не очень нравится
Tikhon
Потому что имена становятся длинные и страшные, приходится вчитываться
Andrey
чем проще код, тем лучше. не занимайся овер инженерингом, не понимая еще даже базовые вещи языка
Tikhon
чем проще код, тем лучше. не занимайся овер инженерингом, не понимая еще даже базовые вещи языка
Я как раз таки хотел сделать код проще, мне кажется что так проще читается, имхо
Tikhon
Спасибо
Andrey
у тебя появится рест на 10 полей, потом еще на 15, и ты тут решил их запихнуть в одну структуру))) не думаю, что такое будет читаться. а потом поитогу у тебя пол кода написано так, пол кода иначе
Tikhon
у тебя появится рест на 10 полей, потом еще на 15, и ты тут решил их запихнуть в одну структуру))) не думаю, что такое будет читаться. а потом поитогу у тебя пол кода написано так, пол кода иначе
Думаю, что мы друг друга немного не понимаем. Я изначально не думал, что embedded получится. Просто попробовал объявить новую структуру внутри структуры, чтобы отдельно её не выносить
Andrey
ну отчасти у тебя получилось встраивание, только анонимное))) это считай ты у interface типа вызвал метод, до его приведения)