Примени тот же тезис к своей экспертизе, лол

@mersinvald хамишь, парниша

> парниша И кто тут хамит?

Вопрос в том, кто тут модератор...

Вопрос в том, кто тут модератор...

давно пора вытащить карающий меч!

идет 18-й час работы ... перенос c dbf нескольких таблиц в MYSQL таблицы со сменой индексов связи ... , когда делаю селекты по индексированным полям на миллион записей MySQL радует ... но некоторые задачи ... просто жопа, хотя может мои террабайтники в ноуте тормознутые ... хз что думать, ну и Windows который не умеет соединяться к MYSQL с помощью UNIX socket .... навевает уныние! Унылая осенняя ночь ....

Вот проснулся я и задался вопросом: а удаление ключа из мапы - дорогостоящая операция?

Нет

Не более дорогостоящая, чем поиск ключа в мапе

Ага, т.е. это O(1)?

Аммортизированно

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

Аммортизированно

Мне нужно удалять два параметра из мапки URL query, которые не относятся к фильтрации

Вот я и подумал, не дорого ли это

Не

Но на O(1) не равняйся, постольку поскольку вообще говоря O(1) это идеальный случай

Но на O(1) не равняйся, постольку поскольку вообще говоря O(1) это идеальный случай

думал, для поиска

То есть если у тебя хэшмапа на корзинах, то там может быть O(k) или O(log(k)) в зависимости от сложности поиска в корзине

идеальный

А мапа может быть еще на дереве основана

Это всегда минимум O(log(n))

я же не ищу, а удаляю ключ. по-идее, это просто. только вот не перестраивается ли хэш внутри? вроде как мапки в Го заимплименчены несколько оригинально. я был на докладе на эту тему.

Чтобы удалить ключ, его надо найти

Хэш вообще не перестраивается, это чистая функция

Чтобы удалить ключ, его надо найти

Блин, а логично же

Хэш вообще не перестраивается, это чистая функция

Я имел ввиду структуру, в которой лежат ключи

Это хороший вопрос, на самом деле.

По сути тогда может быть сложнее, чем поиск

Потому что надо еще там найти и удалить от туда

Если это связный список, то логарифм минимум, опять же, в зависимости от ключа.

Максимум O(n)

Мапки в го - это не LL

Я знаю

Они нигде не LL

Я сейчас не вспомню

Но для какого-нибудь метода map.keys() их надо хранить отдельно

И тут LL напрашивается

В Java - именно бакеты лежат как LL

Иди дерево

но не важно

В Java - именно бакеты лежат как LL

Бакеты — это не хэшмапа

К хэшам бакет не имеет отношения, в принципе

Бакеты это обработка коллизий

Один из способов, угумс

Да, есть еще linear probing, но он в общем случае то еще говно

Просто нужно найти статью про мапы в го, там они что-то намутили. 4 байта от хэша отдаются на ключ, 4 байта ещё на что-то

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

сейчас поищу

/report

/spam

/report

Просто нужно найти статью про мапы в го, там они что-то намутили. 4 байта от хэша отдаются на ключ, 4 байта ещё на что-то

Да там в исходникаах даже более менее понятно https://golang.org/src/runtime/hashmap.go

вот кстати там глаз зацепился за выражение описывающее свойство структуры overflow [2]*[]*bmap как его правильно читать?

Массив из 2 указателей на слайсы указателей bmap?

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

Массив из 2 указателей на слайсы указателей bmap?

похоже

у меня оффтопный вопрос, но это единственный чатик у мнея, где много программистов есть .какой-нить клёвый редактор, который умеет toml и желательно превью маркдауна и тащит с собой гит в себе, чтобы под винду скачал, поставил, склонил проект, удобно поправил и прям из гуев смержил и запушил. под описание подходит джетбрэйнс, но там много избыточного. какой-нить саблайм?

vs code

vscode подходит под описание

Гит не тянет вроде

vscode умеет git плагинами

ERROR: S client not available

у меня оффтопный вопрос, но это единственный чатик у мнея, где много программистов есть .какой-нить клёвый редактор, который умеет toml и желательно превью маркдауна и тащит с собой гит в себе, чтобы под винду скачал, поставил, склонил проект, удобно поправил и прям из гуев смержил и запушил. под описание подходит джетбрэйнс, но там много избыточного. какой-нить саблайм?

Но ведь избыточным не обязательно пользоваться:)

не обязательно.

но вообще vscode использует системный git

мне надо для чайника

visual studio)))))))

какой-нибудь tortoise git накатить

в гуе черпахи на раз потеряться

там должен быть консольный гит который сможет vscode подхватить

у меня оффтопный вопрос, но это единственный чатик у мнея, где много программистов есть .какой-нить клёвый редактор, который умеет toml и желательно превью маркдауна и тащит с собой гит в себе, чтобы под винду скачал, поставил, склонил проект, удобно поправил и прям из гуев смержил и запушил. под описание подходит джетбрэйнс, но там много избыточного. какой-нить саблайм?

Atom

Если в приложение прилетело сразу два запроса, которые требуют загрузки из БД одной и той же структуры данных, как правильно избежать двойного обращения к базе? на ноде в момент первого обращения, я создавал структуру и сохранял её в store, у неё было свойство ready и промись onReady, на который подписывались новые запросы, которым нужна эта же структура из базы. Не уверен что это было правильное решение. Как правильно это сделать в Go?

Делай кеширование на бд и спокойно делай два запроса, один выполнится, а второй из кеша возьмется

/report

у меня оффтопный вопрос, но это единственный чатик у мнея, где много программистов есть .какой-нить клёвый редактор, который умеет toml и желательно превью маркдауна и тащит с собой гит в себе, чтобы под винду скачал, поставил, склонил проект, удобно поправил и прям из гуев смержил и запушил. под описание подходит джетбрэйнс, но там много избыточного. какой-нить саблайм?

Gogland

gogland и пока бесплатно, лишние фичи можно не использовать

#Москва #150-220k Крупный стартап, занимающийся разработкой глобальной логистической платформы, с использованием технологий Blockchaine, Big Data, Machine Learning пищет себе в команду Разработчика backend г. Москва Основные обязанности: • разработка высоконагруженных web-сервисов (SOAP, REST) для компонент информационной безопасности на GO lang или Java + MySQL/Postgres/ElasticSearch; • участие в проектировании архитектуры; • при желании возможно участие в frontend-разработке. Требования: Обязательно: • высшее техническое образование; • опыт разработки от 2х лет; • опыт работы с реляционными СУБД MySQL или Postgres; • знание принципов и шаблонов проектирования, ООП; • опыт работы с системами контроля версий (Git, SVN). Приветствуется: • опыт работы с ElasticSearch • опыт создания REST-сервисов • наличие опыта разработки под высокие нагрузки, оптимизация кода и производительности; • знание других языков Высшее техническое • Опыт работы на подобной позиции – от 1 года Английский – уверенный технический английский • Коммуникабельность, обучаемость, внимательность, системное мышление Условия: Белая заработная плата, оформление по ТК РФ Постоянная занятость, работа в офисе Подробности и вопросы lshumakova@headspartners.com или @lshumakova

#Москва #150-220k Крупный стартап, занимающийся разработкой глобальной логистической платформы, с использованием технологий Blockchaine, Big Data, Machine Learning пищет себе в команду Разработчика backend г. Москва Основные обязанности: • разработка высоконагруженных web-сервисов (SOAP, REST) для компонент информационной безопасности на GO lang или Java + MySQL/Postgres/ElasticSearch; • участие в проектировании архитектуры; • при желании возможно участие в frontend-разработке. Требования: Обязательно: • высшее техническое образование; • опыт разработки от 2х лет; • опыт работы с реляционными СУБД MySQL или Postgres; • знание принципов и шаблонов проектирования, ООП; • опыт работы с системами контроля версий (Git, SVN). Приветствуется: • опыт работы с ElasticSearch • опыт создания REST-сервисов • наличие опыта разработки под высокие нагрузки, оптимизация кода и производительности; • знание других языков Высшее техническое • Опыт работы на подобной позиции – от 1 года Английский – уверенный технический английский • Коммуникабельность, обучаемость, внимательность, системное мышление Условия: Белая заработная плата, оформление по ТК РФ Постоянная занятость, работа в офисе Подробности и вопросы lshumakova@headspartners.com или @lshumakova

самого важного нет. мы тут не любим, когда без вилки

В самом начале все самые трендовые слова

вот абсолютно во всех чатах хрюш пинают за спам без вилок, и, тем не менее, их не пишут почему так?

да хер его знает

я вынужден признать, что российский хедхантер не знает ни своего заказчика, ни рынка, ни кандидата. особенно мало hr знает о кандидате. поэтому к заказчику идет сплошной поток шлака, а к кандидатам - сплошной поток требований, жиденько разбавленный какими-то "плюшками" я с обеих сторон бываю, и это полный фиаско :( если в компании свои hr - с ними еще можно договариваться (их дрессировать). если агентство - все, туши свет

Вот читаю, вроде все есть, но 220 вроде и норм по рынку, а вроде и не встает на них.. На свой проект инвесторы денег не дают, апатия какая-то и серость?

я вынужден признать, что российский хедхантер не знает ни своего заказчика, ни рынка, ни кандидата. особенно мало hr знает о кандидате. поэтому к заказчику идет сплошной поток шлака, а к кандидатам - сплошной поток требований, жиденько разбавленный какими-то "плюшками" я с обеих сторон бываю, и это полный фиаско :( если в компании свои hr - с ними еще можно договариваться (их дрессировать). если агентство - все, туши свет

+++

hr матчит ключевые слова, и к сожалению редко-редко раскладывает cv в структурное понимание что кандидат из себя представляет и подходит ли он заказчику..

попробовал тут кстати hugo - имею сказать, что ваще заебись штука

попробовал тут кстати hugo - имею сказать, что ваще заебись штука

стив просто крутой

у него и кобра крутая

Делай кеширование на бд и спокойно делай два запроса, один выполнится, а второй из кеша возьмется

А если запросов к этой структуре будет много? не лучше ли хранить информацию в десериализованном виде внутри приложения?

А если запросов к этой структуре будет много? не лучше ли хранить информацию в десериализованном виде внутри приложения?

Так он про это и имел ввиду. Создай некий хук на твой хендлер, который сперва проверяет локальную память приложения. Что-то вроде глобальной структуры Cache

А если запросов к этой структуре будет много? не лучше ли хранить информацию в десериализованном виде внутри приложения?

вы пытаетесь реализовать кеш внутри приложения, а есть ли смысл? окупится ли время затраченное на реализацию? Насколько более стабильным будем ваш кеш нежели тот, который разрабатывается крупными командами и на 99% покрыт тестами. Как правило кеша бд вам хватит за глаза, если у вас миллиарды запросов, то из памяти внутри приложения конечно будет быстрее.