На сколько легко найти работу на Go, если до этого работал программистом в сильно другой области? Я много лет пишу драйвера на C (не C++) под специфическую встраиваемую ОС. Возраст уже 35+. Есть ли шанс найти работу мидлом на Go? Или мидлом можно перейти на Go, только если предыдущий опыт был в бэкэнде? На джуна меня наверное не возьмут по возрасту, да и на Go мало джунских вакансий.
За себя не скажу, но мой друг, имея опыт в бэке на других языках, делая различные пэт проекты подался на мидловскую позицию и сказал там прямо, что ребята, я очень сильно хочу к вам, я себя оцениваю на джуна - джуна+, можете прособеседовать, можно даже не признаваться в этом, просто пробовать проходить собесы. Понятное дело, что нужно разбираться знать смежные технологии
1 0 1 мой друг, хочу в backend, выбираю между PHP, Golang, Node.js, Java, C#, что посоветуешь, чтобы легче было устроиться на работу с перспективой? Или с какого языка посоветуешь начать?
Отличный материал, только в конце про SERIALIZABLE я бы добавил, что он конкретно так лочит таблицу, из-за чего падает производительность, но зато все транзакции идут последовательно.
Иван, спасибо за видео, но его нужно переснимать. В процессе просмотра было несколько неточностей. Одна из них кем-то упоминалась в коментах, что мол read uncommitted это не аномалия, а название изоляции. Про другие не вспомню сейчас, т.к. в несколько заходов смотрю видео. Причиной для того, чтобы перезаписать видос, на мой взгляд, является то, что на 15:10 ты говоришь что изоляция repeatable read избавляет от фантомного чтения. Это не так. Repeatable read имеет самое кричащее название (имхо) и гарантирует (внезапно) то, что чтение строки будет повторятся (но не количество строк). Фантомное чтение - это аномалия которая невозможна только на Serializable уровне. Т.е. если на repeatable read 2-ая транзакция изменит данные в рамках одной строки, то ок (1-ая транзакция их не увидит при повторном чтении, аномалия с неповторяющимся чтением не воспроизводится). Но если 2-ая транзакция изменит количество строк (обновит/удалит), то 1-ая транзакция (при повторном выполнении того же самого селекта) должна увидеть добавленные/удаленные строки. Это и есть фантомное чтение, которое не обеспечивается repeatable read-ом.
Про dirty read / read uncommitted - абсолютно минорный момент как назвать ситуацию, что вы читаете незакоммиченные данные. Коммента достаточно, что я не общепринятый термин случайно сказал.
Спасибо, хорошее видео, но думаю, нужно больше примеров и обьяснений. Например, когда ты говоришь, что у селери большая разница в кол-ве строк с 995000 и 999900, то можно было бы сделать select с этим условием и показать, думаю станет намного наглядней В остальном видео супер, спасибо
Собесы по Го - это долбаный кринж. Да и Го сам по себе - это долбаный кринж. Если чуваки в Гугле решили, что можно взять и выкинуть в окно последние 25 лет компьютерсайнц, чтобы белые сахибы не отнимали работу у индусов - бог им судья. Нормальный человек к этому дурдому близко не подойдёт. По этому до сих пор существуют перловые монолиты, которые всякие хипстеры пытаются "распилить" на микросервисы, но как показывает прктика - безуспешно.
И все же не понятно почему count(id) from employee where sex = 'frmale' отработал на 4 секунды дольше после создания индекса по полю sex??? explain показывает seq scan в обоих случаях что без индекса, что с индексом. Но без индекса быстрее. ПОЧЕМУ? ЗЫ: я бы понял если в случае с индексом в explain был бы индекс (а не seq scan), тогда можно было предположить что увеличение по времени произошло из-за неселективной колонки sex. Но даже если бы индекс затормозил поиск из-за неселективности, подсчет бы все равно выполнился по индексу (т.к. он корректный - т.е. указан на верную колонку и не составной) и в explain были бы следы использования индекса. Можно было бы понять если бы индекс был составной с неправильным порядком колонок - тогда поиск по индексу не дал бы результатов и выполнился seq scan по итогу и как следствие увеличение времени из-за неэффективного индекса. НО ПОЧЕМУ ПРАВИЛЬНЫЙ НЕ СОСТАВНОЙ ИНДЕКС (пусть и на неселективной колонке) ТОРМОЗИТ ПРОЦЕСС, А ПОСЛЕ EXPLAIN выдает seq scan ВООБЩЕ НЕ ПОНЯТНО. По итогу метод поиска один и тот же, но индекс дал +4 сек.
