Красавчик, на глазах скилл растет, как в съемке, так и в программировании, очень хорошее видео, много очень полезных нюансов, и в глубь не лез, и в то же время не по верхам👍 P.S. только стоит немножко разобраться с блокировками БД: 1) optiistic locks - это row versioning и последующая проверка версии при попытке коммита - она часто реализуется прямо на уровне приложения 2) pessimistic locks как раз те, о которых ты перед этим говорил, только их вообще больше: - shared: S(for rows, pages and tables), - exclusive: X(for rows, pages and tables), - update: U(for rows and pages only) - она для предотвращения простых deadlocks - и три intent locks: IS, IX, SIX(for tables only) - они блокируют нижестоящий в иерархии ресурс (это позволяет осуществить проверку такой блокировки перед осуществлением и предотвратить преждевременную блокировку более высокого уровня) Они осуществляются на уровне БД, и DB Engine сам решает какую применить в той или иной транзакции, если явно не указано иное
1) версионирование не единственный механизм, самый базовый механизм, это когда фремворк содержит два экземпляра строки таблицы из БД, один для правки, второй неизменный, при сохранении выполняется блокировка, далее проверяется равенство всех полей неизменной строки и строки в БД, если значения в полях совпадают, то выполняется update, если не совпадают, то выбрасывается ошибка.
2) механизмы блокирования и оптимистическая/пессимистическая блокировка это совершенно разные вещи, пессимистическая блокировка - ресурс блокируется для изменений сразу, как только пользователь его запросил (предполагается, что пользователь будет его изменять), оптимистическая - пользователь запросил ресурс, что-то с ним поделал и только непосредственно в момент попытки сохранить сделанные изменения ресурс блокируется. Что касается режимов и уровней блокировки, говорить о них в отрыве от конкретной РСУБД бессмысленно, глобально РСУБД подразделяются на два вида - блокировочники и версионники, в первом варианте читатели блокируют писателей, во втором нет, в версионниках эксклюзивная блокировка не означает, что данные нельзя читать и еще очень много нюансов))
@@DenisNovyshух ты, неплохо) судя по комменту, его писал опытный программист, плотно работающий с компанией Oracle, но в целом дельные замечания кстати, спасибо. Нечасто люди такой квалификации встречаются на просторах UA-cam, да и еще под таким видео) Мое почтение)
Есть такой нюанс/проблема у разных интервьюеров: они сопоставляют определённые знания и уровень разработчика отталкиваясь не от бэкграунда и опыта человека, а от того, что по их мнению нужно знать. И в этом видео полно таких примеров. Хотя в самом начале у нас есть оговорка, что конкретных требований нет, но нужно прощупать кандидата, тем не менее, начинается с исследования знаний о базах данных. Приведу просто в пример себя: я довольно опытный разработчик в областях секьюрности и интеграции. У меня за мой опыт есть лишь какой-то минимальный контакт с персистентностью. Все мои знания в этом вопросе отсылают скорее к периоду учёбы в университете, который я закончил 10 лет назад. Я бы с радостью поговорил бы про транзакциональность в процессах интеграции, если бы мы развили эту тему. Но, скорее всего вы сделаете свои выводы на основе вопросов по БД) Мой опыт собеседований, показывает, что именно так и бывает.
Яростно плюсую! есть еще такой нюанс, что обычно на проекте есть какой-то стек и он едва ли кардинально меняется, а проектом в принципе нормально и больше года заниматься одним (если только не скакать по компаниям каждые несколько месяцев). В итоге прямо в моменте человек в норме хорошо помнит только какой-то конкретный кусок из всех знаний, которыми в принципе как-то владеет. Возможно на каком-то проекте приходится плотно и долго со свагером\опенапи работать, а не с базами данных, или там с секьюрити и докером возиться и подобное. Да даже те же паттерны не то чтоб надо каждый день активно перебирать. А на собесах спрашивают про все подряд. Собеседующих впрочем тоже понимаю - проверять же народ как-то надо, не за красивые наклейки на ноутах же брать народ...
Было бы ещё хорошо услышать когда идёт речь о шаблонах не только про решение. Но и про проблему которую решает этот шаблон. Просто про ивент сорсинг я услышал только решение.
28:10 это очень распространенное заблуждение. На самом деле volatile: 1) обеспечивает атомарность для long/double (остальные примитивы атомарны и без volatile). Дело в том что long и double занимают 64 бита в памяти и процессору при записи или чтении необходимо выполнить две операции по 32 бита, сначала для lower 32 bits, потом для upper 32 bits. 2) предотвращает переупорядычевание на уровне компилятора. Когда поток записывает volatile переменную, все операции, предшествующие записи этой переменной в коде, также будут завершены до записи (барьер записи). И аналогично, при чтении из volatile переменной все операции, следующие за чтением, будут выполнены после фактического чтения (барьер чтения). volatile НЕ ОБЕСПЕЧИВАЕТ когерентнгость кэшей процессора - эта задача решается на уровне железа, а не ОС или JVM. Кстати, для многоядерных систем обеспечение когерентности может потреблять до 20% от всей энергии расходуемой процессором. 28:50 "что будет если применить volatile к объекту" - тут нужно уточнить, не к объекту, а к ссылке на объект. Ничего не будет, чтение/запись ссылки на объект - это сама по себе атомарная операция. Так что никакой разницы (из-за наличия или отсутствия volatile у ссылочный переменной) при работе с объектом мы не получим.
Вот бы ещё пояснение, как с query plan работать. Я один раз сказал, что для исследования неэффективного запроса надо смотреть план, а когда мне его тут же предоставили, я обосрался.
@@TheDiablo461 Для начала нужно понимать, что все єто зависит от конкретной БД(Mysql, oracle.....). Минимально - у каждого єлемента плана есть свой вес, также в плане можно посмотреть какой вид(бьістрьій-медленньій) чтения/поиска таблицьі/индекса используется, каким образом связьіваютсяя єти данньіе, сортируются и т.д. и т.п. Ну и не стоит забьівать про такие вещи как Hints, про факт того, что после прослойки jdbc оптимизатором может сформироваться абсолютно другой запрос, про сбор статитстики в БД(когда и зачем) и возможно сбор єтой статистики значительно повлияет на скорость работьі базьі/запроса. Помимо єтого может стоит снять отчет о работе непосредственно с самой БД в которой указаньі кол-во чтений/записей на диск/память, в какой момент происходит проблема, насколько загружен процессор и чем.... В общем и целом єто работа DBA, но нужно знать, что такие ньюансьі существуют.
10:00 Есть еще Double Update Anomaly, когда одно и то же обновление применяется дважды к одной и той же строке из-за повторного выполнения транзакции Пример: Транзакция A увеличивает значение столбца на 1. Транзакция A завершается с ошибкой и автоматически повторяется. Значение столбца увеличивается на 2 вместо 1.
Макс, можешь поподробнее о volatile? Встречал на одном курсе информацию, что не в кэше дело, т.к. процессор построен так, что кэш распространяется между потоками, и volatile это high-level абстракция, не имеющяя отношение к низкоуровневому управлению кэшем и процессором. А проблема в том, что компилятор не знает о том, что ресурс задействован в нескольких потоках, поэтому во время компиляции в байткод, происходит оптимизация кода, и volatile гарантирут ПОСЛЕДОВАТЕЛЬНОСТЬ выполнения кода, согласно тому, как этот код написан программистом, и не позваляет компилятору его оптимизировать так, что теряется каждоразовая проверка состояния ресурса (на пример while(sharedObject) {} оптимизируется компилятором так, чтобы проверка состояния sharedObject была только один раз, и не повторялась каждый раз во время петли). А везде только информация о кэше... Что думаешь на этот счёт?
Важные аспекты Mono и Flux, которые ответят на вопрос работал ли человек с реактивщиной: какой тип publisher является Mono и Flux (hot or cold), сколько елементов оборачивается во Flux?
Тут важно отменить про джунов то, что лишь немногие могут чем-то похвастаться, (но они день-ночь развиваются и сильно потеют), что на счёт всех остальных - почти ничего не знают или вообще не знают.
Патерни це про досвід, не про памʼять А ось лайфкодінг це інше. Тут пройшов не пройшов залежить від компанії. Як на мене, то ЛайфКодінг потрібен лише для виявлення навичок з вирішення завдань. Але усе пізнається в поповненні
Вот так смотришь все такие подобные видосы, улучшаешь мнение о своих навыках, даже можно сказать избавляешься от синдрома самозванца, а потом приходишь на какой-нибудь собес и там тебе сообщают, что ты даже не пол джуна, не то что не синьор, потому что не выучил еще наизусть за 10+ лет работы названия классов в каком-нибудь пакете или там не распарсил с листочка какой-нибудь вопрос с подвохом, где в листинге точку с точкой запятой специально спутали 😆
Попытка в эмоции которые мешают восприятию материала. Зачем так делаешь? Уровень звука сильно скачет, тяжело слушать. Есть такая штука в подаче материала называется "ПАУЗА". Если сделать твое видео потише то это будет одно сплошное часовое бормотание на повышенной скорости.
Красавчик, на глазах скилл растет, как в съемке, так и в программировании, очень хорошее видео, много очень полезных нюансов, и в глубь не лез, и в то же время не по верхам👍
P.S. только стоит немножко разобраться с блокировками БД:
1) optiistic locks - это row versioning и последующая проверка версии при попытке коммита - она часто реализуется прямо на уровне приложения
2) pessimistic locks как раз те, о которых ты перед этим говорил, только их вообще больше:
- shared: S(for rows, pages and tables),
- exclusive: X(for rows, pages and tables),
- update: U(for rows and pages only) - она для предотвращения простых deadlocks
- и три intent locks: IS, IX, SIX(for tables only) - они блокируют нижестоящий в иерархии ресурс (это позволяет осуществить проверку такой блокировки перед осуществлением и предотвратить преждевременную блокировку более высокого уровня)
Они осуществляются на уровне БД, и DB Engine сам решает какую применить в той или иной транзакции, если явно не указано иное
1) версионирование не единственный механизм, самый базовый механизм, это когда фремворк содержит два экземпляра строки таблицы из БД, один для правки, второй неизменный, при сохранении выполняется блокировка, далее проверяется равенство всех полей неизменной строки и строки в БД, если значения в полях совпадают, то выполняется update, если не совпадают, то выбрасывается ошибка.
2) механизмы блокирования и оптимистическая/пессимистическая блокировка это совершенно разные вещи, пессимистическая блокировка - ресурс блокируется для изменений сразу, как только пользователь его запросил (предполагается, что пользователь будет его изменять), оптимистическая - пользователь запросил ресурс, что-то с ним поделал и только непосредственно в момент попытки сохранить сделанные изменения ресурс блокируется.
Что касается режимов и уровней блокировки, говорить о них в отрыве от конкретной РСУБД бессмысленно, глобально РСУБД подразделяются на два вида - блокировочники и версионники, в первом варианте читатели блокируют писателей, во втором нет, в версионниках эксклюзивная блокировка не означает, что данные нельзя читать и еще очень много нюансов))
Спасибо, за подробное объяснение. Я тоже заметил, что в видео все блокировки в кучу свалили, так же как и дополнительные аномалии транзакций.
@@DenisNovyshух ты, неплохо) судя по комменту, его писал опытный программист, плотно работающий с компанией Oracle, но в целом дельные замечания кстати, спасибо. Нечасто люди такой квалификации встречаются на просторах UA-cam, да и еще под таким видео) Мое почтение)
Есть такой нюанс/проблема у разных интервьюеров: они сопоставляют определённые знания и уровень разработчика отталкиваясь не от бэкграунда и опыта человека, а от того, что по их мнению нужно знать. И в этом видео полно таких примеров.
Хотя в самом начале у нас есть оговорка, что конкретных требований нет, но нужно прощупать кандидата, тем не менее, начинается с исследования знаний о базах данных.
Приведу просто в пример себя: я довольно опытный разработчик в областях секьюрности и интеграции. У меня за мой опыт есть лишь какой-то минимальный контакт с персистентностью. Все мои знания в этом вопросе отсылают скорее к периоду учёбы в университете, который я закончил 10 лет назад.
Я бы с радостью поговорил бы про транзакциональность в процессах интеграции, если бы мы развили эту тему. Но, скорее всего вы сделаете свои выводы на основе вопросов по БД) Мой опыт собеседований, показывает, что именно так и бывает.
Яростно плюсую! есть еще такой нюанс, что обычно на проекте есть какой-то стек и он едва ли кардинально меняется, а проектом в принципе нормально и больше года заниматься одним (если только не скакать по компаниям каждые несколько месяцев). В итоге прямо в моменте человек в норме хорошо помнит только какой-то конкретный кусок из всех знаний, которыми в принципе как-то владеет. Возможно на каком-то проекте приходится плотно и долго со свагером\опенапи работать, а не с базами данных, или там с секьюрити и докером возиться и подобное. Да даже те же паттерны не то чтоб надо каждый день активно перебирать. А на собесах спрашивают про все подряд. Собеседующих впрочем тоже понимаю - проверять же народ как-то надо, не за красивые наклейки на ноутах же брать народ...
Стратегию можно мапой со спрингом удобно делать, в таком случае не нужно if else городить
Любой ассоциативный массив 🤷♂
Вопросы для Джуниор в 2023 году))
На стажера в 2024)
Что вы несёте
испугался?
@@ЛосАнжелес-х4ш
Даже не на интерна)
На пользователя it-продукта в 2025.
Таймзоны меняются на 15 минут? Очень интересно:)))
+ за вопросы и ++ за Lineage - эх времена были:)
Вот так я и попала на проект с AWS AppSync, блин 😂😂😂
А за видео как всегда лайк
Мне кажется нельзя запустить несколько имейджей в одном контейнере, скорее написать докер файл в котором будут и база данных и все сервисы
Отлично затронули тему Docker'a и вопросов по нему. Было бы круто посветить отдельный видос с разобором вопросов и ответов👍
Docker*
Было бы ещё хорошо услышать когда идёт речь о шаблонах не только про решение. Но и про проблему которую решает этот шаблон. Просто про ивент сорсинг я услышал только решение.
28:10 это очень распространенное заблуждение. На самом деле volatile:
1) обеспечивает атомарность для long/double (остальные примитивы атомарны и без volatile). Дело в том что long и double занимают 64 бита в памяти и процессору при записи или чтении необходимо выполнить две операции по 32 бита, сначала для lower 32 bits, потом для upper 32 bits.
2) предотвращает переупорядычевание на уровне компилятора. Когда поток записывает volatile переменную, все операции, предшествующие записи этой переменной в коде, также будут завершены до записи (барьер записи). И аналогично, при чтении из volatile переменной все операции, следующие за чтением, будут выполнены после фактического чтения (барьер чтения).
volatile НЕ ОБЕСПЕЧИВАЕТ когерентнгость кэшей процессора - эта задача решается на уровне железа, а не ОС или JVM. Кстати, для многоядерных систем обеспечение когерентности может потреблять до 20% от всей энергии расходуемой процессором.
28:50 "что будет если применить volatile к объекту" - тут нужно уточнить, не к объекту, а к ссылке на объект. Ничего не будет, чтение/запись ссылки на объект - это сама по себе атомарная операция. Так что никакой разницы (из-за наличия или отсутствия volatile у ссылочный переменной) при работе с объектом мы не получим.
Супер! Побольше такого контента! ❤
Вот бы ещё пояснение, как с query plan работать. Я один раз сказал, что для исследования неэффективного запроса надо смотреть план, а когда мне его тут же предоставили, я обосрался.
😆 Бывает)
Ну вот вопрос который задавал выше, что не так с запросом escape analyse и смотреть сколько шагов сделал каждый запрос?
@@TheDiablo461 Для начала нужно понимать, что все єто зависит от конкретной БД(Mysql, oracle.....). Минимально - у каждого єлемента плана есть свой вес, также в плане можно посмотреть какой вид(бьістрьій-медленньій) чтения/поиска таблицьі/индекса используется, каким образом связьіваютсяя єти данньіе, сортируются и т.д. и т.п. Ну и не стоит забьівать про такие вещи как Hints, про факт того, что после прослойки jdbc оптимизатором может сформироваться абсолютно другой запрос, про сбор статитстики в БД(когда и зачем) и возможно сбор єтой статистики значительно повлияет на скорость работьі базьі/запроса. Помимо єтого может стоит снять отчет о работе непосредственно с самой БД в которой указаньі кол-во чтений/записей на диск/память, в какой момент происходит проблема, насколько загружен процессор и чем.... В общем и целом єто работа DBA, но нужно знать, что такие ньюансьі существуют.
обычно надо смотреть чтобы запрос шёл по индексам и не делал фул сканов таблиц, ну и смотреть потребляемые ресурсы
32:30 так какая коллекция в итоге подходящая когда много записей?
10:00 Есть еще Double Update Anomaly, когда одно и то же обновление применяется дважды к одной и той же строке из-за повторного выполнения транзакции
Пример:
Транзакция A увеличивает значение столбца на 1.
Транзакция A завершается с ошибкой и автоматически повторяется.
Значение столбца увеличивается на 2 вместо 1.
Макс, можешь поподробнее о volatile? Встречал на одном курсе информацию, что не в кэше дело, т.к. процессор построен так, что кэш распространяется между потоками, и volatile это high-level абстракция, не имеющяя отношение к низкоуровневому управлению кэшем и процессором. А проблема в том, что компилятор не знает о том, что ресурс задействован в нескольких потоках, поэтому во время компиляции в байткод, происходит оптимизация кода, и volatile гарантирут ПОСЛЕДОВАТЕЛЬНОСТЬ выполнения кода, согласно тому, как этот код написан программистом, и не позваляет компилятору его оптимизировать так, что теряется каждоразовая проверка состояния ресурса (на пример while(sharedObject) {} оптимизируется компилятором так, чтобы проверка состояния sharedObject была только один раз, и не повторялась каждый раз во время петли). А везде только информация о кэше... Что думаешь на этот счёт?
вау, интересно
Спасибо Макс!
А что не так с escape analyse в первом вопросе?
Класс, спасибо!
Важные аспекты Mono и Flux, которые ответят на вопрос работал ли человек с реактивщиной: какой тип publisher является Mono и Flux (hot or cold), сколько елементов оборачивается во Flux?
Огнищеееее
Оставил свой самый крутой комментарий)
Спасибо
lost update это нестандартная?))
Смотря под каким углом смотреть 😏
Лично для меня базовая
Тут важно отменить про джунов то, что лишь немногие могут чем-то похвастаться, (но они день-ночь развиваются и сильно потеют), что на счёт всех остальных - почти ничего не знают или вообще не знают.
так надоела эта гнусная документация для хардкорщиков , посмотрюка зодорного Макса!
Сливаемся и сливаемся)
Почти всё хорошо, но слишком много воды и абстрактых примеров/рассуждений, которое отводят внимание от вопроса
Мой Like #1000
1.Если не прошел live coding єто отказ на продолжение?
2. Скільки не вчив і не переписував Патерни не можу запам'ятати
Патерни це про досвід, не про памʼять
А ось лайфкодінг це інше. Тут пройшов не пройшов залежить від компанії. Як на мене, то ЛайфКодінг потрібен лише для виявлення навичок з вирішення завдань. Але усе пізнається в поповненні
@@Jetbulb як прокачати навички з вирішення задач на проекті?
@@caffeinejavacode1475просити вирішувати проблеми у проекті 🙃.
Зазвичай це входить в твої обов'язки)) Тобто просто працювати і прокачувати
Вот так смотришь все такие подобные видосы, улучшаешь мнение о своих навыках, даже можно сказать избавляешься от синдрома самозванца, а потом приходишь на какой-нибудь собес и там тебе сообщают, что ты даже не пол джуна, не то что не синьор, потому что не выучил еще наизусть за 10+ лет работы названия классов в каком-нибудь пакете или там не распарсил с листочка какой-нибудь вопрос с подвохом, где в листинге точку с точкой запятой специально спутали 😆
Deisgn patterns best book for Java -> "Effective Java" by Addison Wesley
thanks
Як вчасно, завтра співбесіда на мідл позицію, дякую за контент
Аналогичино, сейчас готовлюсь к собесам на мидла. Хорошее видео.
🇺🇦🇺🇦🇺🇦
Тільки вперед 🇺🇦
прошел?
@@u_n_d_e_r_s_c_o_r_e_d Та співбесіда відмінилась, але минулого тижня була інша і я отримав оффер)
очень affordable
Русский военный корабль в левом верхнем углу. 🤣
лайк за Spell SInger )
Еще очень стремное в видео - это частая смена ракурса, то рожа на пол экрана, то на 1/8, это бесит, это очень стремно.
Попытка в эмоции которые мешают восприятию материала. Зачем так делаешь? Уровень звука сильно скачет, тяжело слушать. Есть такая штука в подаче материала называется "ПАУЗА". Если сделать твое видео потише то это будет одно сплошное часовое бормотание на повышенной скорости.