Который будет первой точкой запроса перед проксированием запросов?

Я решил сделать закрытые сервисы в контейнерах доступ к которым будет только у api-gateway

найс

Ну и между собойчик у них будет)

Видел доклад на эту тему, если интересно могу скинуть чуть позже

Ага. Было бы круто

Ага. Было бы круто

https://youtu.be/SLc3cTlypwM

https://youtu.be/SLc3cTlypwM

Спасибо

thnk you so much!

Товарищи, а как в golang корректно называть конструктор: 1. NewSome 2. BuildSome ? Можете дать пожалуйста ссылочку на code style convention?

Можно посмотреть как сделано в стандартной либе. У таймера, например, используется NewSome.

https://golang.org/doc/effective_go

Golang-дайджест № 6 (1 – 30 июня 2021) Интересное в этом выпуске: ✅ Выпущены версии Go 1.16.5 и 1.15.13 ✅ Выпущен gopls v0.7.0 ✅ Создание собственного Ngrok в 130 строках ✅ GopherCon Europe 2021 Online https://habr.com/ru/post/566782/ @Golang_google

Решил одну задачку со школы программиста :D интересно кто и как бы ее решал

https://acmp.ru/index.asp?main=task&id_task=76

Вообще там задачи прорешивать полезно

Решил одну задачку со школы программиста :D интересно кто и как бы ее решал

это классика жадных алгоритмов: https://stepik.org/lesson/Введение-13238/step/2?unit=3424

А вот попробуйте решить эту задачу: https://acm.timus.ru/problem.aspx?space=1&num=1542

это классика жадных алгоритмов: https://stepik.org/lesson/Введение-13238/step/2?unit=3424

В задаче про музей нет жадных алгоритмов. Обычный подсчёт количества пересекающихся отрезков.

И?

Там их нет, потому что они не нужны. Сверху написали, что это классика жадных алгоритмов. Я написал, что нет. Про уровень речи не было.

Решить ее можно наивно и думать, что задача проста😉

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

Я читал что ее можно решить через дерево отрезков

Но как я понял дерево отрезков подразумевает что нужно сделать отрезок со всеми точками. Типо отрезок это набор минут.

Грубо говоря это будет более оптимальное решение чем если создать массив интов длиной 24*60 и потом время переводить в минуты, и от старта до выезда инкрементить в массиве значение по минуте

А потом брать максимальное значение

Я решил ее иначе.

https://github.com/bless-rng/max-count-cars-on-parking

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

В goland профилировщик странный, то что он только через тесты может профайлер памяти запустить. Или это норма?

Я воспроизвел свое решение на 10 тысяч записей и получил скорость исполнения в 0.01с

окей

вопрос такой к знающим. У меня есть массив структур. У этих структур есть поля в виде строк

type A struct { First string Second string }

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

если я просто возьму срез stringsSlice := []string for _, a := range arrayOfAStructs { stringsSlice = append(stringsSlice, a.Fisrts, a.Second) }

то у меня в новом слайсе будет копия строки или нет?

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

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

если я просто возьму срез stringsSlice := []string for _, a := range arrayOfAStructs { stringsSlice = append(stringsSlice, a.Fisrts, a.Second) }

Можешь это все в play.golang закинуть?

Возможно нужно пройтись по всему массив через индексы и делать типо for i := range arrayOfAStructs { stringsSlice = append(stringsSlice, &a.First, &a.Second): } а потом сравнение делать через *

Я выше кидал репу свою

там в решении это есть

но я думаю что там строки копируются и из за этого алгоритм не оптимальный

Да, точно, вроде разобрался))

Переделал вторую структуру - строки стали указателем. И в сравнении я беру значение по указателю)

@maks_vesnin а в том репо на гитхабе ты специально хранишь время в строках?

Да, для простоты.

@maks_vesnin а в том репо на гитхабе ты специально хранишь время в строках?

https://github.com/bless-rng/max-count-cars-on-parking/pull/1/files

Прав ли я, что так будет оптимальнее?

экономнее

Я просто пока не до конца понимаю как под капотом работает передача строк в го в качестве параметра структуры.

Я просто пока не до конца понимаю как под капотом работает передача строк в го в качестве параметра структуры.

Ну строки это слайсы байтов Рид онли логика соответственно у них похожая

Я в го пока слабый))) По этому и спрашиваю)) Так лучше, или не важно и можно строку просто передавать?

Ща ноут открою посмотрю с мобилки не удобно

Добавил еще капасити сразу, так как мне оно известно. А на больших объемах не выгодно расширят будет

Ну с точки зрения выделения памяти да это эффективней

По сути стринг это https://golang.org/pkg/reflect/#StringHeader

Можно вместо стар и енд юзать time.Duration это int64

В задаче просто сказано что есть на вход массив данных вида {start, end}. Вот я и сделал так

По сути алгоритм это не меняет

То есть сам тип не важен, мне важно только то, на сколько я сделал эффективным алгоритм.

С точки зрения производительности и потребления памяти

Вообще эта задача идентична

https://acmp.ru/index.asp?main=task&id_task=76

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

https://gist.github.com/goriyasno/a4ddebf427fec634686c63965bab2da3

append(states, tempState{&parkingTickets[i].Start,true}, tempState{&parkingTickets[i].End, false}) если я ничего не забыл и не попутал то здесь ты каждую итерацию создаешь новый структ, хотя уже сделал make([]tempState)

Ну я еще ему размер задал нужный

Точнее не размер а капасити

Но изначально элементами пустыми не заполнил

Может быть так будет лучше, сейчас почитаю

Но изначально элементами пустыми не заполнил

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

Я согласен

На скорость это может и не повлияет, а может и повлияет)

Но выглядит логично

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

Ну потому что там 2 за шаг

На скорость это может и не повлияет, а может и повлияет)

Ты же не тратишь лишние тики процесора каждую итерацию, должно быть поменьше времени)

Ты же не тратишь лишние тики процесора каждую итерацию, должно быть поменьше времени)

Так как каждое выделение памяти это трата тиков проца, то логичнее выделить сразу все. Посмотри как сделан fasthttp там работа с памятью возведена в абсолют)