Насколько крупных? Критерии? Ответить не могу, не знаю что вы считаете крупными софтинами, а что - нет.
Кроме того - я бы хотел узнать, о каком виде софта вы спрашиваете.
У меня есть примеры крупных проектов, в которых было действительно много разработки. И это софтиной не назовешь - это гигантские системы.

Есть, но конкретно сказать я по причинам справедливого неразглашения инфы ничего не могу.
Если о сути, то да, мне известна некоторая телеком компания, где действительно было доверено интегратору кастомизировать часть биллинга. Я подозреваю, что пример далеко не единичный.


Это вопрос качества того поставщика услуг, которому вы что-то доверили.
Есть топовые интеграторы, есть дешевые.


То, что вы называете "нехилым пластом математики" вам расскажет в любом более менее приличном университете каждый препод линейной алгебры и аналитической геометрии, чего нельзя сказать о Java ориентированных технологиях. То, что системное программирование априори более требовательно к квалификации, чем прикладное - я с этим в данном виде без дополнительных условий согласиться никак уж не могу. Требование к квалификации зависит очевидным образом не только от вида программирования (системное, прикладное), но и от сути реализуемого проекта и его размаха. Кроме того, в системном программировании решается безусловно более узкий круг задач, которые более понятны всем участникам процесса, по причине их неприкладной природы и , собственно, в таких проектах необходимость в аналитике куда более низкая. Такое программирование менее требовательно к процессу разработки. Его сложность, по сути, заключается не в понимании и контроле требований от постановщика к реализатору и командной организации, а больше в низком уровне оперирования и сложных механизмах взаимодействий объектов и железа.


Не понял, как слабо представляете? Предположим Web приложения на JSP - вот это и есть применение Java в чистом виде. Это может быть ни разу не интеграционный проект в классическом смысле слова.


МСК не единственный город на Руси - это раз. Программистов на Java обычно берут пачками - это два и количество вакансий куда меньше, чем количество реально нужных людей. Бизнес приложения под заказ на С++ становятся редкостью и я таких проектов дано не видел. а Java сплошь и рядом, практически в любом проекте и почти любой вендоровской системе- три.



Не видели крупных решений? Я видел.


См. "крупные решения"


Это которые?



Много ли системных программистов способны спроектировать ИТ структуру банка и оценить её риски и производительность? С помощью рекуррентных формул будете оценивать?
В софтвере и интеграции совсем другие сложности и другие условия и природа работы, чем в системном программировании. Я склонен думать, что у вас сформировались достаточно ограниченные представления о сложности проектов и , собственно, об аспектах сложности.

На мой вопрос про ваше понимание квалификации вы не ответили.


Штучный народ.

ну давайте назовёт крупной систему (автономную, не среду интеграции), на разработку которой потрачено более 3 лет усилий более чем 30 разработчиков, с итоговой стоимостью порядка 10 миллионов, и которые можно тиражировать. вот в посте проскочило нужное слово - в россии практически нету вендоров. есть 1c, cboss, лаборатория касперского. что-то сходу больше ничего в голову и не приходит, а это очень печально.
про телеком - это ведь не из большой тройки, так ведь? хотя бы производителя биллинга назвать можно? это был именно интегратор в классическом смысле или сабконтракторы в стиле люксофта?

далее много текста, в котором сравнивается системный программист с архитектором интеграционного проекта я уже отвечал на этот вопрос - квалификация подобного рода не связана с наличием знаний жавы я совершенно не спорю с тем, что в этих проектах всё не просто на уровне архитектуры, но какие там сложности на уровне непосредственно написания ejb или сервлетов? мы ведь речь вели именно о вакансиях рядовых программистов, не архитекторов.

про математику - математика рендерера примерно на 2 порядка сложнее, чем вы её себе представляете:) для сравнения - в нашем биллинге математика на уровне 3 класса, ибо большего бизнесу не требуется. жаву не изучают у нас в институтах, но, простите, сейчас в мире написание кода на уровне ремесленничества, и отдано на откуп армии индусов. готов поспорить, что вменяемый программист, ни разу до того на жаве ничего не писавший, начнёт писать код с промышленным качеством менее, чем через пол года. впрочем, у нас ситуация с С не намного лучше - армия индусов наступает.

То, что печально - это точно. Кстати за последние полгода в инете мелькала тема и проект (не помню чей - возможно, министерства связи, могу ошибаться), что за n лет скоро у нас будут свои проприетарные фаерволы, офисы и прочие виндовсы. Даже где-то видел документ-стратегию (забавно, кстати тех , кто в теме про вот это будет понятно, почему это забавно), в которой было что-то описано со сроками. Планы там описаны во истину Наполеоновские. Но начать точно нужно. Возможно не за 6, но уж за 15 лет, мы сможем создать базис вендоров.


Оператор в меру известный. Это был классический интегратор.


Каждый участник интеграционного проекта более вовлечен в архитектуру , чем системный программист на своем проекте
. (конечно случаи бывают разные, но я сужу по тем проектам, которые я видел) А какие сложности в том, что я буду в память записывать всяческие интересные последовательности байт и ждать потом от контроллера ответа, в таком случае?

Я бы хотел резюмировать сказанное про системных и индустриальных(как я их называю) программистов : первые решают задачи низкого уровня и ограниченные, вторые - высокого уровня и более широкие. Любой архитектор знает, что в первых задачах сложность заключается в отсутствии правильных абстракций и необходимости в детализированных сложных имплементациях довольно простых логически(х) активностей, а во вторых задачах сложность заключается в уровнях представления данных и функциональнностей и их взаимосвязей, модулях и композитах. Говорить, что первый вид сложности преобладает над вторым и требует более высокой квалификации программистов есть чушь. Куда более правильно сравнивать не виды задач, а конкретные технологии и конкретные проекты. Кроме того, для менеджмента сложность задачи измеряется не более чем в трудозатратах, необходимых на её реализацию в конечном счете. Системные программисты уходят в 18.00 домой, а в индустрии сидят до самого.... позднего - таких много. И почему ? У них же более простые задачи, как вы говорите Сервлет туда-сюда




Но я то её представляю, уважаемый товарищ ToSHiC, а вот вы - что-то не уверен.
Особенно мне интересно, каким образом получена оценка "на 2 порядка" , уж не теми ли асимптотическими методами, к которым вы аппелировали, говоря о практическом программировании?


Математика бывает разной. Я просил критерии квалификации программиста. Где они?
Говорить об уровнях математики я без данных критериев не смогу с вами

Давайте так: вам вообще какое программирование нравится , какие задачи и какие проекты? Какой процесс разработки?
Вот мне нравится вышеназванная интеграция и бизнес аналитика, в которой математики куда больше, чем за третий класс.

Чтобы не отклоняться совсем от темы: я призываю изучать те вещи, которые были мной отмечены для развития. Я не рекомендую связываться с системным программированием и языком Си или С++, они завтра умрут.

так, давайте определимся с программистами и должностями. как у вас проходит введение в проект некоторой фичи, затребованной заказчиком? бизнес-аналитики пишут требования к фиче, затем архитекторы внимательно изучают требования и пишут чендж-реквесты, которые согласуются с заказчиком, потом уже обычные жава-программисты берут готовые чендж реквесты с довольно детальным словесным описанием, где и чего надо сделать, и пишут код, так? какие задачи высокого уровня есть у этих программистов, если чендж-реквесты уже написаны архитекторами? сколько процентов от трудов кнута им желательно знать? почему вы опять притягиваете сюда работу архитектора? вот и заняли почти весь рынок труда в этой области индусы...
критерий квалификации программиста назвать сложно, всё таки работа в том числе и творческая, да и в мире менеджеры всё никак не договорятся об этом... в качестве рабочей версии можно принять относительный критерий, включающий себя сложность кода (не сложнее, чем требуется для решения задачи), объём потребляемых ресурсов и скорость работы готового кода. во многих областях прикладного программирования кроме собственно навыков программиста нужны ещё и навыки из смежных областей. это меньше касается жавы, c# или делфи, и больше С.

чтобы закрыть вопрос с рендерерами - это рынок с бюджетами в сотни миллионов долларов, люди во всём мире успешно уже больше 20 лет защищают диссертации на тему компьютерной графики в общем и техник рендеринга в частности. если, по вашим словам, всё так просто - то почему фотореалистичных рендереров так мало ?:)

согласен с ToSHiC, хорошо описал типичную работу в каком-нибудь люксофте и подобных. В больших компаниях Java программисты это такие code monkey, творчество которых предельно ограничено, единственная задача писать код - реализацию уже придуманных идей и алгоритмов, а также править баги, в команде таких же кодеров. Там даже разговорный английский не требуется, потому как они с заказчиком не общаются, а чтобы было поменьше ошибок у разных джуниоров как нельзя кстати подходят менеджет платформы со сборкой мусора и многочисленными неотключаемыми проверками.

Не все проекты так устроены. Процесс устроен в целом так, но есть детали:
Бывает что архитектор и аналитик - одно лицо. Бывает, что архитектор и программист - одно лицо.
Второе - то, на сколько детализированный CR кто получил -это сильно зависит от проекта.


Кнут , имхо, вреден, поскольку далек от сути. Есть более классные книги по алгоритмам - например Кормен или Ахо и Ульман. Не понимаю вашего пафоса в отношению данного труда. Какие знания оттуда реально могут потребоваться, которых при этом нет в вышеупомянутых книгах?


Архитекторы народ дорогой. Посидели - ушли. Кто занимается архитектурой дальше? Старшие программисты. Второе - где вы видели архитекторов, которые работают в изоляции и делают свою работу в одиночку? Я даже боюсь предположить какие сюрпризы будет преподносить такая архитектура, которую никогда не ревьювила проектная команда. Третье - бывают достаточно большие CR'ы и чтобы их реализовать, недостаточно быть просто Java программистом - нужно как минимум знать существенную часть системы на уровне технической архитектуры, а то и вовсе - на уровне кода. Реализация таких реквестов есть уже показатель профессионализма. Четвертое - оценка сроков реквеста. Пятое - impact analysis. Шестое -общение с заказчиком. Список можно продолжать.

Вы что думаете человек становится архитектором, когда ему присваивают должность "systems architect" ?
Да щас. Он становится им куда раньше по факту.



Потому что специфика работы в бизнес-ИТ сфере бывает
такова, что люди в ней занимаются не только тем, что у них написано в должности. И это отнюдь не только из-за пересекающихся сфер, но и из-за природы решаемых задач.


Если для вас его назвать сложно, то какие могут быть споры о квалификации, если вы не можете оценить то, о чем вы говорите?



Пусть будут такие критерии, однако я бы расширил данный список. Чтобы программист не представлялся человеком, который только и делает что выпускает код и потребляет различные ресурсы.
Программирование бизнес приложений - есть далеко не только кодинг. Видели когда-нибудь Websphere? Вот это и есть истинно удобный подход к решению определенного ряда задач без кодинга.



Откровенная чушь. Решение бизнес задач(Все равно на каком языке, Java, С#, whatever) навязывает автоматическим образом программисту понимание бизнес процессов и алгоритмов заказчика. Программист становится аналитиком в той сфере в которой он работает - будь это страхование или телеком.



Прежде чем это оспорить, я бы хотел поинтересоваться, о чем все-таки идет речь. Примеры есть?


Какое это имеет отношение к обсуждаемой теме?
Как это показывает сложность такого программирования относительного остальных его видов
?
Диссертаций по социалогии, например, я думаю вообще абсолютное большинство, это выводит её в класс outstanding наук?



Во-первых, не по моим словам, - а по вашим. Вы же утверждаете о реально существующих рендерах что-то, а не о фотореалистичных. Мы здесь говорим об индустрии, а не научных 20 летних изысканиях всяких ученых мира, призванных на выходе получить фотореалистичный рендер. Типичные рендеры многих известных игр имеют хорошо известную архитектуру. Посмотрите в википедии список фриварных 3д движков, их уже десятки. Их пишут люди в качестве курсовых работат и таинственные упомянутые вами сложности прекрасно преодолевают. Во-вторых - рендер это лишь одна из подсистем и, на мой взгляд, она проще Logic подсистемы. Рендер - подсистема, которая функциональна по своей природе. Logic подсистема более асинхронна и императивна.


progn
У меня ощущение. что вы говорите о конкретных людях (достаточно эмоционально).
Мы в данной теме обсуждаем не людей, а формальные вещи.

а подскажите ка, сколько у вас человек в команде на одном проекте работает? какой срок жизни проекта? зачем архитектору ревью от команды - он что, не является экспертом по той системе, которой занимается?

программист ресурсы не потребляет:) а вот его код - очень даже. тем более, что мы обсуждаем тут вакансии жава-программистов, которые пишут код. и им не обязательно досконально знать всю логику бизнес-процессов заказчика - для этого есть бизнес-аналитики, пожелания который оформляет и документирует в сиары архитектор. и если программист в силу своего "глубокого понимания" бизнес-процессов начнёт писать код не в соответствии с сиаром - могут возникнуть большие проблемы и тяжко решаемые дефекты, которые появятся на поздних стадиях тестирования, если не в продакшене. да, постепенно программист постигает всё и через несколько лет работы в одной области становится экспертом, но это уже сверх его обязанностей, и даже тогда он всё равно должен сначала обращаться к бизнес-аналитикам.

чтобы закрыть вопрос с рендерерами - в простейших случаях будет достаточно линейной алгебры, получится схематично изобразить картинку. в современных играх всё сложнее. но я вообще вёл разговор о том, что есть такие конторки, как Sony Pictures, Dreamworks, Pixar, Disney, LukasFilm, которые тратят ОЧЕНЬ много денег на рендереры, которые действительно ОЧЕНЬ сложные, и достаточно фотореалистичные. и это точно сделано не на жаве, впрочем, как и игровые движки.

progn довольно точно описал, что сейчас происходит в мире. Aside, вы не согласны с этим? подойдём к вопросу с другой стороны. посмотрите, на что люди тратят деньги: игры, офисный софт, профессиональный софт типа фотошопа или аудиоредактора, различные CADы. тратят ли компании больше денег на софт, написанный на жаве, чем на остальной? может ли вообще какое-либо производство работать только на софте (кроме ОС), написанном на жаве? я уж не говорю про обычного пользователя, у которого дома приставка, макбук и set-top-box. фейсбук, вконтакте и жж тоже не на жаве работают. одноклассники, правда, походу на жаве. это я всё к чему - си с плюсами живее всех живых, и ещё переживут многих.

Проекты разные. От 4 до десятков.


А вот это вообще очевидный факт. Мне сдается, что вы не знакомы с некоторыми промышленными методологиями.


Всю логику - совершенно верно, не обязательно. А ту её часть, с которой они имеют дело - обязательно. В противном случае, качество работы такого программиста будет низким, как и ценность такого программиста.


Это если он есть.
К тому же, ну и что из этого? В CRах достаточно бизнес сведений может содержаться и понимать, что собственно мы программируем важно и нужно.


Если вам нравится ограничиваться чисто техническими задачами и не понимать бизнес-смысла того, что вы программируете, то вероятно вы не сможете стать очень успешным индустриальным программистом. (я говорю не конкретно про вас, а про любого человека)



Рендеры, которые они используют - есть очень узкое направление и делается оно ограниченном числом компаний. В России, я думаю, таких компаний нет вообще (ну или как всегда - есть прототип программы, в виде одной библиотеки, а довести её до ума нет денег и ресурсов). Можно сказать с уверенностью, что данные рендеры не сложнее любой типичной программной ИТ инфраструктуры нескольких банков. А то, на каком языке они написаны - вообще не о чем не говорит. У нас выразительная сила всех языков равна. На чем хочешь - на том и пишешь. Это не более чем вопрос производительности.
Вы видели код этих рендеров? Каким образом вы оценили их сложность?


Мир неоднороден. Есть часть мира , о которой вы не осведомлены. Есть часть о, которой не осведомлен я. Оценивать ситуацию во всем мире я , в отличие от вас, не берусь. Там, где работал я было все вполне неплохо. Но, я думаю, что это действительно зависит от везения, от того, куда попадешь. Есть ли coding monkeys? Да - есть. Есть ли они повсеместно? Нет - нету.



Некоторые - тратят. Только там не одна Java.
Речь не о том , вообще-то, кто и на что тратит, а о том, где движуха. в Java направлении движуха есть, а в С++ она идет на спад. Потому, что это язык для геймдева и прочих закрытых коробочных решений, вроде упомянутого вами Фотошопа. Как вы сами сказали, производителей таких решений в России почти нет. Поэтому, в соответствии с обсуждаемой темой "как дальше развиваться" (к которой я пытаюсь вас вернуть) я и не
рекомендую C++. Нравится программировать однотипную логику? Программируйте. А я лучше буду делать разнообразные проекты на связках из различных технологий и знать, что спрос на это не только не падает, но и растет.



Не надо мне рассказывать про Ерёму. Я уже третий раз повторяю, что в данной теме говорю главным образом о бизнес приложениях под заказ. Этот сектор, как и WEB сектор C++ проиграл.

Прошу прощения, что пришлось отойти от темы. Мои попытки к ней вернуться слабо воспринимаются другими участниками, поэтому приходилось разъяснять некоторые моменты.

примеры можно? что за бизнес приложения?

и еще интересно узнать, например CAD системы к чему относятся? к системному программированию? а embedded/мобильные системы? геймдев?

К коробочным продуктам. Примеры в гугле поищите.



Не ожидал от вас такой невежественности.

простите, а какие РАЗНЫЕ технологии вы в последнем проекте использовали? они сильно отличались от тех, что были на позапрошлом проекте? а какая длительность у одного проекта, для программиста? а для архитектора? вы вообще там странную мысль высказали - для меня совершенно неочевидно, КАК может архитектор работать, если он не является экспертом по проектируемой системе? нафиг он такой нужен? или все проекты одноразовые, сделал и забыл?


возвращаясь к теме, как развиваться. развиваться надо в ту сторону, где интересно. тем более, что надо принять 2 аксиомы: можно менять работу хоть каждые 2 года, и можно работать не только в России. даже если вторую временно не принимать во внимание - простор для выбора всё равно очень широк

Разные системы, разные Субд, разные фреймворки.
Сроки для программистов и архитекторов самые разные. Кто-то посидит полгода и уйдет. Кто-то более года сидит.




Я не говорил, что он не является экспертом. Это вы сказали.
Ваше непонимание связано с рядом неизвестным вам тонкостей, которые я не буду озвучивать.


Поддерживаю и добавлю, что это также должно быть перспективно.

не обязательно коробочным, могут быть и не ретейл продукты, но да ладно, это не так важно, мир ПО состоит не только из ваших корпоративных бизнес систем которыми вы лично возможно занимаетесь.

Даже не знаю куда запостить. Наверное, в "решение задач по математике", но тут больше шанс получить ответ - дискретка всё же довольно специфична.
В общем,

Как такую решать? Очевидно, что <=49, но это явно очень поверхностное условие.
Педивикинг "плоского графа" не помог - в условия следствий ф. Эйлера это условие (e <= [v/2]) с запасом попадает.

99, я так полагаю. если поставить 99 точек по окружности и соединить их - то получится многоугольник с 99 сторонами-отрезками, каждый из которых будет иметь общие точки с другими только на концах-вершинах многоугольника.

ToSHiC Ах да, я протупил, не прочитал "кроме концов"
Идея понятна, но решение - нет.
В если из 6 точек сформировать равносторонний 6угольник, то эти точки можно соединить 8 отрезками, не нарушая условие. 2 отрезка будут "внутри" 6-угольника.
Или даже скажем, вписать в 6-угольник 5-угольник, в него 4-угольник, и так вплоть до 3-угольника, и всё соединить так, чтобы ничего лишнего не пересеклось. Скажем, вписав 3-угольник в 4-угольник получаем 14 ребер для 7 точек.

Но не пойму, какая форумла тут сработает

Posted спустя 13 минут 15 секунд:
Следствие из ф. Эйлера:

Действительно, для графа с v=7 я получил е=15 без нарушения планарности. Треугольник вписал в треугольник, а в него - точку. Сохранилось условие "не 3 вершины на одной прямой".
Вопрос такой. Как это условие правильно учесть? Или оно вообще ничего не решает в данном случае?

интересная лекция Степанова
http://habrahabr.ru/mob/post/103513/
Ява кодерам, которые считают, что крутость программиста определяется количеством знаемых API, стоит обязательно посмотреть (особенно середину второй части там где он начинает отвечать на вопросы)

progn

Во-первых, это кого вы здесь назвали Ява кодером?
Вы сначала ник себе придумайте чуть более чем элементарный

Во-вторых - Если вы не знаете, что требуется на рынке труда - то значит, кто-то другой это знает и будем там раньше Вас.

В-третьих - кроме поддакивания другим участникам конференции и отмашки "смотри сабж по ссылке" вы вообще нечего дельного в данной теме не сказали.

а что не так? если думаете что ник имеет какое-то отношение к программированию, то ошибаетесь это от слова progne, с которым у меня связаны приятные воспоминания


а вы значит знаете? (и вы думаете мне туда надо, куда и другим?)



ну почему-же, я вам рассказал где сейчас используется С++, но так как в мобильном девелопинге вы совсем не разбираетесь, и с CAD тематикой (и вообще вычислений) тоже видимо не знакомы, то поддержать разговор к сожалению не смогли. Я в свою очередь не имел дела с банковскими системами и телекомом

Ну да, 6 лет изучал Computer Science & Applied mathematics в универе , совсем не знаком с вычислениями.
Автокада, Компаса и прочих вещей тоже никогда не видел. Наверно какие-то непопулярные программы.

Студентов, кстати, легко определить - они думают, что чем больше Кнута они знают, тем они более круты.
Это, вообще, имеет определенный термин - максимализм юношеский Такие на собеседования приходят и рассказывают , какие они крутые программисты, но на самом деле взять их можно только на уровень Junior Programmer, потому что технологий и индустриальных практик они не знают. Более того, что для меня удивительно, многие из них не могут потом работать эффективно, т.к. недостаточно практичны и уходят.
Только после некоторого времени у них приходит прозрение, что на практике в основном совсем другие задачи. (где как, но в индустрии - так)
И у меня, несмотря на мои относительно обширные познания в математике и информатике, нет желания носить розовые очки и орать на форумах, что эти знания есть must, потому, что непосредственно они мною использовались достаточно редко за более чем 5 лет работы в индустрии. Скорее стиль мышления полезен, но не непосредственно данные знания.
Что касается тем, которые кто-то якобы не поддержал, то, например, вы не поддержали тему про другие книги , ибо их не читали и не в курсе, что Кнут не самая лучшая книга по алгоритмам.