Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 209
Когда я искал работу, я столкнулся с такой же позицией только наоборот. Соискателем был я и очень много мест где я проходил собеседования как раз таки и скали подобных людей.
Так что большой проблемы я не вижу в этом, взгляните на python, javascript, php и так далее везде такая ситуация.
Отчасти она спровоцирована самим работодателями. От программистов джуниоров и среднего уровня больше требуют как раз таки знание предмета со стороны фреймворка, чтобы он мог быстро решать бизнес задачи.
И многое зависит от человека, захочет — будет сам разбираться, не захочет так и будет работать на том же уровне, рынку. в общем-то такие специалисты тоже нужны, для них есть ниша.
Так что большой проблемы я не вижу в этом, взгляните на python, javascript, php и так далее везде такая ситуация.
Отчасти она спровоцирована самим работодателями. От программистов джуниоров и среднего уровня больше требуют как раз таки знание предмета со стороны фреймворка, чтобы он мог быстро решать бизнес задачи.
И многое зависит от человека, захочет — будет сам разбираться, не захочет так и будет работать на том же уровне, рынку. в общем-то такие специалисты тоже нужны, для них есть ниша.
Такие разработчики ещё и здорово бьют по чувству справедливости и самолюбию.
Вот есть два программиста — крутой гуру, который понимает как работаю всё те же фреймворки, может решить нестандартную задачу и найти трудноуловимый баг. И Framework Coder.
Первый, очевидно, лучший разработчик. Но от этого есть толк только в небольшом проценте сложных, нестандартных задач, для которых нет готовых решений. В большинстве же случаев такой гуру, который потратил много лет на обучение, для бизнеса не намного полезнее, чем framework coder.
Вот есть два программиста — крутой гуру, который понимает как работаю всё те же фреймворки, может решить нестандартную задачу и найти трудноуловимый баг. И Framework Coder.
Первый, очевидно, лучший разработчик. Но от этого есть толк только в небольшом проценте сложных, нестандартных задач, для которых нет готовых решений. В большинстве же случаев такой гуру, который потратил много лет на обучение, для бизнеса не намного полезнее, чем framework coder.
так будет писать фреймворк под себя/контору. гуру в архитекторах всегда рады
так будет писать фреймворк под себя/контору.Для многих реальных задач это будет синонимично словосочетанию «придумывать велосипед».
Только гуру собеседование не пройдет, вакансии архитекторов почти не выкладывают, растят изнутри. И если его даже пригласят (заманят пожурив этой вакансией) то собеседовать будут прикладные программисты и задавать будут вопросы по фреймворкам.
Я конечно далеко не гуру, но на вопрос «как сделать что то во таком то фреймворке», мой ответ — «все описано в документации» никого не устраивает. Т.е. получается я настолько неуч что даже на прикладника не тяну, куда мне выше вакансию предлагать. Извиняюсь, наболело.
Я конечно далеко не гуру, но на вопрос «как сделать что то во таком то фреймворке», мой ответ — «все описано в документации» никого не устраивает. Т.е. получается я настолько неуч что даже на прикладника не тяну, куда мне выше вакансию предлагать. Извиняюсь, наболело.
Bingo!
Меня эта ситуация на рынке труда тоже несколько напрягает. )
Поэтому предпочитаю иметь базис поверхностных знаний по широкому кругу framework'ов, и специальные знания по тем, с которыми приходится работать вплотную.
Хотя приходилось сталкиваться с тем, что приходишь на собеседование по вакансии Senior Java Developer, тебя пытаются грузануть, а когда не получилось — вежливо объясняют, что «до Senior'а надо еще дорасти, сначала поработай у нас с годик-два».
Меня эта ситуация на рынке труда тоже несколько напрягает. )
Поэтому предпочитаю иметь базис поверхностных знаний по широкому кругу framework'ов, и специальные знания по тем, с которыми приходится работать вплотную.
Хотя приходилось сталкиваться с тем, что приходишь на собеседование по вакансии Senior Java Developer, тебя пытаются грузануть, а когда не получилось — вежливо объясняют, что «до Senior'а надо еще дорасти, сначала поработай у нас с годик-два».
Из жизни. Вопрос на собеседовании.
— Как бы вы сделали %тут то что нужно сделать% на %фреймворк нейм% фреймворке.
— Для начала почитал бы документацию и форум сообщества. Возможно там есть стандартный прием.
— Нет такого в документации, все же как это сделать на %фреймворк нейм%.
— Ну наверное я бы сделал так %первый пришедший способ в голову%, есть множество вариантов как реализовать в зависимости от задачи. Но наверняка еще бы посмотрел решения других людей.
— То есть вот так?.. Но все же, как это делаеться в %фреймворк нейм%?
— …?
— Все ясно, мы позвоним вам через неделю.
И получается, например возьмем PHP, что если ты используеш нативный array_merge() это вызывает непонимание, так как правильно оказывается использовать Framework::getInstance()->arrayMergeFactory();
И думаешь… что со мной не так)
— Как бы вы сделали %тут то что нужно сделать% на %фреймворк нейм% фреймворке.
— Для начала почитал бы документацию и форум сообщества. Возможно там есть стандартный прием.
— Нет такого в документации, все же как это сделать на %фреймворк нейм%.
— Ну наверное я бы сделал так %первый пришедший способ в голову%, есть множество вариантов как реализовать в зависимости от задачи. Но наверняка еще бы посмотрел решения других людей.
— То есть вот так?.. Но все же, как это делаеться в %фреймворк нейм%?
— …?
— Все ясно, мы позвоним вам через неделю.
И получается, например возьмем PHP, что если ты используеш нативный array_merge() это вызывает непонимание, так как правильно оказывается использовать Framework::getInstance()->arrayMergeFactory();
И думаешь… что со мной не так)
Не стоит принимать это столь близко к сердцу ) На мой взгляд это нормальная реакция огромного и постоянно растущего рынка.
Если рассматривать фреймворк как программный пакет стоящий на ряду с офисом или фотошопом, то и вовсе пропадают сомнения в естественности появления такой ниши узко профилированных специалистов. Я уверен, что ваш бухгалтер не пишет макросы для EXCEL а аккаунт менеджер не коммитит фичи для CRM.
Если рассматривать фреймворк как программный пакет стоящий на ряду с офисом или фотошопом, то и вовсе пропадают сомнения в естественности появления такой ниши узко профилированных специалистов. Я уверен, что ваш бухгалтер не пишет макросы для EXCEL а аккаунт менеджер не коммитит фичи для CRM.
Вы абсолютно не правы. Сейчас все ще наблюдается дифицит отличных специалистов и любая хорошая компания будет рада такому гуру, если он конечно таковым является.
Если вы такой гуру, отправьтте резюме в гугл, твиттер, фейсбук, майкрософт, оракл… (список длинный, в том числе ряд компания имеет подразделения в России) и если. как вы написали вы такой гуру, который действительно разбирается в своей области все ваши навыки проявятся в этих компаниях, в том числе и в финансовом плане относительно «фреймворк программистов».
Если вы такой гуру, отправьтте резюме в гугл, твиттер, фейсбук, майкрософт, оракл… (список длинный, в том числе ряд компания имеет подразделения в России) и если. как вы написали вы такой гуру, который действительно разбирается в своей области все ваши навыки проявятся в этих компаниях, в том числе и в финансовом плане относительно «фреймворк программистов».
Наверное не так выразился: «небольшой процент задач» — это в среднем по рынку. В отдельной компании (как раз те же гугл, твиттер, фейсбук и дальше по списку) таких задач может быть намного больше и гуру как раз там и место. Я согласен с комментаторами выше — есть ниша как для framework coder, так и для профессионалов с более глубокими знаниями.
если. как вы написали вы такой гуру
Disclaimer
Это перевод, я к автору никакого отношения не имею и гуру себя нигде не называл. Скромный Junior со своим ИМХО.
Я писал комментарий скорее в ответ на это
Человек который действительно знает лучше и больше, не испытывает таких проблем, он находит себе место работы лучше и интересней.
Такие разработчики ещё и здорово бьют по чувству справедливости и самолюбию.
Человек который действительно знает лучше и больше, не испытывает таких проблем, он находит себе место работы лучше и интересней.
Человек может не уметь искать себе место работы лучше и интересней. Отчасти из-за заниженной самооценки, считая свои «лишние» знания невостребованными: «тут не платят больше — почему там будут платить больше?»
Не утрируйте. Это чисто проблемы «человека» и совершенно не важно какие у него знания. Не стоит уходить от темы в фантазии. Если человек не может найти лучшее место работы, видимо не все так гладко с его знаниями.
А если он гений и все знает, но все равно продолжает сидеть на низкой должности ис низкой зп, то я совершенно не вижу по какому чувству «справедливости и самолюбию» ему бьют другие разработчики, которые идут работать на куда лучшее места. Его все устраивает, какие проблемы.
А если он гений и все знает, но все равно продолжает сидеть на низкой должности ис низкой зп, то я совершенно не вижу по какому чувству «справедливости и самолюбию» ему бьют другие разработчики, которые идут работать на куда лучшее места. Его все устраивает, какие проблемы.
Вот по такому и бьют — другим зарплату повышают или новичков берут на большие, а он всё ждёт когда его оценят.
Он идиот, я не знаю как помогать идиотам, простите.
Так что прошу не приводить в пример случаи идиотизма ибо я не вижу как «не умение жить и чегодо-то добиваться» корелирует с «отсутсвием\присутсвием профессиональных знаний».
А ждать можно до конца жизни, можно ждать:
когда девушка, которая тебе нравиться подойдет и попросит тебя начать встречаться/жениться на себе
когда врач из поликлинике сам придет, предчуствуя вашу болезнь, дабы вас вылечить
дальше список сами продолжите :-)
Так что прошу не приводить в пример случаи идиотизма ибо я не вижу как «не умение жить и чегодо-то добиваться» корелирует с «отсутсвием\присутсвием профессиональных знаний».
А ждать можно до конца жизни, можно ждать:
когда девушка, которая тебе нравиться подойдет и попросит тебя начать встречаться/жениться на себе
когда врач из поликлинике сам придет, предчуствуя вашу болезнь, дабы вас вылечить
дальше список сами продолжите :-)
Не идиот, а просто не социализированный человек. Девушку тоже ждёт, да. А врача из поликлиники — нет, только реанимацию.
Тут еще можно добавить, что среди программистов и IT-шников вообще часто встречаются «нерды», то есть люди, упустившие в процессе своего личного развития социализацию в угоду профессионализму. И чисто статистически (просто в результате того, что они больше времени потратили на профессиональное совершенствование, чем прочие) среди них больше крутых профессионалов, чем среди прочих.
Думаю, что хороший IT-менеджер должен уметь находить подход к таким людям.
Думаю, что хороший IT-менеджер должен уметь находить подход к таким людям.
и любая хорошая компания будет рада такому гуру
Тут сильно зависит, что иметь в виду под словом «хорошая». Плюс, готова ли такая компания платить за «избыточные» знания и навыки.
Я же начал писать список компаний, и да. они — готовы платить
Это не просто хорошие, это отличные, лидеры рынка.
Список огромен, просто огромен: яндекс, мейл, джетбрейнс, касперский, самсунг, cisco… ну вы гуглом пользоваться не умеете? Все этим компании рады профессионалам и у них есть должность на которые «фреймворк программисты» просто не подходят. Идите и устраивайтесь, вас там оценят.
Вы перечисляете лидеров рынка, отличные компании. Я же говорю про просто хорошие, имя которых никому ничего не говорит.
Вы же специалист, вы знаете на порядок больше других, вы не только умеет пользоваться фреймворком, вы также понимаете почему в него заложили определенные паттерны, как оно все работает внутри, можете оптимизировать его производительность, имеете свое мнение на архитектурные решения использованные в данном фреймворке и так далее…
Тогда, простите почему вы не хотите идти работать в лидирущие компании которым вы нужны, а сидите в вебстудии от дяди вас и ждете когда вас скажут «чувак ты крут, твои знания нам не нужны, но все равно держи 50к сверху».
Я разве не прав? Почему вы хотите продать свои знания тем кому они не нужны, и упорно не хотите пойти к тем кто ищет специалистов?
Тогда, простите почему вы не хотите идти работать в лидирущие компании которым вы нужны, а сидите в вебстудии от дяди вас и ждете когда вас скажут «чувак ты крут, твои знания нам не нужны, но все равно держи 50к сверху».
Я разве не прав? Почему вы хотите продать свои знания тем кому они не нужны, и упорно не хотите пойти к тем кто ищет специалистов?
Ну по первым 2 вопросам согласен. Третий уже из разряда не знания, что под капотом фреймворка, а общего знания принципов программирования. Последние два вопроса странны в качестве иллюстрации фреймворк-разработчика. Как выбор IDE для написания JSP говорит о скудности знаний у разработчика.а если он в блокноте пишет? То что работали по спецификации, не вижу ничего плохого тоже. Явление имеет место быть, но иллюстрация за уши притянута.
К слову датирован этот пост аж 2006 годом, так что уже наверное многое изменилось (в худшую или лучшую сторону не берусь судить).
К слову датирован этот пост аж 2006 годом, так что уже наверное многое изменилось (в худшую или лучшую сторону не берусь судить).
Второй вопрос, мягко говоря, не серьезен. Как передать параметры подключения JDBC-драйверу надо узнать 1 раз за проект и гуглится за минуту, да еще и формат параметров зависит от БД, так что все равно гуглить придется. Зачем это помнить?
2006 годом
да ничего не изменилось
когда я собеседовался пару лет назад, мне задавали абсолютно такие же вопросы
«какой фреймворк использовали»
«жизненный цикл ejb»
«в чём различие абстрактного класса и интерфейса»
Вполне возможно, что стало хуже, т.к. Java так или иначе набирает популярность, а порог вхождения в EE довольно высок и вроде не снижается.
Могу судить по себе. Не считаю себя гуру программирования, но знаю, как мне кажется, достаточно, причем я довольно поздно начал пользоваться фреймворками (php) и если пользуюсь, то стараюсь понять как именно они работают и это не особо составляет труда.
В сентябре у меня начался курс по Java SE. Я довольно быстро его закрыл за счет общей подготовки, ничего особенно сложного я не заметил, хотя и сильно далеко не вникал. И вот настал момент, когда я вдруг решился взяться за Java EE, думал общее понимание мне поможет. Но блин, может я конечно ноль в программировании, но переход с php на Java EE мне пока не поддался полностью и продолжает сопротивляться.
Основная проблема в том, что по Java EE недостаточно толковых ресурсов на русском языке, даже на хабре информации маловато будет. Вся другая информация только на английском, что в принципе проблем особо не вызывает, но она написана настолько сухо, что иногда создается впечатление, что такие понятия как POJO, DAO, контексты, Bean, EJB, Сервлеты, Гризли, Мавены, Хероку, JDO, JPA и кучка других сокращений/названий, читающий априори знать обязан. Для начального уровня это очень трудно для восприятия, хотя понятно, что нужно иметь общее понятие о Java EE и без него никак. Но с названиями перебор. В итоге очень много времени тратишь на то, чтобы понять, надо ли оно тебе или это какая-то специфичная штука. Понадобилось JSON в Jersey — вот тебе MOXy, Jettison, Jackson. И так довольно часто, создается впечатление, что все это фреймворки, сделанные на фреймворках, чтобы создавать фреймворки.
Буду очень благодарен, если посоветуете какие-нибудь толковые ресурсы по Java EE. Пока что самым информативными для меня оказались туториалы от 308tube (про Jersey на youtube), но там порой совсем очевидные вещи проскакивают, хабр, stackoverflow и одностраничные документации, по которым удобно просто искать.
Могу судить по себе. Не считаю себя гуру программирования, но знаю, как мне кажется, достаточно, причем я довольно поздно начал пользоваться фреймворками (php) и если пользуюсь, то стараюсь понять как именно они работают и это не особо составляет труда.
В сентябре у меня начался курс по Java SE. Я довольно быстро его закрыл за счет общей подготовки, ничего особенно сложного я не заметил, хотя и сильно далеко не вникал. И вот настал момент, когда я вдруг решился взяться за Java EE, думал общее понимание мне поможет. Но блин, может я конечно ноль в программировании, но переход с php на Java EE мне пока не поддался полностью и продолжает сопротивляться.
Основная проблема в том, что по Java EE недостаточно толковых ресурсов на русском языке, даже на хабре информации маловато будет. Вся другая информация только на английском, что в принципе проблем особо не вызывает, но она написана настолько сухо, что иногда создается впечатление, что такие понятия как POJO, DAO, контексты, Bean, EJB, Сервлеты, Гризли, Мавены, Хероку, JDO, JPA и кучка других сокращений/названий, читающий априори знать обязан. Для начального уровня это очень трудно для восприятия, хотя понятно, что нужно иметь общее понятие о Java EE и без него никак. Но с названиями перебор. В итоге очень много времени тратишь на то, чтобы понять, надо ли оно тебе или это какая-то специфичная штука. Понадобилось JSON в Jersey — вот тебе MOXy, Jettison, Jackson. И так довольно часто, создается впечатление, что все это фреймворки, сделанные на фреймворках, чтобы создавать фреймворки.
Буду очень благодарен, если посоветуете какие-нибудь толковые ресурсы по Java EE. Пока что самым информативными для меня оказались туториалы от 308tube (про Jersey на youtube), но там порой совсем очевидные вещи проскакивают, хабр, stackoverflow и одностраничные документации, по которым удобно просто искать.
Хехе ничего не подскажу по ресурсам, но поделюсь теми же ощущениями когда щупал EE. Те книги, которые находил в онлайн, точно описывали работу с фреймворками, но и туториал с сайта Оракл тоже ясности не добавил. Сначала рассказывают про уровни модели абстракции а потом как-то сразу прыгают на визард типа «а давайте запустим сервлет helloworld и посмотрим что у нас получится» :) Я не понимаю, почему SE был так подробно расписан и книг нормальных много, а с EE такой тупняк. Так что буду рад если знающие люди поделяться советами :)
Возможно в этом главный секрет высокой зарплаты Java-разработчиков.
Искусственный дефицит под личиной естественного отбора :)
Искусственный дефицит под личиной естественного отбора :)
У меня 10 лет опыта в Java, работал большей частью по банкам. Натыкался на все эти волшебные слова, но так и не понял, где же он, этот EE. Только один раз выковыривал логику из какого то дремучего индусокода, написанного под Weblogic, вот там были какие то волшебные слова, которые встречал в книжках по EE, всякие там home-интерфейсы и на каждый чих-пых по четыре класса. А так вроде все эти технологии использовали, но где там был EE — черт его знает.
А фактически JavaEE — это и есть солянка разных инструментов в одном флаконе, которые «просто и легко» друг с другом интегрировать.
сдается мне проблема в множестве реализаций стандартов javaEE и их аналогов а также в неупорядоченном их использовании.
По поводу доков. Например выходит официальная спека EE периодически (сейчас 7 версия), где обновляют api для transaction, ejb, jpa, security и т.д., потом оракл имплементирует это в своем глассфише, потом поттягиваются аппсервера вендоров типа jboss, weblogic и т.д., потом аналоги (спринг и т.д.).
В итоге имеем только официальные java доки от оракла ну и мануалы от кастомных вендоров, спринга и все, и только через год-2 может издадут книжку типа «javaEE 7 в действии». Т.е. полные гайды тут всегда с задержкой.
А на javaEE проектах сплошь и рядом сборная солянка даже там где используют аппсервера: например вместе с jboss часто используют spring, чтобы этот EE так сказать упростить (да и знают его многие), в то же время многие из реализованных EE фич — не используют вообще (тот же спринг много чего сам делает), вот и получается что почти на всех проектах понамешано разных фич из EE, кастомных фич аппсерверов, и шаблонов из Спринга.
За свой немаленький опыт в javaEE еще не видел проектов которые ипользуют только фичи из EE спеки, т.е. которые в идеале без серьезных изменений можно было бы запустить на любом аппсервере с поддежкой этой EE спеки
По поводу доков. Например выходит официальная спека EE периодически (сейчас 7 версия), где обновляют api для transaction, ejb, jpa, security и т.д., потом оракл имплементирует это в своем глассфише, потом поттягиваются аппсервера вендоров типа jboss, weblogic и т.д., потом аналоги (спринг и т.д.).
В итоге имеем только официальные java доки от оракла ну и мануалы от кастомных вендоров, спринга и все, и только через год-2 может издадут книжку типа «javaEE 7 в действии». Т.е. полные гайды тут всегда с задержкой.
А на javaEE проектах сплошь и рядом сборная солянка даже там где используют аппсервера: например вместе с jboss часто используют spring, чтобы этот EE так сказать упростить (да и знают его многие), в то же время многие из реализованных EE фич — не используют вообще (тот же спринг много чего сам делает), вот и получается что почти на всех проектах понамешано разных фич из EE, кастомных фич аппсерверов, и шаблонов из Спринга.
За свой немаленький опыт в javaEE еще не видел проектов которые ипользуют только фичи из EE спеки, т.е. которые в идеале без серьезных изменений можно было бы запустить на любом аппсервере с поддежкой этой EE спеки
От языка документации порог входа вряд ли зависит, особенно если это английский язык.
не успел добавить
в моем сообщении язык ресурсов скорее влияет на «скорость» входа и удобство.
Толковый разработчик рано или поздно «войдет», если ему это надо.
Тех, кто только начинает или переходит, это очень сильно тормозит и оставляет скорее негативную оценку сообществу, чем положительную.
в моем сообщении язык ресурсов скорее влияет на «скорость» входа и удобство.
Толковый разработчик рано или поздно «войдет», если ему это надо.
Тех, кто только начинает или переходит, это очень сильно тормозит и оставляет скорее негативную оценку сообществу, чем положительную.
чуть выше добавил про язык. у меня нет проблем, что основная часть информации на английском, я даже этому рад. Только это все равно официальная и сухая документация с упором на уже какие-то конкретные знания.
С SE мне полностью хватило за глаза и за уши оракла и overapi.com
Только вот SE это несколько другая штука ведь — она сильно переплетена с общими знаниями программирования, где все практически ясно, нужно лишь узнать как это устроено в Java
С SE мне полностью хватило за глаза и за уши оракла и overapi.com
Только вот SE это несколько другая штука ведь — она сильно переплетена с общими знаниями программирования, где все практически ясно, нужно лишь узнать как это устроено в Java
Приятно осознавать, что я не один такой. Сталкнулся с ровно такими же трудностями. В итоге пришлось долго возиться с документацией оракла, читать кучу самопальных уроков, смотреть видео уроки (в сети есть видео-уроки по java EE некоего товарища, увы, забыл фамилию, но год назад он один был такой. не думаю, что много изменилось) и много практиковаться. В итоге понимание в какой-то степени пришло, но практического опыта все-равно не хватает.
Относительно недавно вышла книжка Дэвида Хеффельфингера «Разработка приложений Java EE 6 в NetBeans 7» на русском языке.
Java EE — всего лишь спека, есть много разных реализаций поэтому и информации много. Понятия DAO и контексты в целом относятся к стиля программирования и по сути к языку имеют только косвенное отношение. Сложность для новичка всегда в том с чего начать. Я советую всегда начинать с азов. Servlet и что такое Servlet-container, попутно изучив HTTP протокол. Далее IoC и понеслась…
Еще бы неплохо знать про Reflection, создание прокси-классов «на лету» и т.д.
Для понимания того, что под капотом и каким образом оно все-таки работает.
Иначе для непосвященного это выглядит как магия :-)
Даже если он достаточно хорошо знает язык.
Для понимания того, что под капотом и каким образом оно все-таки работает.
Иначе для непосвященного это выглядит как магия :-)
Даже если он достаточно хорошо знает язык.
Так это всё есть в Java SE :) Так что когда пишут что знают SE немного лукавят.
> Даже если он достаточно хорошо знает язык.
Достаточно хорошо знать язык в моем понимании = уметь его использовать для ежедневных задач.
Раньше моя планка была выше, но в текущих реалиях приходится мыслить подобными категориями, глядя на рынок труда.
P.S. Да, и еще: многие под «знать SMTH» понимают «знать N% от SMTH», причем N запросто может быть < 50%.
И они искренне удивляются, когда узнают, что есть остальные >50%.
Достаточно хорошо знать язык в моем понимании = уметь его использовать для ежедневных задач.
Раньше моя планка была выше, но в текущих реалиях приходится мыслить подобными категориями, глядя на рынок труда.
P.S. Да, и еще: многие под «знать SMTH» понимают «знать N% от SMTH», причем N запросто может быть < 50%.
И они искренне удивляются, когда узнают, что есть остальные >50%.
>>что по Java EE недостаточно толковых ресурсов на русском языке
Замечу, что сам с английским уважительно «на Вы». Но надо признавать что этот язык НАДО знать. Хотите Вы этого или нет но в данный момент программист только проседает по эффективности своей работы если не знает английского! Буквально недавно начал изучать новый для меня Golang и скажу, без хоть каких-то навыков чтения и небольших знаний грамматики английского я бы его не осилил. Учите! Надо Вася, надо!
Замечу, что сам с английским уважительно «на Вы». Но надо признавать что этот язык НАДО знать. Хотите Вы этого или нет но в данный момент программист только проседает по эффективности своей работы если не знает английского! Буквально недавно начал изучать новый для меня Golang и скажу, без хоть каких-то навыков чтения и небольших знаний грамматики английского я бы его не осилил. Учите! Надо Вася, надо!
Если Вы разработчик и делаете реальные проекты, забудьте про JavaEE и будьте счастливы! JavaEE вам нужно исключительно для устройства на работу в какую-нибудь контору. Это набор раскрученных брендов, которые заставляют клиента выкладывать бабки. Какая-либо практическая ценность в ней отсутствует. Коротко: JavaEE — это о том как сложно, долго и дорого написать простую вебстраничку.
Я работаю с джава с 95 года, JavaЕЕ начал осваивать потихоньку с 2005. На всем протяжении постоянно не покидал вопрос: «нахрена так сложно»? Все задачи решались традиционным способом в разы быстрее на традиционной джаве с помощью библиотек. Все, что было заявлено в спецификации достаточно рудиментарно и не используется в 95% реальных проектов. А в 5% можно найти простую альтернативу. Более того, называть это все стандартом очень натянуто. Со 100% вероятностью EE-приложение, написанное под JBoss не будет работать под Weblogic без дополнительного допила. Это потому, что спецификация очень ограниченная, и производители всегда добавляют собственные расширения, чтобы обойти ограничения. Последние спецификации JavaEE взяли много от фреймворков типа Spring. Это позволило хоть как-то мало-мальски улучшить ситуацию, но не поменяло радикально.
Ну а сам процесс разработки под EE — это хождение по мукам. Просто начиная с того, чтобы запустить Weblogic нужно ждать пару минут, еще минут десять, чтобы сделать билд проекту, задеплоить, проверить сраную страничку и удалить. Примерно как в начале семидесятых. Поэтому существует куча технологий-хаков, которые ненамного пытаются улучшить ситуацию (Arquillian, JRebel, etc), которые надо будет тоже изучить. Вся разработка будет сводиться к поиску нужного рецепта, обходу ограничений платформы, борьбе с багами имплементации и непредвиденными сбоями приложений. Короче, ничего хорошего.
Я работаю с джава с 95 года, JavaЕЕ начал осваивать потихоньку с 2005. На всем протяжении постоянно не покидал вопрос: «нахрена так сложно»? Все задачи решались традиционным способом в разы быстрее на традиционной джаве с помощью библиотек. Все, что было заявлено в спецификации достаточно рудиментарно и не используется в 95% реальных проектов. А в 5% можно найти простую альтернативу. Более того, называть это все стандартом очень натянуто. Со 100% вероятностью EE-приложение, написанное под JBoss не будет работать под Weblogic без дополнительного допила. Это потому, что спецификация очень ограниченная, и производители всегда добавляют собственные расширения, чтобы обойти ограничения. Последние спецификации JavaEE взяли много от фреймворков типа Spring. Это позволило хоть как-то мало-мальски улучшить ситуацию, но не поменяло радикально.
Ну а сам процесс разработки под EE — это хождение по мукам. Просто начиная с того, чтобы запустить Weblogic нужно ждать пару минут, еще минут десять, чтобы сделать билд проекту, задеплоить, проверить сраную страничку и удалить. Примерно как в начале семидесятых. Поэтому существует куча технологий-хаков, которые ненамного пытаются улучшить ситуацию (Arquillian, JRebel, etc), которые надо будет тоже изучить. Вся разработка будет сводиться к поиску нужного рецепта, обходу ограничений платформы, борьбе с багами имплементации и непредвиденными сбоями приложений. Короче, ничего хорошего.
Я бы с радостью, честно)
Уже немного подумываю, чтобы немного изменить курс диплома с %REST-сервис на Java + Android клиент% на %REST-сервис на php + Android клиент%.
Я уже десять раз бы все это написал на php и начал бы клиент под Android)
Уже немного подумываю, чтобы немного изменить курс диплома с %REST-сервис на Java + Android клиент% на %REST-сервис на php + Android клиент%.
Я уже десять раз бы все это написал на php и начал бы клиент под Android)
Вы REST-сервис что ли на WebLogic пишете? Возьмите хотя бы Spring MVC, там его поднять дело трех минут (включая модульные и интеграционные тесты).
Если все-же решитесь:
Для изучения есть неплохая связка NetBeans+Glassfish и официальный тьюториал от Oracle: docs.oracle.com/javaee/6/tutorial/doc/
Для экспериментов есть прекрасный легковесный контейнер Apache TomEE, который может запускаться в embedded режиме прямо из любого JavaSE приложения. Имеется неплохая документация и отличные примеры: tomee.apache.org/examples-trunk/index.html Не требует геморроя со сборкой и деплоем на сервак — пускаем/дебагим прямо из IDE!
Для работы я использую Eclipse+JBoss Tools и JBoss AS 7. Redhat молодцы — допилили процесс разработки до удобоваримого состояния. В JBoss Tools одним кликом можно добавить в workspace уже готовые шаблоны проектов и погонять их. Есть step-by-step tutorials & examples: www.jboss.org/developer/quickstarts.html (NB! некоторые примеры используют технологии JBoss, не входящие в JavaEE)
P.S. В помощь EE-разработчику: www.physics.usyd.edu.au/~rennie/javaEEReferenceSheet.html
Для изучения есть неплохая связка NetBeans+Glassfish и официальный тьюториал от Oracle: docs.oracle.com/javaee/6/tutorial/doc/
Для экспериментов есть прекрасный легковесный контейнер Apache TomEE, который может запускаться в embedded режиме прямо из любого JavaSE приложения. Имеется неплохая документация и отличные примеры: tomee.apache.org/examples-trunk/index.html Не требует геморроя со сборкой и деплоем на сервак — пускаем/дебагим прямо из IDE!
Для работы я использую Eclipse+JBoss Tools и JBoss AS 7. Redhat молодцы — допилили процесс разработки до удобоваримого состояния. В JBoss Tools одним кликом можно добавить в workspace уже готовые шаблоны проектов и погонять их. Есть step-by-step tutorials & examples: www.jboss.org/developer/quickstarts.html (NB! некоторые примеры используют технологии JBoss, не входящие в JavaEE)
P.S. В помощь EE-разработчику: www.physics.usyd.edu.au/~rennie/javaEEReferenceSheet.html
Сейчас есть один приятный аппсервер: JBoss AS 7 (следующая версия, поддерживающая EE7, называется WildFly — бешеный мух). Запускается очень быстро (обычно — секунды) в отличии от всяких стеклорыбин и более тяжелых серверов.
уже наверное многое изменилосьПо крайней мере Java 6 в SE и EE-разновидностях появилась уже после этого поста…
Почему сразу деградирует — больше похоже на развитие. Если каждый раз начинать работу с создания велосипеда, то одни велосипеды в итоге получаться и будут)
Но, согласитесь, знать, что «под капотом» твоего инструмента все равно необходимо.
Да, фреймворки — это хорошо. Но из принципа Дырявых Абстракций следует, что если систему (инструмент, фреймворк etc) используют на пике возможностей, знание внутренностей будет необходимо. Раз человек с этим не сталкивался, значит реальных задач он с этими инструментами не решал.
Да, фреймворки — это хорошо. Но из принципа Дырявых Абстракций следует, что если систему (инструмент, фреймворк etc) используют на пике возможностей, знание внутренностей будет необходимо. Раз человек с этим не сталкивался, значит реальных задач он с этими инструментами не решал.
Раз человек с этим не сталкивался, значит реальных задач он с этими инструментами не решал.
Определение «реальных задач» назовёте?) Т.е., все работающие приложение, пусть даже очень сложные, но при разработке которых не пришлось разбирать внутренности выбранного фреймворка — нереальные, эфемерные?) Хочу узнать!
В идеале — надо бы может и знать, что под капотом. В идеале. Но вот как глубоко именно необходимо? Нужно ли быть инженером-проектировщиком CPU что бы оптимально писать приложения на Java?
Может, не полностью отвечу на Ваш вопрос, но вот пример:
Все знают, что есть Jetty, Netty, Undertow и другие библиотеки для работы с сетью. Из общей логики понятно, что берем либу, запускаем и все супер, все счастливы. Но начни приходить запросы не стандартного поведения, нужно будет разобраться с пулами на accept, на обработку, что бы выяснить, где ложиться вся супер система после минуты успешной работы. Нужно понять как устроен TCP стек, что бы найти например интересный параметр SO_LINGER, который спасает если много краткосрочных запросов. И в итоге к моменту когда все начинает работать как нужно, знания как все устроено есть. Я не считаю, что это должен знать каждый, но хорошо бы иметь представление о том, как это вообще работает. Это на примере HTTP стека
Все знают, что есть Jetty, Netty, Undertow и другие библиотеки для работы с сетью. Из общей логики понятно, что берем либу, запускаем и все супер, все счастливы. Но начни приходить запросы не стандартного поведения, нужно будет разобраться с пулами на accept, на обработку, что бы выяснить, где ложиться вся супер система после минуты успешной работы. Нужно понять как устроен TCP стек, что бы найти например интересный параметр SO_LINGER, который спасает если много краткосрочных запросов. И в итоге к моменту когда все начинает работать как нужно, знания как все устроено есть. Я не считаю, что это должен знать каждый, но хорошо бы иметь представление о том, как это вообще работает. Это на примере HTTP стека
Мой основной посыл был — нет «серебряной пули». Нет универсальных решений как и нет беспроблемных проектов (если не считать вырожденные случаи).
Пока все работает хорошо, то да, можно посадить вот такого эникейщика от программирования, чтобы тот клепал код на своем расово-верном фреймворке. Собственно, изоляция сложности и абстрагирование — это как раз правильно.
Но рано или поздно решение либо выйдет за границы применимости конкретной технологии, либо обнаружится неприятная проблема, где-то на стыке технологий (например, в связке DB+Hibernate+Teneo+EMF сущности почему-то стали теряться, либо внезапно доставаться стали буквально не те, хотя вроде и в базе все ок). Такие проблемы не редкость, и программист за них так же отвечает.
Пока все работает хорошо, то да, можно посадить вот такого эникейщика от программирования, чтобы тот клепал код на своем расово-верном фреймворке. Собственно, изоляция сложности и абстрагирование — это как раз правильно.
Но рано или поздно решение либо выйдет за границы применимости конкретной технологии, либо обнаружится неприятная проблема, где-то на стыке технологий (например, в связке DB+Hibernate+Teneo+EMF сущности почему-то стали теряться, либо внезапно доставаться стали буквально не те, хотя вроде и в базе все ок). Такие проблемы не редкость, и программист за них так же отвечает.
На самом деле всё это уже проходили в других областях, например электротехнике. Сто лет назад электрификация — это был hi tech, и инженер должен был всё знать электричестве. А сейчас роли разделились: есть инженер-электротехник, и есть электрик. Если первому необходимо высшее образование, то второму среднего специального достаточно с головой. В этом нет ничего плохого, инженер проектирует, электрик монтирует. IT развивается, и со временем большинство программистов будут уровня электрик-сантехник, собирающими типовое приложение на базе готовых модулей. Но останутся и задачи по разработке чего-то нового и сложного.
Более того часто использование многих Frameworks не оправдано.
Из моего опыта, не менее часто для программиста вообще нет возможности выбирать фреймворки — они заданы заранее и давно.
Зато решение писать «нативно» или через фреймворк лежит обычно на программисте.
Интересно получится если из команды в 10 человек один пишет нативно, а остальные на фреймворке?
Вот именно поэтому я считаю, что подготовка и сдача сертификационных экзаменов по своему языку программирования очень полезна в том числе и для опытных разработчиков. Ведь действительно, человек может иметь огромный стаж в своей компании, но не понимать некоторых важных аспектов языка. Если бы такой Framework Java Coder прошел бы сертификацию, он бы блестяще выступил на собеседовании.
Сертификация — это же тестирование — худший способ контроля знаний из всех!
Очень многие люди знают правильные ответы. Но знать правильно отвечать и действовать в соответствии со своими ответами — это две большие разницы.
Если спросить людей — нужно ли бросать курить, то почти все скажут — да.
А спортом заниматься надо? Да.
А уступать место в транспорте? Да
А кто так именно поступает? Горадо меньше людей.
Прямо как в анекдоте:
Две компании исследовали длину пениса, по одним данным получилось 5 см, по другим — 20 см. Потому что одни мерили, а другие – спрашивали.
Очень многие люди знают правильные ответы. Но знать правильно отвечать и действовать в соответствии со своими ответами — это две большие разницы.
Если спросить людей — нужно ли бросать курить, то почти все скажут — да.
А спортом заниматься надо? Да.
А уступать место в транспорте? Да
А кто так именно поступает? Горадо меньше людей.
Прямо как в анекдоте:
Две компании исследовали длину пениса, по одним данным получилось 5 см, по другим — 20 см. Потому что одни мерили, а другие – спрашивали.
А если надо выбрать несколько правильных ответов? А если надо расставить ответы в необходимом порядке? А если перед этим надо разобраться в полотне кода и уже потом дать правильный ответ или несколько? Попробуйте сдать сертификацию с такими тестами по какому-либо языку, не зная его, а потом уже делитесь своим опытом на реальном примере сертификации, а не «спортом заниматься» и «место в транспорте уступать». Да даже попробуйте решить какую-нибудь школьную олимпиаду, например, по биологии или химии, где число ответов ограничивается 4мя.
Я вот склоняюсь в мнению, что сертификацией специалистов должен заниматься работодатель, то есть чтобы здать экзамен надо потратить время на обучение и подготовке к нему, надо заплатить за него деньги. Причем реальной 100% выгоды это обычно не несет.
То есть компания должна обучать своих сотрудников иначе никак.
То есть компания должна обучать своих сотрудников иначе никак.
Да, сильная базовая подготовка — вещь весьма полезная…
Такие вот нынешние веб-кодеры, которые сделают вот сайт (развернут, например, какую-нибудь джумлу), напихают кучу плагинов со свистелками на любой вкус, а как надо что-то допилить/исправить для себя/заказчика, так гугл, потом паника, отчаяние, и «нет, ну это точно невозможно».
В том же геймдеве «Я создал игру» == «Скачал фреймворк, написал скриптов с тонной учебников под рукой, нарисовал (ну хотя бы нарисовал сам), молодец», а потом на геймдев.ру только и видно темы вида «как организовать инвентарь», «персонаж двигается рывками», «не вижу передних граней куба» и т.д.
В том же геймдеве «Я создал игру» == «Скачал фреймворк, написал скриптов с тонной учебников под рукой, нарисовал (ну хотя бы нарисовал сам), молодец», а потом на геймдев.ру только и видно темы вида «как организовать инвентарь», «персонаж двигается рывками», «не вижу передних граней куба» и т.д.
Это плохо? Я в школьные и студенческие годы копался с написанием своего «графического движка» сначала на Делфи, потом на C++ (OpenGL под Windows, простенькие шейдеры, простенькое освещение, поддержка моделек в MD2).
Сегодня я в вот ни в жисть не полезу в такое. Ни-за-что. Окончательно окрепнет желание разработать игру — возьму Unity, ну или что там в к тому времени будет актуальным. Ибо удобно, а вся низкоуровневая часть где-то там. Я в общих чертах теперь представляю, что там происходит, но сам копаться не хочу, время можно потратить гораздо полезнее и интереснее, чем написав очередной велосипед.
Сегодня я в вот ни в жисть не полезу в такое. Ни-за-что. Окончательно окрепнет желание разработать игру — возьму Unity, ну или что там в к тому времени будет актуальным. Ибо удобно, а вся низкоуровневая часть где-то там. Я в общих чертах теперь представляю, что там происходит, но сам копаться не хочу, время можно потратить гораздо полезнее и интереснее, чем написав очередной велосипед.
Я не понимаю, зачем многие нюансы, которые относятся к уже реализованным вещам, держать в голове? Например, у некоторых людей даже по паттернам есть специальный файлик, где описано, что, для чего и когда нужно и пример кода, например какой-нибудь паттерн вроде chain of responsibility или flyweight, которым человек крайне редко пользуется, но при случае может посмотреть в этом файлике. Также не понимаю собеседующих, которые считают, что разработчик должен все это держать в своей голове. Хотя, конечно, senior должен знать досконально, как работает платформа и каким образом код переводится в машинные инструкции.
— Какую IDE Вы использовали для написания JSP?
— Dreamweaver.
— Почему?
— В нашей компании все пользовались им.
А какой был бы ответ был бы… лучше? Правильнее? Что этот ответ вообще показывает?
Ну вот я когда использую PHP — дома пишу в Netbeans, потому что бесплатно и удобно, на работе писал в PhpStorm, потому что все в отделе использовали его же, а купить софт для компании не проблема. И когда все работают в одной IDE — так ведь всем удобнее, когда нужно от одного к другому рабочему месту подойти, что-то рассказать/спросить/показать.
В случае с андроидом аналогично выберу IntelliJ IDEA — удобно, бесплатно, работает быстро и достаточно безглючно. Другие пока не пробовал, никак времени не найду попробовать заново NetBeans — в старые времена она была очень тормозная. Android Studio никак не соберусь попробовать, она ведь основана на той же IntelliJ IDEA, есть ли большие преимущества — фиг знает.
Правильный ответ — я попробовал eclipse, netbeans, idea, блокнот, свой собственный редактор, и dreamviewer подходит лучше, потому что а), б), в), ну и все в отделе им пользуются, да.
Да ничего подобного, ответ «В нашей компании все пользовались им.» куда более реальней. Вот у нас все пользуются eclipse для java проектов, я бы рад пересесть на idea, да никак.
А что у вас в проектах такого завязано на eclipse?
Весь процесс разработки. Если в компании как IDE принята eclipse (или какая другая) у вас нет вариантов работать в другой. Хотя бы по вопросам совместимости.
P.S. упоминать что idea умеет работать с проектами от эклипса тоже не совсем актуально ибо это не 100% связь в обе стороны, а тратить часы на то, чтобы донастраивать каждый проект в своей idea никто не намерен + где гарантия что все мои настройки 100% попадут в проект эклипса и у других разработчиков не будет проблем.
P.S. упоминать что idea умеет работать с проектами от эклипса тоже не совсем актуально ибо это не 100% связь в обе стороны, а тратить часы на то, чтобы донастраивать каждый проект в своей idea никто не намерен + где гарантия что все мои настройки 100% попадут в проект эклипса и у других разработчиков не будет проблем.
По каким именно вопросам совместимости? И зачем «100% связь в две стороны»? Вы пишете в идее код, коммиттите его, его скачивают в eclipse и продолжают работу, нет? Я понимаю, если например компания пишет свою настройку над eclipse, или сильно завязана на какие-то специфические плагины, но в случае обычного энтерпрайза, например, нет вроде как ничего такого, привязанного именно к eclipse. Ну и вообще считается хорошей практикой держать в репозитории самодостаточный код, независимый от ide и способный собраться откуда угодно. Если у вас не так, то может быть стоит потратить некоторое время на исправление этого недостатка.
А ваши настройки в идее — это исключительно ваши настройки, зачем их кому-то показывать? Все, связанное непосредственно со сборкой проекта, должно лежать в репозитории в ide-независимом формате, всё остальное разноцветное — в .gitignore. Включая конфиги eclipse. И все будет хорошо. Да, нужно на это потратить какое-то время, возможно личное, но оно себя окупит в результате. Жалко проводить лучшую часть жизни, не видя солнца.
А ваши настройки в идее — это исключительно ваши настройки, зачем их кому-то показывать? Все, связанное непосредственно со сборкой проекта, должно лежать в репозитории в ide-независимом формате, всё остальное разноцветное — в .gitignore. Включая конфиги eclipse. И все будет хорошо. Да, нужно на это потратить какое-то время, возможно личное, но оно себя окупит в результате. Жалко проводить лучшую часть жизни, не видя солнца.
Например у нас стандартом является использование R# и тех, кто отказывается (были и такие), приходится заставлять. Причина проста: общекомандные настройки форматирования кода.
Возможно и в случае IDEA есть нечто подобное.
Возможно и в случае IDEA есть нечто подобное.
Такие проблемы должны лечиться на другом уровне: прекоммит хук для валидации (необходим на сервере, плюс может быть на машине разработчика) в VCS, плагин системы сборки (в том же мавене есть такие).
В случае IDEA есть поддержка конфигурации форматирования eclipse сторонним плагином. У меня такая настроена, правда особой разницы не вижу, отключу наверное и может пару настроек форматирования в самой идее подкручу.
В vcs лежат эклипсовские проекты, со своими настройками и тд и тп. то есть скачал и сразу открывай в эклипсе и работай. Соотсвенно все должны также и класть в vcs в виде проекта эклипса.
С одной стороны это хорошо ибо скачал открыл и 100% работает из коробки, с другой стороны я не могу использовать другую ide.
Что лучше, а что хуже сложно сказать.
С одной стороны это хорошо ибо скачал открыл и 100% работает из коробки, с другой стороны я не могу использовать другую ide.
Что лучше, а что хуже сложно сказать.
В первом случае разработчик тратит пару часов на разовую настройку проекта под себя (или копирует конфиг у старших товарищей), во втором раз в месяц посреди работы у вас какая-то хрень в IDE происходит и вы убиваете час, чтобы понять, что кто-то что-то у себя в конфиге поменял. Потом вы ещё час ругаетесь по поводу того, какая настройка лучше. Иногда бьете лица.
В общем-то кроме невозможности использовать другую ide проблем нет. Настройки размеров шрифтов и прочей лабуды лежать в конфиге эклипса и в свн не попадают конечно же так что ваш интерфейс и юзабилити не страдают.
Проект попадающий в свн содержит чисто настройки по подключаемым библиотекам, специфичные для проекта настройки и тд. Так что в общем-то описанных вами проблем я не наблюдаю.
Проект попадающий в свн содержит чисто настройки по подключаемым библиотекам, специфичные для проекта настройки и тд. Так что в общем-то описанных вами проблем я не наблюдаю.
Подключаемые библиотеки должны лежать в конфиге мавена, или чем вы там проект собираете. Специфичные для проекта настройки — это например что?
Нифига у вас сурово. Почти как у нас. Только это неправильно, блин.
Правильно или нет вопрос риторический. Чисто в рамках компании (в частности в нашей) это дает положительный эффект на производительность. Остается только полюбить эклипс, с дргой стороны почему требование использовать определенную IDE в разработке столько странно звучит, вполне себе нормальное требование.
Потому что эти вот настройки это прикладной момент. А код он и в афике код. Какая разница в какой IDE его писать?
Вот вы сначала жалуетесь, что вам не дают любимой игрушкой пользоваться, а потом eclipse защищаете. Отсюда закономерный вопрос про шашечки и ехать. Я вам пытаюсь объяснить, что если вы хотите работать в IDEA, а в команде принято работать в eclipse, то кроме вас никто вас на IDEA не пересадит, нужно самому инициативу проявить.
тут инициатива будет только уволитьсяи дрогое место найти ибо сложившуюся структуру никто менять не собирается из-за того, что кто-то хочет другую ide. Слишком дорогой процесс перезда при полной отсутсвии выгоды для компании.
P.S. и я не защищаю эклипс, я лишь сказал что такой подход организации рабочего процесса имеет место быть и ничег окриминального нет.
P.S. и я не защищаю эклипс, я лишь сказал что такой подход организации рабочего процесса имеет место быть и ничег окриминального нет.
Увольняться не выход, всегда можно что-то поменять под себя. А то устроитесь на новое место — а там вместо мавена библиотеки в папке lib/. Оттуда уйдете — на третьем месте Дженкинс будет глючить, и так далее.
Ну вот кстати на этом месте работы мавен не используют. Увольнение вполне себе нормальный способ решения проблема.
Странно. У нас вот тоже раньше не было мавена, гита своего. Все сидели на таких же условиях. Пришел один человек. Всего лишь один. За пол года у нас появился свой гит нормальный, появился свой мавен репозиторий со всеми нашими проектами, и сейчас потихоньку пилится свой проект-рыба для EE приложений (даже на фреймфорк немного похоже местами). Причем он пилится для pure JavaEE т.е. чтобы после чекаута запустился на любом контейнере с нужной поддержкой и в любой IDE. И выходит что фирме такая трата времени тоже невыгодна, но он смог же поменять всё вот это годами привычное.
Час раз в месяц — это немного, митинги больше занимают…
с другой стороны я не могу использовать другую ide.Не знаю насчёт IDEA и NetBeans, но сам Eclipse в качестве «другой IDE» вполне нормально работает — за счёт механизма «linked-папок».
если у вас страктура проекта используемой IDE храниться в cvs и все её используют и поддерживают, сменить ide вы не сможете.
Зачем «сменить ide»? Просто параллельно обрабатывать одни и те же сорцы в двух IDE. Гиморно, но, если надо, то реально…
Не забывайте что может быть много проекто, проекты могут быть связаны, пока вы эту структуру настроите в Idea пройдет пара дней.
И не забывайте важный момент страктура проекта используемой Idea храниться в cvs и все её используют то есть если вам надо добавить новый модуль, этот модуль надо поддержать в структуре проекта, то есть чтобы он подцепился у всех других разработчиков, вот тут и проблема — у вас Idea у них эклипс
И не забывайте важный момент страктура проекта используемой Idea храниться в cvs и все её используют то есть если вам надо добавить новый модуль, этот модуль надо поддержать в структуре проекта, то есть чтобы он подцепился у всех других разработчиков, вот тут и проблема — у вас Idea у них эклипс
Ну так и настраивайте по вечерам потихоньку. Если оно вам надо, конечно. Заодно и модули в мавен можно перенести. Может быть, вам даже премию выпишут в итоге.
По вечерам у меня есть семья )
А мы ушли не в то русло, я лишь завялял, что выбор IDE может быть со стороны компании и не подлежать обсуждению. даже если я себе настрою проект мне придется поддерживать актуальным проект для eclipse и тестировать его, так как в компании используется эклипс и компании это удобно.
А мы ушли не в то русло, я лишь завялял, что выбор IDE может быть со стороны компании и не подлежать обсуждению. даже если я себе настрою проект мне придется поддерживать актуальным проект для eclipse и тестировать его, так как в компании используется эклипс и компании это удобно.
Ну а я просто говорил, что даже в условиях, приближенных к боевым, можно всегда выкопать окоп и из него отстреливаться наиболее подходящими для этого инструментами.
Так нужный веский повод. У эклипса есть проблема он не понимает jsp, точнее понимает но очень очень плохо, ну вот специально jsp я засунул как файлики в Idea и с ними там работаю. не влияя на весь проект.
Повышение вашей личной производительности труда — вполне себе он.
Если мне придется все равно пользоваться эклипсом, чтобы протестить изменения внесенные мной выйигрыша как такового не будет. Ведь все остальные продалж пользоваться эклипсом и хранить проекты в cvs, следовательно я должен это поддерживать
Это ненадолго. IDEA — она как чума, сегодня у вас, завтра у коллеги, послезавтра у всей компании.
И что самое плохое, из-за её платности нельзя всех обязать пользоваться ею. В отличие от Eclipse.
Есть бесплатная версия.
Если это ваши сотрудники, можно им ее купить.
На такое обычно «жаба душит». Да и количество пользователей «коллективной лицензии» заранее неизвестно…
У идеи, насколько понимаю, нет коллективной лицензии (в общем случае). Есть фиксированная цена за рабочее место, которая отличается при покупке на компанию (без привязки к конкретному человеку) и на конкретного человека за его личные деньги.
Насчет жабы — идея как день работы программиста стоит в худшем (для программиста) случае, плюс расходы списываются с налогов. Имхо окупается она быстро.
Насчет жабы — идея как день работы программиста стоит в худшем (для программиста) случае, плюс расходы списываются с налогов. Имхо окупается она быстро.
У Eclipse и IDEA разные, несовместимые, настройки автоматического форматирования. Открывают код после одной IDE в другой, автоформатируют все строки, сохраняют — вот уже две «разные версии». Одна среда в Javadoc пробелы после звёздочек в конце строк ставит, другая убирает, и эта мелочь не настраивается. Также не настраиваются и отличаются нюансы форматирования разбиения длинной строки на несколько строк. После одной среды изменили одно место в другой, заодно всё переформатирвалось — в диффе изменений куча, все кроме одного бесполезные.
А такую штуку пробовали?
И сколько человеко-часов стоит этот правильный ответ? Теоретически, в качестве «хотелки», я ваш вариант, конечно, поддерживаю…
Наверное, этот мой коммент и на этот ваш тоже является репликой…
Правильно не «В нашей компании все пользовались им.», а «это был корпоративный стандарт де-факто». Сразу видно, что чел и в комманде работать умеет и баззворды знает и факт отпиарить правильно может…
«jQuery developer» уже давно, вроде, нарицательное выражение.
Ругаете framework разработчиков, а ведь большинство таковыми и является, только на один уровень абстракции ниже. Человека, который в совершенстве знает java se, тоже можно назвать framework разработчиком. Потому что все в итоге упирается в нативные методы. А много ли из этих людей знает как написан компилятор и виртуальная машина? А как работает и написан встроенный в jvm jit компилятор. И этот стек можно продолжать до самого нижнего уровня, который упирается в команды определенного процессора. А если продолжать еще ниже, то тут вообще остаются считанные единицы людей, которые знают как и что работает. Не в общих чертах, а конкретные реализации на конкретных примерах. Да в принципе можно дойти и до атомарного уровня. А то, что мы называем неделимым — тоже скрывает от нас свою реализацию и наука до этого еще не дошла. Так что все мы с вами по сути фреймворк разработчики.
Всё правильно, идеальный сферический разработчик в вакууме должен знать всё от фабрик фабрик фабрик до команд процессора (в физику давайте, всё таки, не лезть). Учитывая то, насколько обширен каждый из «фреймворков», это займёт слишком много времени.
Вот и приходится расставлять приоритеты. А начинать логично с самого высоко уровня, т.к. реализовать какое-то приложение, умея только работать с готовым библиотеками (ну и сама Java, куда же без этого) проще, чем зная только ассемблер.
Вот и приходится расставлять приоритеты. А начинать логично с самого высоко уровня, т.к. реализовать какое-то приложение, умея только работать с готовым библиотеками (ну и сама Java, куда же без этого) проще, чем зная только ассемблер.
Никак, потому что я их не знаю.
Команды процессора я упомянул в ответ на комментарий выше, потому что в целом я в этим согласен — любая технология так или иначе помогает в работе. Просто какая-то — больше, какая-то — меньше.
Ну и не смотря на то, что в знании самих команд для разработчика я не вижу, из этого знания часто следует понимание архитектуры компьютера, устройства памяти, осознание того, как всё работает на элементарном уровне. Не уверен, что это даёт практическую пользу, но как минимум приятно понимать, как устроены привычные инструменты.
Команды процессора я упомянул в ответ на комментарий выше, потому что в целом я в этим согласен — любая технология так или иначе помогает в работе. Просто какая-то — больше, какая-то — меньше.
Ну и не смотря на то, что в знании самих команд для разработчика я не вижу, из этого знания часто следует понимание архитектуры компьютера, устройства памяти, осознание того, как всё работает на элементарном уровне. Не уверен, что это даёт практическую пользу, но как минимум приятно понимать, как устроены привычные инструменты.
Ява еще более-менее близка к железу, в отличие от многих новых динамических и функциональных языков. Поэтому знание железа может помочь написать более быстрый Ява-код.
Не ради придирок… а как вам помогает знание команд процессора программировать на Java?
Например, позволяет ответить на такой вопрос по довольно высокоуровневой теме: stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array
Вот еще забавная штука, про компиляцию ява байткода gist.github.com/Fuud/8122612/raw/af8bf68e31c12e9fcde28633e1b6df861645c5e7/LoopBac, разница между for (int i = 0; i < arr.length; i++) и for (int i = arr.length — 1; i >= 0; i--)
Но маловероятно что в жизни это хоть раз понадобится. Не считая того что команды процессора или в какой байткод компилируется код-может быть в любой момент без предупреждения изменено разработчиками явамашин и процессоров.
Но маловероятно что в жизни это хоть раз понадобится. Не считая того что команды процессора или в какой байткод компилируется код-может быть в любой момент без предупреждения изменено разработчиками явамашин и процессоров.
Так, а чего это не лезть в физику?! Совсем уже эти фреймворк-программеры обленились, выучат какой-то высокоуровневый язык типа ассемблера и думают, что понимают, как компьютер работает!
Servlet API тоже та еще фигня на самом деле — как только нужно по TDD сделать макеты HttpServletRequest/HttpServletResponse и всех связанных вещей (всяких контекстов, сессий и т.п.) — сразу понимаешь «всю глубину глубин». И либо бросаешь эту затею — и не выходит из этого ничего, либо колупаешь по выходным и т.п., и получается какой-нибудь mockito, jmock или easymock.
А тем временем некоторым людям за такое платят — и пишут они, счастливые, какой-нибудь Spring (-:
А тем временем некоторым людям за такое платят — и пишут они, счастливые, какой-нибудь Spring (-:
Все правильно говорите. Только вот каждому нужно знать на один уровень ниже. А в статье речь идет о том, что люди не знают на один уровень ниже.
Фреймворк фреймворку рознь, степень «дырявости абстракций» сильно разнится. Хороший фреймворк должен кроме прочего хорошо писать логи и обрабатывать ошибки в вызовах его функций.
Представьте, например, если бы виртуальная машина Java, вместо культурного бросания NPE с дампом java-стека, просто бы падала из-за ошибки уже в самом своём бинарнике, вызванной попыткой получить что-то там от объекта, который должен бы находиться по самому этому указателю “в никуда”, скупо что-то сообщая об этой вызванной входными данными ошибке в интерпретаторе. Или не падала бы, если мусор по нулевому адресу оказывался бы «съедобным». Или падала бы через раз на каком-нибудь следующем шаге, пытаясь использовать свойства этого фантомного объекта. Или, если «повезло» не упасть, ошибки вылезали бы каждый раз разные и в разных местах. Поиск ответа на вопрос “в каком месте находится ошибка” в таких условиях может сам по себе оказаться задачей на час-другой.
А во фреймворках, особенно «самопальных», управляемых метаданными на XML (а для JVM java-байткод — это практически такие же метаданные), подобная ситуация — стандарт: «не найден атрибут 'A' у класса 'B'» с «простынёй» вложенных java-стек-трейсов (которые бесполезны хотя бы потому, что при разных ошибках в данных номера строк в стек-трейсе одинаковые) — и сиди-догадывайся, в каком месте случилось и что и где нужно исправить в настройках.
Представьте, например, если бы виртуальная машина Java, вместо культурного бросания NPE с дампом java-стека, просто бы падала из-за ошибки уже в самом своём бинарнике, вызванной попыткой получить что-то там от объекта, который должен бы находиться по самому этому указателю “в никуда”, скупо что-то сообщая об этой вызванной входными данными ошибке в интерпретаторе. Или не падала бы, если мусор по нулевому адресу оказывался бы «съедобным». Или падала бы через раз на каком-нибудь следующем шаге, пытаясь использовать свойства этого фантомного объекта. Или, если «повезло» не упасть, ошибки вылезали бы каждый раз разные и в разных местах. Поиск ответа на вопрос “в каком месте находится ошибка” в таких условиях может сам по себе оказаться задачей на час-другой.
А во фреймворках, особенно «самопальных», управляемых метаданными на XML (а для JVM java-байткод — это практически такие же метаданные), подобная ситуация — стандарт: «не найден атрибут 'A' у класса 'B'» с «простынёй» вложенных java-стек-трейсов (которые бесполезны хотя бы потому, что при разных ошибках в данных номера строк в стек-трейсе одинаковые) — и сиди-догадывайся, в каком месте случилось и что и где нужно исправить в настройках.
Есть мнение, что нужно знать тот уровень абстракций на котором приходится делать большинство задач + на один уровень ниже.
Т.е. Не просто скармливать ORM'у параметры для выборки, но еще и иметь представление о генерируемых запросах в конкретную бд (например, sql), которые ORM будет генерировать и уметь эти запросы читать и профилировать. А вот знать как работает механизм генерации запросов внутри ORM как правильно не нужно, т.к. патчи лепить бессмысленно, а уж разбираться можно несколько дней.
Отсюда вывод — нужно знать все, что пригодится, чтобы максимально быстро решать ежедневные задачи и какие именно уровни абстракции понадобятся — дело особенностей конкретного места работы.
Ваш КО.
Т.е. Не просто скармливать ORM'у параметры для выборки, но еще и иметь представление о генерируемых запросах в конкретную бд (например, sql), которые ORM будет генерировать и уметь эти запросы читать и профилировать. А вот знать как работает механизм генерации запросов внутри ORM как правильно не нужно, т.к. патчи лепить бессмысленно, а уж разбираться можно несколько дней.
Отсюда вывод — нужно знать все, что пригодится, чтобы максимально быстро решать ежедневные задачи и какие именно уровни абстракции понадобятся — дело особенностей конкретного места работы.
Ваш КО.
нужно знать все, что пригодится, чтобы максимально быстро решать ежедневные задачи
Периодически возникают задачи, не входящие в круг ежедневных. Обычно на них (скорости, а то и возможности решения) и проявляется разница между «гуру» и «фреймворк-кодером». В вашем примере с ORM, скажем, мало возможности профилировать запросы — толку от того, что будет видно, что запрос или гидрация тормозят и в каком месте, если не знать как заменить запрос, обойтись без гидрации (это ещё знание фреймворка) или вообще поработать с БД напрямую.
Нужно, например, отсортировать данные — поставим гем. А как оно внутри работает и зачем — да кому это интересноА интересно это должно быть тем, кто занимается архитектурой проекта. Т.к. «поставим гем/заюзаем фреймворк/притащим тулу» без согласования со всей командой, без анализа нужностей и возможностей этого гема и т.п. поможет приехать проекту в ректум чуть побыстрее, чем обычно.
Я, видимо, не совсем правильно выразился. Суть моей позиции такая — нет в принципе ничего плохого в фреймворках, библиотеках, и т.д. — все эти инструменты сами по себе, как и любой другой инструмент, не плохи и не хороши, они полезны. Плохо бесконтрольное притаскивание в проект сторонних элементов, которое не согласовано с командой — и вот тут в рамках проекта/команды должен быть некий координационный/архитектурный консилиум, который понимает, что именно в проект можно притащить, а что — можно писать самому. К сожалению, при невысоком уровне координации в команде, её зачастую шатает от одного полюса (на котором пишется ещё один велосипед для каждого чиха) до другого (в котором в проект импортится по 2-3 компоненты, делающие одно и то же, но «чуточку по разному»).
По моему тут вопрос не уровня программиста, а просто ну архитектор человек или кодер. Или более того — просто разный взгляд на архитектуру.
По хорошему — решил задачу, поставил gem — ок, не написал руками — сэкономил время. Ну правда стоит смотреть «живой» gem или не живой, но это может быть просто policy проекта.
Я не могу сказать что встречал прямо таких Rails кодеров которые «не программисты», для меня это все на голову выше чем я в PHP мире встречал, особенно по сравнению со всякими «Я твой сайт джумла друпал».
А еще — ну а кто готов реально загрузить таких спецов? В мире Java я понимаю в чем проблема — когда я писал на JavaEE все постоянно «подглюкивало» и без понимания кишок проект нельзя было запустить, но в Rails то — ну берешь и пишешь, фигли тут придумывать.
По хорошему — решил задачу, поставил gem — ок, не написал руками — сэкономил время. Ну правда стоит смотреть «живой» gem или не живой, но это может быть просто policy проекта.
Я не могу сказать что встречал прямо таких Rails кодеров которые «не программисты», для меня это все на голову выше чем я в PHP мире встречал, особенно по сравнению со всякими «Я твой сайт джумла друпал».
А еще — ну а кто готов реально загрузить таких спецов? В мире Java я понимаю в чем проблема — когда я писал на JavaEE все постоянно «подглюкивало» и без понимания кишок проект нельзя было запустить, но в Rails то — ну берешь и пишешь, фигли тут придумывать.
Мне кажется, это не деградация, а специализация. Программисты на ассемблере тоже были, наверное, фреймворк-кодерами в глазах тех, кто привык писать в машкодах. Аналогично с переходом Ассемблер — Си, Си — Си++, Си++ — Ява и т. д.
Вот и отлично, чем больше таких программистов – тем лучше живётся действительно толковым специалистам.
Такая ситуация во многих отраслях: есть медсёстры, которые закончили ПТУ при церковно-приходской школе и умеют преимущественно катать ватные шарики. А ещё есть, например, операционные медсестры, которые ассистируют врачу в действительно сложных вещах. Соответственная разница в зарплате.
Допускаю, что есть очень много людей, не увлекающихся своим делом в принципе, которые на любой работе одинаково страдают и ждут конца рабочего дня с секундомером, чтобы забыть всё, как страшный сон. Не могу их обвинять, это личное дело каждого.
Такая ситуация во многих отраслях: есть медсёстры, которые закончили ПТУ при церковно-приходской школе и умеют преимущественно катать ватные шарики. А ещё есть, например, операционные медсестры, которые ассистируют врачу в действительно сложных вещах. Соответственная разница в зарплате.
Допускаю, что есть очень много людей, не увлекающихся своим делом в принципе, которые на любой работе одинаково страдают и ждут конца рабочего дня с секундомером, чтобы забыть всё, как страшный сон. Не могу их обвинять, это личное дело каждого.
Какая работа — такие работники. Когда на 1 позицию разработчика фреймворка приходиться 1000 позиций формошлепов г-нокодеров (с не радикально меньшей оплатой) — стоит ли удивляться увеличению кол-ва последних?
В этом нет ничего плохого до тех пор, пока программист понимает, как работает остальные части приложения.
В крупных компаниях разделение труда программистов настолько сильно, что даже знания «как оно работает изнутри» не спасает от решения проблем. На практике при возникновении неуловимого бага — его дебажит автор кода. Вот он и только он понимает, что он там написал (и то спустя месяцы с трудом), и он и только он способен тестировать приложение. И только он найдёт решение проблемы.
Посадите на его место другого ещё более крутого специалиста (ну вот наняли нового к примеру) — специалист почешет затылок и заново напишет данный фрагмент, потому что реинженерить более затратно по времени. Каждый в собственную меру применяет рефакторинг. Кому-то удобнее прыгать из функций в функцию, расположенные в разных модулях (потому что так по феншую), а кому-то удобнее всё в одной процедуре на 2 тыс. строк реализовать (и то пользуясь копипастой).
Единственный, кому наплевать на это с высокой башни, это клиенты. Порой достаточно поставить костыль в виде TRY...CATCH...ENDTRY и денежка потечёт рекой. Я не удивлюсь, если в вашем процессоре таких багов десяток, и их исправляет драйвер, а вы пьёте кофе и понять не можете, почему компьютер иногда зависает именно у Васи Петрова, играющего в игры, а не у Маши, которая ведёт блог. Всё таки не все «погроммисты» пишут команды для ядерного реактора. Большинство программ на рынке создаются, чтобы тётя в бухгалтерии стала тыкать на одну кнопочку меньше, чем раньше. И поэтому возникли все эти фреймворки.
В крупных компаниях разделение труда программистов настолько сильно, что даже знания «как оно работает изнутри» не спасает от решения проблем. На практике при возникновении неуловимого бага — его дебажит автор кода. Вот он и только он понимает, что он там написал (и то спустя месяцы с трудом), и он и только он способен тестировать приложение. И только он найдёт решение проблемы.
Посадите на его место другого ещё более крутого специалиста (ну вот наняли нового к примеру) — специалист почешет затылок и заново напишет данный фрагмент, потому что реинженерить более затратно по времени. Каждый в собственную меру применяет рефакторинг. Кому-то удобнее прыгать из функций в функцию, расположенные в разных модулях (потому что так по феншую), а кому-то удобнее всё в одной процедуре на 2 тыс. строк реализовать (и то пользуясь копипастой).
Единственный, кому наплевать на это с высокой башни, это клиенты. Порой достаточно поставить костыль в виде TRY...CATCH...ENDTRY и денежка потечёт рекой. Я не удивлюсь, если в вашем процессоре таких багов десяток, и их исправляет драйвер, а вы пьёте кофе и понять не можете, почему компьютер иногда зависает именно у Васи Петрова, играющего в игры, а не у Маши, которая ведёт блог. Всё таки не все «погроммисты» пишут команды для ядерного реактора. Большинство программ на рынке создаются, чтобы тётя в бухгалтерии стала тыкать на одну кнопочку меньше, чем раньше. И поэтому возникли все эти фреймворки.
Смотря все в глубь и вглубь можно дойти до реализации жвм, архитектуры процессора, химмии, физики, теории струн, а закончить на филосовско-политеческом дискусе. И на каждом этапе может быть гуру который возмущается отсутствием знаний в чем-либо.
Интересно было бы узнать, для каких задач набирали Senior Java разработчиков. А то приходишь работать в солидную компанию с большим соцпакетом, проходишь сложнейшее собеседование, а потом сидишь и клепаешь вьюшки на фреймворке без конца и края.
И в гугле и в фэйсбуке, слышал, от этого очень страдают. Рутины куча.
И в гугле и в фэйсбуке, слышал, от этого очень страдают. Рутины куча.
И в гугле и в фэйсбуке, слышал, от этого очень страдают. Рутины куча.
вот про такое не слышал, неужели?
Да, а кто там по-вашему делает верстку FAQ и формы регистрации/terms&conditions и прочую ерунду, специально обученные обезьянки?
— Как Вы подключались к базе данных?
— У нас был XML файл, в котором хранились параметры для БД, вроде имени пользователя или пароля.
— Но где эти данные на самом деле определялись/находились?
— В классе Database фраемфорке DBConnector
— а как он подключался в самой БД
— создавалося экземпляр класса DBCOnnector::XYZSession с заданными параметрами
— а что делал этот класс
— создавал TCP обеспечивал работу по протоколу XYZ
— а с чего начиналась работа
— устанавливалось TCP соединения
— а какое оно было
— асинхронное
— а что использовалось для созданния асинхронного соединения
— класс AynscTCPSession из ABC
— а что он делал
— создавал неблокирующий сокет и связывал его с реактором
— а как создавался соке
— класс TCPSocket
— а что он делал
— вызов стандартной функции socket
— а что она делала
— вызов системной функции
— а она
— создавала сущность в ядре
— а оно
— предавало управление в драйвер
— а он
— выдавал эллектрические сигналы в канал
— а тот
— передевался по каналу связи
— а из чего он
— из меди
— а вы знаете что это
— такойто элемент в таблице менделеева
— а он кто такой
—…
Это очень нерационально создавать большие системы с нуля, в противном случае вы пользуетесь высокоуровнеными конструкциями, а они на то и высокоуровневые, что бы вы не знали как они реализованы.
— У нас был XML файл, в котором хранились параметры для БД, вроде имени пользователя или пароля.
— Но где эти данные на самом деле определялись/находились?
— В классе Database фраемфорке DBConnector
— а как он подключался в самой БД
— создавалося экземпляр класса DBCOnnector::XYZSession с заданными параметрами
— а что делал этот класс
— создавал TCP обеспечивал работу по протоколу XYZ
— а с чего начиналась работа
— устанавливалось TCP соединения
— а какое оно было
— асинхронное
— а что использовалось для созданния асинхронного соединения
— класс AynscTCPSession из ABC
— а что он делал
— создавал неблокирующий сокет и связывал его с реактором
— а как создавался соке
— класс TCPSocket
— а что он делал
— вызов стандартной функции socket
— а что она делала
— вызов системной функции
— а она
— создавала сущность в ядре
— а оно
— предавало управление в драйвер
— а он
— выдавал эллектрические сигналы в канал
— а тот
— передевался по каналу связи
— а из чего он
— из меди
— а вы знаете что это
— такойто элемент в таблице менделеева
— а он кто такой
—…
Это очень нерационально создавать большие системы с нуля, в противном случае вы пользуетесь высокоуровнеными конструкциями, а они на то и высокоуровневые, что бы вы не знали как они реализованы.
«Хороших разработчиков фреймворки тупыми не сделает, а плохих уже ничего не спасёт.»
© qbash.ru
© qbash.ru
Сначала подумал, что имеется в виду, что есть спрос на разработчиков фреймворков.
Фреймворки это ведь только инструмент, главное чтобы человек кодил нормально: использовал SOLID подход и паттерны применял умно.
Фреймворки это ведь только инструмент, главное чтобы человек кодил нормально: использовал SOLID подход и паттерны применял умно.
Если проект длится достаточно долго — в нём так или иначе появляется свой фреймворк…
Я не хочу сказать, что framework coder — это круто, но я хочу сказать, что быть хорошим framework coder очень и очень непросто.
Вот возьмём, например, .NET.
Если ты разрабатываешь desktop-приложения под Windows, то тебе нужно знать WPF. Я сейчас опускаю необходимость хорошо знать C# (а это уже очень серьёзные знания, ибо C# сильно разросся и Скит это подтверждает, выучить его с нуля и знать тонкости очень затратно).
Так взглянем же на WPF.
Его можно знать поверхностно, да. Но в таком случае вы будете писать говнокод, у вас будет уходить куча времени на настройку привязок, постоянное копание в доках при необходимости создать простой CustomControl и многое другое. Неплохо также было бы знать какой-нибудь MVVM-framework.
Всех ваших минимальных знаний по WPF и, скажем, Caliburn, будет хватать до тех пор, пока не начнёт твориться что-то непонятное и вы будете вынуждены лезть под капот. Тут буквально недавно вышел семичасовой курс по WPF Data Binding. Семичасовой! Вдумайтесь в это.
Это я к тому, что хорошему Framework Coder приходится хранить в голове столько, что с ума сойти можно.
Никто из работодателей не собирается ждать мегаалгоритического гуру, пока тот разберётся в тонкостях framework. Это очень дорого.
Всё абсолютно справедливо. Каждый находит свою нишу. Алгоритмисты должны писать алгоритмы, UI-программисты должны разрабатывать UI и так далее. Вот и всё.
Вот возьмём, например, .NET.
Если ты разрабатываешь desktop-приложения под Windows, то тебе нужно знать WPF. Я сейчас опускаю необходимость хорошо знать C# (а это уже очень серьёзные знания, ибо C# сильно разросся и Скит это подтверждает, выучить его с нуля и знать тонкости очень затратно).
Так взглянем же на WPF.
Его можно знать поверхностно, да. Но в таком случае вы будете писать говнокод, у вас будет уходить куча времени на настройку привязок, постоянное копание в доках при необходимости создать простой CustomControl и многое другое. Неплохо также было бы знать какой-нибудь MVVM-framework.
Всех ваших минимальных знаний по WPF и, скажем, Caliburn, будет хватать до тех пор, пока не начнёт твориться что-то непонятное и вы будете вынуждены лезть под капот. Тут буквально недавно вышел семичасовой курс по WPF Data Binding. Семичасовой! Вдумайтесь в это.
Это я к тому, что хорошему Framework Coder приходится хранить в голове столько, что с ума сойти можно.
Никто из работодателей не собирается ждать мегаалгоритического гуру, пока тот разберётся в тонкостях framework. Это очень дорого.
Всё абсолютно справедливо. Каждый находит свою нишу. Алгоритмисты должны писать алгоритмы, UI-программисты должны разрабатывать UI и так далее. Вот и всё.
«Framework Coder» — это из серии «не проектировщик, а решатель проблем». «У клиента программа не работает, вникать некогда, надо срочно починить чтоб как-то работало». В идеале можно даже не знать толком языка программирования и всё равно мочь находить в коде самые тупые логические ошибки (мне на собеседованиях попадались задачи из этой серии). Правда, одно дело, когда ты этот язык видишь в первый и, может быть, последний раз, другое — когда ты пишешь на нём долго.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новый вид разработчиков — Framework Java Coder?