Статья о том, как добавить в JetBrains Intellij IDEA 9 проверку русской орфографии. Кроме того, она окажется полезной и для других IDEA-based сред разработки: MPS, RubyMine, WebStorm, PyCharm, PhpStorm.
Правда, используемый в статье словарик совсем небольшой. Никто не в курсе, где можно скачать действительно большой русский текстовый словарь?
Новость скорее всего не нова, но тем не менее она заслуживает внимания.
В Flex Developer Center появилась серия видео-уроков под общим названием «Flex in a Week». Благодаря этим урокам за пять дней (два выходных дня в расчет не берутся) вы можете получить общее представление об основных концепциях Flex Framework и после этого использовать полученные знания на практике.
Я всегда был сторонником видео-обучения, поскольку подобный вид подачи материала позволяет в краткой и — что важно — наглядной форме изложить основные моменты. В общем, для начинающих изучать Flex 4 крайне рекомендую — «Flex in a Week».
Недавно столкнулся со следующей задачей: на одном веб-сервере под управлением Windows Server 2003 необходимо было установить несколько экземпляров Apache Tomcat 6 для того, чтобы в каждом из них «крутилось» свое собственное приложение. Установить нужно было таким образом, чтобы каждый из этих сервлет-контейнеров являлся в системе обособленным сервисом со своей конфигурацией, параметрами автозапуска, отдельным пунктом в списке установленных программ системы, ну и, в качестве бонуса, собственной иконкой в трее. 
Посмотрев решения подобной задачи в интернете, обнаружил, что, пожалуй, единственным способом ее решения будет самостоятельная правка реестра системы. Это связано с тем, что стандартный инсталлятор Apache Tomcat 6 не поддерживает возможности его установки в виде нескольких сервисов и не позволяет разнести настройки каждого из экземпляров по отдельным веткам реестра.
Здесь я хочу сделать важное предупреждение. Описываемая в статье техника является работоспособной и проверенной мной на собственном опыте и на реальном рабочем сервере. Она даже не является хаком, поскольку, будь инсталлятор немного более грамотным, он бы выполнял ее автоматически. Я не проверял, но скорее всего эта техника будет работать и на Windows Server 2008. Выполняемые процедуры не затрагивают никаких других настроек и веток реестра, кроме тех, которые непосредственно относятся к каждому отдельному сервису Apache Tomcat. Однако я не несу никакой ответственности за возможный ущерб, связанный с непосредственным, а так же с неосторожным или неправильным применением этой техники. Используйте ее на свой страх и риск. И не забудьте сделать резервную копию важных данных перед началом процедуры.
Итак, поехали.
C:\Tomcat6_1. На последнем шаге мастера установки нужно убрать галочку Run Tomcat.regedit → нажмите Enter.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tomcat6 и переименуйте ее из Tomcat6 в Tomcat6_1.DisplayName с Apache Tomcat на Apache Tomcat 6 (1). Именно под этим именем теперь будет отображаться сервис в списке локальных служб системы. Чтобы посмотреть список служб вашей системы выполните следующую последовательность действий: кнопка Start → Run… → services.msc → клавиша Enter.
ImagePath с …//RS//Tomcat6 на …//RS//Tomcat6_1. Именно с этим именем будет запускаться экземпляр службы. Это значение понадобится нам в шаге 9.HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat6 и переименовываем ее в Tomcat6_1. В дальнейшем это позволит нам установить новый экземпляр Apache Tomcat без перезаписи настроек устанавливаемого в настоящий момент экземпляра.HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\6.0 на 6.0_1.HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run и меняем имя ключа с ApacheTomcatMonitor на ApacheTomcatMonitor_1. Это имя приложения по управлению службой. Его изменение позволяет нам избежать перезаписи этого ключа при установке следующих экземпляров Tomcat и управлять каждым из сервисов при помощи отдельного окна приложения.
…Tomcat6 на …Tomcat6_1. Внимание: это значение должно совпадать с тем, которое мы присвоили ключу ImagePath в шаге 5.HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Apache Tomcat 6.0 и изменить ее название на Apache Tomcat 6.0_1. Это позволит нам избежать перезаписи данных, необходимых для деинсталляции приложения, во время установки последующих экземпляров Apache Tomcat. Здесь же можно изменить значение ключа DisplayName на Apache Tomcat 6.0 (1).
<Server port="8005" shutdown="SHUTDOWN"> на 8001 (для каждого из последующих сервлет-контейнеров мы будем использовать порты 8002, 8003 и т.д.).<Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000" redirectPort="8443" /> на 8081 (далее будем использовать 8082, 8083 и т.д.).C:\Tomcat6_2, ветка реестра из шага 3 должна быть переименована в Tomcat_2, а ключ DisplayName в шаге 4 изменен на Apache Tomcat (2) и т.п.На этом все на сегодня. Буду надеяться, что заметка окажется вам полезной. Удачного вам дня!
В этом посте каждый может задать вопрос, каким-либо образом относящийся к среде разработки Intellij IDEA, и получить на него вразумительный ответ. На русском. Развернуто и актуально.
Если вы уже давно присматриваетесь к этой среде разработки, либо даже пробовали перевести свой рабочий процесс на разработку в ней, но что-то у вас не получалось, не выходило, не настраивалось, вызывало недоумение, приводило в шок; и в результате чего вы так и не смогли взять этот неприступный бастион, этот редут интеллекта, этот ларец, доверху наполненный изумрудами программерской мудрости, и вынуждены были отказаться от использования среды на долгие месяцы и годы, то «вэлкам» внутрь поста. Попробуем вместе решить вашу проблему.
Со временем, если накопится достаточное количество вопросов, то на их основе будет создан Intellij IDEA FAQ, который, я думаю, окажется небесполезным многим разработчикам.
Ну а для начала, всем интересующимся этой темой я рекомендую ознакомиться вот с этим PDF-документом, полным цветных картинок и изумительных комментариев к ним (правда на английском). Ну и не забывайте задавать свои вопросы.
Все мы знаем, о таком замечательном методе, как toString(), имеющемся у любого объекта в языках, подобных Java и ActionScript. При попытке работы объектом, как со строкой, будет использовано возвращаемое именно этим методом значение. Поэтому мы можем в своих классах переопределять поведение метода, имеющееся у объекта по умолчанию, и возвращать свои собственные специализированные значения.
В этом отношении язык Groovy не стал исключением — в нем тоже все объекты имеют метод toString(), логику которого можно переопределять, как в собственных классах пользователя, так и в любом другом из уже имеющихся классов и объектов программы, при помощи свойства metaClass. Однако Groovy шагнул дальше — он позволяет нам похожим образом приводить объекты и к булеву значению, и, кроме того, к любому другому типу объектов в приложении.
Рассмотрим для начала ситуацию приведения объекта к булеву значению. Все просто — берете и переопределяете в своем классе (или посредством поля metaClass в объекте или классе, доступа к исходному коду которого у вас нет) метод asBoolean():
Ну и, как вы уже могли догадаться, аналогичным способом мы переопределяем метод asType(), чтобы тем самым сделать возможным приведение нашего объекта к любому нужному нам типу:
Вот такие очень гибкие возможности предоставляет нам Groovy.
Должно быть каждый Grails-программист, только начавший постигать премудрости метода «разработки приложения посредством тестирования», задается вопросом: «Для чего же в Grails существуют две разновидности тестов, и какая между ними разница?». Ведь на первый взгляд очевидной разницы между ними нет, кроме того, что Unit-тесты создаются в папке test/unit приложения, а интеграционные — в test/integration.
Однако все не так просто, как могло бы показаться. Начнем с Unit-тестов. Они потому так и называются, что производят тестирование очень маленьких частей приложения, единиц или юнитов функциональности: отдельных классов и их методов. Интеграционные тесты же специально разработаны для тестирования достаточно крупных частей приложения: таких, как контроллеры и все их зависимости. Но главное же отличие между этими разновидностями тестов заключается в том, что интеграционные тесты выполняются в контексте запущенного приложения — с одновременным запуском базы данных и доступом ко всем динамическим свойствам и методам, в которых может нуждаться тестируемый код. Т.е. буквально, интеграционные тесты интегрируются в запущенное приложение во время его тестирования. Поэтому отпадает необходимость в моккинге (англ. «mock» - имитирование, подражание).
Давайте рассмотрим более подробно, что будет, и что не будет работать при интеграционном тестировании:
BootStrap будет выполнен. Контекст Spring-приложения будет полностью развернут;request (GrailsMockHttpServletRequest), response (GrailsMockHttpServletResponse) и session (MockHttpSession);Важной особенностью является то, что интеграционным тестам требуется гораздо больше времени для выполнения, чем Unit-тестам, поскольку в этом случае перед тем, как непосредственно выполнить интеграционные тесты, Grails необходимо осуществить запуск и развертывание приложения. Поэтому, из-за достаточно серьезной экономии времени, Unit-тесты являются более предпочтительными. Однако не стоит относиться с пренебрежением и к интеграционным тестам. Вот список тех ситуаций, когда они могут оказаться просто незаменимыми:
На этом все. Удачного вам погружения в физику и магию тестирования!
Представим себе типичную ситуацию. Пусть в составе нашего приложении имеются два сервиса:
и
Как мы видим, оба этих сервиса нуждаются во взаимной инъекции экземпляра другого сервиса и сохранении его в виде внутреннего свойства. С виду все правильно, однако, если мы попытаемся запустить наше приложение, то получим ошибку следующего характера:
Ошибка связана с тем, что Spring не может проинициализировать свойство, в которое требуется поместить ссылку на экземпляр объекта, нуждающийся в обратной ссылке на текущий объект. Классическая ситуация «курицы и яйца», по-другому не назовешь.
Как же решить проблему? Снимем обязанность по инъекции в одном из классов со Spring и прибегнем к ленивой инициализации свойства. А еще точнее в одном из сервисов сам процесс инъекции поместим в соответствующий геттер. Посмотрите на следующий листинг:
Итак, что же мы сделали:
PostService мы имплементировали интерфейс ApplicationContextAware.ApplicationContext.personService мы создали метод-геттер getPersonServiceBean, в котором посредством метода applicationContext.getBean() возвращаем ссылку на экземпляр нужного нам сервиса.bar к экземпляру сервиса обращаемся посредством свойства personServiceBean, которое, по сути дела, является аналогом вызова геттера getPersonServiceBean(). Обратите внимание, что названием геттера является getPersonServiceBean, а не getPersonService. Тем самым при помощи переименовывания мы пресекаем любые попытки инъекций этого свойства со стороны Spring.Код сервиса PersonService мы оставляем без изменений — с односторонними зависимостями Spring справляется очень даже хорошо. Тестируем приложение и проверяем, что теперь оно запускается без ошибок.
Вот и все на сегодня. Удачного вам дня!
Давно хотел написать об этом, да все руки не доходили... На сайте JetBrains доступны два четыре относительно новых видеоурока, касающихся поддержки Flex в Intellij IDEA:
Кстати, сам не проверял, но, насколько мне известно, начиная с версии 8.1.1 в IDEA появилась поддержка встраиваемой ASDoc-документации.
P.S.: с Днем Победы вас!
UPDATE: В список добавлены еще 2 урока. Спасибо nicity за информацию.
А знаете ли вы, что, начиная с версии 5, в Java появилась такая интересная «фишка», как импорт статических членов класса? Выглядит это следующим образом. Допустим, в нашем классе в нескольких местах используется метод Math.random(). Если поместить в начало класса следующий импорт:
то мы можем в любом месте этого класса вызывать метод при помощи более короткой записи:
Можно импортировать все статические члены класса, указав вместо названия конкретного поля или метода символ *:
В Groovy импорт статических членов также поддерживается, но в более продвинутой форме — кроме указания имени импортируемого члена класса, можно указывать еще и псевдоним (англ. alias), через который этот член будет доступен в коде:
Таким образом, мы создали псевдоним rand и теперь можем через него производить вызов статического метода Math.random:
Кстати, точно таким же образом в Groovy можно указывать псевдоним для импортируемого класса:
В ActionScript 3 подобного функционала пока нет, но если он появится в будущих версиях, то этот язык станет чуточку более удобным.
Предлагаю вашему вниманию небольшой трюк по оптимизации Flex приложений.
Часто бывает необходимым наделить свой класс возможностью рассылать события, однако мы почти уверены, что подписываться на эти события объекты-получатели будут крайне редко. Поэтому не хочется наследовать в своем классе весь функционал flash.event.EventDispatcher и запускать «без дела» в коде своего класса распространение событий вызовом метода dispachEvent().
Как раз на этот случай во Flex 4 framework припасен утилитный класс mx.utils.OnDemandEventDispatcher, позволяющий улучшить производительность нашего приложения по двум направлениям:
OnDemandEventDispatcher не является наследником EventDispatcher, а только лишь реализует интерфейс IEventDispatcher. Класс посредством композиции делегирует выполнение методов, объявленных в интерфейсе, внутреннему экземпляру EventDispatcher. Сам же внутренний объект-диспетчер создается только в случае необходимости — при первой подписке на рассылку событий от текущего объекта. Таким образом, удается немного сэкономить занимаемый приложением объем оперативной памяти.OnDemandEventDispatcher:
Таким вот нехитрым образом, наследуясь там, где это необходимо, от класса OnDemandEventDispatcher мы хоть и ненамного, но все же улучшаем производительность нашего Flex приложения.
