Программирование на мехмате МГУ
3. В аспирантуре кроме халявного жилья смысла нет — для работы в индустрии она не нужна.Есть люди, которые весьма неплохо занимаются вопросами всякой хитрой обработки информации, теориями БД, тем же самым поиском, шифрованием... и все это отлично сочетают с аспирантурой и нормальной работой в индустрии....
Потолок зп разработчикаубери из фака. слишком динамичная величина, а фак статичен
2. Это инженерия, не наука. Важно то, что штука работает, чем корректное объяснение "почему"вот мля из-за этого сплошные wtf
Инструменты различаются по скорости разработки ПО, по скорости работы ПО, по типу программистов.Настоящий программист пишет на всём и выбирает инструмент под задачу )
Настоящий программист пишет на всём и выбирает инструмент под задачу )
настоящий программист сражается с легаси кодом всеми доступными видами ООП паттернов
6. В разработке вы будете общаться больше с компьютером, чем с людьми.
Какие-то аутичные у тебя разработчики. Может все-таки стоит упомянуть важность общения с коллегами, необходимость находить общий язык для правильного решения проблем и так далее?
— в сисадминстве: можно либо бездельничать настроив кой-какие системы, при активном желании можно дорасти до IT-начальника неайтишной конторы.
"либо бездельничать"... а где альтернатива? Опять же перспективы различны: можно стать хоть ИТ-директором, можно уйти в обучение и продажи оборудования. Можно осознав детали внутреннего устройства ОС, программ и сопутствующего, стать хорошим системным разработчиком. В общем, хочется верить, что пункт про системных администраторов будет дополнен. И более радужным что-ли.
И не холивара ради, а ради полноты картины, в девятый пункт хотя бы Perl стоит добавить.
И кстати, может сузить понятие IT: ты пишешь о каком-то своем, но есть еще много разных. Можно заняться научными вычислениями, и это будет уже наука, а не инженерия. Можно работать в тех. поддержке и добиться там своих высот, и это будет ни разработка, ни администрирование. Есть еще люди занимающиеся IT-безопасностью — это тоже IT, но не администрирование и не разработка в чистом виде, но тоже довольная важная часть IT.
В общем, если делать FAQ по IT, то либо делать его максимально полным и непредвзятым. Либо пускай будет "FAQ от для разработчиков (предпочтительно на Python-е)".
чем больше читаю эти буквоки, тем больше понимаю, что это не фак. ты описал так много ограничений, что читатель чувствует ограниченность и тщетность возможных усилий. ты не описал ширь и глубину возможностей.
IT в настоящий момент достаточно сырая сфера деятельности и очень динамичная. в ней даже нет best practices (точнее мне не известны). поэтому все ездят на велосипедах
IT в настоящий момент достаточно сырая сфера деятельности и очень динамичная. в ней даже нет best practices (точнее мне не известны). поэтому все ездят на велосипедах
Это распространенное заблуждение. Сейчас большая часть работы программиста состоит в прикручивании к программе библиотек. Знания о том какую библиотеку стоит использовать, а какую — нет, просто так не получить. Это труднее чем выучить синтаксис.
вот-вот. описанный фак похож на описание компашки, которая занимается потоковым программированием, говносайтоклепание итд. которая ни разу не писала больших промышленных решений
Я сам вижу что получился у меня FAQ для разработчика. Выложил как раз чтобы получить комментарии. Буду апдейтить заглавный пост.
PS: ссылок на питон постарался избежать. Если нет — покажи.
Pps : подробно отвечу позже.
PS: ссылок на питон постарался избежать. Если нет — покажи.
Pps : подробно отвечу позже.
Ну ты же не только критиковать умеешь? Ждем описания от гуру :-)
Есть зависимость от инструментария с которым работаете. От инструментов зависят задачи и перескочить на другие инструменты будет сложно.
PHP,Ruby —сайтостроение
Python — прикладные системы, много применений
Java — много чего
С# — корпоративные приложения
С — системное программирование
сейчас работаю над системой у которой совокупность всего этого, а система обыкновенная корп трехзвенка.
а вообще если руки прямые не важно на чем писать
поэтому утверждение про перескакивание спорноЗнания о том какую библиотеку стоит использовать, а какую — нет, просто так не получить.А это, разве, не выбор инструмента?
Выбор. Я и говорю: перескакивание с языка на язык это вопрос мозгов, научиться думать на другом языке еще можно. А при использовании библиотеки/конкретной реализации вылезут всякие проблемы, которых в документации не описано. Это уже вопрос опыта.
а зачем было включать сисадминство в список, если ты не имеешь о нем никакого представления?
Ты читай чо пишу: представление какое-то имею. Затем и запостил чтоб понять насколько правильное. Если неправильное — напиши свое, правильное. Вот 'у например спасибо.
[IT] FAQ: Юноше, обдумывающему житье.По заголовку думал, тут про ипотеку или про суицид.
Текст нормальный, в в основном согласен.
Реально лекцию читал старшекурам? Я помню, когда сам учился, ходил на подобную лекцию году так в 2003.
Организатор - кафедра теорвера, лекция была в 1616. 2 страховщика пришли и рассказывали про работу.
Один из них очень смущался и запинался все время, но интересные вещи рассказывал, как ему в конце 80-х удалось составить и применить математеческие модели для решения реальных проблем на больших производствах и как он преодолевал организационное сопротивление, пока их внедрял.
сисадминство — это постоянное обучение, то есть, решая стать сисадмином, человек должен понимать, что момент, когда ты знаешь всё, и можно больше ничего не делать, не наступит никогда
так как в россии большинство компаний жмотятся на серьезное обучение, нужно еще быть готовым к тому, что знания придется искать самостоятельно, порой выкапывая их по крупицам из тонн говна
сисадминство — это всегда работа в незнакомых условиях. тебе придется искать решение проблемы по косвенным признакам, причем иногда эти признаки настолько не связаны с сутью проблемы, что очень сложно принимать их в расчет
сисадмину всю свою карьеру придется изучать огромное количество технической документации и запоминать ее, даже если она не нужна прямо сейчас
так что хорошим сисадмином может стать только человек с сильными аналитическими способностями, умеющий держать в голове и свзяывать между собой огромное количество информации
вообще, из меня фиговый советчик, так как я не мальчик, и не ебу как это все дается мальчикам
для меня админство всегда было наиболее сложной частью моей работы, в основном, правда, из-за того, что невозможно собрать статистику ошибок, ну и из-за того, что я без общения с людьми схожу с ума
так как в россии большинство компаний жмотятся на серьезное обучение, нужно еще быть готовым к тому, что знания придется искать самостоятельно, порой выкапывая их по крупицам из тонн говна
сисадминство — это всегда работа в незнакомых условиях. тебе придется искать решение проблемы по косвенным признакам, причем иногда эти признаки настолько не связаны с сутью проблемы, что очень сложно принимать их в расчет
сисадмину всю свою карьеру придется изучать огромное количество технической документации и запоминать ее, даже если она не нужна прямо сейчас
так что хорошим сисадмином может стать только человек с сильными аналитическими способностями, умеющий держать в голове и свзяывать между собой огромное количество информации
вообще, из меня фиговый советчик, так как я не мальчик, и не ебу как это все дается мальчикам
для меня админство всегда было наиболее сложной частью моей работы, в основном, правда, из-за того, что невозможно собрать статистику ошибок, ну и из-за того, что я без общения с людьми схожу с ума
ах да, кстати
руководство ИТ отделом непрофильной компании — это то еще счастье
во-первых, это не айтишная позиция ни разу. от руководителя ИТ требуются следующие навыки: умение говорить и умение делать красивые презентации, чтобы давали бабло
и работа ИТ директора состоит в этих разговорах и презентациях, нужно уметь посчитать стоимость проекта в экселе и все такое
если компания не очень большая, еще придется общаться с поставщиками и бухгалтерией
большинство руководителей ИТ в непрофильных компаниях разбираются в вопросе гораздо хуже своих сотрудников
ставить себе цель — стать ИТ директором — не стоит, я вот поставила и ошиблась
то есть когда-то мне было это все интересно, но сейчас я понимаю, что настраивать системы гораздо интереснее, чем рисовать презентации
руководство ИТ отделом непрофильной компании — это то еще счастье
во-первых, это не айтишная позиция ни разу. от руководителя ИТ требуются следующие навыки: умение говорить и умение делать красивые презентации, чтобы давали бабло
и работа ИТ директора состоит в этих разговорах и презентациях, нужно уметь посчитать стоимость проекта в экселе и все такое
если компания не очень большая, еще придется общаться с поставщиками и бухгалтерией
большинство руководителей ИТ в непрофильных компаниях разбираются в вопросе гораздо хуже своих сотрудников
ставить себе цель — стать ИТ директором — не стоит, я вот поставила и ошиблась
то есть когда-то мне было это все интересно, но сейчас я понимаю, что настраивать системы гораздо интереснее, чем рисовать презентации
В общем, мне кажется, что задуманный FAQ будет аналогичен попытке ответа на вопрос о смысле жизни. Уж слишком много здесь вариантов, предпочтений, точек зрения, совпадений, случайностей и так далее. И то, что подойдет для одного человека, абсолютно не подойдет для другого. Ce la vie.
На мой взгляд, будет полезней показать особенности каждого выбора на конкретной истории конкретного человека с рассказом о совершенных достижениях и досадных ошибках. Ради такого дела (если будет интерес, конечно же) я готов написать небольшой рассказ о том, как я стал сетевым инженером: с чего все началось, как я сделал этот выбор, какие были альтернативы, на какие грабли каждый будущий сетевой инженер должен наступить сам, а какие повторять не стоит и как я вижу свои перспективы на данный момент.
Мне кажется, что если различные люди из ИТ работающие в различных направлениях сделают аналогичные рассказы, то это позволит каждому читателю выбрать наиболее подходящее для себя решение, ну или хотя бы иметь представление что его ждет, если он решит заняться тем-то или тем-то.
На мой взгляд, будет полезней показать особенности каждого выбора на конкретной истории конкретного человека с рассказом о совершенных достижениях и досадных ошибках. Ради такого дела (если будет интерес, конечно же) я готов написать небольшой рассказ о том, как я стал сетевым инженером: с чего все началось, как я сделал этот выбор, какие были альтернативы, на какие грабли каждый будущий сетевой инженер должен наступить сам, а какие повторять не стоит и как я вижу свои перспективы на данный момент.
Мне кажется, что если различные люди из ИТ работающие в различных направлениях сделают аналогичные рассказы, то это позволит каждому читателю выбрать наиболее подходящее для себя решение, ну или хотя бы иметь представление что его ждет, если он решит заняться тем-то или тем-то.
Важно то, что штука работает, чем корректное объяснение "почему".
ГОЛАКТЕКО ОПАСНОСТЕПункт 9 также жжот.
6. В разработке вы будете общаться больше с компьютером, чем с людьми. Если любите поговорить и помахать руками — будет тяжелоПока что все наоборот - отсутствие необходимых навыков общения с аудиторией не позволило донести информацию.
Получилось плохо — не было проектора, говорю тихо, народ к тому времени уже устал.А вообще две эти цитаты говорят о некоторой некоммуникабельности, и общение с людьми для тебя - тягость?
Что наоборот? Я где-то говорил что умею выступать? 
Нет, просто ты говоришь что умение "любить поговорить" будет мешать 
И я написал, что с этим не согласен, и что это полезно в любой профессии, IT или не IT
Вот "помахать руками", пожалуй, будет мешать
И я написал, что с этим не согласен, и что это полезно в любой профессии, IT или не IT
Вот "помахать руками", пожалуй, будет мешать
Вот "помахать руками", пожалуй, будет мешатьне, тоже будет помогать: можно в ебальник двинуть охуевшему оппоненту
Читай что написано, а не то что ты себе придумал. Попробуй перечитывать.
Найди, например, место где я сказал что умение поговорить будет мешать.
Найди, например, место где я сказал что умение поговорить будет мешать.
6. В разработке вы будете общаться больше с компьютером, чем с людьми. Если любите поговорить и помахать руками — будет тяжелоВсе понятно. Тут конечно имелось в виду, что будет тяжело на обед ходить, наверное? Извините
Понятно что тебе непонятно: умение и желание это разные вещи.
Выступать перед полной аудиторией это не работа разработчика, это тоже, надеюсь, понятно.
Выступить за обедом и перел аудиторией это разные вещи. Надеюсь, понятно?
Выступать перед полной аудиторией это не работа разработчика, это тоже, надеюсь, понятно.
Выступить за обедом и перел аудиторией это разные вещи. Надеюсь, понятно?
Так, пишу алгоритм, раз IT-кун моя не понимай.
Поднять глаза на два поста выше. Перечитать. Подумать.
Ты спросил: "где я написал, что мешает (видимо, карьере разработчика)?". Я тебе показал где ты это написал, или не показал?
Без желания поговорить, кстати, умения не будет, что ты своим примером неудачной лекции и показал (это на случай если ты хочешь меня поймать на разнице между хотеть/уметь).
>ы спросил: "где я написал, что мешает?". Я тебе указал где ты это написал?
куда ты указал - написано не то, на что ты намекал
куда ты указал - написано не то, на что ты намекал
Выступать перед полной аудиторией это не работа разработчика, это тоже, надеюсь, понятно.крутые разработчики выступают на айти-конференциях, и довольно часто неплохо это делают
может, это и не часть их работы, но что не мешает им — это точно
А сисадмину в рамках одной небольшой конторы просто идти некуда кроме как в ИТ-директоры. Либо сваливать в более профильное админство в большую контору, либо основательно менять сферу деятельности.
Помимо критики от -а (с которым я частично согласен я ещё прицеплюсь к этому пункту:
Другое дело, если речь о написании библиотеки, которая будет использоваться много лет во множестве проектов. Или о приложении, которое будет работать много лет на множестве инсталляций.
Конечно, с временным кодом приходится сталкиваться чаще. Поэтому инженерии больше чем науки.
2. Это инженерия, не наука. Важнее то, что штука работает, чем корректное объяснение "почему".Не правда. Если код недолгоживущий, то таки да. То есть можно забить и не анализировать веб-сайт который держит текущую нагрузку и прогнозы на рост нагрузки явно не более одного порядка. Да и если очевидно, что через год будет новая версия. А ещё через год ещё более новая.
Другое дело, если речь о написании библиотеки, которая будет использоваться много лет во множестве проектов. Или о приложении, которое будет работать много лет на множестве инсталляций.
Конечно, с временным кодом приходится сталкиваться чаще. Поэтому инженерии больше чем науки.
если речь о написании библиотеки, которая будет использоваться много лет во множестве проектов. Или о приложении, которое будет работать много лет на множестве инсталляций.Windows разных версий, 1C... надо продолжать?
Ну да, именно разработчики Windows и 1C, самих этих программ, должны куда более научно подходить к своему ремеслу. Потому как каждая миллисекунда, которую они поленились выиграть с помощью оптимизации кода в масштабах Земли собирается в человекочасы проведённые в ожидании перед песочными часиками.
Ну да, именно разработчики Windows и 1C, самих этих программ, должны куда более научно подходить к своему ремеслу.ну как бе... Разработчики этих программ подходят так, как говорят манагеры. А манагерам важны сроки, ресурсы и т.д. Я те про реальность говорю
Поднимись по карьерной лестнице и стань манагером разработчиков, которые пишут эти программы.
Поднимись по карьерной лестнице и станьтаким же.
Не правда. Если код недолгоживущий, то таки да. То есть можно забить и не анализировать веб-сайт который держит текущую нагрузку и прогнозы на рост нагрузки явно не более одного порядка. Да и если очевидно, что через год будет новая версия. А ещё через год ещё более новая.Проиллюстрирую что я имел в виду, чтобы зря не спорить:
Какие-то аутичные у тебя разработчики.Ты так говоришь как будто это что-то плохое. Аутист-шизоид это нормальный психотип программиста. Тебе эти слова кажутся ругательными?
http://rudnevslovar.narod.ru/f3_h1.htm#har — вот только не хочу обсуждать правдоподобность такого деления.
Может все-таки стоит упомянуть важность общения с коллегами, необходимость находить общий язык для правильного решения проблем и так далее?
Зачем, это очевидно.
"либо бездельничать"... а где альтернатива?
Исправил.
можно уйти в обучение и продажи оборудования. Можно ... стать хорошим системным разработчиком. В общем, хочется верить, что пункт про системных администраторов будет дополнен. И более радужным что-ли.
Интересно. Что-нибудь про количество идущих сказать можно?
в девятый пункт хотя бы Perl стоит добавить
Угу. Но он вроде умер
Можно работать в тех. поддержке и добиться там своих высот, и это будет ни разработка, ни администрирование. Есть еще люди занимающиеся IT-безопасностью — это тоже IT, но не администрирование и не разработка в чистом виде, но тоже довольная важная часть IT.
С удовольствием бы узнал про работу техподдержки и безопасников. Техподдержка которую я видел на следующей карьерной ступени превращалась в сисадминов.
ok, я понял.
Единственная тогда просьба не называть это "FAQ по всему IT", а просто назови свой труд "Взгляд на разработчиков глазами Василия Федорова" — это будет лучше отражать содержание и позволит избежать лишних вопросов и недоразумений.
Единственная тогда просьба не называть это "FAQ по всему IT", а просто назови свой труд "Взгляд на разработчиков глазами Василия Федорова" — это будет лучше отражать содержание и позволит избежать лишних вопросов и недоразумений.
вот мля из-за этого сплошные wtfподдерживаю, с теми, кто не понимает необходимость доказательства (хотя бы набросков в голове) работоспособности очень тяжело общаться и тяжело поддерживать код
Единственная тогда просьба не называть это "FAQ по всему IT", а просто назови свой труд "Взгляд на разработчиков глазами Василия Федорова"Проигнорирую, извини.
Да, эта картинка отлично иллюстрирует что представляет из себя computer science с точки зрения инженеров.
Поднимись по карьерной лестнице и стань манагером разработчиков, которые пишут эти программы.Боюсь тебя огорчить но с точки зрения манагера Виндоус и 1С — очень и очень успешные проекты.
Сейчас большая часть работы программиста состоит в прикручивании к программе библиотек. Знания о том какую библиотеку стоит использовать, а какую — нет, просто так не получить. Это труднее чем выучить синтаксис.Тут в треде про ООП был тезис о том, что библиотеки - суть те же языки.
ага, это так же как с машинами. Пипл же хавает.
Да, эта картинка отлично иллюстрирует что представляет из себя computer science с точки зрения инженеров.А какую точку зрения, если не секрет, иллюстрирует твое мнение что мол если программа работает хорошо то в ней есть computer science?
Ты сейчас нагло приписал мне какое-то мнение, которое сам придумал.
Можно было бы добавить про перспективы во внедрении - перейти в обслуживаемую организацию на какую-нибудь руководящую должность. Несколько знакомых так в нефтянку перешли - из SAP-консультантов.
Ты сейчас нагло приписал мне какое-то мнение, которое сам придумал.Не так уж и нагло, цитирую:
именно разработчики Windows и 1C, самих этих программ, должны куда более научно подходить к своему ремеслу
Что здесь общего?
если программа работает хорошо то в ней есть computer science
именно разработчики Windows и 1C, самих этих программ, должны куда более научно подходить к своему ремеслу
Тут в треде про ООП был тезис о том, что библиотеки - суть те же языки.Треду ничем помочь не могу.
Про "языки" ситуация такая: есть язык-абстракция — это способ мышления и записи мыслей. Есть язык-библиотека, это реализация обработчика мыслей в реальном мире. Язык-библиотека это инструмент, как и любой другой — сначала я и говорил про инструменты.
Высказывание что мол хороший программист способен писать на любом языке относится к абстракции — хороший программист способен выучить разные способы записи мыслей, способен научиться думать так чтоб его мысли к этому способу записи подходили оптимально. Это правда.
Что здесь общего?Общего? Ну хз, давай выясним что такое по-твоему наука.
Давай представим что я тупой а ты гуру, и расскажи мне, пожалуйста, что там за наука:
Не правда. Если код недолгоживущий, то таки да. То есть можно забить и не анализировать веб-сайт который держит текущую нагрузку и прогнозы на рост нагрузки явно не более одного порядка. Да и если очевидно, что через год будет новая версия. А ещё через год ещё более новая.
Другое дело, если речь о написании библиотеки, которая будет использоваться много лет во множестве проектов. Или о приложении, которое будет работать много лет на множестве инсталляций.
Конечно, с временным кодом приходится сталкиваться чаще. Поэтому инженерии больше чем науки
Например, в написании библиотеки.
Чтобы ты не сел нечаянно в лужу, расскажу, что, например, проверить что в программе не течет память — это чисто инженерное решение, проверили и все.
Так же как при строительстве мостов: можно делать такие, которые падают от ветра, можно такие. которые качаются, можно делать как следует. Но это не наука как ни крути.
Жду с нетерпением!
Что называть наукой, а что нет — это уже вопрос философский.
Лично я считаю, что наука делится (условно) на фундаментальную и прикладную. При этом не считаю, что одно из них лучше другого.
Опять же ИМХО инженерное дело — строить мосты — это наука. Лечить людей — тоже наука (хотя казалось бы, что сложного, забил симптомы в гугл и готово, зачем столько лет учиться).
Если конечно считать наукой — только прорывы между парадигмами, то учеными можно считать 1-2 человек за 20 лет. А остальных просто аналитиками. На мой взгляд изменение терминологии ничего не меняет. (Переименовали "продавца" в "менеджера по продажам", что продажи пошли лучше? Сильно сомневаюсь.)
Лично я считаю, что наука делится (условно) на фундаментальную и прикладную. При этом не считаю, что одно из них лучше другого.
Опять же ИМХО инженерное дело — строить мосты — это наука. Лечить людей — тоже наука (хотя казалось бы, что сложного, забил симптомы в гугл и готово, зачем столько лет учиться).
Если конечно считать наукой — только прорывы между парадигмами, то учеными можно считать 1-2 человек за 20 лет. А остальных просто аналитиками. На мой взгляд изменение терминологии ничего не меняет. (Переименовали "продавца" в "менеджера по продажам", что продажи пошли лучше? Сильно сомневаюсь.)
>Что называть наукой, а что нет — это уже вопрос философский.
>Лично я считаю, что наука делится (условно) на фундаментальную и прикладную. При этом не считаю, что одно из них лучше другого.
между наукой и инженерией есть принципиальное отличие.
ученый - исследует, инженер - применяет готовый алгоритм.
кнут - ученый, исследующий разные варианты сортировки, а программист, выбирающий между quicksort, mergesort и т.д. - инженер.
>Лично я считаю, что наука делится (условно) на фундаментальную и прикладную. При этом не считаю, что одно из них лучше другого.
между наукой и инженерией есть принципиальное отличие.
ученый - исследует, инженер - применяет готовый алгоритм.
кнут - ученый, исследующий разные варианты сортировки, а программист, выбирающий между quicksort, mergesort и т.д. - инженер.
— в разработке: программист — ведущий программист — системный архитектор или менеджер. Чем выше поднимаетесь тем важнее социальные навыки. Потолок зп разработчика — 150 тыр.а какова судьба "внедренцев" - ныне модного направления?
— в сисадминстве: можно либо бездельничать настроив кой-какие системы, либо при активном желании можно дорасти до IT-начальника неайтишной конторы.
а какова судьба "внедренцев" - ныне модного направления?чуть выше пара слов.
Как это выглядит изнутри я не знаю, могу наврать, надеюсь кто-то поправит.
Я больше интересовался ERP:
— Тоже есть зависимость от инструментов — что именно внедрять, 1С, SAP или что-то еще.
— Крупный бизнес в большой степени уже окучен, у MS, SAP и других основные надежды на рост автоматизации среднего и малого бизнеса (выпускают дешевые версии, например).
Как следствие количество внедренцев должно вырасти, их средние зарплаты должны упасть.
между наукой и инженерией есть принципиальное отличие.Пока у тебя демагогия. И те и другие делают и то и другое, и исследуют и применяют готовые решения. Ты где-то забыл вставить слово "только"? Будешь уточнять?
ученый - исследует, инженер - применяет готовый алгоритм.
Так же как при строительстве мостов: можно делать такие, которые падают от ветра, можно такие. которые качаются, можно делать как следует. Но это не наука как ни крути.по поводу мостов, у меня есть знакомый (сейчас уже в пожилом возрасте он является автором стали, из которой строят наиболее длинные мосты (он называл какие, сейчас не помню). Да, это наука. И он кандидат технических наук. При этом он работал непосредственно на металлургических заводах (и во время войны тоже).
Так же в технологиях для обработки информации. Ты можешь работать с уже готовыми технологиями, но по ходу дела могут возникать новые. И это уже наука. Грань сложно уловима, да и зачем проводить эту грань?
>Пока у тебя демагогия. И те и другие делают и то и другое, и исследуют и применяют готовые решения. Ты где-то забыл вставить слово "только"? Будешь уточнять?
уборщица - тоже исследует. например, может исследовать куда запропастилась тряпка.
ученый может работать по алгоритму - например, выписывая список всех известных алгоритмов сортировки, и дальше опять же алгоритму будет сравнивать сильные и слабые стороны, но при этом сама постановка и формулировка полной задачи (сравнить алгоритмы сортировки) - это сложная исследовательская задача.
деление по исследует/применяет нечеткий алгоритм/применяет четкий алгоритм - делается по конечной цели и по тому, какой вид деятельности существенен для данной деятельности.
и ученого конечная цель - исследовать,
у инженера конечная цель - применить знания из института(нечеткие алгоритмы) для решения текущей задачи,
у рабочего/служащего конечная цель - выполнить инструкцию (готовый четкий алгоритм) выученную в пту или при обучении на работе
уборщица - тоже исследует. например, может исследовать куда запропастилась тряпка.
ученый может работать по алгоритму - например, выписывая список всех известных алгоритмов сортировки, и дальше опять же алгоритму будет сравнивать сильные и слабые стороны, но при этом сама постановка и формулировка полной задачи (сравнить алгоритмы сортировки) - это сложная исследовательская задача.
деление по исследует/применяет нечеткий алгоритм/применяет четкий алгоритм - делается по конечной цели и по тому, какой вид деятельности существенен для данной деятельности.
и ученого конечная цель - исследовать,
у инженера конечная цель - применить знания из института(нечеткие алгоритмы) для решения текущей задачи,
у рабочего/служащего конечная цель - выполнить инструкцию (готовый четкий алгоритм) выученную в пту или при обучении на работе
>по поводу мостов, у меня есть знакомый (сейчас уже в пожилом возрасте он является автором стали, из которой строят наиболее длинные мосты (он называл какие, сейчас не помню). Да, это наука. И он кандидат технических наук. При этом он работал непосредственно на металлургических заводах (и во время войны тоже).
логично же - самые длинные, значит уникальные, которых до этого делали мало - готовых алгоритмов мало, требуется большая доля исследований
> Грань сложно уловима, да и зачем проводить эту грань?
тебя кстати не смущает, что в цветовом спектре выделяют, например, три цвета: красный, зеленый и синий - и называют их опорными, не смотря на то, что грань условная, и что в каждом реальном цвете есть все три компоненты?
или что всё цветовое пространство люди обычно делят на 9(10) цветов: красный, синий(+голубой желтый, зеленый, фиолетовый, оранжевый, белый, серый, черный?
логично же - самые длинные, значит уникальные, которых до этого делали мало - готовых алгоритмов мало, требуется большая доля исследований
> Грань сложно уловима, да и зачем проводить эту грань?
тебя кстати не смущает, что в цветовом спектре выделяют, например, три цвета: красный, зеленый и синий - и называют их опорными, не смотря на то, что грань условная, и что в каждом реальном цвете есть все три компоненты?
или что всё цветовое пространство люди обычно делят на 9(10) цветов: красный, синий(+голубой желтый, зеленый, фиолетовый, оранжевый, белый, серый, черный?
тебя кстати не смущает, что в цветовом спектре выделяют, например, три цвета: красный, зеленый и синий - и называют их опорными, не смотря на то, что грань условная, и что в каждом реальном цвете есть все три компоненты?мне кажется или ты, действительно, плохо знаешь школьную программу?
>мне кажется или ты, действительно, плохо знаешь школьную программу?
какую из?
какую из?
ну про цвета
>ну про цвета
просвети, мне даже интересно стало, чему это такому обучают в школе
просвети, мне даже интересно стало, чему это такому обучают в школе
просвети, мне даже интересно стало, чему это такому обучают в школену, цвет это вовсе не условность, а вполне конкретная вещь — длина волны света.
А передача цвета (в устройствах, фотографиях и т.п.) через смешение трех цветов RGB это чисто из-за особенности человеческого глаза (три вида колбочек, как-то так).
>А передачу цвета через смешения трех цветов RGB это чисто из-за особенности человеческого глаза (три вида колбочек, как-то так).
так тебе в школе рассказали почему именно красный, зеленый и синий?
так тебе в школе рассказали почему именно красный, зеленый и синий?
Там пики у гауссиан чувствительности этих рецепторов.
>Там пики у гауссиан чувствительности этих рецепторов.
это заблуждение
420-440 - это скорее фиолетовый, чем синий
530-540 - зеленый
560-580 - желтый
это заблуждение
The human eye has photoreceptors (called cone cells) for medium- and high-brightness color vision, with sensitivity peaks in short (S, 420–440 nm middle (M, 530–540 nm and long (L, 560–580 nm) wavelengthshttp://en.wikipedia.org/wiki/CIE_1931_color_space
420-440 - это скорее фиолетовый, чем синий
530-540 - зеленый
560-580 - желтый
Там потом картинки идут — красный пик на 600.
>там потом картинки идут — красный пик на 600.
и в русском, и в английском - это все равно оранжевый(orange а не красный(red)
и в русском, и в английском - это все равно оранжевый(orange а не красный(red)
не уводи разговор в сторону, вернемся к твоей фразе о том, что грань между цветами условная. Ты спорол чушь, признаешь?
>не уводи в сторону разговор, вернемся к твоей фразе о том, что грань между цветами условная. Ты спорол чушь, признаешь?
ты готов четко доказать где кончается красный, и где начинается оранжевый?
или в чем именно ты отрицаешь условность понятия цвета?
ты готов четко доказать где кончается красный, и где начинается оранжевый?
или в чем именно ты отрицаешь условность понятия цвета?
или в чем именно ты отрицаешь условность понятия цвета?в понятии цвета условностей нет вообще, там всё четко (можно померить с хорошей точностью).
>в понятии цвета условностей нет вообще, там всё четко (можно померить с хорошей точностью).
названия цветов условны
и выделение базовых цветов тоже условно
зы
и соответственно, выделение трех видов работ в виде базовых: исследование, инженерия, труд рабочего - тоже условность
ззы
какой именно работой в каждый момент времени занимается конкретный человек тоже можно измерить с заданной точностью, что позволит с заданной точностью "разложить" на "базовые" работы
названия цветов условны
и выделение базовых цветов тоже условно
зы
и соответственно, выделение трех видов работ в виде базовых: исследование, инженерия, труд рабочего - тоже условность
ззы
какой именно работой в каждый момент времени занимается конкретный человек тоже можно измерить с заданной точностью, что позволит с заданной точностью "разложить" на "базовые" работы
названия цветов условныэто только вопрос обозначений, такой-то диапазон длин вол называем таким-то цветом, тут нет "сложно уловимой грани"
и выделение базовых цветов тоже условно
это вопрос выбора/договоренности, какие "лампочки" (с какой длинной волны) вставляем в девайс, проблемы измерений тут нет, неуловимой грани нет
и соответственно, выделение трех видов работ в виде базовых: исследование, инженерия, труд рабочего - тоже условность
здесь нет аналога измеряемой физической величины — длины волны
это вопрос выбора/договоренности, какие "лампочки" (с какой длинной волны) вставляем в девайс, проблемы измерений тут нет, неуловимой грани нетцвет — скорее функция (интенсивности/отражающей способности от длины волны а информация с сетчатки ещё и конкретно перерабатывается. Некая условность, имхо, есть. Одна и та же лампочка, с одной и той же спектральной характеристикой, может по-разному восприниматься в зависимости от фонового освещения. Зелёная лампочка может казаться чуть ли не синей при одном фоновом освещении, и красной — при другом.
Хотя, если по теме ДаркГрея (уже когда-то где-то обсуждалось то как-то это притянуто всё. Пусть есть рабочий, который хочет к грузу трос привязать, чтобы с помощью крана поднять. Если он открывает справочник, выискивает информацию про то, какой толщины должен быть трос для груза заданной массы, то это уже инженер. А если по принципу "постепенно увеличивать толщину троса, пока не перестанет рваться" действует — то уже почти учёный-исследователь
По мне, так интеллектуальную деятельность можно на две основные категории разделить, на решение прямых и обратных задач. Прямые — это зная законы и начальные условия, построить или рассчитать что-то. Обратные — зная результаты опытов/наблюдений, найти или начальные условия, или законы. Соответственно, кому-то лучше даются прямые, кому-то обратные задачи, ну и в каких-то областях больше с прямыми, в каких-то больше с обратными работают.
цвет — скорее функция (интенсивности/отражающей способности от длины волны а информация с сетчатки ещё и конкретно перерабатывается. Некая условность, имхо, есть. Одна и та же лампочка, с одной и той же спектральной характеристикой, может по-разному восприниматься в зависимости от фонового освещения. Зелёная лампочка может казаться чуть ли не синей при одном фоновом освещении, и красной — при другом.Есть физическая величина цвет, как характеристика излучающего/отражающего объекта, это строго длина волны. И есть восприятие цвета человеком (которое много от чего зависит, в том числе, от конкретного человека). Не надо эти два понятия смешивать.
Так вот, где у нас аналог хорошо измеряемой физической величины в случае с измерением количества науки и количества инженерии у конкретного объекта (работника)? Аналога просто нет. Поэтому аналогия с цветом была неуместна.
По мне, так интеллектуальную деятельность можно на две основные категории разделитьа нафига?
С какой целью делаем какое-либо разделение?
О, кстати, недавно видел ещё одну знакомую - так она из фирмы, занимающейся внедрением, перешла аж в Генпрокуратуру.
frostenrus
Недавно попытался рассказать про IT мехматянам-старшекурсникам. Получилось плохо — не было проектора, говорю тихо, народ к тому времени уже устал.Запишу тут для будущих поколений:
0. Имхо это не столько про зарабатывание бабла, сколько про интересную работу.
1. IT это не только разработка ПО, это всякая разнообразная работа с информацией. Тестирование, системное администрирование, внедрение систем, разработка ПО и т.д.
2. Это инженерия, не наука. Важнее то, что штука работает, чем корректное объяснение "почему".
3. В аспирантуре кроме халявного жилья смысла нет — для работы в индустрии она не нужна. Нужна только в конторе типа Гугла для галочки. На сайте Стэнфорда можете найти что это верно и за границей.
4. Быстро кодить на мехмате не учат. Но это и не нужно. От правильно придуманной архитектуры, от правильных идей польза гораздо больше.
5. То что вы выучили какой-нибудь действительный анализ — неважно. Важно что вы его _смогли_ выучить. Именно поэтому средний балл важен — это уровень мозгов.
6. В разработке вы будете общаться больше с компьютером, чем с людьми. Если любите поговорить и помахать руками — будет тяжело. Тем не менее самые хорошие менеджеры получаются из разработчиков, которые умеют общаться. Таких мало.
7. Карьерный рост:
— в разработке: программист — ведущий программист — системный архитектор или менеджер. Чем выше поднимаетесь тем важнее социальные навыки. Потолок зп разработчика — 150 тыр.
— в сисадминстве: можно либо бездельничать настроив кой-какие системы, либо при активном желании можно дорасти до IT-начальника неайтишной конторы.
8. Как выбрать:
Q: Айтишная компания или нет?
A: Для любой области верно: если хотите стать профессионалом в области — идите в ту компанию, которая на этой области специализируется.
Q: Большая или маленькая?
A: В большой будете крутым специалистом по узкому вопросу, в маленькой будет шире кругозор.
9. Есть зависимость от инструментария с которым работаете. От инструментов зависят задачи и перескочить на другие инструменты будет сложно.
PHP, Ruby, Perl — сайтостроение
Python — прикладные системы, много применений
Java — много чего
С# — корпоративные приложения
С — системное программирование
и т.д.
Инструменты различаются по скорости разработки ПО, по скорости работы ПО, по типу программистов.
PS: Кроме холивара, который тут можно развести, интересны дополнения к FAQ.