Search
Write a publication
Pull to refresh
20
0
Лохас Пименаускас @crashdumper

User

Send message
Да я и не отрицаю методу которую написал мичурин, я просто перед ней хочу поставить фильтр который отсеет низкоквалифицированных сотрудников прежде чем я начну выяснять насколько человек команден, насколько стрессоустойчив, как подходит к решению сложных задач и т.п. На хабре уже поднималась тема «врунов в резюме» — людей которые пишут заоблачные сказки в своих резюме и сколько необходимо времени потратить, чтобы всё выяснить.
Вот из недавнего опыта, пришел человек устраиваться на должность системного архитектора, я его решил просто послушать… он мне нарасказывал какие замечательные проекты он строил и какие сервера проектировал и взаимодейсвтия с каими базами данных делал. А потом он мне просто не ответил о том что такое транзакция и что такое управляемый код.
Подумайте, что бы он мне спроектировал? Сервер работающий с базой где одна операция затирает другую? Или план развертывания приложения где нить на голой инсталляции Win2003 где нет .NET Framework 3.5 (а сервер будет написан под него).
Упс, я имел в виду что 90%-ам даже не будем перезванивать. (а то мою фразу можно прочитать по другому)
Час о_О!!! Я не могу тратить столько времени на беседы с людьми, особенно учитывая что 90% из них даже не будут перезванивать.
Обычно задушевные беседы ведет у нас HR, я как руководитель не могу тратить столько времени, я должен выяснить уровень знаний претендента и то смогу ли я и остальные члены нашей команды с претендентом работать. На первое — я использую описаный в статье метод отсева, по остальному беседую только с теми кто остался и согласитесь, реальный профессионал легко пройдет тест описаный в статье. Здесь шанс пропустить «бриллиант» очень низок
Ну это скорее шутка по поводу профессиональной терминологии.
Это займет у вас очень много времени, а то что я предлагаю — это очень быстро.
Ещё раз напишу, я не пытаюсь заменить стандартные вопросы по определению предыдущего опыта работы, я стараюсь отсеять ненужных людей ещё до того как я полезу копать их прошлое. Всю рутину интервью вы можете оставить такой как есть, просто вствив вначале предлагаемый мной фильтр.
За такое надо пинать в первую очереть не отделы разработки а QA отделы, т.к. они такие продукты пускают в мир. Разработчик не может помнить обо всем на свете, но если над ним будет висеть домоклав меч тест кейса на проверку работы продукта на нестандартных разрешениях экрана, на нестандартных размерах штифтов, на нестандартных темах оформления — то он будет и GUI верстать правильно.
Да я не агитирую за использование WinDbg в качестве отладчика на каждый день. Каждий инструмент хорош для своего дела, например гайку можно открутить разводным ключем, накидным ключем, рожковым ключом, торцевым ключем, всё зависит от того что за гайка, как к ней подлезать и чем будет удобно работать. Я всем руками за, если мои программеры хорошо владеют отладчиком студии, WinDbg и Ida
Автору на заметку, где-то видел DIY создания лайткуба из пластиковых труб (для водоснабжения) по бюджету выходило дешево, лайткуб был складной и компактный. Вспомнил… в персональном блоге автора этой статьи habrahabr.ru/blogs/DIY/74537/#habracut, листаем вниз и находим там ссылку на его сайт, идем в раздел «Фототема» и ищем тему «Лайткуб своими руками».
Подход нормальный, но виндовая шара начинает жутко тормозить когда там большое кол-во файлов, здесь спасает трехуровневое хранилище. А доступ по http — это просто желание сделать всё как у «большого брата» из Редмонда :)
Вот-вот.
У меня был опыт расследования утечек хендлов при проведении определенной операции в программе, т.е. я смотрел кол-во хендлов, делал операцию, ещё раз смотрел кол-во хендлов и оно не совпадало. Обычным дебагером такое нельзя было расследовать, т.к. дело было в том что во время выполнения действия в процесс подгружалась Dll, хендлы текли в ней, по завершению действия Dll выгружалась и досвидания. только связка WinDbg + Microsoft Application Verifier помогла найти все стеки создания и удаления хендлов, данные были сопоставлены и выявлен модуль в котором утечка, модуль был выгружен, но это уже было делом техники найти от него pdb и выдрать данные (а-ля map файл)
Конечно это напоминает COM, тут и фабрика класса и реализация интерфейса на основании подсчета количества ссылок, но реально под задачу описанную в примере — подсчет ссылок не нужен. Нужен аналог С++ шаблона (извините, не помню есть ли такое в делфи — 100 лет в делфи не программил), т.е. некий класс который сам создаваясь на стеке создает экземпляр нужного нам объекта в куче. Когда первый объект вылетит из зоны видимости, он сам будет уничтожаться (он ведь в стеке) ну и в деструкторе должен потянуть за собой уничтожение объекта из кучи.

Подсчет ссылок нужен тогда, когда мы совсем отпускаем объект в свободное плавание, передаем его в разные функции, маршалим его между потоками и т.п. тут он уничтожается неявно когда становится не нужен. И тут возникает как раз проблема создания фабрики классов и автоматического удаления, чтобы и операция создания и операция удаления была сделана одним и тем же рантаймом.

Автору топика +1 за изобретательность.
Ещё вспомнил, формат минидампов вроде открытый и в сети можно найти его описание, а вот фуллдамп которы делает система при синем экране смерти — закрытый формат.
И вообще минидамп — это просто в удобной форме сделаная информация из *.map и *.cod файлов (посмотрите настройки проекта, там есть опции создания этих файлов, затем гляньте их содержимое, всё станет ясно)
Студия умеет отрывать дампы, но опять-же с сервером символов работает хуже.
Действительно, для отладки не очень хорош, чаще всего его используем для разбора дампов и удаленной отладки. Плюс — он лучше чем студия заточен на руботу с сервером символов, с различными тулзами типа Microsoft Application Verifier (для поиска утечек хендлов). Хотя я возможно уже что-то упастил ибо я на данный момент больше управленец чем прораммер.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered