Здравствуйте Igor Trofimov, Вы писали:
IT>>Английский они знают получше меня, тем более индусы. Он у них почти родной. А вот лишнего в резюме много пишут.
IT>Чего, например? интересно...
2 года C++
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте Igor Trofimov, Вы писали:
IT>Чего, например? интересно...
я, например, будучи студентом 5-го курса, нигде никогда не работавшим программистом, писал, что у меня 5 лет знания C++.
Написав один контрол на ATL, писал, что год опыта ATL/COM (я его и по сей день не знаю никак)
Написав пару базулин небольших для учета некой статистики на Oracle 7.2. (правда, с триггерами и т.д.) — писал пол-года работы с Oracle 7
Правда, я где-то тогда видел, что в резюме (в примере) написан и Оффис, и еще куча пользовательских прог, и я их тоже писал.
Короче, у такого резюме шансов не было изначально. Но я с ним ходил, меня везде хвалили за собеседования, но нигде не брали. Как тех индусов.
Здравствуйте KVLD, Вы писали:
KVLD>иначе если весы изменили результат на обратный в сравнении с пунктом 3 KVLD>то фальшивка в двух монетах которые были перемещенные в пункте 5 и опять зная тяжелее фальшивка или легче мы находим ее
в п5. ты переместил 4 монеты:
(2 из 2к) -> ( в 3к ) и
(2 из 3к) -> ( в 2к ).
так что если весы изменили результат на обратный, то фальшивка — одна из них.
Одного оставшегося взвешивания явно недостаточно при таком подходе.
KVLD>кажется такое решение
в принципе, ты на верном пути.
P.S. Sorry, практически моментально отправил обратно твое сообщение ( видимо, на доработку )
Здравствуйте xab, Вы писали:
xab>Здравствуйте KVLD, Вы писали:
KVLD>>иначе если весы изменили результат на обратный в сравнении с пунктом 3 KVLD>>то фальшивка в двух монетах которые были перемещенные в пункте 5 и опять зная тяжелее фальшивка или легче мы находим ее
xab>в п5. ты переместил 4 монеты: xab>(2 из 2к) -> ( в 3к ) и xab>(2 из 3к) -> ( в 2к ). xab>так что если весы изменили результат на обратный, то фальшивка — одна из них. xab>Одного оставшегося взвешивания явно недостаточно при таком подходе.
KVLD>>кажется такое решение xab>в принципе, ты на верном пути.
нашел главную ошибку она в п.1 5+4+4
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Eugene_B, Вы писали:
EB>>Вы забыли свое IMHO приписать. A>Я так и сказал, я лучше не видел. A>Imho 'imho' здесь не нужно.
Нужно.
A>>>Требования там указанные вполне справедливы. A>>>И они не технические, их все можно выяснить A>>>просто спросив.
EB>>Классно! Тогда любые знания можно выяснить EB>>просто спросив. EB>>"Ты умеешь программировать на С++" EB>>"О, да, я умею программировать на С++.
A>Ты своего оппонента то читаешь вообще A>или просто пишешь сам.
Грубый выпад. Не буду отвечать.
A> Я сказал нетехнические. A>Кроме того именно эти требования никто A>в резюме не пишет.
Вы как различаете технические и нетехнические требования?
Умение устанавливать разные программы для вас -- нетехническое
требование.
A>>>Ты согласен взять на работу человека который говорит A>>>я "офигенный C++ программист" но при этом не может себе A>>>поставить самостоятельно Visual Studio на машину? A>>>Или говорит "Извини а как ставится Windows95? A>>>а чем она отличается от Windows 2000"
EB>>Не надо подменять то, что написано в сообщении по EB>>вашей ссылке своими словами. Там написано не только EB>>про Windows 98, а еще про всякие почтовые клиенты EB>>и прочее.
A>Ну уж Microsoft Office поставить и A>настроить Outlook это вообще все A>должны уметь. Опять же ты возьмешь A>на работу человека который не может это A>делать?
Да просто совершенно не к чему спрашивать об этой
ерунде на собеседовании.
A>>>Извини но этот человек получает деньги за то A>>>что нанимает людей.
EB>>Ну и что? Если получает деньги, так сразу автоматически EB>>умеет это делать? Мало кто за что деньги получает.
A>Ты знаешь если он только этим занимается A>он должен делать это хорошо. Если не делает A>гнать его в шею.
Необязательно. Он может уметь создавать видимость
у руководства, быть блатным и пр. Вариантов много.
Фирма может не успеть понять это и развалиться, а
он спокойно перейти в другую.
EB>>Чтобы ссылаться на практику, надо привести хотя бы EB>>один живой пример. И хорошо бы определить понятие EB>>"хорошо"
A>Когда я устраивался на работу меня никто не спрашивал A>про лампочки. Единственный технический вопрос A>был ты "используешь STL в своей работе". A>Разговаривали со мной менеджер и программист.
Ну и что из этого следует? Вы считаете свою
нынешнюю работу эталоном? Чтобы убедить в этом
других, придется рассказать о ней подробнее.
A>>>Не важно что он сам не может программировать. A>>>Поверхностные знания у него есть.
EB>>Вы не поняли, задачки про лампочки как раз от таких EB>>людей с поверхностными знаниями, а не от программистов.
A>Перечитай еще раз, задачу про лампочки задал программист.
Почитайте внимательнее -- это была шутка и о человеке судили
вовсе не по ней. К тому же задавать такие вопросы они
наверняка научилсь у 'специалистов по найму'.
A>>>Что касается ошибок. Если твой предыдущий проект был неудачным.
A>>>И ты не можешь просто сформулировать почему именно(уже не говоря правильно A>>>или нет) то это говорит не в твою пользу.
EB>>Ну вы даете! Да это же задача (решить трудности больших EB>>проектов в программировании), которую пытаюся решить EB>>во всем мире и не могут пока.
A>Она давно уже решена просто не все об этом знают.
И где же решение?
EB>>Категорически не согласен. Причины провала проектов, EB>>непрограммисту не понять. Другое дело, может быть, EB>>что для этого не достаточно быть просто программистом, EB>>а надо иметь какие-то дополнительные знания, но EB>>программистом быть обязательно.
A>Ты знаешь сейчас у нас всеми проектами управляет человек A>который вообще никогда программистом не был и A>делает это очень хорошо(он безусловно опирается на A>технических специалистов)
A>Почитай какую нибудь из книг на эту тему. Там A>собрана статистика(просто цифры) о неудачных проектах. A>Так вот технические трудности стали причиной неудач A>в 5% проектах. Тогда как отсутствие управения требованиями A>(грубо говоря когда несколько месяцев писали не совсем A>то что нужно) 30%
Опять непонятно ваше понимание 'технического' и 'нетехнического'.
EB>>В моем сообщении понятие ВЕСЬ курс сразу четко EB>>очерчено: "ВЕСЬ курс, который тебе читали". EB>>Т. е. берется некая объем знаний и умений, EB>>составляется по нему курс, и затем для EB>>этого ИЗВЕСТНОГО набора строятся проверочные EB>>задания. Так же можно поступить и для дисциплины EB>>"программирование". Будем иметь некий перечисленный EB>>набор знаний и умений и при условии грамотного, EB>>талантливого составления тестового задания EB>>уверенность с достаточной степенью вероятности, EB>>что человек, правильно выполнивший это задание, EB>>владеет перечисленными знаниями и умениями. EB>>Конечно, человек, составляющий такие задания EB>>должен обладать исчерпывающими познаниями в EB>>данной области.
A>Как ты думешь он во всех фирмах есть?
Фирмы в первую очередь должны стремится иметь
таких людей, платить им высокую зарплату. Печальна
участь фирмы, которая этого не делает.
A> Кто будет A> составлять задания если набирается новый отдел A> и никто вообще не знает области в которой они A> будут работать?
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Eugene_B, Вы писали:
EB>>Здравствуйте Вы писали:
EB>>Пример задачки (по Дельфи, правда) с Дружественного сайта: EB>>http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1028556871&n=3
A>Обрати внимание на следующие вещи A>1) В форуме ее решают толпой притом долго
Если 3 человека для вас толпа -- значит толп вы не видели.
Каждый из них решал ее своим путем. В резульате
было предложено несколько вариантов решения.
A>2) Знания необходимые для решения задачи нигде A>почти не пригодятся, т.к. от программиста Delphi A>обычно требуется писать простые приложения по A>вводу/обработки данных
Такие слова происходят от вашей неосведомленности
о Дельфи, задачах которые решаются с ее помощью
и средсивах, которыми они решаются.
Здравствуйте Eugene_B, Вы писали:
A>>Обрати внимание на следующие вещи A>>1) В форуме ее решают толпой притом долго
EB>Если 3 человека для вас толпа -- значит толп вы не видели. EB>Каждый из них решал ее своим путем. В резульате EB>было предложено несколько вариантов решения.
Там совсем очевидное решение было. Внедряемся в процесс.
И делаем FindControl по hwnd безо всяких атомов.
Потом имея сам Control с помошью RTTI ставим ему свойство.
Все остальные варианты это незначительные модификации.
Но при этом дельфовых программистов обычно берут чтобы те
делали задачи связанные с БД.
EB>Такие слова происходят от вашей неосведомленности EB>о Дельфи, задачах которые решаются с ее помощью EB>и средсивах, которыми они решаются.
О как. Прежде чем наезжать попытался бы сначала
получше узнать о том на сколько человек знает Delphi.
если хочешь почитай мою статью на тему близкую к задаче http://www.softforum.ru/html/index.asp?id=items&group=cps.borland.delphi&topic=item221101
после этого подумай о том сколько дельфистов пишет сложные вещи,
а сколько пишут формы для ввода информации в базу данных,
могу тебя уверить вторых на порядок больше.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Eugene_B, Вы писали:
EB>>>Вы забыли свое IMHO приписать. A>>Я так и сказал, я лучше не видел. A>>Imho 'imho' здесь не нужно.
EB>Нужно.
Да не нужно, imho расшифровывается
"по моему скромному мнению" а когда я
уже сказал что "я лучше не видел"
это абсолютно точно. Ты претендуешь на то
что лучше меня знаешь что я видел а что нет?
A>>Ты своего оппонента то читаешь вообще A>>или просто пишешь сам.
EB>Грубый выпад. Не буду отвечать.
Извини, конечно грубый, но тот комментарий
был совсем не в тему.
EB>Вы как различаете технические и нетехнические требования? EB>Умение устанавливать разные программы для вас -- нетехническое EB>требование.
В данном случае пусть будет: связанные с кодированием
и все остальное.
EB>Да просто совершенно не к чему спрашивать об этой EB>ерунде на собеседовании.
Конечно не зачем, и так по человеку видно.
EB>Необязательно. Он может уметь создавать видимость EB>у руководства, быть блатным и пр. Вариантов много. EB>Фирма может не успеть понять это и развалиться, а EB>он спокойно перейти в другую.
Это уже другой вопрос. Таким человеком может бфть и
начальник и директор и тп.
EB>Ну и что из этого следует? Вы считаете свою EB>нынешнюю работу эталоном? Чтобы убедить в этом EB>других, придется рассказать о ней подробнее.
Ну вообще то да. Мне очень нравится. Убаждать
других не буду.
EB>К тому же задавать такие вопросы они EB>наверняка научилсь у 'специалистов по найму'.
Каково твое общение со специалистами по найму?
Они все задавали такую задачу или ты просто
одного такого встретил.
Я вижу ты считаешь что хороших специалистов по найму не
бывает в принципе. Если ты так в этом уверен то
подумай как делают свой бизнес всякие рекрутинговые
агенства?
EB>>>Ну вы даете! Да это же задача (решить трудности больших EB>>>проектов в программировании), которую пытаюся решить EB>>>во всем мире и не могут пока.
A>>Она давно уже решена просто не все об этом знают.
EB>И где же решение?
Читай книжки, начни с "мифического человеко-месяца"
(в ней решения нет но проблемы поставлены, это уже
половина решения), потом почитай что-нибудь про CMM
и управления требованиями.
A>>Почитай какую нибудь из книг на эту тему. Там A>>собрана статистика(просто цифры) о неудачных проектах. A>>Так вот технические трудности стали причиной неудач A>>в 5% проектах. Тогда как отсутствие управения требованиями A>>(грубо говоря когда несколько месяцев писали не совсем A>>то что нужно) 30%
EB>Опять непонятно ваше понимание 'технического' и 'нетехнического'.
Программирование и управление проектом если хочешь
EB>>>Конечно, человек, составляющий такие задания EB>>>должен обладать исчерпывающими познаниями в EB>>>данной области.
A>>Как ты думешь он во всех фирмах есть?
EB>Фирмы в первую очередь должны стремится иметь EB>таких людей, платить им высокую зарплату. Печальна EB>участь фирмы, которая этого не делает.
Такие люди должны программировать, а не вопросы составлять,
если фирма хочет потратить деньги на специальную
тестирующую программу для (будующих)сотрудников
ей легче заплатить в десятеро меньшие деньги например
Brainbench-у, и получить за них в десятеро боле
квалифицированные тесты. Brainbench сейчас активно
сотрудничает с фирмами если ты не в курсе.
Кстати Brainbench и есть пример профессионализма
в этой области.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Там совсем очевидное решение было. Внедряемся в процесс. A>И делаем FindControl по hwnd безо всяких атомов. A>Потом имея сам Control с помошью RTTI ставим ему свойство. A>Все остальные варианты это незначительные модификации.
Статья ничего, из серии Hello, World. Все равно я не согласен
с вашим мнением о неприменимости знаний к написанию
реальных приложений БД. Они очень даже могут пригодится.
A>после этого подумай о том сколько дельфистов пишет сложные вещи, A>а сколько пишут формы для ввода информации в базу данных, A>могу тебя уверить вторых на порядок больше.
Откуда основания для такой уверенности?
Вы располагаете статистикой? Предъявите ее.
Здравствуйте Eugene_B, Вы писали:
EB>Здравствуйте Anatolix, Вы писали:
EB>Не получится. Надо было внимательнее читать условие. EB>У компонента, которому нужно выставить свойство, нет hwnd.
Да не надо его по hwnd искать, его надо найти в
списке Controls у его parent-а у которого есть hwnd.
EB>Откуда основания для такой уверенности? EB>Вы располагаете статистикой? Предъявите ее.
У меня слишком много друзей и знакомых которые
пишут на Delphi, я очень хорошо предстваляю их
уровень подготовки.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Eugene_B, Вы писали:
EB>>>>Вы забыли свое IMHO приписать. A>>>Я так и сказал, я лучше не видел. A>>>Imho 'imho' здесь не нужно.
EB>>Нужно.
A>Да не нужно, imho расшифровывается A>"по моему скромному мнению" а когда я A>уже сказал что "я лучше не видел" A>это абсолютно точно. Ты претендуешь на то A>что лучше меня знаешь что я видел а что нет?
Вы считаете, что ваше мнение что лучше, что хуже
абсолютно? Может, вы видели, да распознать не
сумели?
EB>>Вы как различаете технические и нетехнические требования? EB>>Умение устанавливать разные программы для вас -- нетехническое EB>>требование.
A>В данном случае пусть будет: связанные с кодированием A>и все остальное.
EB>>Да просто совершенно не к чему спрашивать об этой EB>>ерунде на собеседовании.
A>Конечно не зачем, и так по человеку видно.
А в лучшей, по вашему мнению, рекомендации, этому
вопросу уделяется столь большое внимание, что
одно это ставит под сомнение ее пригодность.
EB>>Необязательно. Он может уметь создавать видимость EB>>у руководства, быть блатным и пр. Вариантов много. EB>>Фирма может не успеть понять это и развалиться, а EB>>он спокойно перейти в другую.
A>Это уже другой вопрос. Таким человеком может бфть и A>начальник и директор и тп.
Я хочу сказать, что надо судить не расплывчивыми
эмпирическими рассуждениями ("если бы он не работал,
его бы уволили"), а конкретно по делу.
EB>>Ну и что из этого следует? Вы считаете свою EB>>нынешнюю работу эталоном? Чтобы убедить в этом EB>>других, придется рассказать о ней подробнее.
A>Ну вообще то да. Мне очень нравится. Убаждать A>других не буду.
Ну, значит это не пример и не аргумент.
EB>>К тому же задавать такие вопросы они EB>>наверняка научилсь у 'специалистов по найму'.
A>Каково твое общение со специалистами по найму? A>Они все задавали такую задачу или ты просто A>одного такого встретил.
A>Я вижу ты считаешь что хороших специалистов по найму не A>бывает в принципе. Если ты так в этом уверен то A>подумай как делают свой бизнес всякие рекрутинговые A>агенства?
Опять "если бы, то". Это не аргумент.
EB>>>>Ну вы даете! Да это же задача (решить трудности больших EB>>>>проектов в программировании), которую пытаюся решить EB>>>>во всем мире и не могут пока.
A>>>Она давно уже решена просто не все об этом знают.
EB>>И где же решение?
A>Читай книжки, начни с "мифического человеко-месяца" A>(в ней решения нет но проблемы поставлены, это уже A>половина решения), потом почитай что-нибудь про CMM A>и управления требованиями.
Дайте конкретный ответ, если вы его знаете. А Брукса
я читал, не волнуйтесь. Как раз из его книги хорошо
видно, что решения до сих пор не найдено.
A>>>Почитай какую нибудь из книг на эту тему. Там A>>>собрана статистика(просто цифры) о неудачных проектах. A>>>Так вот технические трудности стали причиной неудач A>>>в 5% проектах. Тогда как отсутствие управения требованиями A>>>(грубо говоря когда несколько месяцев писали не совсем A>>>то что нужно) 30%
EB>>Опять непонятно ваше понимание 'технического' и 'нетехнического'. A>Программирование и управление проектом если хочешь
EB>>>>Конечно, человек, составляющий такие задания EB>>>>должен обладать исчерпывающими познаниями в EB>>>>данной области.
A>>>Как ты думешь он во всех фирмах есть?
EB>>Фирмы в первую очередь должны стремится иметь EB>>таких людей, платить им высокую зарплату. Печальна EB>>участь фирмы, которая этого не делает.
A>Такие люди должны программировать, а не вопросы составлять, A>если фирма хочет потратить деньги на специальную A>тестирующую программу для (будующих)сотрудников A>ей легче заплатить в десятеро меньшие деньги например A>Brainbench-у, и получить за них в десятеро боле A>квалифицированные тесты. Brainbench сейчас активно A>сотрудничает с фирмами если ты не в курсе.
A>Кстати Brainbench и есть пример профессионализма A>в этой области.
Вы приводите еще одие ответ на свой вопрос, т. е.
подкрепляете мое мнение.
А составление заданий не является пустой тратой
времени, т. к. способно существенно повысить
квалификацию этого специалиста.
Здравствуйте Eugene_B, Вы писали:
A>>Читай книжки, начни с "мифического человеко-месяца" A>>(в ней решения нет но проблемы поставлены, это уже A>>половина решения), потом почитай что-нибудь про CMM A>>и управления требованиями.
EB>Дайте конкретный ответ, если вы его знаете. А Брукса EB>я читал, не волнуйтесь. Как раз из его книги хорошо EB>видно, что решения до сих пор не найдено.
Книга Брукса написана в 70 году. И даже дополнение
не помогает. Кроме того брукс не самый хороший
IT менеджер, он просто самый первый.
EB>Вы приводите еще одие ответ на свой вопрос, т. е. EB>подкрепляете мое мнение.
EB>А составление заданий не является пустой тратой EB>времени, т. к. способно существенно повысить EB>квалификацию этого специалиста.
Очень спорно. Аргументируй.
Я считаю что любое занятие темой
естественно повышает уровень, но решения
проблем в области существено выше его повышает
чем составление тестов
(когда ты тест составляешь ты не можешь ничего нового
узнать, для этого надо что-то читать)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Eugene_B, Вы писали:
A>>>Читай книжки, начни с "мифического человеко-месяца" A>>>(в ней решения нет но проблемы поставлены, это уже A>>>половина решения), потом почитай что-нибудь про CMM A>>>и управления требованиями.
EB>>Дайте конкретный ответ, если вы его знаете. А Брукса EB>>я читал, не волнуйтесь. Как раз из его книги хорошо EB>>видно, что решения до сих пор не найдено.
A>Книга Брукса написана в 70 году. И даже дополнение A>не помогает. Кроме того брукс не самый хороший A>IT менеджер, он просто самый первый.
Классно! Вы сами ссылаетесь на Брукса, потом заявляете,
что он не лучший. Кто же лучший? Конкретно?
EB>>Вы приводите еще одие ответ на свой вопрос, т. е. EB>>подкрепляете мое мнение.
EB>>А составление заданий не является пустой тратой EB>>времени, т. к. способно существенно повысить EB>>квалификацию этого специалиста.
A>Очень спорно. Аргументируй. A>Я считаю что любое занятие темой A>естественно повышает уровень, но решения A>проблем в области существено выше его повышает A>чем составление тестов A>(когда ты тест составляешь ты не можешь ничего нового A>узнать, для этого надо что-то читать)
Составление тестов помогает проникнуть вглубь,
на что при работе над проектом может не хватить
времени.
Необязательно читать книжки, сведения могут
получаться из самостоятельного исследования.
То, что исселедование само по себе часто дает
больше, чем конечный результат давно известно.
Пример: решение великой теоремы Ферма. При
попытках решения были созданы целые отрасли
математики. Сам факт, который утверждает
теорема, в общем то и не нужен особо никому.
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Eugene_B, Вы писали:
EB>>Здравствуйте Anatolix, Вы писали:
EB>>Не получится. Надо было внимательнее читать условие. EB>>У компонента, которому нужно выставить свойство, нет hwnd.
A>Да не надо его по hwnd искать, его надо найти в A>списке Controls у его parent-а у которого есть hwnd.
Ну, давайте не будем здесь повторять целиком тему с
delphi.mastak.ru. Такие решения там предлагались и
даже в таком же порядке. Обратитесь непосредственно к
этой теме.
Здравствуйте Eugene_B, Вы писали:
EB>Здравствуйте Anatolix, Вы писали:
EB>Классно! Вы сами ссылаетесь на Брукса, потом заявляете, EB>что он не лучший. Кто же лучший? Конкретно?
Книгу брукса я тебе порекомендовал для начала.
Меня последнее время проперла вот эта книга http://www.books.ru/shop/books/27743
там в первой главе достаточно четко собрана статистика
о причинах неудач проектов. Она естественно не
все покрывает.
Потом можешь почитать материалы по CMM.
Это совсем в тему, но не для начинающих.
EB>То, что исселедование само по себе часто дает EB>больше, чем конечный результат давно известно. EB>Пример: решение великой теоремы Ферма. При EB>попытках решения были созданы целые отрасли EB>математики. Сам факт, который утверждает EB>теорема, в общем то и не нужен особо никому.
Ты привел аргумент в мою пользу. Представь что
математики которые получили так много при решении
т. Ферма занимались разработкой тестов для студентов.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Eugene_B, Вы писали:
EB>Ну, давайте не будем здесь повторять целиком тему с EB>delphi.mastak.ru. Такие решения там предлагались и EB>даже в таком же порядке. Обратитесь непосредственно к EB>этой теме.
Да спор то был не об этом. Знаешь разработчику
на Delphi гораздо полезнее знать предметную область,
например бухучет, чем RTTI и WinAPI это сделает его
гораздо более ценным специалистом.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев