Какой-то конь выложил свои домашние фотографии в моем топике - поэтому я скопировал сюда последний ответ и продолжу диалог, если можно.


Цитата - Vasay
Вцелом - проект развивается (и гораздо быстрее чем многие другие Java фреймворки). Как я понимаю, основные разработчики использующие Grails - Индусы и Китайцы.

Цитата(oson @  27.8.2012,  17:23 )
проблема с плагинами и их зависимостями

Есть такое. 

Цитата(oson @  27.8.2012,  17:23 )
трудно отлавливать ошибки

Плата за динамическую типизацию. Согласен, что порой 10 строками кода на Groovy можно заменить 100 на Java, а потом долго отлавливать непонятную ошибку в этих 10 строках, которую на Java подчеркнул бы редактор кода.
Но постепенно, с опытом, начинаешь меньше делать таких ошибок и гораздо быстрее их отлавливать. 


Цитата(oson @  27.8.2012,  17:23 )
трудно контролировать то что генерируется на лету

А что там контролировать, когда знаешь что должно быть сгенерировано?


Цитата(oson @  27.8.2012,  17:23 )
 Трудно интегрировать с другими технологиями

Хм... Вот это с какой стороны посмотреть. На мой взгляд простая интеграция с Java технологиями и фреймворками и есть основное преимущество Grails над RoR, Django и темболее PHP-фреймворками.

Добавлено @ 12:58
По поводу динамической типизации - а если принять в команде исключить в своем коде ее исключить (для чего она вообще нужна?!).
То есть только  объявлять тип данных
 
это позволит отлавливать ошибки на этапе компиляции? Или могут быть проблемы  с кодом в самой реализации Grails?

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

И если можно по вопросу совместимости/несовместимости с другими технологиями - можете немного развить, чтобы понять как тут дела с Grails - а то до сих пор писали что типа плохо.

Это сообщение отредактировал(а) oson - 28.8.2012, 13:04

С опытом начинаешь и на Java писать лаконичнее и понятнее 


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

Groovy все же гораздо лаконичней, но вот обилие всяких "магических" фишек порой делает его достаточно непонятным для человека не имеющего приличного опыта в Groovy.





Работая с Grails полностью исключить динамическую типизацию не получится, хотя можно весьма ограничить общение с ней написанием основной части кода на Java.  Но фишка в том что после того как набьете руку с Groovy захочется применять его весьма часто, даже вне Grails. Ну а если Вам не захочется и Groovy будет вызывать неприязнь - для Вас есть Roo.


Это помогает IDE подчеркивать ошибки. Но замедляет выполнение кода, т.к. добавляет проверки соответствия типов во время выполнения. 



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

Однако это же правило можно применить к Java-библиотекам. 



Это сообщение отредактировал(а) Vasay - 28.8.2012, 22:58

Спасибо за ответ.

Про Roo читал много негативных отзывов.
Что можно про него сказать в сравнении с Groovy/Grails? 

И кстати - там у Grails есть команда типа сгенерировать контроллеры статически, если не ошибаюсь.
А можно сгененрировать все эти запросы типа findUserByName() на момент разработки, чтобы 
можно было посмотреть их - я так понимаю в Roo так и делается.
Можно осуществить такое в Grails? Чтобы больше контроля было над кодом.

Это сообщение отредактировал(а) oson - 29.8.2012, 17:24

Смотрю Groovy. Волосы встают дыбом. Как же разработку такого кода держать в таких рамках, чтобы приложение работало.
Например

 

То есть мы просто что-то, что по нашему замыслу должно быть коллекцией, назвали def collection.
А если другой программист туда передаст int? Или он должен догадаться по названию?
 Я мог бы назвать параметр например def vasya. И как тогда должен пользователь метода догадываться,что именно передавать как параметр.

Кстати, если я делаю def list = new ModifyList(3), то ничего не падает. 
Спокойно отрабатывается код и печатает []
Если такое будет внутри сложной системы, то как же отловить такую ошибку?
Получается, что например я написал код и назвал параметр collection, а другой член команды
должен был по названию догадаться, что это коллекция и передавать туда именно ее, а не int.
Но если он не догадается об этом или случайно передаст туда int, то билд все равно соберется и будет тихо работать неправильно.
Никаких сообщений об ошибке не будет даже в runtime. Будет падать где-то дальше, где ожидается например непустой List, а приходит пустой.
Но понять почему падает будет сложно.


Далее 

. 
Тут я передаю closure в метод, а в методе уже происходит



То есть closure должен знать как обработать каждый элемент из этого this[i].
Если я выполняю умножение в этом closure, то я предполагаю, что там цифры. 
То есть я должен передать известные мне аргументы, и передать что с ними делать 
Например тут я передаю closure, который выполняет над String то что есть для String - конкатенацию.


А тут я вызываю в closure то, что можно сделать с int - ну и передаю соответственно int.



Тут вроде я контролирую ситуацию. 
Но при этом я должен знать, что будет делать метод modify(closure) в классе ModifyList с этим closure? То есть я должен знать внутреннее устройство метода прежде чем передать туда closure? И общая функциональность получается в результате сложения функциональности метода и функциональности передаваемого closure,
Как тут контролировать это смешение моего кода в closure, который я передаю в метод, и собственно кода в самом методе?
Хорошо если код в методе просто пробегает коллекцию и делает манипуляции, задаваемые closure, над каждым элементом.
Но наверное ж это просто частный случай?

В чем тут философия? Как это понимать?


Это сообщение отредактировал(а) oson - 3.9.2012, 18:04

Как понимать? Свобода - это не только права, но и ответственность   



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

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

Ответственность в разумных пределах. Как же руководить командой, которая может писать любой def?
Может быть надо запрещать это делать? И заставлять строго документировать?
Иначе проект быстро превратиться в неуправляемый набор символов.

Или же в проектах на Groovy должны участвовать только супер-профессионалы?
Или писать должен только один человек на проект? 

Это сообщение отредактировал(а) oson - 3.9.2012, 20:52

А как пишут код на динамических языках программирования?

Документируйте код, пишите тесты.  Да, динамическая типизация имеет свои минусы, но и имеет свои плюсы. 

Делаете перегрузку операторов. Или используете Generic. Вообщем решается это даже с типами.


Так дело в том, что БОЛЬШИЕ проекты на таких языках писать получается не очень хорошо (а точнее - хреново). Надо самого себя сильно ограничивать, надо писать коменты (в нормальном коде на Java их нужен мимниму). И выигрыш, который поначалу казалось был огромный, испаряется и начинается кошмар расширения и поддержки.
На таких "свободных" языках могут ХОРОШО писать только очень ПРОФЕССИОНАЛЬНЫЕ разработчики. Обычно получается наобот - люди с опытом для больших проектов берут типизированные языки, которые более НАДЕЖНЫ, а начинающие кидаются на красивые обертки, решают элементарные задачки и думают, что большие решаются так же легко и просто. Ну и результат не заставляет себя долго ждать.

Решается, но на Groovy получается лаконичней.





Есть такая фраза - "Ковчег построил любитель, профессионалы построили Титаник"

К сожалению, к Java технологиям и фрейморкам эта фраза подходит как нельзя лучше.

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


Можно перефразировать - Joomla создали любители, а профессионалы сваяли ibm websphere portal.

Хотя, любители, конечно дураки - они пытаются делать софт, а профессионалы делают деньги - какой смысл создавать портал ГосСтруктуры на Joomla? Лучше провести тендер заточенный под websphere portal - желающих принять участие будет меньше (ведь в ТЗ можно потребовать наличие у исполнителей всяких сертификатов от IBM) и IBM хороший откат даст   


п.с. Grails один из немногих адекватных фреймворков среди Java технологий, который пригоден для построения публичных сайтов/порталов.
Groovy дает плюсы динамический ЯП и при этом отлично комбинируется с Java - там где важнее плюсы Groovy можно использовать Groovy, там где критичны его недостатки - Java. 

Это сообщение отредактировал(а) Vasay - 4.9.2012, 16:05

А Вы имеет опыт работы с WebSphere Portal чтобы говорить, что он никому не нужен ? Вы сравниваете Joomla на движке PHP с системой, которая поддерживает огромное количество спецификаций для Java EE. И это только Application Server. Портал добавляет много чего еще - я на нем работаю уже несколько лет.


А сколько продуктов (если Вашим языком - сколько всякой хрени) от того же IBM Вы знаете ?

Я смотрю на Ваш опыт работы    

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

Это сообщение отредактировал(а) Vasay - 4.9.2012, 21:37

Про WebSphere Portal не я начал говорить 

Современные системы стали гораздо сложнее, чем раньше. По некоторым оценкам сложность систем за 10 лет выросла в 100 раз. Как в большой организации многие процессы надо бюрократизировать, так и типизированный язык позволяет писать более надежно.
Лично по моим оценкам реальный выигрыш у нас получается из достаточно узкого круга технологий - ORM (JPA, Hibernate), Web-Services, EJB/Spring, GWT/ZK/JSF, jQuery (и подобное им).
Все остальные инструменты уже слабо помогают ускорить разработку - иногда они ее даже усложняют. Надо искать некоторые хитрые ходы для того, чтобы обойти ограничения этих самых генераторов в каких-то нестандартных случаях. А таких случаев в больших системах встречается в избытке. Поэтому во главу угла ставится надежность и удобство расширяемости. Попробуйте в том же NetBeans сгенерить GUI-приложение и потом в нем разобраться. Чаще надо уметь собирать вместе продукты, которые умеют делать конкретную задачу и пытаться ими как-то управлять через их интеграционные возможности.
Возникает больше задач по расширению, интегрированию и администрированию многих модулей и целых продуктов - ну не будет бухгалтерия использовать что-то самописное, когда есть 1С. Это уже не имеет отношения к разработке - это готовые сервисы, которые просто есть и ими надо уметь пользоваться.
Сгенерить пару экранов для быстрой админки - да, Grails вполне подойдет. Но когда система требует интеграции двух-трех десятков разных продуктов, когда юзер-интерфейс не может быть стандартный и бизнес-процессы надо менять постоянно - то Grails уже ничего не дает, а отсутствие типизации может угробить многие часы для отладки.

А что мешает интегрировать Grails с другими Java технологиями? 

Grails великолепно подходит для создания публичного интерфейса, лучше чем многие другие Java фреймворки.  И уж тем более лучше чем WebSphere Portal, которая вообще не подходит для создания публичных сайтов.

 


Если Вы хотите использовать 1с для чего-то сложнее упрощенки, то Вы столкнетесь с необходимостью разработки. Причем после Java вас будет ожидать очень много неприятных сюрпризов ввиде кучи ошибок в платформе и конфигурациях, малом количестве документации, отсутствием конструктивного общения на форумах и очень высоких запросов 1с "специалистов" (написал в кавычках, так как реальных специалистов очень мало). И на практике ситуация с автоматизацией на базе 1с  ничем не будет отличаться от ситуации, когда в компании за автоматизацию отвечали парочка Делфи разработчиков, разве что зарплату 1с-ники будут простить раз в 5 больше. 

Вот сижу я сейчас, пытаюсь найти себе жилье на недельку в январе на горнолыжном курорте Garmisch-Partenkirchen.
Есть у них сайтик с поиском жилья: http://www.gapa.de/Garmisch_Partenkirchen_...terkuenfte_book

Вот сколько матов я сложил в адрес разработчиков этой, казалось бы, простой программки! 

Не знаю какой фреймворк они для этого использовали, но поведение типично для "GWT/ZK/JSF, jQuery" и им подобным.
Ссылка на детально описание жилья через JS (т.е. в новой вкладке не открыть). Контент не соответствует URL - вот как мне сохранить ссылку на понравившуюся квартирку, или отправить ее по ICQ другу, который со мной едет? Я уж не говорю, что в Opera вся эта система периодически вообще перестает работать.

А еще - пошел чай попил, сессия накрылась. Новый поиск - новый порядок. Хрен разберешься, что я там смотрел уже, а что нет. 

Блин, может нафиг этот Гармиш, поехать туда где поиск жилья не вызывает столько негативных эмоций?  

А на том же Grails создать поиск по базе жилья - час времени. И поведение изначально будет правильным.

Это сообщение отредактировал(а) Vasay - 4.9.2012, 20:16