Прямо не бывает халявы. Сколько раз такое было, из - за технических сбоев. Потом халяву отбирали, но люди через суд все равно возвращали. В т - банке, ламоде, цуме и много где еще. Халява бывает, но - крайне редко
Ну как же - у них же возникла проблема, которая ни у кого и никогда в истории человечества не возникала! Явно же, что использовать OLAP, другие кеши кроме редиса/другие OLTP не было вариантом.
не надо бояться писать кастомные решения
Да. Добавить только, что надо докупить памяти на 500к+ для экспериментов. Но для компаний уровня островка это капля в море. Ram лишней никогда не будет.
По описанному, задача не выглядит такой уж сложной. Часто сталкивался с кастомными кешами. Кроме арены еще часто sync.Pool используют. Странно по времени - 3 года. Обычно такие mvp за месяц пишут, взамен каким - нибудь готовым, но платным решениям.
БД вообще - то и сейчас блокировщики используют. Кто - то «почти» не использует - как PostgreSQL, а кто - то весьма активно - как SQL Server. А версионники и в 20 веке использовались, но не как механизм оптимизации, а для решения конкретных проблем конкурентного доступа
Вот по поводу паники в дочерней горутине - какой каноничный подход? Я думал, паника в дочерней горутине не должна затрагивать main - горутину. Но вот выполняю я следующий код на playground 1.25:
package main
import (
"fmt"
"time"
)
func risky() {
panic("всё пропало!")
}
func main() {
go risky() // Запускаем горутину, которая упадет
// Ждем, чтобы дать горутине время упасть
time.Sleep(100 * time.Millisecond)
fmt.Println("Main жив и здоров!") // Это выполнится
} - на какой версии Go?
А вот почему именно трехцветный алгоритм? Почему не двухцветный? Выбрали глобальные переменные и указатели, их сразу отметили черным. Потом идем по ссылкам и помечаем их черным. ВСЕ! И в фазе sweeping просто убираем белые и оставляем черные. НИКТО вообще не может пояснить, зачем нужен серый цвет, все на собесах просто читают одну и ту же мантру.
В общем то, не такой уж сложный концепт про BFS и почему GC работает именно по такому алгоритму.
Одна вода, «методологии», размышления типа «надо было нанять Лидера, а наняли обычного человека». «У конкурентов у всех новомодная AI - штука, надо тоже нанять человека, который в этом разбирается, чтобы тоже эту штуку у нас сделал и бабло рекой текло». И вместо тех спецов, которые реально что - то делают, наняли Лидера.
Эффективного менеджера, в понимании которого Лидер - это альфа - самец, начальник мужчин и любимец женщин. Лидер не должен ничего организовывать на это есть специальные люди. В технической части Лидер тоже не должен разбираться даже в общем - это даже не достойно Лидера. Любимая призказка таких «Дело не в технологиях и организации, дело всегда в Людях». И если на прошлой работе все развалилось, на новую всегда легко устроиться - нужно просто одеть дорогой костюм, сделать стильную короткую прическу и бородку у дорогого барбера, «лидерскую» и говорить на собесе как Лидер. Вы ведь все таких видели, правда?
Обычное дело, которое сплошь и рядом. Имхо, если за 19 лет не научился отличать Лидеров от «Лидеров», никакие методологии не помогут
А есть ли какая - то «ниша» Oracle сейчас в России? Уже очень давно не слышал, чтобы где - то Oracle в России использовался, тем более в банках. PostgreSQL/tarantool/greenplum и т.д. уже давно эту нишу заняли
Не сказал бы, что прямо «очень хорошая статья». Такое ощущение, что студент перед экзаменом разом зазубрил учебник и выпаливает все разом. Приведено много сложных моментов вроде next key lock, но особо они не поясняются. Не приведено причинно - следственной логической связи между разными проблемами, способами их решения в разных СУБД и соответствующими уровнями изоляции. Статья полезна в качестве быстрой шпаргалки для тех, кто в теме, поэтому плюсую. Но те, кто хочет разобраться в теме транзакций в принципе, имхо, мало что тут поймут
«Просто, элегантно и почти без лишнего кода» - ну такое себе. Себя не похвалишь, никто не похвалит. Это имеется в виду две этих функции - processSqlValue и processSqlExpr? Сама по себе задача то простая. Это даже не полноценный sqlParser/sqlBuilder. Простенький where/between/and/or реализуется.
«Реализовать валидатор SQL-условий WHERE на Go довольно просто — почти тривиально» - как бы и так очевидно. Любой джун конкретно с указанной в статье задачей справится. Если копнуть глубже, вроде условий IN, подстроки или select с join - чем более функционально, тем более сложно будет, придется также учитывать, как обрабатывают SQL конкретные субд/движки.
Ну то есть если кому - то действительно нужно написать много апи, где используется простейший where/and/or, то вместо кучи однообразных апи с преобразованием в Sql через dbx можно использовать такое решение. Или использовать кодогенерацию. Но на практике чаще сразу используют graphql - и более функционален и полно готовых надстроек для контроля доступа
“Ранее в Go для разрешения коллизий в хеш-таблицах использовался метод цепочек, при котором каждый бакет содержал указатель на связанный список элементов с одинаковым хеш-значением.» - ранее это насколько ранее? Мне вот это предложение не давало покоя. Насколько я помню, с go 1.8 в хеш - таблицах метод цепочек, предполагающий списки, уже не используется. Все хранится в одном большом массиве. И действительно:
Начиная с Go 1.8, реализация map в Go перешла с метода цепочек (связные списки в бакетах) на комбинацию открытой адресации и "bucket-ов"
А сколько по времени заявка рассматривается? Вчера подал заявку и пока никакого ответа. И да, пришлось на получение рекламных материалов согласиться, теперь заспамите?)
Прямо не бывает халявы. Сколько раз такое было, из - за технических сбоев. Потом халяву отбирали, но люди через суд все равно возвращали. В т - банке, ламоде, цуме и много где еще. Халява бывает, но - крайне редко
Чел явно с Go перешел. Любитель вендоринга
Ну как же - у них же возникла проблема, которая ни у кого и никогда в истории человечества не возникала! Явно же, что использовать OLAP, другие кеши кроме редиса/другие OLTP не было вариантом.
Да. Добавить только, что надо докупить памяти на 500к+ для экспериментов. Но для компаний уровня островка это капля в море. Ram лишней никогда не будет.
По описанному, задача не выглядит такой уж сложной. Часто сталкивался с кастомными кешами. Кроме арены еще часто sync.Pool используют. Странно по времени - 3 года. Обычно такие mvp за месяц пишут, взамен каким - нибудь готовым, но платным решениям.
БД вообще - то и сейчас блокировщики используют. Кто - то «почти» не использует - как PostgreSQL, а кто - то весьма активно - как SQL Server. А версионники и в 20 веке использовались, но не как механизм оптимизации, а для решения конкретных проблем конкурентного доступа
Вот это правильно! Это точно подмечено! Я именно это и отвечаю сейчас на собесах в бигтехах на вопрос мотивации в работе
Вот по поводу паники в дочерней горутине - какой каноничный подход? Я думал, паника в дочерней горутине не должна затрагивать main - горутину. Но вот выполняю я следующий код на playground 1.25:
И «Main жив и здоров!» не выводится
9 👍, при этом 300+ закладок. Как так?
А вот почему именно трехцветный алгоритм? Почему не двухцветный? Выбрали глобальные переменные и указатели, их сразу отметили черным. Потом идем по ссылкам и помечаем их черным. ВСЕ! И в фазе sweeping просто убираем белые и оставляем черные. НИКТО вообще не может пояснить, зачем нужен серый цвет, все на собесах просто читают одну и ту же мантру.
В общем то, не такой уж сложный концепт про BFS и почему GC работает именно по такому алгоритму.
Нужно просто написать про все работы: «Улучшил работу всего в Гугл раз». И тогда резюме гарантированно будет в топе)
Одна вода, «методологии», размышления типа «надо было нанять Лидера, а наняли обычного человека». «У конкурентов у всех новомодная AI - штука, надо тоже нанять человека, который в этом разбирается, чтобы тоже эту штуку у нас сделал и бабло рекой текло». И вместо тех спецов, которые реально что - то делают, наняли Лидера.
Эффективного менеджера, в понимании которого Лидер - это альфа - самец, начальник мужчин и любимец женщин. Лидер не должен ничего организовывать на это есть специальные люди. В технической части Лидер тоже не должен разбираться даже в общем - это даже не достойно Лидера. Любимая призказка таких «Дело не в технологиях и организации, дело всегда в Людях». И если на прошлой работе все развалилось, на новую всегда легко устроиться - нужно просто одеть дорогой костюм, сделать стильную короткую прическу и бородку у дорогого барбера, «лидерскую» и говорить на собесе как Лидер. Вы ведь все таких видели, правда?
Обычное дело, которое сплошь и рядом. Имхо, если за 19 лет не научился отличать Лидеров от «Лидеров», никакие методологии не помогут
А есть ли какая - то «ниша» Oracle сейчас в России? Уже очень давно не слышал, чтобы где - то Oracle в России использовался, тем более в банках. PostgreSQL/tarantool/greenplum и т.д. уже давно эту нишу заняли
Не сказал бы, что прямо «очень хорошая статья». Такое ощущение, что студент перед экзаменом разом зазубрил учебник и выпаливает все разом. Приведено много сложных моментов вроде next key lock, но особо они не поясняются. Не приведено причинно - следственной логической связи между разными проблемами, способами их решения в разных СУБД и соответствующими уровнями изоляции. Статья полезна в качестве быстрой шпаргалки для тех, кто в теме, поэтому плюсую. Но те, кто хочет разобраться в теме транзакций в принципе, имхо, мало что тут поймут
«Просто, элегантно и почти без лишнего кода» - ну такое себе. Себя не похвалишь, никто не похвалит. Это имеется в виду две этих функции - processSqlValue и processSqlExpr? Сама по себе задача то простая. Это даже не полноценный sqlParser/sqlBuilder. Простенький where/between/and/or реализуется.
«Реализовать валидатор SQL-условий WHERE на Go довольно просто — почти тривиально» - как бы и так очевидно. Любой джун конкретно с указанной в статье задачей справится. Если копнуть глубже, вроде условий IN, подстроки или select с join - чем более функционально, тем более сложно будет, придется также учитывать, как обрабатывают SQL конкретные субд/движки.
Ну то есть если кому - то действительно нужно написать много апи, где используется простейший where/and/or, то вместо кучи однообразных апи с преобразованием в Sql через dbx можно использовать такое решение. Или использовать кодогенерацию. Но на практике чаще сразу используют graphql - и более функционален и полно готовых надстроек для контроля доступа
Прямо сборник типовых задач на собес по go. «Заучите их наизусть и куда - нибудь точно пройдете»
“Ранее в Go для разрешения коллизий в хеш-таблицах использовался метод цепочек, при котором каждый бакет содержал указатель на связанный список элементов с одинаковым хеш-значением.» - ранее это насколько ранее? Мне вот это предложение не давало покоя. Насколько я помню, с go 1.8 в хеш - таблицах метод цепочек, предполагающий списки, уже не используется. Все хранится в одном большом массиве. И действительно:
Как в старом советском анекдоте - "Если не можешь/не берут работать - учи. Если и учить не можешь - руководи"
А сколько по времени заявка рассматривается? Вчера подал заявку и пока никакого ответа. И да, пришлось на получение рекламных материалов согласиться, теперь заспамите?)
Наконец - то ВК перейдет с их кастомного PHP на Go. Давно пора!
И зарплату получал)
Хорошо, что картинками пояснено, было бы решительно ничего не понятно