>Или вы хотите сказать что человек работавший несколько лет с одним фреймворком легко может пересесть на другой?
Да, может. Если человек знает что такое DI и делал его на Spring, то он с минимальным временем на обучение перейдёт на Guice. Если человек знает что такое Hibernate, то он с небольшой потерей времени перейдёт на TopLink. А если он вообще ни одного фреймворка в глаза не видел, то и получается — ручной маппинг в DTO, синглетоны на каждом шагу и прочее.
>Ну дык и я о том же.
Простите, как то не заметил.
>Почему вы считаете что смена фреймворка на Java проще перехода с C++ на Java (с одновременной сменой фреймворка, понятно)?
Потому, что переход от A+B+C к X+Y+Z сложнее, чем переход от A+B+C к A+B+D.
И вообще насколько я помню разговор шёл не про то, что человека перевести с С++ на Java, а про то, что С++ девелопера можно на пару дней «дёрнуть» на Java проект. Я что-то неправильно понял?
Собственно всё началось ровно тогда, когда вы сказали, что все фреймворки — это «побрякушки». Оно конечно так, только всё когда-либо превращается в побрякушку. Как вы будете делать ORM? А DI? А MVC? Всё руками? Всё с нуля?
Собственно Вы в праве продолжать относиться к фреймворкам и вообще к IT как вам хочется. Но предлагаю спорить о вкусе устриц всё-же хотя бы попробовав их на вкус.
Я непонял, мы про какую платформу говорим? Естественно есть среды, где и java будет досточно тормозной. Я говорю про сегодняшние реалии, где клиентский компьютер обладает гигом памяти и гигогерцами проца. Где дополнительный гиг памяти (даже серверной) стоит до 100 баксов.
>А это — смотря какой у вас бизнес :-) Если вы делаете полезные для людей продукты, то да — умение оценить ресурсы, которые ваша программа потребует для своей работы важнее знания основ JEE. Если вы впариваете людям сляпанные «на скорую руку» системы, а потом «за дополнительную плату» решаете проблемы с производительностью в этих системах, то важнее знание JEE.
Для любого бизнеса использование наработанных, распространённых решений зачастую благо. Месяц работы одного (!) программиста окупит любой фреймворк и любую IDE. Использование стандартных (а тем более поддерживаемых сторонними разработчиками) решений — есть удешевление продука и снижение рисков.
Все самопальные решения постоянно приходят к тому, что:
а) Становятся «местячковыми», т.е. ушёл главный программист — половина мест хз пойми как работает и где что вообще надо править, чтобы что-то изменилось.
б) Начинают дублировать функционал какого-либо фреймворка (ов), только вся поддержка этого куска кода лежит на разработчиках приложения. И вместо того, чтобы забивать гвозди начинаешь так же следить за состоянием молотка, качеством досок, светом в туалете и прочее…
>Кто бы спорил. Но тут вот какая беда: фреймворки приходят и уходят, алгоритмы остаются.
Ну да, приходят и уходят… А стратсу и хибернейту под 10ку уже, а так да — приходят и уходят.
>Нельзя объять необъятное.
То же самое можно сказать об изучении Java Core. Не бойтесь изучать новые технологии и фреймворки, их вам всё-равно придётся изучить ;)
>Посмотрим. К написанию кода я пока не приступил, но уже нашёл одно место где (при неудачном стечении обстоятельств) программа может сожрать несколько гиг памяти (и, соответственно, рухнуть). Хотя человек, её писавший, как раз таки большой знаток Java-технологий. А вот о том сколько займут объекты в памяти перед тем как пропадут «живые» ссылки на них и GC сможет приняться за работу — он не подумал.
Я не против углублённого изучения java, я наоборот ЗА, но этого слишком мало, java без созданных инструментов и фреймворков есть C++ с GC. Java с фреймворками — это танк, на котором можно хоть куда и хоть когда, хотя и жрёт порядочно.
Позволю себе не согласиться, знание плюсов и минусов каждого из языков — удел senior architector-а, а PM — он скорее манагер, чем программист. Хотя на вкус и цвет фломастеры разные.
Извините, Вы предполагает, что знание того, по какому алгоритму работает Array.sort() более важны, чем знание JEE или современных фреймворков? Вопрос на засыпку: что более выгодно для бизнеса — знание программистом тонкостей Java core или основ JEE?
Только фрэймворки и паттерны позволяют не изобретать велосипед, а работать примерно в одной системе координат всем разработчикам в команде. То, что Вы называете указанные фрэймворки «побрякушками» говорит о недостаточном опыте работы в Java среде.
Я видел разный код, и когда я вижу, что понаписали люди, не ведающие про отработанные в индустрии подходы и фреймворки (типа JPA) — мне становится дурно.
При этом я согласен, что зачастую можно написать узко-специализированный фреймворк для своих задач уделывающий любой другой, даже самый «модный и распространённый». Но это, опять таки, возможно только после изучения всех существующих подходов к решению проблемы (читай фреймворков).
А насчёт Вашей будущей встречи — не расчитывайте сильно на благоприятный исход, холодильники совмещённые с экскаватором редко хорошо работают 8)
Вы что издеваетесь? Как можно человека, пишущего на С++ перебросить на Java? КАК? Я просто представить себе не могу!
Какой C++ программист знает про AOP, про JPA или там про GC java-овский или про maven? Где они — эти программисты? Почему я ни одного такого программиста не видел?
"еженедельный подкаст от такогото" - плагиат?? Я далёк от подкастов, но имхо это перебор. Это всё-равно, что Артемий Лебедев копирайт на известное слово бы заявил.
Хочу прокомментировать первый вариант - сейчас на работе с ним приходиться иметь дело...
Описание данной схемы неполно... В нашем случае ObjectsFields является не отдельной таблицей, а целым набором таблиц, для разных типов данных своя таблица. Т.е. существуют таблицы ObjectFieldsVarchar, ObjectFieldsDate, ObjectFieldsBlob и так далее... Понятно, что можно сделать одну таблицу ObjectsFields, в которой будут поля всех типов, но в итоге это совсем не намного изменит ситуацию - работать с этой пачкой сложно.
Присоединюсь ко всем здесь высказывавшимся - работать с этой пачкой говна очень сложно. Либо полностью через хранимые процедуры (которые возвращают тебе строку с полями, которые ты запросил), либо приходится делать УЖАСНЫЕ извращения на клиенте. В частности ужасной ужастностью здесь является известная N+1 проблема, из-за которой динамическая lazy-линковка практически невозможно.
А насколько мелкие jar-ники были? Получается, что надо делать очень маленькие библиотеки, чтобы при необходимости можно было их заменять?
Да, может. Если человек знает что такое DI и делал его на Spring, то он с минимальным временем на обучение перейдёт на Guice. Если человек знает что такое Hibernate, то он с небольшой потерей времени перейдёт на TopLink. А если он вообще ни одного фреймворка в глаза не видел, то и получается — ручной маппинг в DTO, синглетоны на каждом шагу и прочее.
>Ну дык и я о том же.
Простите, как то не заметил.
>Почему вы считаете что смена фреймворка на Java проще перехода с C++ на Java (с одновременной сменой фреймворка, понятно)?
Потому, что переход от A+B+C к X+Y+Z сложнее, чем переход от A+B+C к A+B+D.
И вообще насколько я помню разговор шёл не про то, что человека перевести с С++ на Java, а про то, что С++ девелопера можно на пару дней «дёрнуть» на Java проект. Я что-то неправильно понял?
Собственно Вы в праве продолжать относиться к фреймворкам и вообще к IT как вам хочется. Но предлагаю спорить о вкусе устриц всё-же хотя бы попробовав их на вкус.
Для любого бизнеса использование наработанных, распространённых решений зачастую благо. Месяц работы одного (!) программиста окупит любой фреймворк и любую IDE. Использование стандартных (а тем более поддерживаемых сторонними разработчиками) решений — есть удешевление продука и снижение рисков.
Все самопальные решения постоянно приходят к тому, что:
а) Становятся «местячковыми», т.е. ушёл главный программист — половина мест хз пойми как работает и где что вообще надо править, чтобы что-то изменилось.
б) Начинают дублировать функционал какого-либо фреймворка (ов), только вся поддержка этого куска кода лежит на разработчиках приложения. И вместо того, чтобы забивать гвозди начинаешь так же следить за состоянием молотка, качеством досок, светом в туалете и прочее…
>Кто бы спорил. Но тут вот какая беда: фреймворки приходят и уходят, алгоритмы остаются.
Ну да, приходят и уходят… А стратсу и хибернейту под 10ку уже, а так да — приходят и уходят.
>Нельзя объять необъятное.
То же самое можно сказать об изучении Java Core. Не бойтесь изучать новые технологии и фреймворки, их вам всё-равно придётся изучить ;)
>Посмотрим. К написанию кода я пока не приступил, но уже нашёл одно место где (при неудачном стечении обстоятельств) программа может сожрать несколько гиг памяти (и, соответственно, рухнуть). Хотя человек, её писавший, как раз таки большой знаток Java-технологий. А вот о том сколько займут объекты в памяти перед тем как пропадут «живые» ссылки на них и GC сможет приняться за работу — он не подумал.
Я не против углублённого изучения java, я наоборот ЗА, но этого слишком мало, java без созданных инструментов и фреймворков есть C++ с GC. Java с фреймворками — это танк, на котором можно хоть куда и хоть когда, хотя и жрёт порядочно.
Только фрэймворки и паттерны позволяют не изобретать велосипед, а работать примерно в одной системе координат всем разработчикам в команде. То, что Вы называете указанные фрэймворки «побрякушками» говорит о недостаточном опыте работы в Java среде.
Я видел разный код, и когда я вижу, что понаписали люди, не ведающие про отработанные в индустрии подходы и фреймворки (типа JPA) — мне становится дурно.
При этом я согласен, что зачастую можно написать узко-специализированный фреймворк для своих задач уделывающий любой другой, даже самый «модный и распространённый». Но это, опять таки, возможно только после изучения всех существующих подходов к решению проблемы (читай фреймворков).
А насчёт Вашей будущей встречи — не расчитывайте сильно на благоприятный исход, холодильники совмещённые с экскаватором редко хорошо работают 8)
Какой C++ программист знает про AOP, про JPA или там про GC java-овский или про maven? Где они — эти программисты? Почему я ни одного такого программиста не видел?
Описание данной схемы неполно... В нашем случае ObjectsFields является не отдельной таблицей, а целым набором таблиц, для разных типов данных своя таблица. Т.е. существуют таблицы ObjectFieldsVarchar, ObjectFieldsDate, ObjectFieldsBlob и так далее... Понятно, что можно сделать одну таблицу ObjectsFields, в которой будут поля всех типов, но в итоге это совсем не намного изменит ситуацию - работать с этой пачкой сложно.
Присоединюсь ко всем здесь высказывавшимся - работать с этой пачкой говна очень сложно. Либо полностью через хранимые процедуры (которые возвращают тебе строку с полями, которые ты запросил), либо приходится делать УЖАСНЫЕ извращения на клиенте. В частности ужасной ужастностью здесь является известная N+1 проблема, из-за которой динамическая lazy-линковка практически невозможно.
Это вы, батенька, перегнули...