Подскажите, пожалуйста, почему malloc возвращает "Ок" если в цикле гигабайты запрашивать, но не использовать? В какой-то итерации "выделено" будет даже больше, чем есть свободной RAM. ОС считает, что запрашиваемый кусок меньше, чем доступно в целом RAM и этого достаточно для положительного ответа программе?
Что произойдёт с т.зр. malloc, ОС, TLB при записи в такую область?
А если есть несколько ЦОДов. У каждого есть мастер. В оба мастера приходят запрос баланса и списания суммы, если баланса достаточно. Как синхронизировать мастера, чтобы не было двойного списания и в итоге в минус на счету не ушли?
Вы же наоборот ушли от докер фишки(обращение по имени контейнеров), чтобы в явном виде видеть сетевое взаимодействие сервисов указывая такие статические ip в конфигах сервисов.
Если так, то обоснование было бы:
"Для того, чтоб не терять понимания сетевого взаимодействия сервисов"?
Мне было интересно с точки зрения восприятия целостной картины. На других ресурсах, конечно, можно смотреть:
Более детальные разборы
Более правильные шаблоны
Более правильные применения
И это уже будут детали.
Думаю, что для общего впечатления пойдёт. И общее впечатление передаётся, по ощущением, нормально. Не уводит в сторону чем-то плохим(изложением, применением шаблонов).
Если принять мнение, что шаблоны не очень, тогда => вообще не воспринимать эту статью, книгу, подходы? Нет. Я воспринимаю, т.к. считаю, что там изложены принципы.
Рассказано про подход из 4 стадий по созданию системы. В книге каждая из предложенных систем строится в процессе прохождения по таким стадиям. Рассказано про формат общения. Про возможные вопросы. Про построение сначала общей картины. Это вполне резонно. Вполне укладывается в моё понимание возможного интервью. Вполне могут быть полезны такие подходы.
В общем, мне понравился стиль изложения. Самое плохое, что может случиться - это если супер углубиться в такой подход и воспроизводить по этим лекалам на настоящем интервью, а окажется, что оно идёт вообще не так. Что шаблоны вообще не такие. Тогда можно просто не пройти эту секцию, получить(этим самым, как минимум) обратную связь. И далее корректировать или отказаться от такого опыта вообще(и это тоже опыт).
А для вливания в эту тему вполне годный материал. Тем более, особо конкурирующих книг я не видел. Автор, по описанию, вполне опытный инженер. Так что пустого говорить не должен. Что-то, как минимум, должно быть релевантно.
То есть, худшее, что может случиться - потратить время в пустую. И то такого быть не может. Так как никто, как считаю, не даст универсального рецепта. Вот так, самообразованием, что-то пробуя и можно наработать знание, навык.
И если это не совсем то => всегда можно скорректировать. В любом случае, есть много материала. И для подготовки надо изучить много и с разных углов.
Хорошо, что книга позволяет понять, что такая подготовка и успешное прохождение интервью возможны. Возможно понять такую не простую тему. Не привычную для разработчика.
Книга своим понятным изложением воодушевляет. А это тоже много значит.
Спасибо за распечатку! Очень интересно! Знаю, что это труд - перевести выступление в хорошо форматированный материал. Как-то делал такое с видео "Top K problem" - https://www.youtube.com/watch?v=kx-XDoPjoHw
Требования кажутся очень серьезными. Согласен с мыслью в комментариях, что это уже уровень хорошего менеджера. Возможно, что-то взяли от product manager(разгрузив его роль).
На какую зп вилку может рассчитывать такой тимлид? К примеру, уровня average = 4 балла.
Насколько нужно ITшнику интересоваться политикой? То есть, для людей, которые смотрели за развитием мировой экономики, сменой технологических укладов и текущими напряженностями между странами, создаваемыми разными силами, то что случилось - возможный вариант развития событий. Он же не взялся из вакуума.
Или ITшник должен априори считать, что за него всё должно быть продумано во внешнем круге, чтобы он мог спокойной работать в своей зоне ответственности вообще не задумываясь над чем-то более, чем дом-работа-хобби-сон?
Спасибо! Обновил.
Принято, спасибо!
Получилось разобраться?)
Перед каждым собеседование перечитываю. Спасибо за ясное изложение)
Классная статья, спасибо!
Подскажите, пожалуйста, почему malloc возвращает "Ок" если в цикле гигабайты запрашивать, но не использовать? В какой-то итерации "выделено" будет даже больше, чем есть свободной RAM. ОС считает, что запрашиваемый кусок меньше, чем доступно в целом RAM и этого достаточно для положительного ответа программе?
Что произойдёт с т.зр. malloc, ОС, TLB при записи в такую область?
Вспомнилась статья "Что должен знать каждый программист о памяти". Там тоже был обход массива)
А если есть несколько ЦОДов. У каждого есть мастер. В оба мастера приходят запрос баланса и списания суммы, если баланса достаточно. Как синхронизировать мастера, чтобы не было двойного списания и в итоге в минус на счету не ушли?
Вы же наоборот ушли от докер фишки(обращение по имени контейнеров), чтобы в явном виде видеть сетевое взаимодействие сервисов указывая такие статические ip в конфигах сервисов.
Если так, то обоснование было бы:
"Для того, чтоб не терять понимания сетевого взаимодействия сервисов"?
Предложения:
1) Возвращать пользователю task_id при добавление задачи. Сейчас пользователь просто добавляет задачу и не знает её task_id.
2) Добавить выводимый результат в wait_result. Сейчас даём ссылкой переменную через аргумент функции. А можно и не готовить специально заранее переменную, а просто её получать. https://github.com/skprpi/Habr/blob/main/thread_pool/best_version.cpp#L109
Прочитали? Какое впечатление?)
Мне было интересно с точки зрения восприятия целостной картины. На других ресурсах, конечно, можно смотреть:
Более детальные разборы
Более правильные шаблоны
Более правильные применения
И это уже будут детали.
Думаю, что для общего впечатления пойдёт. И общее впечатление передаётся, по ощущением, нормально. Не уводит в сторону чем-то плохим(изложением, применением шаблонов).
Если принять мнение, что шаблоны не очень, тогда => вообще не воспринимать эту статью, книгу, подходы? Нет. Я воспринимаю, т.к. считаю, что там изложены принципы.
Рассказано про подход из 4 стадий по созданию системы. В книге каждая из предложенных систем строится в процессе прохождения по таким стадиям. Рассказано про формат общения. Про возможные вопросы. Про построение сначала общей картины.
Это вполне резонно. Вполне укладывается в моё понимание возможного интервью. Вполне могут быть полезны такие подходы.
В общем, мне понравился стиль изложения. Самое плохое, что может случиться - это если супер углубиться в такой подход и воспроизводить по этим лекалам на настоящем интервью, а окажется, что оно идёт вообще не так. Что шаблоны вообще не такие. Тогда можно просто не пройти эту секцию, получить(этим самым, как минимум) обратную связь. И далее корректировать или отказаться от такого опыта вообще(и это тоже опыт).
А для вливания в эту тему вполне годный материал. Тем более, особо конкурирующих книг я не видел. Автор, по описанию, вполне опытный инженер. Так что пустого говорить не должен. Что-то, как минимум, должно быть релевантно.
То есть, худшее, что может случиться - потратить время в пустую. И то такого быть не может. Так как никто, как считаю, не даст универсального рецепта. Вот так, самообразованием, что-то пробуя и можно наработать знание, навык.
И если это не совсем то => всегда можно скорректировать. В любом случае, есть много материала. И для подготовки надо изучить много и с разных углов.
Хорошо, что книга позволяет понять, что такая подготовка и успешное прохождение интервью возможны. Возможно понять такую не простую тему. Не привычную для разработчика.
Книга своим понятным изложением воодушевляет. А это тоже много значит.
Спасибо за распечатку! Очень интересно! Знаю, что это труд - перевести выступление в хорошо форматированный материал. Как-то делал такое с видео "Top K problem" - https://www.youtube.com/watch?v=kx-XDoPjoHw
https://docs.google.com/document/d/1lgRnUI3nWEICQgKDmACP1pvHo3EM0K6Pc6HPRbDtnTA/edit?usp=sharing
Конечно, спасибо Александру. Как-то собеседовался в его компанию. Очень понравилось общение. Интересные вопросы, вместе рассуждали.
Требования кажутся очень серьезными. Согласен с мыслью в комментариях, что это уже уровень хорошего менеджера. Возможно, что-то взяли от product manager(разгрузив его роль).
На какую зп вилку может рассчитывать такой тимлид? К примеру, уровня average = 4 балла.
Если не брать публикуемую статистику, сколько конкретно твоих знакомых уехало, сколько осталось?
Из моих где-то 10ти не уехал никто. Так что у меня статистика - 0%.
И стандартная полуобнаженка для привлечения внимания:
1) Оголенное плечо
2) Взгляд из-за плеча - мы тут с тобой одни, у нас что-то намечается
3) Приоткрытые губы
4) Трогает своё тело
Насколько нужно ITшнику интересоваться политикой? То есть, для людей, которые смотрели за развитием мировой экономики, сменой технологических укладов и текущими напряженностями между странами, создаваемыми разными силами, то что случилось - возможный вариант развития событий. Он же не взялся из вакуума.
Или ITшник должен априори считать, что за него всё должно быть продумано во внешнем круге, чтобы он мог спокойной работать в своей зоне ответственности вообще не задумываясь над чем-то более, чем дом-работа-хобби-сон?