ну так в стектрейсе или дампе это было бы видно сразу, но их не дают
Ничего из предложенного мной не требует ни стектрейса, ни навыков программирования, ни даже пересылки данных при желании. Только пошаговые инструкции к исполнению.
В целом, как я и сказал: залогировать можно и нужно, но анализ обозначенной в статье проблемы не требует выездной бригады). Любой монитор ресурсов показал бы out of memory.
То, что у компании есть деньги на оплату выездной бригады и нет денег на настройку мониторинга ресурсов на железе - это оч интересно конечно)
Я вот на Rust не пишу, а вот на С++ пишу. И всё же у меня всегда возникает вопрос: а оно мне точно надо, этот кастомный deleter? Почти всегда это костыль.
Программа как минимум могла бы напечатать "Out of memory".
Или просто поможно было посмотреть в диспетчер задач, Process Monitor, Event Viewer, Performance Monitor, тысячи их. Без всякой выездной бригады. За неумение диагностировать проблемы приходится платить.
Да и толку особо нет. Я проверю, я молодец, а кто-нибудь из моих зависимостей - не проверит, опять упадём, что делать будем? Опять бригаду высылать?
P.S.
Вообще я всеми руками за то, чтобы всё проверять и писать сообщения об ошибках везде, где только можно. Включая malloc. Просто для malloc это имеет наименьший из всех смыслов.
P.P.S.
Вообще, при анализе проблем в закрытых системах, "выездные бригады" неизбежны. Я не видел еще никого, кто бы смог уйти от этого при работе над такими системами.
Не очень понятно зачем это было на хабр-то писать? Тот объём информации, что тут представлен гугл/GPT расскажет одним запросом. Открывая статью я ожидал увидеть какую-то глубину погружения хотя бы на уровень "смотрите как оно реализовано в коде GCC".
Для таких публикаций на хабре придуманы посты.
P.S.
Ваша картинка со стрелочками плоховата. По ней можно заключить будто об объект oth в move-конструкторе всегда умирает при выходе из move-конструктора.
Это справедливо для временных объектов, но в общем случае не является верным.
Для С++ это более чем возможно, т.к. в имени функции есть вся информация о типах. Вы всегда можете извлечь эту информацию с помощью любого доступного "де-манглера" (не знаю как demangling перевести корректно). Хоть бы и онлайн.
В многоуровневой поддержки есть одна очень большая проблема, которую непонятно как решать: кадры.
Посадить разработчика на поддержку можно только в качестве наказания. А для оказания действительно квалифицированной помощи нужен человек с экспертизой даже большей, чем рядовой разработчик, тут скорее нужен прям настоящий DevOps, если речь о сложной системе.
Представляете стоимость такой поддержки? Но даже не стоимость главное, главное то, что человек способный такие функции выполнять - никогда не пойдет заниматься такой ерундой, как поддержка.
Звучит занятно. Я не музыкант, конечно, но кривизна в уши бросается. Хотя ощущается она всё равно довольно "гармонично". Получается, что кривизна-то - художественная!
но решал только типовые задачи в большой команде с наличием рядом гуру, который всегда знал ответы на сложные вопросы, значит ли что он опытный?
Так всё просто: спросите у человека как у них был выстроен процесс разработки на предыдущем месте: откуда ему поступали задачи, как распределялись, как решались, как контролировался процесс исполениня, какие были методы по контролю качества работы.
Опытные люди без проблем хоть по шагам расскажут каждый пункт и ответят на уточняющие вопросы. Несамостоятельные люди крайне редко вникают в процессы и обычно сразу заваливаются тут.
нужно как-то объективно сравнивать кандидатов. А это важная часть процесса
Вы декларируете эту важность, но никак не обосновываете. Я не вижу никакого смысла в "общей линейке", я вижу смысл лишь в том, внушает ли кандидат доверие или нет. Излишняя субъективность отсекается коллегиальной оценкой.
это один и тот же вопрос для каждого кандидата?
Список "стартовых вопросов" для всех одинаковый. Дополнительные вопросы для рассуждения - ситуативны.
вы уверены что вопрос проверяет именно то что нужно?
Все мои вопросы так или иначе вытекают из кодовой базы на моём проекте. Да, есть ряд базовых скрининг-вопросов по самому базовому синтаксису языка (которые естественно используется в проекте), но в остальном вопросы так или иначе относятся к бизнес-части проекта.
Вам нужен лишний стресс от кандидата? А зачем?
Какой, простите, стресс? Человек общается с двумя людьми всегда. И видит только двух человек. Иногда может подключиться 1, максимум 2 человека, кандидат их не видит, не слышит и вообще никак не контактирует.
как вы считаете подсказки, если вы даже заранее не знаете в какую сторону пойдет разговор
Я - никак не считаю. Мы не размер черепной коробки по линейке измеряем, мы просто общаемся с человеком))) Как я и упомянул - финальная оценка - это просто согласие двух (редко - трёх) человек по части того, проходил ли кандидат или нет.
Субъективно - как бы да. Выбираем ли мы в итоге кандидата, который похож на нас нравится как человек, т.е. исходя из его личных качеств - ну, отчасти да. Мы же не робота в команду ищем, а человека, с которым будет комфортно работать и при этом он подходит технически. В чём проблема с этим подходом?
Я не заметил, а где вы код пишете? Не пишите?
Вы тут только что про стресс говорили, а теперь предлагается под пристальным взглядом заставлять человека писать код, решать какие-то замороченные задачки за полчаса, хотя на реальной работе у него НИКОГДА не будет таких задач. У нас никогда не бывает "почини за 30 минут, а я буду за спиной стоять". Нет у нас такой херни.
Вместо у это у нас есть небольшая задачка на кодревью, где кандидату предлагается просто взглянуть на код, найти ошибки и сказать/написать исправление в редакторе. Ведь подобная рутина и есть каждодневная задача программиста: смотреть на код, исправлять, дополнять. Иногда будут задачи по написанию чего-то "с нуля", но это "с нуля" всегда будет в рамках какой-то готовой архитектуры, так что здесь проблем нет.
"Собес ровно один, длится часа полтора максимум" - это очень мало, особенно в вашем стиле собеседования.
На чём основано ваше "очень мало"? Наша статистика говорит, что вполне норм, большинство нанятых людей проходят испытательный и успешно справляются с работой в дальшейнем. В моей команде проблем не было вообще ни разу. В других - ну, я могу припомнить только 2 случая за последние 5 лет.
Даже больше скажу, когда-то в компании были многоэтапные собеседования. В них просто не оказалось никакой нужды. Потому как определяющим всегда было техническое интервью, а все остальные "для галочки".
HR в курсе такого стиля и без кода? Если нет, то почему? Если да, то как результативность оценивается?
HR в курсе. Вышестоящее начальство в курсе. Вообще все в курсе. Жалоб не поступало. Результативность чего вы хотите знать?
Я пока не видел ни разу определение, что значит "думать".
Почему меня это должно волновать? :) Я знаю что значит "думать", мои коллеги знают, что значит "думать") Остальное меня мало волнует)
а значит это только ваше субъективное ощущение мало имеющее отношение к реальности.
Реальность нам дана в ощущениях))) Реальность субъективная) Но опять же - я не вижу ни одной причины, почему мне не должно быть пофигу? В конечном итоге, как я и сказал, я не роботов нанимаю "работу работать", а людей, с которыми буду взаимодействовать на ежедневной основе. Я не занимаюсь конвейерным наймом "куда-то там". Зачем мне в команде люди, которые мне субъективно не по душе?
Я оценку оставляю прежней "детский уровень"
Мне ваши рассуждения тоже кажутся подростково-идеалистическими. Так и живём)
Занятно то, что я за последние 5-6 лет не словил вообще ни одной проблемы при обновлениях.
С одной стороны, да - личный опыт нерелевантен. С другой - срок наблюдений довольно длинный, так что какая-то статистическая значимость у этих наблюдений имеется.
Я ни разу ничего не откатывал, ничего не падало, ничего не начинало тормозить.
Ну это прям детский уровень собеседования. Как вы кандидатов между собой сравниваете при таком подходе?
А какие тут проблемы? Если нужны чиселки, тот тут шкала крайней простая.
1. Ответил на вопрос и не утонул в ответах - ставим плюсик что в данной теме разбирается, молодец.
2. Не ответил: считаем количество данных подсказок на вопрос. Чем больше потребовалось, тем меньше условных баллов человек получает. Если не смог ответить вовсе и вообще думал не туда, ну тут да, ставим нолик за вопрос. Если думал куда надо, но всё равно не смог прийти к нужному ответу, ставим условную единичку: "думать умеет, но нужен наставник".
Дальше можно проссумировать и там посчитать какие-то объективные циферки, но у меня на проекте нет такого потока кандидатов, чтобы была необходимость в какой-то сложной процедуре. Типа собеседование в лучшем случае раз в неделю.
Финальная оценка у нас - это просто "коллегиальное субъективное". Собес ведут 2 человека, некоторые еще могут подключаться чисто послушать (без видео), но в собесе они не участвуют. По итогу оффер выкатывается только если все присутствующие согласны с тем, что кандидат подходит.
У нас нет никаких многоэтапных собесов. Собес ровно один, длится часа полтора максимум.
ХЗ. Я на собесах вообще не смотрю правильно ответил человек или неправильно.
Если человек говорит правильные слова, я лишь раскручиваю его на разговор, чтобы проверить, понимает ли он вообще то, о чем говорит или просто заучил ответ.
Если человек говорит что-то совершенно неправильное, я его останавливаю, говорю что он не прав, потом даю несколько дополнительных подсказок и смотрю сможет ли он прийти к правильному ответу самостоятельно, т.е. просто оцениваю сколько в целом нужно будет тратить время на вводные для человека, чтобы он решал задачи ответ на которые не знает.
Сам по себе ответ - вообще не важен.
Оставшийся кусок времени Team lead закрывает собесами. Команда живёт сама по себе
Печально, но да, так и есть. Но если вы думаете, что тимлиды сильно рады такому положению вещей - эт точно не так. Я не рад)
Опять же, если они такие большие, то зачем вообще нужна IT ипотека?
Для того, чтобы застройщики не разорились? Огромные площади жилья стоят невостребованными. Нужно влить бабла в отрасль. У кого есть бабло? У айтишников! Внезапно именно ипотека и есть показатель того, что в IT зарплаты больше. Ну и то, что нужны какие-то стимулы, чтобы привязать разработчиков территориально, не без этого.
Ничего из предложенного мной не требует ни стектрейса, ни навыков программирования, ни даже пересылки данных при желании. Только пошаговые инструкции к исполнению.
В целом, как я и сказал: залогировать можно и нужно, но анализ обозначенной в статье проблемы не требует выездной бригады). Любой монитор ресурсов показал бы out of memory.
То, что у компании есть деньги на оплату выездной бригады и нет денег на настройку мониторинга ресурсов на железе - это оч интересно конечно)
Это действительно так, но идеологически - это более правильно.
К слову, написать подобный универсальный Guard можно, но да, в стандартной библиотеке его нет, насколько я знаю.
Я вот на Rust не пишу, а вот на С++ пишу. И всё же у меня всегда возникает вопрос: а оно мне точно надо, этот кастомный deleter? Почти всегда это костыль.
Или просто поможно было посмотреть в диспетчер задач, Process Monitor, Event Viewer, Performance Monitor, тысячи их. Без всякой выездной бригады. За неумение диагностировать проблемы приходится платить.
Да и толку особо нет. Я проверю, я молодец, а кто-нибудь из моих зависимостей - не проверит, опять упадём, что делать будем? Опять бригаду высылать?
P.S.
Вообще я всеми руками за то, чтобы всё проверять и писать сообщения об ошибках везде, где только можно. Включая malloc. Просто для malloc это имеет наименьший из всех смыслов.
P.P.S.
Вообще, при анализе проблем в закрытых системах, "выездные бригады" неизбежны. Я не видел еще никого, кто бы смог уйти от этого при работе над такими системами.
Не очень понятно зачем это было на хабр-то писать? Тот объём информации, что тут представлен гугл/GPT расскажет одним запросом. Открывая статью я ожидал увидеть какую-то глубину погружения хотя бы на уровень "смотрите как оно реализовано в коде GCC".
Для таких публикаций на хабре придуманы посты.
P.S.
Ваша картинка со стрелочками плоховата. По ней можно заключить будто об объект oth в move-конструкторе всегда умирает при выходе из move-конструктора.
Это справедливо для временных объектов, но в общем случае не является верным.
@oktonion
Для С++ это более чем возможно, т.к. в имени функции есть вся информация о типах. Вы всегда можете извлечь эту информацию с помощью любого доступного "де-манглера" (не знаю как demangling перевести корректно). Хоть бы и онлайн.
http://demangler.com/
Но есть и локальные, c++filt например. Для Си, ясное дело, простого решения этой проблемы нет.
Не могу припомнить каких-то других киллер-фич у винды 11. Хотя признаться, я ей пользовался всего неделю, так что распробовать не успел.
Лол. Вообще, это единственная фича из W11, которой мне хватает в W10. И получается, что снова Microsoft делает всё, чтобы похоронить W11.
В многоуровневой поддержки есть одна очень большая проблема, которую непонятно как решать: кадры.
Посадить разработчика на поддержку можно только в качестве наказания. А для оказания действительно квалифицированной помощи нужен человек с экспертизой даже большей, чем рядовой разработчик, тут скорее нужен прям настоящий DevOps, если речь о сложной системе.
Представляете стоимость такой поддержки? Но даже не стоимость главное, главное то, что человек способный такие функции выполнять - никогда не пойдет заниматься такой ерундой, как поддержка.
Звучит занятно. Я не музыкант, конечно, но кривизна в уши бросается. Хотя ощущается она всё равно довольно "гармонично". Получается, что кривизна-то - художественная!
А у Генеральной прокуратуры и, прости господи, Роскомнадзора есть полномочия "снимать требования?".
Долго я не мог понять, почему печка идёт до нанесения тонера на бумагу, в потому понял, что кто-то очень добрый сделал схему справа-налево)
Ну, вы недооцениваете способности ChatGPT к парсингу криво поставленных задач.
Вот недавно как раз в комментариях проверял его возможности на этот счёт
https://habr.com/ru/companies/sberbank/articles/796181/comments/#comment_26554975
Так всё просто: спросите у человека как у них был выстроен процесс разработки на предыдущем месте: откуда ему поступали задачи, как распределялись, как решались, как контролировался процесс исполениня, какие были методы по контролю качества работы.
Опытные люди без проблем хоть по шагам расскажут каждый пункт и ответят на уточняющие вопросы. Несамостоятельные люди крайне редко вникают в процессы и обычно сразу заваливаются тут.
Вы декларируете эту важность, но никак не обосновываете. Я не вижу никакого смысла в "общей линейке", я вижу смысл лишь в том, внушает ли кандидат доверие или нет. Излишняя субъективность отсекается коллегиальной оценкой.
Список "стартовых вопросов" для всех одинаковый. Дополнительные вопросы для рассуждения - ситуативны.
Все мои вопросы так или иначе вытекают из кодовой базы на моём проекте. Да, есть ряд базовых скрининг-вопросов по самому базовому синтаксису языка (которые естественно используется в проекте), но в остальном вопросы так или иначе относятся к бизнес-части проекта.
Какой, простите, стресс? Человек общается с двумя людьми всегда. И видит только двух человек. Иногда может подключиться 1, максимум 2 человека, кандидат их не видит, не слышит и вообще никак не контактирует.
Я - никак не считаю. Мы не размер черепной коробки по линейке измеряем, мы просто общаемся с человеком))) Как я и упомянул - финальная оценка - это просто согласие двух (редко - трёх) человек по части того, проходил ли кандидат или нет.
Субъективно - как бы да. Выбираем ли мы в итоге кандидата, который похож на нас нравится как человек, т.е. исходя из его личных качеств - ну, отчасти да. Мы же не робота в команду ищем, а человека, с которым будет комфортно работать и при этом он подходит технически. В чём проблема с этим подходом?
Вы тут только что про стресс говорили, а теперь предлагается под пристальным взглядом заставлять человека писать код, решать какие-то замороченные задачки за полчаса, хотя на реальной работе у него НИКОГДА не будет таких задач. У нас никогда не бывает "почини за 30 минут, а я буду за спиной стоять". Нет у нас такой херни.
Вместо у это у нас есть небольшая задачка на кодревью, где кандидату предлагается просто взглянуть на код, найти ошибки и сказать/написать исправление в редакторе. Ведь подобная рутина и есть каждодневная задача программиста: смотреть на код, исправлять, дополнять. Иногда будут задачи по написанию чего-то "с нуля", но это "с нуля" всегда будет в рамках какой-то готовой архитектуры, так что здесь проблем нет.
На чём основано ваше "очень мало"? Наша статистика говорит, что вполне норм, большинство нанятых людей проходят испытательный и успешно справляются с работой в дальшейнем. В моей команде проблем не было вообще ни разу. В других - ну, я могу припомнить только 2 случая за последние 5 лет.
Даже больше скажу, когда-то в компании были многоэтапные собеседования. В них просто не оказалось никакой нужды. Потому как определяющим всегда было техническое интервью, а все остальные "для галочки".
HR в курсе. Вышестоящее начальство в курсе. Вообще все в курсе. Жалоб не поступало. Результативность чего вы хотите знать?
Почему меня это должно волновать? :) Я знаю что значит "думать", мои коллеги знают, что значит "думать") Остальное меня мало волнует)
Реальность нам дана в ощущениях))) Реальность субъективная) Но опять же - я не вижу ни одной причины, почему мне не должно быть пофигу? В конечном итоге, как я и сказал, я не роботов нанимаю "работу работать", а людей, с которыми буду взаимодействовать на ежедневной основе. Я не занимаюсь конвейерным наймом "куда-то там". Зачем мне в команде люди, которые мне субъективно не по душе?
Мне ваши рассуждения тоже кажутся подростково-идеалистическими. Так и живём)
Если не печатаешь в промышленных масштабах, есть подозрение, что вред здоровью будет очень тяжело нанести этими испарениями.
Занятно то, что я за последние 5-6 лет не словил вообще ни одной проблемы при обновлениях.
С одной стороны, да - личный опыт нерелевантен. С другой - срок наблюдений довольно длинный, так что какая-то статистическая значимость у этих наблюдений имеется.
Я ни разу ничего не откатывал, ничего не падало, ничего не начинало тормозить.
Да блин, если бы ко мне приходили на проект люди с патчами моих проблем - я бы только спасибо говорил и подарки всем на новый год им рассылал)
А какие тут проблемы? Если нужны чиселки, тот тут шкала крайней простая.
1. Ответил на вопрос и не утонул в ответах - ставим плюсик что в данной теме разбирается, молодец.
2. Не ответил: считаем количество данных подсказок на вопрос. Чем больше потребовалось, тем меньше условных баллов человек получает. Если не смог ответить вовсе и вообще думал не туда, ну тут да, ставим нолик за вопрос. Если думал куда надо, но всё равно не смог прийти к нужному ответу, ставим условную единичку: "думать умеет, но нужен наставник".
Дальше можно проссумировать и там посчитать какие-то объективные циферки, но у меня на проекте нет такого потока кандидатов, чтобы была необходимость в какой-то сложной процедуре. Типа собеседование в лучшем случае раз в неделю.
Финальная оценка у нас - это просто "коллегиальное субъективное". Собес ведут 2 человека, некоторые еще могут подключаться чисто послушать (без видео), но в собесе они не участвуют. По итогу оффер выкатывается только если все присутствующие согласны с тем, что кандидат подходит.
У нас нет никаких многоэтапных собесов. Собес ровно один, длится часа полтора максимум.
ХЗ. Я на собесах вообще не смотрю правильно ответил человек или неправильно.
Если человек говорит правильные слова, я лишь раскручиваю его на разговор, чтобы проверить, понимает ли он вообще то, о чем говорит или просто заучил ответ.
Если человек говорит что-то совершенно неправильное, я его останавливаю, говорю что он не прав, потом даю несколько дополнительных подсказок и смотрю сможет ли он прийти к правильному ответу самостоятельно, т.е. просто оцениваю сколько в целом нужно будет тратить время на вводные для человека, чтобы он решал задачи ответ на которые не знает.
Сам по себе ответ - вообще не важен.
Печально, но да, так и есть. Но если вы думаете, что тимлиды сильно рады такому положению вещей - эт точно не так. Я не рад)
Для того, чтобы застройщики не разорились? Огромные площади жилья стоят невостребованными. Нужно влить бабла в отрасль. У кого есть бабло? У айтишников! Внезапно именно ипотека и есть показатель того, что в IT зарплаты больше. Ну и то, что нужны какие-то стимулы, чтобы привязать разработчиков территориально, не без этого.