второй год юзаю

Года 4 назад я открывал какойто файлик в архиве eap ide и ежемесячно менял там дату)

Года 4 назад я открывал какойто файлик в архиве eap ide и ежемесячно менял там дату)

лол, любопытная тема

Года 4 назад я открывал какойто файлик в архиве eap ide и ежемесячно менял там дату)

Я не знал

А 4 года назад вы пользовались идеей?)

А если просто дату на компе менять, работает?

А если просто дату на компе менять, работает?

Кажется, нет. Там был xml, где указана дата выпуска и когда сдохнет триалка

Ну года 2 юзаю

А 4 года назад вы пользовались идеей?)

4 года назад я на си лабы только писать начал?

Кажется, нет. Там был xml, где указана дата выпуска и когда сдохнет триалка

Хитрецы))

Ну вот поэтому и не знали) Выживали как могли)

До этого эклипс был, тот еще тормоз

До этого эклипс был, тот еще тормоз

Он ещё и выглядит уёбищно

От, я тоже с эклипса на джаве начинал, жесть ещё та

На тот момент он казался офигенным)

Он ещё и выглядит уёбищно

??

Года 4 назад я открывал какойто файлик в архиве eap ide и ежемесячно менял там дату)

Вот бы так с дедлайнами..

Как можно архитектурно зарефакторить такой код? switch incomeEvent.Action { case models.CALL: switch incomeEvent.Method { case models.GET: getRequestHandler(incomeEvent) case models.POST: postRequestHandler(incomeEvent) } case models.SUBSCRIBE: switch incomeEvent.Method { case models.POST: postSubscribeHandler(incomeEvent) } } P.S. Внутри этих методов еще switch. Полиморфизм? Регистрация колбеков? Мб еще варианты есть? В golang новичок. Такая вложенность, еще и раскиданная по файлам мне не нравится

Попробовал сделать. Мне не нравится, много действий нужно сделать. Но сам switch стал хотя бы читаемый type IncomingHandlerPool struct { messages MessagesHandler } type MessagesHandler interface { GetMessages(event models.IncomeEvent) GetChatsCount(event models.IncomeEvent) SendMessage(event models.IncomeEvent) MarkRead(event models.IncomeEvent) NotifyTyping(event models.IncomeEvent) } const ( requestMessages = "request_messages" requestChatsCount = "request_chats_count" sendMessage = "send_message" markRead = "mark_read" notifyTyping = "notify_typing" ) var ( handlerKeys = map[string]string{ requestMessages: handleKey(models.CALL, models.GET, models.TYPE_MESSAGE), requestChatsCount: handleKey(models.CALL, models.GET, models.TYPE_COUNTS), sendMessage: handleKey(models.CALL, models.POST, models.TYPE_MESSAGE), markRead: handleKey(models.CALL, models.POST, models.TYPE_READ), notifyTyping: handleKey(models.CALL, models.POST, models.TYPE_TYPING), } ) // ... switch handleKey(incomeEvent.Action, incomeEvent.Method, incomeEvent.Type) { case requestMessages: handlers.messages.GetMessages(incomeEvent) case requestChatsCount: handlers.messages.GetChatsCount(incomeEvent) case sendMessage: handlers.messages.SendMessage(incomeEvent) case markRead: handlers.messages.MarkRead(incomeEvent) case notifyTyping: handlers.messages.NotifyTyping(incomeEvent) } // ... func handleKey(a int, m string, t string) string { return fmt.Sprintf("%s-%s-%s", a, m, t) }

Как не потерять читаемость, но убрать эту громоздкость?)

Я делаю пакет app и пишу там routers handlers и models

Я делаю пакет app и пишу там routers handlers и models

И как это уменьшит громоздкость?

В main уже просто сервак

Это вообще норм? Потому как мне удобно так, в стиле django

И как это уменьшит громоздкость?

Никак, просто стиль такой

Вот так уже проще) По имени метода понятно, что это за кейс type IncomingHandlers struct { messages MessagesHandler } type MessagesHandler interface { GetMessages(event models.IncomeEvent) GetChatsCount(event models.IncomeEvent) SendMessage(event models.IncomeEvent) MarkRead(event models.IncomeEvent) NotifyTyping(event models.IncomeEvent) } var ( handlers = IncomingHandlers{ messages: &MessagesServerHandler{}, } ) // ... switch handleKey(incomeEvent.Action, incomeEvent.Method, incomeEvent.Type) { case handleKey(models.CALL, models.GET, models.TYPE_MESSAGE): handlers.messages.GetMessages(incomeEvent) case handleKey(models.CALL, models.GET, models.TYPE_COUNTS): handlers.messages.GetChatsCount(incomeEvent) case handleKey(models.CALL, models.POST, models.TYPE_MESSAGE): handlers.messages.SendMessage(incomeEvent) case handleKey(models.CALL, models.POST, models.TYPE_READ): handlers.messages.MarkRead(incomeEvent) case handleKey(models.CALL, models.POST, models.TYPE_TYPING): handlers.messages.NotifyTyping(incomeEvent) }

А интерфейс на одну сущность?

Это вообще норм? Потому как мне удобно так, в стиле django

норм вроде, beego так делает примерно

А интерфейс на одну сущность?

не, там несколько сущностей будет

Аа

Оу

Зная норм

Просто чтобы подключить ещё приложение, создам пакет

Я сомневался если честн

Как не потерять читаемость, но убрать эту громоздкость?)

так лучше вообще не делать

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

и еще с мапами надо осторожно храня в глобальной переменной

если будешь читать их с двух рутин, получишь гонку

а есть какой то быстрый способ посчитать кол-во аллокаций если у меня маленькая функция main памяти кроме тестов и кроме GODEBUG=allocfreetrace=1 ?

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

А предоставлять из пакета в клиентский код каналы нормально вообще?) Я просто хз, не хотелось бы применять там, где не надо

и еще с мапами надо осторожно храня в глобальной переменной

Если глобальный мап в отдельном пакете - он доступен только пакету ж

Если с маленькой буквы

а есть какой то быстрый способ посчитать кол-во аллокаций если у меня маленькая функция main памяти кроме тестов и кроме GODEBUG=allocfreetrace=1 ?

А atomic? Не подходит?

А предоставлять из пакета в клиентский код каналы нормально вообще?) Я просто хз, не хотелось бы применять там, где не надо

https://play.golang.org/p/yByhf7iTNH Очень даже, типа так

Если глобальный мап в отдельном пакете - он доступен только пакету ж

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

А atomic? Не подходит?

а конкретно ??? ну вот я учу Го хочу понять как правильно аллоцировать написал простейший код https://play.golang.org/p/WQVXfwWzue хочу понять сколько в нем аллокаций запустил GODEBUG=allocfreetrace=1 go run test.go и получил тонну вывода... и большинство аллокаций вообще не в моем коде =( как померить правильно?

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

Ну, если честно, эти обработчики обрабатываются в пакете, снаружи нужно только предоставлять данные для обработчика внутри и реагировать на события асинхронно. С реакцией на события соглашусь, можно каналы давать, но что делать, когда нужно получить данные? Вот у меня есть GetMessages. Он делает какую-то внутренню бизнес-логику, в середине ему нужно получить сообщения от клиентского кода, из них сформировать структуру и отправить в свой канал. Тут каналы не лишнее использовать?

а конкретно ??? ну вот я учу Го хочу понять как правильно аллоцировать написал простейший код https://play.golang.org/p/WQVXfwWzue хочу понять сколько в нем аллокаций запустил GODEBUG=allocfreetrace=1 go run test.go и получил тонну вывода... и большинство аллокаций вообще не в моем коде =( как померить правильно?

Так gobyexample, там есть паттерн

если будешь читать их с двух рутин, получишь гонку

Нет

если будешь читать их с двух рутин, получишь гонку

Кстати да, я там ничего не читаю

просто дёргаю callback

Ну, если честно, эти обработчики обрабатываются в пакете, снаружи нужно только предоставлять данные для обработчика внутри и реагировать на события асинхронно. С реакцией на события соглашусь, можно каналы давать, но что делать, когда нужно получить данные? Вот у меня есть GetMessages. Он делает какую-то внутренню бизнес-логику, в середине ему нужно получить сообщения от клиентского кода, из них сформировать структуру и отправить в свой канал. Тут каналы не лишнее использовать?

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

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

Я в golang новичок (3 недели), и паттернов каких-то именно для go у меня еще не набралось, поэтому вот и спрашиваю, как что лучше)

я думаю, пока забудьте о них на время, разве-что поробуйте и всё. Там есть что учить, а потом на уровне стандартных пакетов разберётесь как и когда их применять. Как говориться, это ты должен сердцем чуять, когда их применять а когда нет. Усложнить и хелловорлд можно , но зачем? Но эт только моё мнение, у каждого свой путь.)

Ну, в сервере для чатов сложно о них забыть) Хочешь-не хочешь, а для внутренней работы сервера они 100% нужны

Ну, если честно, эти обработчики обрабатываются в пакете, снаружи нужно только предоставлять данные для обработчика внутри и реагировать на события асинхронно. С реакцией на события соглашусь, можно каналы давать, но что делать, когда нужно получить данные? Вот у меня есть GetMessages. Он делает какую-то внутренню бизнес-логику, в середине ему нужно получить сообщения от клиентского кода, из них сформировать структуру и отправить в свой канал. Тут каналы не лишнее использовать?

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

Нет

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

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

В том и прикол, что клиент должен записать туда данные, а не читать, если это будет канал, причём либо синхронно, либо wg какой-нибудь func (c *MessagesServerHandler) GetMessages(event models.IncomeEvent) { response, err := client.GetChatMessages(event) if err != nil { resultChan <- event.CreateResult(nil, err.Error()) return } resultChan <- event.CreateResult(response, nil) }

Не стоит пихать все результаты в один канал, создай два

В один канал ошибки, в другой - удачный результат

Не стоит пихать все результаты в один канал, создай два

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

+ нужно его уведомить, что сейчас нужно туда записать

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

В сокеты прилетает что-то типа json-rpc - например, запрашивают список сообщений. Сервер должен распарсить запрос, понять, что хочет браузер, и отдать этот список сообщений опять же в определенном формате типа json-rpc Сами сообщения сервер не хранит, и к базе доступа нет, поэтому нужно это сделать другому (клиентскому) коду, но этот код не должен влиять на сам протокол работы сервера. У нас несколько проектов, и эти чаты нужны оказались на еще одном проекте. Не хочется с нуля писать сервер и разрабатывать свой протокол обмена с браузером, поэтому то, что реализует протокол, решили выделить в отдельный пакет, а всё взаимодействие с конкретным проектом - это должно быть реализовано уже в конкретном проекте

ERROR: S client not available

Клиенты для ios/android/js есть, их можно переиспользовать, только если протокол не изменится

Друзья, насколько "костыльно" использовать build тэги с сорцах? В доках на эту тему целая страница, но в коде на гитхабе такое редко встречаются..

Они редко нужны

Ну вот если я точно знаю, что буду билдить только под linux, то могу вставить чтобы каждый раз не писать GOOS=linux?

Это другое

Ну вот если я точно знаю, что буду билдить только под linux, то могу вставить чтобы каждый раз не писать GOOS=linux?

Ты можешь использовать силу CI

Проще экспорт сделать переменной

В сокеты прилетает что-то типа json-rpc - например, запрашивают список сообщений. Сервер должен распарсить запрос, понять, что хочет браузер, и отдать этот список сообщений опять же в определенном формате типа json-rpc Сами сообщения сервер не хранит, и к базе доступа нет, поэтому нужно это сделать другому (клиентскому) коду, но этот код не должен влиять на сам протокол работы сервера. У нас несколько проектов, и эти чаты нужны оказались на еще одном проекте. Не хочется с нуля писать сервер и разрабатывать свой протокол обмена с браузером, поэтому то, что реализует протокол, решили выделить в отдельный пакет, а всё взаимодействие с конкретным проектом - это должно быть реализовано уже в конкретном проекте

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

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

да. В одном проекте это БД, в другом http может быть

пока не ждёт, но идея такая

Ну вот если я точно знаю, что буду билдить только под linux, то могу вставить чтобы каждый раз не писать GOOS=linux?

Смотря при каких условиях билдить. Если люди будут билдить с разных ос, а потом запускать на линуксе, надо явно указывать таргет ос

Ну вот если я точно знаю, что буду билдить только под linux, то могу вставить чтобы каждый раз не писать GOOS=linux?

build теги используют, когда нужно описать, что конкретный файл можно билдить только под линукс.(а под винду другие файлы, например) То под что билдить во время билда указывает переменная окружения. На нее можно сделать export GOOS=linux.

да. В одном проекте это БД, в другом http может быть

Т.е. грубо говоря, у вас приложение разбито на некоторые независимые друг от друга (микро) сервисы и стоит проблема, как общаться между ними.

Так почему бы не заюзать брокер сообщений? Ну реально выходит, что приходится костылять свой

Т.е. грубо говоря, у вас приложение разбито на некоторые независимые друг от друга (микро) сервисы и стоит проблема, как общаться между ними.

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

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

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

А как вариант написать сервис, который будет слушать чат, дальше все складывать в RabbitMQ?

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

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

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

В точку)

Ну сделай в либе функцию установить хэндлер под такое событие и все.

Вот я и делаю, говорят хрень какая-то) Маппинги на них пока что

Ну мы же не видим всю картинку целиком

Ну вот я и спрашиваю) Тут client.GetChatMessages(event) - это кастомный обработчик func (c *MessagesServerHandler) GetMessages(event models.IncomeEvent) { response, err := client.GetChatMessages(event) if err != nil { resultChan <- event.CreateResult(nil, err.Error()) return } resultChan <- event.CreateResult(response, nil) }

Вот я и делаю, говорят хрень какая-то) Маппинги на них пока что

Ну стандартная либа так делает во всяких http, а нам нельзя что ли?

А с клиента скорее всего будет server.handler(action, handler)

Ну вообще, да, так http и делает type ServeMux struct { mu sync.RWMutex m map[string]muxEntry hosts bool // whether any patterns contain hostnames } //... mux.m[pattern] = muxEntry{explicit: true, h: handler, pattern: pattern}

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

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

много читателей не приводит к панике, к панике приводит много писателей

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

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

это откуда такие сведения?

Народ, а как можно сделать анонимно что-то вроде: res := Result{ Status: status, Result: H{ "token": tokenString, }, Error: error, } type Result struct { Status bool `json:"status"` Error string `json:"error,omitempty"` Result map[string]interface{} `json:"result,omitempty"` } type H map[string]interface{} Что бы не потребовалось type H делать?

этот код не должен компиляться