Grails (Теперь) стоит того?

Вместо использования большого пространства без необходимости, используйте пространство, которое не только дает вам больше занимать место для места хранения, но и быструю скорость выполнения, так как ему не нужно было читать все символы. Если выделить varchar (255) и добавить текст «abc», он будет считывать символы «a», «b», «c» и другие как космос.

Поэтому всегда используйте требуемое пространство u вместо максимального пространства.

EnvDTE.DTE dte = (EnvDTE.DTE) Система. Время выполнения. InteropServices. Маршал. GetActiveObject («VisualStudio. DTE»); строковое решение Dir = System.IO.Path.GetGroupName (dte.Solution.FureName);

Но это возвращает решение каталог для добавлений, а не текущее решение.

Ваш подход к получению каталога является хорошим. Что не так, так это путь получения объекта StartStudio.DTE . Где называется этот код? Полагаю, это в вашей надстройке. Выполняете ли вы (отладите) надстройку в Visual Studio, которая открывает другой экземпляр Visual Studio, где вы открываете решение? Итак, у вас есть два экземпляра Visual Studio.

Метод GetActiveObject («StartStudio.DTE») получает случайный экземпляр Visual Studio. В вашем случае это, видимо, Visual Studio с проектом надстройки, так как вы получаете путь к надстройке. Это для объяснения причины вашей проблемы.

Правильный способ получения DTE очень прост. Фактически надстройка уже имеет ссылку на DTE, в котором она выполняется (то есть в котором решение открыто). Он хранится в глобальной переменной, _applicationObject в классе подключения надстройки. Он устанавливается при запуске надстройки в обработчике событий OnConnection . Так что все, что вам нужно, это позвонить:

string solutionDir = System.IO.Path.GetDirectoryName(_applicationObject.Solution.FullName);

Я использую Грайлс уже более 4 месяцев, и я постараюсь дать вам мое личное чувство о Грайлсе и его пригодности.

Стоит ли теперь Грейлс против Руби или другого своего?

Конечно, ответ не «Да» или «Нет», но это зависит . Это зависит от ваших требований (вам нужно быть в Java World?), от ваших предпочтений (вы предпочитаете доменно-ориентированную разработку, вы предпочитаете Groovy...)? Тем не менее, я могу ответить, что Грейлс - серьезная альтернатива Рейлсу. Я считаю, что что бы ни было в вашем приложении Rails, вы также можете сделать это с Грейлс. Но в зависимости от характера вашего проекта это может занять больше или меньше времени. Опять же, если вы знакомы с Rails, но не с Grails, Rails является более безопасным вариантом.

Преодолел ли он свой багги старт?

Да . Если вы посмотрите на мои первоначальные сообщения (на этом сайте или других), я много жаловался на ошибки в Грайлсе. Но вы просто должны помнить, что Грайлс немного грубый на краю (не слишком много использования наследования домена, например) и, как только вы знакомы с рамкой, вы не испытываете слишком много плохих сюрпризов. Я не говорю, что Грейлс не багги. Это, конечно, больше, чем Рейлз. Но также он более полезен, чем багги .Совет для этого: используйте как можно меньше плагинов . Потому что многие из них багги, а некоторые не совместимы между собой. Таким образом, не включать Грайлс плагин, если вы не уверены, что Грайлс плагин является актуальным, неинтрузивным и протестирован (самостоятельно).

Действительно ли это дает быстрые преимущества для развития?

Да . Вам почти не нужно иметь дело с конструкцией БД. Настройка практически выполнена для вас с самого начала благодаря Convention over Configuration. Ваше приложение легко обслуживается. Единственный недостаток, который я вижу, это разработка переднего плана, которая не так богата, как другие технологии (такие как Rails или ASP)

Работает ли она для реальных производственных приложений?

Я не могу сказать, потому что я все еще не ходил на мой сайт в прямом эфире, но я довольно уверен, поскольку sky.com использует Грайлс и сайты привлекают значительный трафик - вокруг 7 миллионов просмотров страниц в день . Производительность опять же во многом зависит от архитектуры приложений и решений по проектированию.

Лучше ли подключаемый модуль Eclipse, чем он был, и подходит ли он для этой цели?

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

Надеюсь, это поможет.

Я являюсь полный рабочий день Java Developer, но используйте рельсы для моих хобби. Мы оценили Grails для проекта на работе в году назад. Мой опыт с границами оставила меня немного разочарованным, и это была причина, по которой я начал расследовать рельсы. Используя оба своего впечатления, так это то, что, хотя Groovy не далеко позади Ruby в качестве языка, Rails обеспечивает значительно улучшенный опыт над границами. Проще говоря, рельсы, кажется, решают гораздо более реальные мировые проблемы, особенно когда вы фактически в количестве хороших драгоценных камней, которые доступны. Я думаю о таких вещах, как, предоставляя поиск, версию, RSS, нерудные приложения, интеграцию с облачными сервисами и т. Д. У меня сложилось впечатление, что гралитры вокруг уровня рельсов 1.x. К концу этого месяца рельсы 3 должны были быть выпущены. Мы фактически решили теперь двигаться к использованию рельсов на работе. В конце концов, Grails легче забрать для разработчиков Java, но в конечном итоге не хватает уточнения для покрытия более широкого диапазона требований проекта.

Я бы предложил вам попробовать для себя. Я люблю гибкость грейлей и скорость развития. Однако, как вы можете видеть, что опыт других людей отличается. Я хочу быть в состоянии разрабатывать быстрые приложения для моих клиентов, используя платформу Java, и я нашел Trails, чтобы очень хорошо работать для нас.

Я также обнаружил, что Frontend очень гибкий для развития. Я также думаю, что вам нужно использовать здравый смысл и тщательно выбирать свой плагин. Я придерживаюсь плагинов, поддерживаемых Springsource.

Это очень стоит!

Мы используем Grails в нескольких проектах, все они с большим успехом по следующим причинам:

• Легко - это одна из самых простых рамок, которые мы когда-либо использовали

• повторное использование наследие - все, что нам нужно сделать, Наш устаревший код и бросить его на папку lib или SRC, и это сделано. Просто здорово для нас.

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

Теперь о жизнеспособности:

• ошибок: мы не сталкиваемся с слишком много ошибок с версии 1.1 (версия 1.0 было слишком активно для нас)

• Инструменты: NetBeans действительно улучшается на этом фронте, но это не Даже закрыть другие инструменты, такие как Intellij Idex (отличная поддержка!). То же самое можно сказать о затмении.

• Портативность: мы никогда не сталкиваемся с одной проблемой на наших проектах.

Лучше ли подключаемый модуль Eclipse, чем он был, и подходит ли он для целей?

Он определенно значительно улучшился за последний год. В декабре я присутствовал на бирже Groovy & Grails в Лондоне. Был замечательный разговор об интеграции Groovy & Grails в Eclipse/SpringSource STS, который был записан, см. видео .

С моей точки зрения, Eclipse получил много земли. В настоящее время IntelliJ, кажется, немного впереди, но это может измениться в течение следующих нескольких месяцев.

EnumWindows перечисляет все окна верхнего уровня в процессе. GetWindowThreadProcessId получает процесс и идентификатор каждого потока.

Теперь у вас достаточно информации для корректного закрытия любого приложения GUI.

Сообщения WM _ CLOSE можно отправлять в любое окно, которое требуется закрыть. Многие окна обрабатывают WM _ CLOSE для запроса сохранения документов. Можно отправить сообщение WM _ QUIT с помощью PostThreadMessage обнаруженным потокам для завершения цикла сообщений.

Код пользователя не может вызывать DestroyWindow из другого приложения или потока в окна... если приложение не отвечает на запросы WM _ CLOSE или WM _ QUIT , вы возвращаетесь в TerminateProcess .

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

См. T.s. Ответ Arun ниже для правильного метода работы с консольными приложениями.

Плагин Grails Eclipse - это дерьмо. Он терпит крах без всякой причины и не очень поддерживает гибкость Groovy. По слухам, NetBeans и IntelliJ намного лучше, но я еще не пробовал их.

Работает ли он? Конечно, так и есть. Даже Ruby on Rails работает, пока вы бросаете достаточно серверов на проблему. Я понятия не имею, как Грейлс сравнивает с различными рамками Java.

Действительно ли это дает быстрые преимущества для развития? Ну, я все еще скучаю по многим хорошим вещам Руби/Рейлз. Он не распознает параметры запроса Date и Enum автоматически (опять же, Rails также имеет некоторые проблемы с датами), TimeCategory должен быть частью стандартной конфигурации, но не является. Но есть также много вещей, которые требуют удивительно мало конфигурации.

Это не совсем то место, где Rails (я особенно жду Rails 3), но работать с ним гораздо приятнее, чем со многими рамками Java. Тем не менее, магия ниже поверхности проходит гораздо глубже, чем в Рейлсе. Например, система для ограничений действительно мощная, но построенная поверх огромного слоя непроницаемого материала Весны, и действительно негибкая, если вы хотите использовать ту же самую мощность несколько другим способом. Рельсы легче подорвать, IME.

Стоит ли это того? Да. Это лучший выбор, чем что-то другое? Это зависит.

, касающийся плагина Eclipse, все еще находится, но вы можете использовать версию Eclipse от пружинного источника (Springsource Tool Suite)

http://www.springsource.com/products/sts

Это вполне прилично по сравнению с предыдущими версиями плагинов, и, поскольку Spring Source приобрел компанию, ответственную за границы и Groovy, вы можете Ожидайте, что STS станет лучше быстро

Является ли плагин Eclipse лучше, чем он был и пригоден для использования?

Он определенно значительно улучшился за последний год. В декабре я посетил Groovy&Grails Exchange в Лондоне. Было много разговоров об интеграции Groovy&Grails в Eclipse/SpringSource STS, которые были записаны, смотрите видео .

С моей точки зрения, Затмение приобрело много оснований. В настоящее время IntelliJ, похоже, немного опережает, но в ближайшие месяцы ситуация может измениться.

Это очень стоит. Я использовал его уже более года, и полюбите это. Я раньше уклонялся от этих типов RAD Tools, но он изменил то, как я работаю. С высвобождением 1.2 он стал еще лучше с лучшей информацией о трассировке стека (особенно для GSPS).

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

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

• Мы используем IntelliJ. Он не очень дорогой и окупился для нас за несколько недель.
• Автоматизированное тестирование, непрерывная интеграция и рефакторинг являются обязательными, как и для всего кода на динамических языках. Если вы уже практикуете TDD или хотя бы имеете приличное покрытие кода тестами, то это не добавит вам дополнительной работы.
• Hibernate поставляется по умолчанию с Grails, но вы можете использовать другие фреймворки персистентности. На сегодняшний день существует 5 плагинов персистентности
• Логирование явно не было заботой Грэма Рошера, но оно неуклонно улучшается. Хотя я не сталкивался с проблемой, когда ошибка не регистрировалась (вы должны убедиться, что правильно ловите исключения в своем коде)
• Отладка явно не была на радаре (но это не улучшилось). В любом случае, мы не полагаемся на отладку.

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

Недавно использовав Grails для проекта, я хочу поделиться нашим опытом по сравнению со стандартной разработкой приложений J2EE.

Действительно ли это дает преимущества для быстрого развития?

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

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

Переход с Java на Groovy доставляет огромное удовольствие, мы любили иметь литералы списков и карт, замыкания, компоновщики, отбрасывать нашу стандартную реализацию «карты» на Java и писать компактный, содержательный и сфокусированный код.

Что замедляет скорость разработки, так это не очень идеальная поддержка IDE, которая также верна для плагина IntelliJ, который мы используем. Плохая, часто старая и даже неправильная документация, разбросанная по разным местам (сорвавшая обещание «поиск окончен») также мешает быстрому развитию. Поэтому нам часто приходилось возвращаться к чтению исходного кода - впоследствии мы были напуганы лежащими в основе иерархиями классов Spring.

По моему опыту, Grails предлагает несколько очень привлекательных функций, которые определенно стоит изучить и использовать.

• Гибкость - то, на что нам раньше уходили недели, чтобы реализовать в обычных проектах J2EE, обычно представляет собой день работы с системой надстроек grails. Такие вещи, как ajax, jquery ui, acegi, спокойная реализация, система планировщика и многие другие
• Работает на JVM, что облегчает необходимость изучения какой-либо другой системы времени выполнения и ее особенностей

• Синтаксис, подобный Java, и отличный синтаксический сахар. как лучшее из обоих миров.Вы можете сразу начать с Java вместо изучения синтаксиса нового языка, такого как Ruby, а затем постепенно перейти к отличному синтаксису, который является надежным, простым и интуитивно понятным

  Для руководителей проектов, если нет веских причин для «не использовать» grails по какой-то причине (сопротивление сверху, внедрение новой технологии или что-то в этом роде), я не вижу причин, по которым grails нельзя использовать или, по крайней мере, попробовать.

Ответить на вопрос об отладке не так уж сложно. Отладка выполняется легко, если вы используете IDE Netbeans. Это подводит меня к еще одному моменту, о котором стоит упомянуть. После нескольких экспериментов со всеми IDE мы обнаружили, что Netbeans лучше всего подходит для этой работы. Он лучше поддерживает автозавершение кода, подсветку синтаксиса, отладку и т. Д. На мой взгляд, STS для этого недостаточно.