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


Цитата - 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

Давай не будем обсуждать продукт, который ты знаешь не очень хорошо (возможно я ошибаюсь - тогда можно устроить дискуссия на эту тему в отдельном топике).
Можно конечно оценивать дизайн по-разному, но вот для примера сайты на WebSphere Portal. Оба сайта мало используют самописные приложения - большая часть сделана с использованием стандартных возможностей портала. Весь материал само собой в CMS и есть несколько морд - обычная, мобильная и для терминалов.

http://www.teachforamerica.org/ - Teach for America 
http://www.admhmao.ru/ - тут из-за пробем с железом иногда тормозит.


Там несложно увидеть jQuery  Но это уже проблема разработчика сайта - если руки кривые, то тут ничего не поможет.

Вопрос JavaPortal-ов я изучал. Идея хорошая, реализация подкачала. При этом пару лет назад, единственным порталом, хоть как-то пригодным для создания web-сайтов был LifeRay портал. Но и он имел ряд недостатков, делающим его применение для web неоправданным.


Насчет Ваших примеров - я быстро посмотрел. И я не вижу там задействование портального функционала. Т.е. портал используется как примитивная CMS. Но зачем ставить для этого тяжеловесный портал, когда можно поставить простенькую легкую CMS? 
Для того что бы:

Неужели портал Ханты-Мансийского имеет такую большую посещаемость? 

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

Одним из важнейших требований к web сайту является соответствие URL контенту. 2 года назад нормальный механизм, позволявший сохранять состояние портлета в URL имел только LifeRay. Но и то реализация была с кучей костылей дававших сбои.
Возможно, с тех пор что-то поменялось.  





Только проблемы, которые есть на этом сайте, свойственны многим фреймворкам, активно использующим JS.
Несколько лет назад самый крупный доменный регистратор godaddy обновил админку - все стало Ajax-ово красиво. Не знаю сколько миллионов $ они на это потратили. Но работать с ним стало невозможно! Потом начались доработки, костыли....   

А если вспомнить продвигаемый в свое время Sun-ом набор компонентов woodstock (слава Богу, канувший в лету) - табличка в 100 строк вешала IE напрочь. 

Я не говорю, что JS плохо. Иногда он очень уместен. Но использовать для WEB JS ориентированные фреймворки ( GWT/ZK/*Faces ) нельзя! Но я вижу, что Java разработчики их очень часто используют. А потом конфликты с заказчиком, когда до того дойдет, какое г в кросивой обертке он получил.

Для WEB нужны фреймворки типа Grails - позволяющие максимально контролировать соответствие URL контенту, сами URL, редиректы. А не GWT/ZK/*Faces и им подобные.

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

Если хочется поспорить о порталах - в отдельный топик 


Почитай тут - http://www.javatalks.ru/ftopic32853-0-asc-0.php - там очень хорошо разложено что и как по поводу Grails.

Темы про порталы в свое время я тут создавал. И темы про Java технологии, непригодные для WEB, но активно туда продвигаемые. 

Но я превосходно понимаю зачем нужен WebSphere Portal и почему Ваша компания его так любит, но этот вопрос к программированию отношения не имеет и затрагивать его тут я вообще не хочу. 




Я читал эту тему. Реально толковые посты там пишет Староверъ. 

А негатив возникает тогда, когда берут команду Java разработчиков, которые никогда не видели Grails,  и сажают писать проект на Grails. Вот и прет негатив. 
Да есть минусы, но есть и плюсы. И часто + Grails сильно перевешивают. 

Да Grails нишевый продукт -в нем есть смысл когда нужна скорость разработки RoR или Django но в Java среде с интеграцией с другим Java проектами и технологиями. 

Я для обсуждения открыл тему - http://forum.vingrad.ru/forum/act-ST/f-113...3/unread-1.html

Добавлено @ 19:28

Потому что он чуть ли ни единственный, кто не хаял Grails ? Хотя и он говорил, что Grails лучше всего подходит для быстрого "сляпать".

Эта подборка фактов не является правдой ?
For the developers 
- No compile time errors when calling missing functions (makes refactoring difficult) 
- Errors only reported at runtime, when the problem occurs 
- Internally, it uses a GString to represent Strings for which the conversion isn't automatic, so you need to do stuff like: "this is a string".toString(); Of course, you don't know you need to do that until runtime and you hit the problem 

Недостаток Grails в том, что при работе в команде описываются интерфейсы взаимодействия модулей и никто не лезет в чужой модуль. Важно, чтобы данные передавались точно по спецификации. Если же они не могут быть определены точно (а с динамической типизацией это просто невозможно), то гробится куча времени на отладку и дальнейшее сопросвождение. Или это оспаривается ?

Дальнейшее обсуждение Groovy и Grails перетекло в ту тему    



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

Насчет третьего - не сталкивался с такой проблемой.




Они могут быть определены точно. За исключением случаев когда есть смысл не определять конкретно типы передаваемых значений (тогда пишется Doc). 



AntonSaburov, попробуйте Groovy, Вам еще понравится    Для некоторых задач он очень удобен. И применять его можно только там, где он нужен. 

Это сообщение отредактировал(а) Vasay - 6.9.2012, 01:00

Согласен. Попробовать конечно надо, но когда ... ПРосто читать - это не дело. Надо работать на продукте - тогда будешь его правильно понимать. И зачем и почему и как сделать.

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

По своему опыту внедрения Groovy в проекты web-crawler-ов могу сказать - что это положительно сказалось на скорости разработки и почти никак не сказалось на скорости их работы - т.к. основная нагрузка приходится на стандартные библиотеки написанные на Java. 

Это в каком смысле ? Индексирование веб-сайтов ? Любопытно.

Различный сбор статистики. Самой разной, от простой, для SEO анализа:
- Используемый CMS
- Исходящие ссылки
- Коды бирж продаже ссылок

До сложной - для маркетингового анализа активности "черных маркетологов" на различных форумах и блогах.

Это сообщение отредактировал(а) Vasay - 6.9.2012, 13:51

Т.е. кроулится сайт по всяким мнешним проявлениям - хидерам, кукам и прочим радостям - и собирается статистика на него ?

Для сборки информации о CMS нужно искать некоторые признаки этой CMS.  Например, ставящиеся именно этим движком куки, очень надежный метод - проверить существование URL админки (там обычно и название и версия CMS написаны) 

Исходящие ссылки - просто перебор страниц сайта и сохранение в базу исходящих ссылок. Ресурсоемкая задача. Основная сложность - заставить быстро работать базу. 

Коды бирж продаж ссылок - тут по определенным признакам. Особой точности, конечно, не добиться.


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


Это сообщение отредактировал(а) Vasay - 6.9.2012, 18:36

Да совершенно верно. 

С другой стороны крсивый контент сопряжен огромным числом файлов в т.ч. css и png и при подходе построения многостраничного приложения вижу минус в значительной задержке по времени при загрузке очередной страницы. Но при этом разработка и поддержка проекта проще и быстрее. Например я использую в своем проекте Dojo  — свободную модульную библиотеку JavaScript. Был опыт одностраничного приложения с использованием данной библиотеки, при данном подходе приложение работает молненостно, но зато без ссылок  подобно http://www.gapa.de/Garmisch_Partenkirchen_...terkuenfte_book, хотя никто ни разу не предъявил притензий по этому поводу так, как это было корпоративное web-приложение. Также было затрачено очень много времени на создание виджетов, а это в свою очередь создание своей уникальной архитектуры.

Я пришел к выводу, что все же нужно использовать подход многостраничного построения приложения. Но не сплошь и везде как устроено по умолчанию в Grails.
Например для перехода на конкретный сервис (список+форма) нужна ссылка, но когда работаем с элементами сервиса (переход к форме редакт, фильтра, переход к очередной странице gridа), тут уже излишне.

Не думаю, что это актуально при современных скоростях интернета.




Для WEB приложения это не "излишне". Это необходимость, иначе поисковый робот дальше первой странице не пойдет. Не сможете сохранить ссылку или передать ее по ICQ на конкретную страницу.


п.с. мой опыт работы, как обычного пользователя, с web-приложениями перегруженными JS, говорит о том, что чем больше JS тем хуже юзабилити. Админку GoDaddy я вообще вспоминаю как страшный сон. 
Сейчас все больше и больше расстраивает яндекс.почта. Вот сейчас в опере у них глюк - вставляешь e-mail из буфера обмена в поле получателя - а он при отправке пишет - введите адрес получателя.  Да и вообще фигню они с полем адреса сделали - неудобно.