(no subject)
16/6/10 13:23![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenЕсть у меня впечатление, что технологии Java EE проще учить по Grails. Нет лишней обвязки.
Если есть плагин, то работают настройки by-convention.
Это я смотрю на примеры JMS. Сравните.
Если есть плагин, то работают настройки by-convention.
Это я смотрю на примеры JMS. Сравните.
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
16/6/10 11:40 (UTC)Сравнивай тогда уже с MDB из EJB 3.x.
И врядли ты выучишь Java EE используя frameworks, которые Java EE скрывают.
Все что ты выучишь - это подходы: messages, request-response, IoC.
(no subject)
17/6/10 07:03 (UTC)Ты предлагаешь сравнить, скажем, с этим? Ну, или это, пожалуй, будет ближе. Код почти такой же краткий, но мы ещё не посчитали обвязку - этот код, конфигурацию...
А что значит - "не выучишь"? Не запомню конфиги, сигнатуру именно таких лиснеров, методов инициализации, и прочей обвязки? Или, может, таки важнее понять, какую именно задачу решает технология, и увидеть big picture?
(no subject)
17/6/10 13:07 (UTC)А то что ты видишь общую картину через Grails -- это ты выидишь общую картину Grails. Grails plugin style видение. Это как учить html рисуа в Dreamweaver.
Так вот, мне поэтому и показалось странным высказывание что JEE лучше учить через сокрытие JEE.
Я читал Grails и пробовал до того как прочувствовал Servlets/JSP. И теперь уверен что если хочешь быть специалистом в JEE лучще вначале читать Servlets/JSP а потом Grails. "Leaking Abstractions".
А так конечно проще дать толпе Juniors Grails с плугианми и бдить с высока.
(no subject)
17/6/10 13:20 (UTC)Потом ты бьешся головой об стены нагибая технологию против шерсти.
Картины с высока -- это хорошо, но строить архитектуру изходя из них - преступление.
Ну а если ты архитектор, то тебе не надо учить JEE -- ты его уже знаешь.
А если ты не архитектор, пиши на Grails и даже не строй связи между Grails plugin и JMS API, потомучто смысла в этом нет.
(no subject)
23/6/10 07:41 (UTC)Мне это высказывание видится необоснованным. Имнсхо, технология - это не только ворох деталей, но и решаемая задача. Причём второе важнее.
Это как учить html рисуа в Dreamweaver.
Я учился работать с текстом в Word, а строить запросы - в Access. Бывали случаи, когда я решал текстовые задачи лучше, чем асы TeX, да и на знание SQL не жалуюсь.
Так что этот аргумент совершенно мимо кассы.
мне поэтому и показалось странным высказывание что JEE лучше учить через сокрытие JEE
Это потому, что для тебя JEE - это ворох API, паттернов и типичных багов. Но, имнсхо, это вторично.
Я читал Grails и пробовал до того как прочувствовал Servlets/JSP. И теперь уверен что если хочешь быть специалистом в JEE лучще вначале читать Servlets/JSP а потом Grails. "Leaking Abstractions".
Обоснуй, пожалуйста, каким-нибудь примером, а не только словами "я читал оба и уверен".
В частности, что теряет человек, который начнёт с Grails, а не с сервлетов?
(no subject)
23/6/10 07:47 (UTC)Картины с высока -- это хорошо, но строить архитектуру изходя из них - преступление.
Это ты уже довёл вопрос до абсурда. Я нигде не утверждал, что важна *только* big picture. Важны и зрелость технологии, и learning curve, и поддерживаемость. Но важнее всего всё-таки - решить именно поставленную задачу.
Ну а если ты архитектор, то тебе не надо учить JEE -- ты его уже знаешь.
А если ты не архитектор, пиши на Grails и даже не строй связи между Grails plugin и JMS API, потомучто смысла в этом нет.
Извини, это я могу истолковать то ли как личный выпад, то ли plain wrong statement. Есть Grails plugin для JMS API, я его использую и правлю под свои нужды.
(no subject)
23/6/10 10:53 (UTC)Вторично. Эх.
JMS -- 2 страницы идеи. Все.
JPA -- 1 страница. Хорошая технология. Что там учить?
JEE для меня набор стандартных технологий для конкретных задач. Я не решаю задачи RPC с помошью JMS и т.д.
Вот тебе примеры выбора технологий для решения конкретной задачи. Рассуждения.
Так у нас есть C# клиент -- ага будет JAX-WS. У нас есть база -- будем полюбому JPA, это ж для этого вроде. EJB -- наклипаем компонентов и оно ж отлично работает с JAX-WS. Это в общих чертах принятые технологии.
Но есть еще ж Application Servers и легаси таблицы. И в середние оказываеться что расставление корректных аннотаций над сущностями занимает времени больше чем просто написать plain sql. И не всегда ты имеешь правильные ключи, а JPA это не предусмотрело (но ктоже знал эти детали?).
Что у нас 3-4 апликейшн сервера, которые не полностью поддерживают EJB + JAX-WS. И ты (о чудо технологии) пишешь 3 строки кода и 53 xml. Но кто же лезет в технические подробности. И может проще было бы пойти в сторону JAX-RS и какого нибудь легкого DI.
Мы можем выбрать JMS. И некий ПМ некоего проекта подумает ну это ж ерунда делов послал принял сообщение. И через неделю ноль результатов. Оно еще даже не деплоится.
Узнать о применениях той или иной JEE части легко. И для этого Grails не нужен. Достаточно почитать первые страницы каждой главы из JEE туториал.
Но вот чтобы адекватно выбрать взять ли JEE JPA или Jboss Hibernate. JSF или GWT или Grails. JMS или JMS Templates из Spring.
Про Grails. Когда я пробовал его было ощущение "Ух ты магия!". Все что я от туда мог почерпунть что есть запрос и ответ в виде данных с моей стороны + view. Я не знал что происходит под низом и в большинстве случаев мне это не нужно было. В результате -- 0 знаний о Servlets/JSP.
Если прочитать в начале Servlets/JSP, любое действие в Grails становиться для тебя понятным и так или иначе маппиться на твои знания. Фильтры, Секурити. Велком страницы. Работая в Grails ты продолжаешь развивать знания о Servlets. И в случае проблем (leaking abstractions) ты знаешь что и как.
Учить Servlets после Grails это примерно такое же удовольствие как учить C-arrays после Java Collections.
Наверное ты не понял мою аналогию про Dreamweaver. В Access ты строил запросы. Ты писал SQL queries. В Dreamweaver ты можешь не писать ни одной строчки html и получить html страницу. Сказав при этом что я знаю html.
Когда я пишу "Ты" я не имею ввиду тебя, а просто человека. И не в коем случае не накого не незжаю.
Как вариант предлагаю перенести эту дискуссию в прохладное место с хорошим чаем, так как вижу что не очень ясно выражаю свою мысль по этому вопросу в письменном виде.
(no subject)
23/6/10 13:59 (UTC)Потому что пример, может быть, и выстраданный, но как-то уж очень безмозгло в нём принималось решение. Кажется, это оставило у тебя негативный отпечаток и сильное предубеждение :)
(no subject)
23/6/10 14:02 (UTC)(no subject)
23/6/10 14:04 (UTC)(no subject)
23/6/10 14:05 (UTC)Давай в мышах. часов 7?
(no subject)
23/6/10 14:05 (UTC)Я созову народ?
(no subject)
23/6/10 14:07 (UTC)