Здравствуйте, CreatorCray, Вы писали:
CC>Да как то с С# у них тоже не фонтан.
Индусы немножко по другому думают. Вот как рассуждает типичный русский, когда его просят сделать новую фичу — да я щас так крута замучу, что бы и расширяемость была и красиво вписалось в архитектуру и побочных эффектов не было, ну понятно дело еще кучу кода отрефакторить придется. И делает русский эту фичу неделю.
Индус думает по другому — начальник сказал сделать, надо сделать быстро-быстро, он меня выделит за то, что я быстро работаю и я получу повышение, а если все потом упадет или код некрасивый, так потом русский поправит, его недавно начальник ругал, что он в сроки не уложился, вот глупый какой русский.
Здравствуйте, elmal, Вы писали:
E>Ну так и докажи кандидатам, что у тебя лично все это наблюдается.
Зачем это ему и кандидатам? Он ищет людей, он задает им вопросы и выбирает кандидатов на основе ответов, кандидаты в свою очередь получают информацию о компании по характеру вопросов и тоже делают выбор. Всем хорошо. Нафига кандидату тестировать непонятного собеседующего, с которым может и работать не придется?
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>А вот незнание (судя по озвученным наблюдениям mymuss) — напротив, гарантирует некоторые существенные проблемы в том числе и в области "правки багов". И что же нужно выбрать? Гарантированные проблемы в угоду шибко специализированным специалистам?
O>Какие именно проблемы в области написания веб-приложений? Да еще причем и гарантированные.
Такие же проблемы, как и в других областях разработки ПО, и вообще в других областях, гм, народного хозяйства.
Мой коллега по поводу этой дискуссии сказал так. Есть техники, а есть инженеры. Техник отлично крутит свою гайку на 24, но и только. Как примерить заклепку и что такое точечная сварка, он уже имеет право не знать, ну не нужно оно чтоб крутить гайку на 24.
В отличие от инженера, который знает как свою область, так и несколько смежных областей. Невеждество в сопредельных областях знаний для инженера именно потому и недопустимо, что мешает качественно решать творческие задачи.
Я, пожалуй, приму точку зрения AndrewVK (если я правильно ее понял), что спрашивать такие вопросы на собеседованиях оскорбительно в такой же степени, как стыдно на них не суметь ответить.
Здравствуйте, SE, Вы писали:
SE>Такие же проблемы, как и в других областях разработки ПО, и вообще в других областях, гм, народного хозяйства.
Так какие именно? Я плотненько работал в нескольких областях разработки ПО и не могу придумать ни одной проблемы, которую могла бы создать забытая школьная формула. Я тебе даже больше скажу, довелось мне и с математикой поработать в свое время, так и там это не было бы проблемой, т.к. для формул есть справочники, как для параметров методов документация. Это не то что бы не гарантированная проблема, это гарантированное отсутствие каких либо проблем в разработке вообще.
SE>В отличие от инженера, который знает как свою область, так и несколько смежных областей.
Математика лишь одна из кучи областей, и я бы сказал — редко встречаемая.
Здравствуйте, olegkr, Вы писали:
ГВ>>Ты правда не понимаешь, или прикалываешься? А под чьим крылом тогда велась разработка вычислительной техники и ПО? Сорока на хвосте принесла, что ли? O>Да та IT-"индустрия" и процента от нынешней не составит. Несерьезно.
Фу ты, ну ты, пальцы гнуты. В 80-90-х обороты IT-индустрии ещё нигде не составляли такой же доли, как сейчас. Это совершенно не означает, что её можно сбрасывать со счетов.
O>Тем более, что оригинальных разработок практически не было, сдирали все с запада
Ну это не совсем так, хотя здесь просто нужно взять справочник по полупроводниковым приборам и посмотреть наличие аналогов. Кажется, аналоги были даже не у всех микросхем серии 155. И если я не ошибаюсь, то топологии даже функционально аналогичных микросхем и их западных прототипов отличались.
Ну и как ты понимаешь, "содрать" ту же элементную базу — это только вершина айсберга. Нужно иметь то, чем "сдирать" и то, на чём "передраное" можно выпустить. А это уже совсем другая история. Одним только сдиранием сыт не будешь.
ГВ>>Чему учиться? Новые API, тулзы, языки, ОС растут как грибы — ни один вуз за ними не угонится. O>Не так уж и часто происходят критические изменения. На моей памяти их было всего 2 — переход на ООП и на управляемые среды.
Ну вот видишь, а я это не считаю даже изменениями, не говоря об их критичности. Может, ты ещё и веб-сервисы революцией прикажешь считать? Скорее уж революция произошла в СМИ, которые стали больше гудеть "про технологии", ну так это уже совсем из другой оперы.
ГВ>>Та же история с теорией графов, статистикой, формальными грамматиками, теорией автоматов и т.п. И почему-то всё из перечисленного пригодилось. Что я делал не так? O>Ты работал в той узкой области где это применимо. Это не фундамент — это такая же специализация, как дотнет. Причем очень узкая специализация.
Хм. То, о чём я упомянул, применялось в самом обычном бизнес-софте: склады, бухгалтерии, биллинги, какая-то ещё хрень того же порядка. Это узкая специализация?
ГВ>>Ну я ж сказал, что LSP сильно повлиял на развитие ОО-проектирования. O>Ради бога, я не возражаю, что он повлиял на развитие CS. И потом CS родил эти самые принципы и паттерны, которые уже стали применяться на практике. Так что LSP, само по себе — это чисто научное творение. Не понимаю, зачем о нем надо знать девелоперу, пишущему код? Специалисту в области CS — пожалуй стоит.
Для того, чтобы не зубрить "паттерны" и массу странных слов, хотя бы. Сильно экономит время и нервы.
ГВ>>Это связано с двумя явлениями: первое — объективно стали хуже учиться, второе — стало намного больше истерики по поводу "неподготовленности" молодых специалистов. O>Так было и есть еще с советских времен. Причем не только в программировании. Очень хорошо помню, как точно такая же проблема была в микроэлектронике (из личных бесед) — представители заводов жаловались, что выпускники ни на что не годны и их надо учить заново. На что универовцы только разводили руками и предлагали расширить производственную практику.
Кстати, универовцы правильно предлагали расширить производственную практику. Собственно, я отнюдь не пытаюсь утверждать, что вузы были свободны от недостатков. Но это ж не повод коверкать всю систему вообще.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, olegkr, Вы писали:
O>Какие именно проблемы в области написания веб-приложений? Да еще причем и гарантированные.
А это ты у mymuss спроси.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Для того, чтобы не зубрить "паттерны"
Паттерны бесполезно зубрить в любом случае, достаточно просто помнить их название, просто чтобы букварь при разговоре о дизайне был общий, не более того.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Паттерны бесполезно зубрить в любом случае, достаточно просто помнить их название, просто чтобы букварь при разговоре о дизайне был общий, не более того.
+1. Так ведь всё равно же зубрят.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Фу ты, ну ты, пальцы гнуты. В 80-90-х обороты IT-индустрии ещё нигде не составляли такой же доли, как сейчас. Это совершенно не означает, что её можно сбрасывать со счетов.
Я и не сбрасываю, я писал только о том, что IT в современном понимании этого слова началось в те годы. Что кардинально поменялось в конце 80-х, начале 90-х? IT ушло из науки и крупного производства и стало вездесущим. Задачи перед ним стали совершенно другими, масштаб вырос на порядки. Фактически то, чем IT занималось раньше превратилось в несколько процентов от нынешнего IT.
ГВ>Ну это не совсем так, хотя здесь просто нужно взять справочник по полупроводниковым приборам и посмотреть наличие аналогов. Кажется, аналоги были даже не у всех микросхем серии 155.
Точнее будет сказать, что микроэлектроника остановилась на каком-то уровне и стала отставать. Пытались догнать, сдирая западные микросхемы, но при том темпе развития элементарно фатально не успевали. Почему развитие отечественной микроэлектроники остановилось — вопрос отдельный.
ГВ>Ну вот видишь, а я это не считаю даже изменениями, не говоря об их критичности.
Зря не считаешь. Тот же переход на ООП породил интересную проблему — программисты, давно работающие испытывали сложности с переходом. Для них не было проблемы перейти с фортрана на C, решать сложнейшие задачи, но новая объектно-ориентированная концепция просто не вписывалась в их понимание. Это была самая настоящая ломка. Частенько недавние бывшие студенты легче воспринимали ООП, чем ветераны. Это я заметил даже в России на опыте коллег, хотя у нас это было малоактуально. Но настоящая проблема была на западе, судя по прочитанными мною статьям.
Если ты не считаешь изменение всего мировоззрения даже изменением, то я не знаю, что ты таковым считаешь. Приведи пример, пожалуйста.
ГВ>Хм. То, о чём я упомянул, применялось в самом обычном бизнес-софте: склады, бухгалтерии, биллинги, какая-то ещё хрень того же порядка. Это узкая специализация?
У меня знакомый работает со складом и бухгалтерией. Чего-то в 1С ничего подобного он не пишет. Я писал биллинг, не очень большой, на полмиллиона абонентов. И скажу я тебе, что самая большая Ж у нас была с самописным языком по разбору логов. Не я его писал, честно, но вроде бы все было написано по-правильному... с точки зрения математика-теоретика, а не архитектурного дизайна... жаль только работало это через раз, очень медленно и что-то поменять там было малореально. Потом перешли, конечно, на нормальное решение (без вышеописанных buzzwords), но сие творение запомнилось мне надолго. С тех пор я считаю, что ДНК у хорошего математика и хорошего программиста различаются значительно.
ГВ>Для того, чтобы не зубрить "паттерны" и массу странных слов, хотя бы. Сильно экономит время и нервы.
Было бы интересно посмотреть пример. Вот возьмем, банальный, всем известный паттерн Abstract Factory. Как его из LSP вывести?
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, SE, Вы писали:
SE>>Такие же проблемы, как и в других областях разработки ПО, и вообще в других областях, гм, народного хозяйства. O>Так какие именно? Я плотненько работал в нескольких областях разработки ПО и не могу придумать ни одной проблемы, которую могла бы создать забытая школьная формула. Я тебе даже больше скажу, довелось мне и с математикой поработать в свое время, так и там это не было бы проблемой, т.к. для формул есть справочники, как для параметров методов документация. Это не то что бы не гарантированная проблема, это гарантированное отсутствие каких либо проблем в разработке вообще.
Забытая формула дает проблемы не сама по себе, забытая формула — показатель того, что человек научившись крутить свою гайку, решительно и бесповоротно поставил крест на всем остальном. И наличие справочника по параметрам функции никак ему не помогает — ну не знает он даже что классы есть готовые, с нужными методами в которых параметры, на которые есть документация. Он ведь гордая птица, ему "левые" знания не нужны, и любознательности у него ноль.
SE>>В отличие от инженера, который знает как свою область, так и несколько смежных областей. O>Математика лишь одна из кучи областей, и я бы сказал — редко встречаемая.
Хм. А по-моему так же часто как и остальные. Вот конечные автоматы просто в каждом проекте из года в год. Может это специфика веба? Деревья тоже с завидной регулярностью встречаются. Тоже специфика? Да, это не вторые производные и не интегралы, это дискретка, но это тоже математика.
И по моему опыту, человек, который бравирует тем, что "это мне не надо", очень часть оказывается не в состоянии качественно сделать скажем хитрую навигаю по по опроснику, просто потому что понятие "конечный автомат" он считает чем то слишком заумным, знай себе клепает десятки if'ов.
Я не сомневаюсь в компетенции всех, кто присутствует на этом сайте, но оглянитесь вокруг, множество людей называют себя программистами, даже не зная разницу между рекурсивными вычислениями и итеративными. Потому что оно им не надо. Незнание площади круга ведь не мешает неподдерживаемый код писать.
Здравствуйте, Геннадий Васильев, Вы писали:
O>>Какие именно проблемы в области написания веб-приложений? Да еще причем и гарантированные. ГВ>А это ты у mymuss спроси.
Спрошу, конечно, хотя о гарантированных проблемах именно ты речь завел, может и нету у него никаких проблем, просто ему просто неприятно работать с теми, кто школу закончил давно и программу школьную забыл.
mymuss, скажи, пожалуйста, каких гарантированных проблем в разработке вебсайтов ты пытаешься избежать, отсеивая собеседуемых таким вопросом по школьной программе? Вот я, например, помимо прочих задаю вопросы про многопоточность, синхронизацию и дедлоки. Ну с этим все понятно, потоки мы используем активно и неправильное обращение с ними приводит к трудноуловимым неприятным ошибкам. К сожалению, отвечают не так что бы много.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Чему учиться? Новые API, тулзы, языки, ОС растут как грибы — ни один вуз за ними не угонится. Правильный вуз даёт прежде всего фундаментальную подготовку, подкрепляя её определённой практикой, но ни в коем случае не наоборот! Под "фундаментом" я не имею в виду "фундаментальные знания об устройстве ОС Windows", конечно... Вот, например, много тебе пришлось изучать такую штуку, как нормальные формы БД после вуза? Мне не пришлось совсем, вполне хватило институтских конспектов, потом купил пару книжек, чтоб не забыть. Та же история с теорией графов, статистикой, формальными грамматиками, теорией автоматов и т.п. И почему-то всё из перечисленного пригодилось. Что я делал не так?
вопрос в том, какеой процент времени ты в вузе изучал то, что пригодилось? в моём вузе то например было всего 10-20%, остальное — многочисленный хлам от матана до автокода
AVK>Паттерны бесполезно зубрить в любом случае, достаточно просто помнить их название, просто чтобы букварь при разговоре о дизайне был общий, не более того.
ну вот, вы говорите, что паттерны достаточно просто помнить их названия. и в то же время требуете, чтобы формулы школьной геометрии кандидат не просто помнил названия, а помнил сами формулы. где логика? программисту паттерны знать не обязательно, но геометрию обязательно.
а между тем, на собеседованиях оч часто спрашивают конкретную реализацию конкретного паттерна. и вот это логично и правильно.
Здравствуйте, игппук, Вы писали:
И>и в то же время требуете, чтобы формулы школьной геометрии кандидат не просто помнил названия, а помнил сами формулы.
Ты меня с кем то спутал. Я нигде такого не требовал.
И> где логика?
Хороший вопрос. К тебе.
И>а между тем, на собеседованиях оч часто спрашивают конкретную реализацию конкретного паттерна. и вот это логично и правильно.
Ты тоже не в курсе, что такое LSP?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, SE, Вы писали:
SE>Забытая формула дает проблемы не сама по себе, забытая формула — показатель того, что человек научившись крутить свою гайку, решительно и бесповоротно поставил крест на всем остальном.
Об этом говорит скорее незнание школьной формулы, а не то, что она забыта.
SE>И наличие справочника по параметрам функции никак ему не помогает — ну не знает он даже что классы есть готовые
Это если не знал, а не забыл. Ключевое слово. Если не применял давно и забыл параметры, то найдет их легко.
SE>Хм. А по-моему так же часто как и остальные. Вот конечные автоматы просто в каждом проекте из года в год.
Бывает, согласен.
SE>Деревья тоже с завидной регулярностью встречаются.
Тоже соглашусь.
SE>Тоже специфика? Да, это не вторые производные и не интегралы, это дискретка, но это тоже математика.
Если таком понимании, то да, ты меня убедил. Такая математика встречается часто, возможно я просто не воспринимаю ее, как математику. В моем понимании математика —
это нечто посложнее
SE>Я не сомневаюсь в компетенции всех, кто присутствует на этом сайте, но оглянитесь вокруг, множество людей называют себя программистами, даже не зная разницу между рекурсивными вычислениями и итеративными.
Есть, согласен. И точно так же считаю, что это плохо.
SE>Потому что оно им не надо. Незнание площади круга ведь не мешает неподдерживаемый код писать.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>вопрос в том, какеой процент времени ты в вузе изучал то, что пригодилось? в моём вузе то например было всего 10-20%, остальное — многочисленный хлам от матана до автокода
Не знаю, как Геннадия, а меня ВУЗ научил прежде всего думать, анализировать, и впитывать знания, в том числе научил и отбрасывать несущественный хлам. Но даже не отбрасывать, а откладывать на потом, потому что мало ли что может понадобиться.
Мне кажется в этом и состоял смысл института — не в тоннах теории, а в выращивании инженерного мышления.