pavels91: к вашей скорее комментарий снизу, а те четыре пункта - для тех кто попадёт в ваш вопрос с поиском информации по теме:) И на них побудил комментарий от Денис Букреев :)
У меня было два, или может быть три,успешных опыта с представительницами прекрасной половины человечества:) Вот список правил как с ними работать:
точно понимать что вы можете сделать то что в техническом ТЗ, а техническое ТЗ, как правило, составляли не они, они его максимум "верстали" из того что им дал кто-то ещё, например предыдущий разработчик или начальник или ещё кто-то:)
не делать больше одного проекта за раз и вообще не браться за следующие если первый прошёл не просто (с точки зрения общения) так как последующие могут затянуть вас в болото непонимания (что и случилось с топикпастером)
не соглашаться на то что не нравится или в чём вы не уверены
быть формалистом - оговорить заранее, что, как, в каком виде, а потом проследить что бы всё было по списку и с оплатой - что они будут делать потом - это истории не известно и лучше не связываться:)
Что бы закончить сотрудничество - достаточно сказать другой стороне что сотрудничество завершено, можно так же выставить счёт за то что вы уже сделали но за что не получили оплаты, но, вы можете этих денег и не получить - это те риски что есть у фрилансеров.
Никита: правда при удалении первого элемента всё равно придётся перезаписывать slice.
Один из вариантов который используют когда не хотят перезаписывать slice
- добавляют в элемент флаг удалённости
- время от времени перезаписывают slice убирая все удалённые элементы, делают это в фоне, подменяют указатель на slice через atomic или sync.RWMutex
Стратегий одного и тогоже может быть множество, важно выбирать то что больше всего удовлетворяет задаче.
Никита: если помимо удаления первого элемента нужно будет иметь возможность вытащить N элементов с начала, конца или из произвольной точки, то больше подойдёт slice, либо их комбинация:
- слайс для доступа к произвольным порядковым номерам
- канал для организации удаления старых записей - "первый вошёл первый вышел"
Никита: в теории:
- буфиризированный канал это по сути очередь, при добавлении лишних аллокаций быть не должно (надо бы проверить на самом деле)
- слайс при добавлении элементов всегда растёт (чанками, но всё таки)
- записи в такой слайс или буфер может быть очень много
- при удалении из слайса память нужно перезаписать, а это затратно, в канале такого быть не должно
На практике же компилятор постоянно тюнят и те или иные моменты могут поменяться или уже поменялись. Иными словами канал для очерей больше подходит чем его эмуляция через slice
Хорошо, если это ничего не значит то как container/heap защищён от конкурентного доступа? Ответ - никак. Видимо потому что это забота программиста - выбирать способ и уровень защиты.
Gizmothron: Все мы ставим перед собой цели для достижения которых приходится много учиться:) В этом суть того чем мы любим заниматься:) Чем не реальнее цель тем лучше:)
Владимир Грабко: вы вообще книги читаете или каждый свой мыслительный процесс задаёте на тостере?:)
sync.RWMutex
Lock() и Unlock() - когда данные пишете
RLock() и RUnlock() - когда читаете
В момент когда несколько конкурентных чтений - читаются параллельно без особых накладных расходов (не блокируется), но гарантируется что если вызван Lock() RLock() уже не запустишь и наоборот, Lock() вклинивается между ближайшими RLock() и не даёт следующим читать до тех пор пока не обновит данные.
Владимир Грабко: может быть, всё может быть:) Ещё про gorpc хорошо отзываются, но у меня пока не было времени его попробовать:) goprotoboof тоже чуть ли не фаворит в этом деле. В общем выбрать есть из чего.
Стоит ли использовать WebSockets для таких целей? Скорее нет. Потому что поверх вам придётся всё равно писать много логики, а если коннект разорвётся то желательно делать два и более канала между двумя точками, в специализированных протоколах это должно лучше решаться.
Индекс на текст (в MySQL) имеет ограничение на максимальную длину, а полнотекстовый поиск (который так же можно использовать для фильтра) адски медленный.
Фрилансю на Golang немногим меньше двух лет - иной раз бывает очень интересно:)