Здравствуйте, Begemot_, Вы писали:
B_>Здравствуйте, samius, Вы писали:
B_>>>ну это зависит от логики приложения В блокирующей очереди нужен иначе работать не будет. S>>Объясните плиз, зачем вы используете Pulse-ы и Wait-ы таким образом?
B_>Это блокирующая очередь, она работает следующим образом B_>1. Первый поток производитель что-то делает, и добавляет задания в очередь используя Add() B_>2. Второй поток потребитель — берет задания из очереди и обрабатывает их.
B_>При этом B_>1. если потребитель пытается что-то добавить задачу в очередь которая уже полная (количество задач == максимально разрешенному), то очередь блокирует его выполнение до тех пор, пока потребитель не освободит место в очереди B_>2. если потребитель, работает быстрее производителя, и пытается взять задачу из пустой очереди, очередь блокирует выполнение производителя до тех пор пока потребитель не добавит задачу.
S>А IsAddingCompleted не нужно ли сделать volatile?
не готов ответить, никогда серьёзно с потоками не работал, можно сказать первый опыт многопоточного программирования. Про volatile конечно читал пару раз, когда попадалась информация, но не четкого понимания что она делает, а сейчас я не в том состоянии что бы разбираться
Здравствуйте, Begemot_, Вы писали:
B_>Здравствуйте, samius, Вы писали:
S>>А IsAddingCompleted не нужно ли сделать volatile? B_>не готов ответить, никогда серьёзно с потоками не работал, можно сказать первый опыт многопоточного программирования. Про volatile конечно читал пару раз, когда попадалась информация, но не четкого понимания что она делает, а сейчас я не в том состоянии что бы разбираться
Ок, принято. Подозрительно что оно устанавливается внутри lock, опрашивается в том числе вне lock и имеет protected доступ на запись, причем _locker в наследниках не доступен.
Здравствуйте, GGoga, Вы писали:
GG>Здравствуйте, vmpire, Вы писали:
V>>Вот с этим утверждением я бы поспорил. V>>Наша контора несколько лет назад отказалась от тестовых заданий, о чём я давно жалею. V>>Тестовым заданием на раз отсекаются пионеры-теоретики, которые где-то что-то слышали, но как применять не знают. В конце концов, человек-то берётся код писать, а не про ООП рассказывать. Рассказывать-то мнегие мастера.
V>>Я бы тестовое задание давал. И сам я такие делал, когда искад работу. V>>Конечно, тестовое задание не должно быть на какие-то специальные знания, только если эти знания составляют обязательные требования. V>>Но вот когда человек, декларирующий хорошее знание SQL не может в уме вычислить результаты простого држойна — это настораживает.
GG>Ок, тогда могу ли я, в ответ на просьбу о написании тестового задания, попросить аванс, чтобы проверить платежеспособность работодателя? Да на такой вопрос работодатель "обезумеет от наглости" соискателя.
Аналогия весёлая, но, к сожалению, неверная. Почему — см. дальше.
GG>А то получается, что в процессе найма только одна тестируемая сторона — соискатель. А то, что работодатель может быть "г...ном" всегда умалчивается.
Ваша логическая ошибка в том, что вы предполагаете, что при найме отношения работник-работодатель симметричные, а это не так:
То, что "работодатель может быть "г...ном" не умалчивается, и в ряде случаев это так и есть.
Но обычно работодатель без расширения штата может прожить гораздо дольше и комфортнее, чем человек без работы. Поэтому работодатель и может себе позволить такие вольности.
С другой стороны, даже если предположить симметричность отношений, "тестирование" вполне может быть и двухсторонним. Не так сложно узнать, есть ли у работодателя финансовые проблемы. Просто для этого не нужно тестовое задание, достаточно прочитать отзывы о нём или спросить его текущих работников.
GG>Куча фирм ищут сотрудников без тестовых заданий и как-то себе выживают и даже деньги зарабатывают. Т.е. получается, что им удается отсеивать плохих кандидатов.
...И в куче фирм в результате работают толпы идиотов, которых приходится вытягивать более опытным сотрудникам.
Это вообще не аргумент. Как минимум потому, что не учтено сколько фирм заглохло из за профнепригодности персонала.
GG>Мне лично все равно, кто и как относится к тестовым заданиям. Я просто даже не пойду на собеседование в фирму, которая просит выполнить такое задание (да, фирмы мечты у меня нет, а на нынешнем рынке труда многие платят одинаковые деньги),
Это ваше право, которого у вас никто не отнимает. Если отсутствие тестового задания для вас критерий адекватности фирмы — можете смело отсеивать такие фирмы.
GG>потому что под "всего лишь 2 часами потраченного времени" прячется 2 реальных дня, потому что если напишешь за те же 2 часа получишь — "вот здесь можно было бы написать так, сделать еще то-то и то-то, да дописать такое-то", спросив, что этого не было в требованиях — "ну это само по себе подразумевалось..." — занавес...
Это вопрос адекватности оценивающих результаты. Хотя, тоже имеет право на существование. Например, если вы устраиваютесь на фирму, которая занимается передовыми разработками многопоточной обработки, то корректная реализация многопоточности может вполне подразумеваться.
GG>Почитайте данный форум и найдете кучу тем, где кандидат (ТС не исключение) написал тестовое задание, а его не взяли. Он выставил его здесь "напоказ", а оказывается, что и придраться то не к чему, кроме небольшого отступа и открывающейся фигурной скобки на на отдельной строчке.
Опять же вопрос адекватности проверяющих. Но тут есть ещё один нюанс, почему так может происходить, если хотите, расскажу, как проверка тестового задания выглядит изнутри и почему хорошее тестовое задание может быть "не принято"
GG>Все имхо, но мое отношение к тестам — резко отрицательное. Нервы и личное время дороже и можно вполне устроиться без оного.
Я бы давал тестовые задания только в том случае, если проверять их буду тоже я
Кстати, одна из причин отказа нашей фирмы от тестовых заданий как раз в том, что многие не хотят его делать.
Но есть и обратная сторона: без тестового задания сильно увеличивается поток левых людей.
Вот не далее как на этой неделе искал человека в команду. Типичное резюме: образование высшее но не профильное, 25 лет, опыт работы по спецальности 2 года программистом в не программерской конторе, позиционирует себя как ведущего программиста, хочет 80000 рублей (Питерские цены). А на тестовом задании он бы сразу отсеялся.
Кстати, есть мысль: давать тестовое задание, но с автоматической его проверкой. Как бы вы к этому отнеслись?
Здравствуйте, Begemot_, Вы писали:
B_>Из того что я вижу тут не try C#, это неиспользование var для локальных переменных, а явное указание типа. Решарпер настойчиво предлагал их использовать, но я не согласился. Что еще тут не так?
#define TestBegBlockedQueue1 и #if TestBegBlockedQueue1 скорее всего. Все-таки тесты
для роботов (continuous integration) создаются в первую очередь, а подобные конструкции
требуют человеческого вмешательства. Уж если есть две реализации, то и тест-классов
должно быть два.
Здравствуйте, vmpire, Вы писали:
V> Но тут есть ещё один нюанс, почему так может происходить, если хотите, расскажу, как проверка тестового задания выглядит изнутри и почему хорошее тестовое задание может быть "не принято"
Мне интересно было бы послушать, я первый раз делаю тестовое задание, как-то раньше не приходилось. А в будущем еще буду думаю, так что интересно послушать как оно с другой стороны...
BB>#define TestBegBlockedQueue1 и #if TestBegBlockedQueue1 скорее всего. Все-таки тесты BB>для роботов (continuous integration) создаются в первую очередь, а подобные конструкции BB>требуют человеческого вмешательства. Уж если есть две реализации, то и тест-классов BB>должно быть два.
ну тут немножко не так все. Все таки это тестовое задание и никакой continuous integration тут не будет. К тому же первая реализация, была просто пустым классом наследником стандартного класса — скорее шуткой, и тестировать ее точно не надо, разве что проверить работу тестов. Тестировать надо только вторую — так что частое человеческое вмешательство не предполагается. Можно было конечно разнести на два класса простым копи\пейстом, но было важно что бы вторая реализация проходила именно те тесты которые прошли на первой, поэтому сделал одну базу кода с переключением, что бы при правке тестов не пришлось править одинаковый код в двух местах.
Здравствуйте, Begemot_, Вы писали:
B_>Здравствуйте, blacksun, Вы писали:
B_>Да, скорее всего именно ЛК.
Думаю не стоит искать черную кошку в темной комнате. HR сказал одно, ему лишь бы людей побольше окучить, да заданий разослать, а тот кто задания проверял может совсем другого мнения по 10 лет С++ и джуниорскую позицию C#, вот и выдал формальную причину. Я такое же задание как-то выполнял для ЛК, только на C++, позвонили на следующий день и пригласили на телефонное интервью. Код был самый обычный, обертка над std::queue, делал вечером после работы и не парился вообще — подход был формальный. Когда до очного интервью дошел, понял там что не боги горшки обжигают, а обычные люди там работают.
Здравствуйте, Begemot_, Вы писали:
V>> Но тут есть ещё один нюанс, почему так может происходить, если хотите, расскажу, как проверка тестового задания выглядит изнутри и почему хорошее тестовое задание может быть "не принято" B_>Мне интересно было бы послушать, я первый раз делаю тестовое задание, как-то раньше не приходилось. А в будущем еще буду думаю, так что интересно послушать как оно с другой стороны...
Тут есть два варианта, хороший и плохой. Заранее, к сожалению, не узнать, так как даже в одной фирме могут этим заниматься разные люди.
Хороший вариант:
Тестовое задание проверяет ведущий программист проекта, в который нужен человек.
В этом случае, так как человек ему нужен лично, он во первых будет проверять задание сам, а во вторых не будет обращать внимание на всякую ерунду типа форматирования, скобок, формальных комментариев, префиксов...
Потому, что если на это в фирме даже есть стандарты то всегда можно их просто выдать человеку когда он придёт на работу, большинство очень быстро привыкает к новому стилю.
Но на что программист обязательно посмотрит — это внятность кода и отсутствие излишней запутанности (ведь код нужно потом сопровождать), на отсутствие ошибок, типичных для новичков (проверка, не наврал ли в резюме об опыте), иногда на имена переменных. Ну и на то, что код вообще компилируется и работает.
В общем, это скорее проверка на общую адекватность, чем окончательный вердикт. Для окончательного вердикта есть собеседование.
Обращаю внимание, что ведущий программист проекта не заинтересован в том, чтобы завернуть способного кандидата, он заинтересован ровно в обратном — ему же нужен человек и чем скорее он его найдёт тем скорее освободится от этой муторной в общем-то задачи.
Плохой вариант (встречается чаще среди крупных контор, но не всегда):
Набором персонала занимаются специальные люди из HR либо не технический менеджер проекта. Это чтобы максимально разгрузить технических специалистов, что при правильном подходе вполне возможно.
Сами они задание, естественно, проверить не могут, так как это в принципе не программмисты, поэтому отсылают тестовое задание двум-трём программистам, обычно тем, кто сейчас наименее загружен.
Вопрос к программистам при этом ставится примерно так: найти все недостатки кода.
Ну а программисты (особенно не загруженные) — народ увлекающийся и будут соревноваться кто больше чего найдёт. Поэтому находят обычно много, в основном, конечно, ерунды. Посмотрите, например, ответ Codechanger
, который, говоря что код неплохой, тем не менее нашёл прилично недостатков.
Ну а дальше списки придирок объединяются и итог получается довольно большим. И смотрит на этот список менеджер и видит, что недостатков много, что все программисты что-то нашли (напоминаю, сам он серьёзность недостатков оценить не может) и думает: что-то мнего недостатков. Наверное, плохой код. Не будем брать.
Если кандидат спросит, что, собственно, не понравилось, в ответ ему высылают пару пунктов из этого списка, где, напоминаю, в основном несерьзные придирки. Кандидат остаётся в недоумении а фирма без работника.
Здравствуйте, G-Host, Вы писали:
GH>это точно позиция на юниора?
А хз, я так понял людей им надо не один и разных, ну по крайней мере пока они позиции закрыть не могут. А тестовое задание наверняка для всех одно. А мне без разницы, мне дали задание — я сделал
Здравствуйте, Begemot_, Вы писали:
B_>Лет 10 пишу в основном на С++ и немного на других языках, C# не пробовал. Предложили работу джуниором на С# честно сказал что его не знаю, но давно думаю освоить. Сказали — мы верим что с вашим опытом вы сможете, напишите тестовое задание, а мы посмотрим. Прочел полкнижки по шарпу, написал задание.
Нужно было прочитать всю книжку и подаваться на сеньора.
Серьезно. Я именно так и сделал. С аналогичным опытом. Сейчас консультирую "чистых" шарперов без C++ бэкграунда.
ned>Нужно было прочитать всю книжку и подаваться на сеньора. ned>Серьезно. Я именно так и сделал. С аналогичным опытом. Сейчас консультирую "чистых" шарперов без C++ бэкграунда.
Да я так и хотел, вообще думал прочесть книжку, может сходить на курсы шарпа, у нас тут одна крупная контора организует, а только потом думать про работу. А тут компания сама написала мол идите к нам, я не очень хотел, но они убедили, а всю книжку не успел прочесть за неделю Через пару недель закончу, буду думать дальше
Здравствуйте, Begemot_, Вы писали:
B_>Задание вкратце "Необходимо реализовать блокирующую очередь и автоматические тесты к ней. Задача должна быть выполнена как можно более простым способом. .Net 3.5 or 4.0, + тесты, + отсутствие проблем с многопоточностью, + правильный стиль етс."
1. Возможно, решение показалось слишком многословным и не удовлетворяющим условию "как можно более простым способом". Это посчитали признаком C++ стиля. Классическое решение очень простое — требует всего лишь пары семафоров (http://en.wikipedia.org/wiki/Producer-consumer_problem).
2. Ваш BegBlockedQueue2 не реализует IEnumerable<T> и других итерфейсов, обычных для .net коллекций.
Здравствуйте, vmpire, Вы писали:
V>Аналогия весёлая, но, к сожалению, неверная. Почему — см. дальше.
Ок, фирма небольшая, работников так просто не выцепить. Где узнать о финансовых результатах? Ес-но начальство рассказывать будет о манне небесной и прочем, но в реальности может оказаться все иначе. Т.е. Ваше утверждение не всегда работает.
V>Ваша логическая ошибка в том, что вы предполагаете, что при найме отношения работник-работодатель симметричные, а это не так: V>То, что "работодатель может быть "г...ном" не умалчивается, и в ряде случаев это так и есть. V>Но обычно работодатель без расширения штата может прожить гораздо дольше и комфортнее, чем человек без работы. Поэтому работодатель и может себе позволить такие вольности. V>С другой стороны, даже если предположить симметричность отношений, "тестирование" вполне может быть и двухсторонним. Не так сложно узнать, есть ли у работодателя финансовые проблемы. Просто для этого не нужно тестовое задание, достаточно прочитать отзывы о нём или спросить его текущих работников.
Спорный вопрос. Ваша же логическая ошибка в том, что Вы не видите, что на сегодня рынок как раз работника, а не работодателя. Сменить работу как минимум на аналогичные деньги, если они средние по рынку — не составляет труда и много времени. Т.е. проблем с трудоустройством (сейчас) нет. Плюс во многих случаях как раз работодатель не может прожить без сотрудника, потому что сроки проекта прошли "вчера" и если срочно не найти людей, то заказчик просто уйдет.
V>...И в куче фирм в результате работают толпы идиотов, которых приходится вытягивать более опытным сотрудникам. V>Это вообще не аргумент. Как минимум потому, что не учтено сколько фирм заглохло из за профнепригодности персонала.
А сколько не заглохло? А сколько раcширилось? Не вижу связи между тестовое задание — успех фирмы. ИМХО, многие фирмы загибаются не из-за плохих разработчиков, а из-за кривого менеджмента. Вы проверяете тестами руководителей? Уверен, что нет. А ведь успех в большей доли как раз от них и зависит. Т.е. тоже не аргумент.
V>Это вопрос адекватности оценивающих результаты. Хотя, тоже имеет право на существование. Например, если вы устраиваютесь на фирму, которая занимается передовыми разработками многопоточной обработки, то корректная реализация многопоточности может вполне подразумеваться.
Опять же, на вкус и цвет. Вы считаете, что только тестовое задание может помочь оценить кандидата, а я считаю, что и без этого можно обойтись.
V>Опять же вопрос адекватности проверяющих. Но тут есть ещё один нюанс, почему так может происходить, если хотите, расскажу, как проверка тестового задания выглядит изнутри и почему хорошее тестовое задание может быть "не принято"
V>Я бы давал тестовые задания только в том случае, если проверять их буду тоже я V>Кстати, одна из причин отказа нашей фирмы от тестовых заданий как раз в том, что многие не хотят его делать. V>Но есть и обратная сторона: без тестового задания сильно увеличивается поток левых людей. V>Вот не далее как на этой неделе искал человека в команду. Типичное резюме: образование высшее но не профильное, 25 лет, опыт работы по спецальности 2 года программистом в не программерской конторе, позиционирует себя как ведущего программиста, хочет 80000 рублей (Питерские цены). А на тестовом задании он бы сразу отсеялся. V>Кстати, есть мысль: давать тестовое задание, но с автоматической его проверкой. Как бы вы к этому отнеслись?
Что Вы понимаете под "автоматической проверкой"? Если бы у меня была "фирма мечты" и я бы любыми путями туда хотел попасть, то я бы делал и тестовое задание и вообще проходил бы все адекватные тестирования со стороны работодателя. Но! У меня такой фирмы нет, получить среднерыночную зп можно в большом числе компаний, которые не занимаются "тестированием", а отдают предпочтение классическим собеседованиям. А получить +200 у.е. можно и другими путями, причем с меньшими усилиями, чем пытаясь попасть в компанию, которая платит на эти 200 баксов выше рынка, но просит написать тестовое задание.
PS.: давайте закончим данную холиварную дискуссию, потому как лично я не хочу Вас переубеждать Ваше право давать и проверять тестовые задания, а "мое" — их не писать
Здравствуйте, GGoga, Вы писали:
GG>Ок, фирма небольшая, работников так просто не выцепить. Где узнать о финансовых результатах? Ес-но начальство рассказывать будет о манне небесной и прочем, но в реальности может оказаться все иначе. Т.е. Ваше утверждение не всегда работает.
Для небольшой фирмы это, конечно, сложнее. Но можно, например, попросить провести мини-экскурсию по фирме, посмотреть, в каких условиях люди работают и мельком глянуть, что у них на экранах. Если видно, что на оборудовании экономят, то наверное здесь не всё хорошо. А если откажут в экскурсии — сразу посылать нафиг и искать других
V>>Но обычно работодатель без расширения штата может прожить гораздо дольше и комфортнее, чем человек без работы. Поэтому работодатель и может себе позволить такие вольности.
задание, достаточно прочитать отзывы о нём или спросить его текущих работников. GG>Спорный вопрос. Ваша же логическая ошибка в том, что Вы не видите, что на сегодня рынок как раз работника, а не работодателя. Сменить работу как минимум на аналогичные деньги, если они средние по рынку — не составляет труда и много времени. Т.е. проблем с трудоустройством (сейчас) нет. Плюс во многих случаях как раз работодатель не может прожить без сотрудника, потому что сроки проекта прошли "вчера" и если срочно не найти людей, то заказчик просто уйдет.
Да, согласен, вопрос не однозначный. Да и фирмы бывают разные. Кто-то отлично проживёт без работника ещё несколько лет, а кто-то без расширения загнётся. Просто по моему личному опыту (без претензии на универсальность) первых больше.
V>>...И в куче фирм в результате работают толпы идиотов, которых приходится вытягивать более опытным сотрудникам. V>>Это вообще не аргумент. Как минимум потому, что не учтено сколько фирм заглохло из за профнепригодности персонала. GG>А сколько не заглохло? А сколько раcширилось? GG>Не вижу связи между тестовое задание — успех фирмы.
А её напрямую и нет. Тестовое задание — способ немного упростить поиск программистов, но не замена личной встрече.
GG> ИМХО, многие фирмы загибаются не из-за плохих разработчиков, а из-за кривого менеджмента.
Менеджер — тоже работник фирмы. И от качества его работы успех фирмы, конечно, тоже зависит, так же, как и от программистов.
GG> Вы проверяете тестами руководителей? Уверен, что нет. А ведь успех в большей доли как раз от них и зависит. Т.е. тоже не аргумент.
Насчёт "в большей доли" не согласен, но это субъективно. А что до тестов — будь моя воля — проверял бы, но, к сожалению, это не в моей компетенции пока.
V>>Это вопрос адекватности оценивающих результаты. Хотя, тоже имеет право на существование. Например, если вы устраиваютесь на фирму, которая занимается передовыми разработками многопоточной обработки, то корректная реализация многопоточности может вполне подразумеваться. GG>Опять же, на вкус и цвет. Вы считаете, что только тестовое задание может помочь оценить кандидата, а я считаю, что и без этого можно обойтись.
Я нигде не утверждал про "только". И обойтись без этого можно, но всё имеет свою цену — см. выше про толпы идиотов.
V>>Кстати, есть мысль: давать тестовое задание, но с автоматической его проверкой. Как бы вы к этому отнеслись? GG>Что Вы понимаете под "автоматической проверкой"?
Ну, типа как на олимпиадах по программированию. Программа имеет чёткий вход и выход, проверяется другой программой по входу-выходу.
GG>Если бы у меня была "фирма мечты" и я бы любыми путями туда хотел попасть, то я бы делал и тестовое задание и вообще проходил бы все адекватные тестирования со стороны работодателя. Но! У меня такой фирмы нет, получить среднерыночную зп можно в большом числе компаний, которые не занимаются "тестированием", а отдают предпочтение классическим собеседованиям. А получить +200 у.е. можно и другими путями, причем с меньшими усилиями, чем пытаясь попасть в компанию, которая платит на эти 200 баксов выше рынка, но просит написать тестовое задание.
Это уже с вашей стороны субъективизм. Спорить тут не о чем.
GG>PS.: давайте закончим данную холиварную дискуссию, потому как лично я не хочу Вас переубеждать Ваше право давать и проверять тестовые задания, а "мое" — их не писать
Я и не планировал никого ни в чём убеждать. Просто высказал своё мнение. Я же не даю вам тестовое задание
Здравствуйте, Begemot_, Вы писали: B_> BegBlockedQueue1<int> q = new BegBlockedQueue1<int>();
пишут обычно var q = new BegBlockedQueue1<int>();
B_> q.Add(2); B_> q.Add(32); B_> q.Add(212);
скорее всего это можно записать в стиле q = new BegBlockedQueue1<int>() {2, 32, 212};
B_> private bool _isAddingCompleted = false;
это лишнее. лучше авто-property public bool IsAddingCompleted { get; set; }
B_> // Maybe there is waiting producer inside Add B_> if (IsAddingCompleted == false && Count == BoundedCapacity — 1)
== false
ну и в других местах это в глаза бросается
B_>namespace UnitTest B_>{ B_>#if TestBegBlockedQueue1 B_> using TestClassImplementation = BegBlockedQueue1<int>; B_>#else B_> using TestClassImplementation = BegBlockedQueue2<int>; B_>#endif
дефайны в C# не популярны
B_> for (int t = 0; t < 20; ++t)
и сильно любят foreach
Здравствуйте, SuhanovSergey, Вы писали:
SS>Здравствуйте, Begemot_, Вы писали:
B_>>Задача должна быть выполнена как можно более простым способом.
да, на это стоило обратить внимание, более того, заострить.
SS> ... слишком многословным и не удовлетворяющим условию...
похоже на то
SS>2. Ваш BegBlockedQueue2 не реализует IEnumerable<T> и других итерфейсов, обычных для .net коллекций.
круто, ч0!
здесь реализация этого интерфейса вообще-то сильно усложняет задание.
оно нужно?
Всё сказанное выше — личное мнение, если не указано обратное.
В блокирующей очереди нужен иначе работать не будет.
