Linux — хорошая система для разработчика. В ней есть много «полезностей», которых нет под другими платформами. Но вот с разработкой Flash/Flex-приложений в ней есть определенные трудности. Это связанно с тем, что Debug Flash Player под Linux-ом завершает дебаг-сессию через 2-60 секунд после ее запуска. Согласитесь, что не очень удобно разрабатывать приложения, не имея возможности толком их продебажить.

Больше года назад (а конкретнее 2 февраля 2009 года) в Adobe Jira был создан таск с описанием этого бага. С тех пор разработчики Flash Player не сделали в этом направлении ни-че-го. Поэтому я обращаюсь ко всем, кого заботит этот вопрос. Давайте дружно проголосуем за этот баг и попытаемся таким образом общими усилиями собрать сто тыщ мильонов хотя бы сотню голосов, чтобы разработчики наконец-то обратили свое внимание на него, изменили его приоритет с «None» на «Normal» и взялись за его исправление.

Заранее спасибо всем поддержавшим.

5 комментариев

Недавно столкнулся со следующей задачей: на одном веб-сервере под управлением Windows Server 2003 необходимо было установить несколько экземпляров Apache Tomcat 6 для того, чтобы в каждом из них «крутилось» свое собственное приложение. Установить нужно было таким образом, чтобы каждый из этих сервлет-контейнеров являлся в системе обособленным сервисом со своей конфигурацией, параметрами автозапуска, отдельным пунктом в списке установленных программ системы, ну и, в качестве бонуса, собственной иконкой в трее.

Посмотрев решения подобной задачи в интернете, обнаружил, что, пожалуй, единственным способом ее решения будет самостоятельная правка реестра системы. Это связано с тем, что стандартный инсталлятор Apache Tomcat 6 не поддерживает возможности его установки в виде нескольких сервисов и не позволяет разнести настройки каждого из экземпляров по отдельным веткам реестра.

Здесь я хочу сделать важное предупреждение. Описываемая в статье техника является работоспособной и проверенной мной на собственном опыте и на реальном рабочем сервере. Она даже не является хаком, поскольку, будь инсталлятор немного более грамотным, он бы выполнял ее автоматически. Я не проверял, но скорее всего эта техника будет работать и на Windows Server 2008. Выполняемые процедуры не затрагивают никаких других настроек и веток реестра, кроме тех, которые непосредственно относятся к каждому отдельному сервису Apache Tomcat. Однако я не несу никакой ответственности за возможный ущерб, связанный с непосредственным, а так же с неосторожным или неправильным применением этой техники. Используйте ее на свой страх и риск. И не забудьте сделать резервную копию важных данных перед началом процедуры.

Итак, поехали.

1. Установите первый экземпляр Apache Tomcat в отдельную директорию, например, в C:\Tomcat6_1. На последнем шаге мастера установки нужно убрать галочку Run Tomcat.
2. Откройте редактор реестра regedit: Start → Run… → regedit → нажмите Enter.
3. Переместитесь к ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tomcat6 и переименуйте ее из Tomcat6 в Tomcat6_1.
4. Здесь же измените значение свойства DisplayName с Apache Tomcat на Apache Tomcat 6 (1). Именно под этим именем теперь будет отображаться сервис в списке локальных служб системы. Чтобы посмотреть список служб вашей системы выполните следующую последовательность действий: кнопка Start → Run… → services.msc → клавиша Enter.



5. Теперь измените часть значения свойства ImagePath с …//RS//Tomcat6 на …//RS//Tomcat6_1. Именно с этим именем будет запускаться экземпляр службы. Это значение понадобится нам в шаге 9.
6. Далее переходим к ветке HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat6 и переименовываем ее в Tomcat6_1. В дальнейшем это позволит нам установить новый экземпляр Apache Tomcat без перезаписи настроек устанавливаемого в настоящий момент экземпляра.
7. По тем же самым причинам меняем название ветки HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\6.0 на 6.0_1.
8. Теперь переходим к ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run и меняем имя ключа с ApacheTomcatMonitor на ApacheTomcatMonitor_1. Это имя приложения по управлению службой. Его изменение позволяет нам избежать перезаписи этого ключа при установке следующих экземпляров Tomcat и управлять каждым из сервисов при помощи отдельного окна приложения.



9. Теперь изменим завершающую часть значения этого ключа с …Tomcat6 на …Tomcat6_1. Внимание: это значение должно совпадать с тем, которое мы присвоили ключу ImagePath в шаге 5.
10. Для того, чтобы иметь возможность потом деинсталлировать по отдельности каждый из установленных экземпляров Tomcat, мы должны перейти в ветку реестра 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).



11. Перезагрузите систему, чтобы изменения вступили в силу.
12. Для того чтобы распределить установленные экземпляры Tomcat по разным локальным портам, мы должны правильно сконфигурировать каждый из них. Открываем файл C:\Tomcat6_1\conf\server.xml и меняем значения следующих узлов:
    1. <Server port="8005" shutdown="SHUTDOWN"> на 8001 (для каждого из последующих сервлет-контейнеров мы будем использовать порты 8002, 8003 и т.д.).
    2. <Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000" redirectPort="8443" /> на 8081 (далее будем использовать 8082, 8083 и т.д.).
13. Выполните инструкции с 1 по 12 для каждого из последующих экземпляров Apache Tomcat, используя для разделения каждого из них увеличенное значение индекса. Допустим, второй экземпляр должен быть установлен в папку C:\Tomcat6_2, ветка реестра из шага 3 должна быть переименована в Tomcat_2, а ключ DisplayName в шаге 4 изменен на Apache Tomcat (2) и т.п.
14. Перезагрузите систему, чтобы удостовериться в том, что разные экземпляры Tomcat нормально запускаются во время старта Windows.

На этом все на сегодня. Буду надеяться, что заметка окажется вам полезной. Удачного вам дня!

Комментариев нет

В этом посте каждый может задать вопрос, каким-либо образом относящийся к среде разработки Intellij IDEA, и получить на него вразумительный ответ. На русском. Развернуто и актуально.

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

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

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

27 комментариев

Хорошие люди попросили разместить объявление, что я и сделал.

В компанию «Датэк» для работы над проектом «COMDI» требуются хорошие программисты:

Flex/Flash программист

• Хорошее знание ActionScript3, Flex.
• Опыт разработки полноценных веб-приложений
• Желателен опыт работы с медиа серверами (FMS, Wowza).

JAVA программист

• Опыт разработки апплетов, работа с изображениями.
• Желательно, опыт работы с JNI.
• Необходимо представление о работе WinAPI, cетевых протоколах, желательно P2P.
• Придется разрабатывать системы скриншаринга, удаленного управления рабочим столом, работа с веб-камерами, p2p соединения и т.д.

Работа постоянная в современном офисе, в районе ВДНХ. Уровень ЗП – 70,000-100,000.
Резюме присылайте на egor.voronin@gmail.com

Комментариев нет

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

В этом отношении язык Groovy не стал исключением — в нем тоже все объекты имеют метод toString(), логику которого можно переопределять, как в собственных классах пользователя, так и в любом другом из уже имеющихся классов и объектов программы, при помощи свойства metaClass. Однако Groovy шагнул дальше — он позволяет нам похожим образом приводить объекты и к булеву значению, и, кроме того, к любому другому типу объектов в приложении.

Рассмотрим для начала ситуацию приведения объекта к булеву значению. Все просто — берете и переопределяете в своем классе (или посредством поля metaClass в объекте или классе, доступа к исходному коду которого у вас нет) метод asBoolean():

Ну и, как вы уже могли догадаться, аналогичным способом мы переопределяем метод asType(), чтобы тем самым сделать возможным приведение нашего объекта к любому нужному нам типу:

Вот такие очень гибкие возможности предоставляет нам Groovy.

Комментариев нет

Если кто не в курсе, то уже почти месяц как Intellij Idea 9 имеет возможность просмотра UML-диаграмм для ActionScript и Flex классов, а это значит, что у нас есть возможность анализировать код своих Flex проектов при помощи UML диаграм классов.

2 комментария

Вы все еще нежитесь на новогодних каникулах? А вот Бьёрн Вильмсман (Björn Wilmsmann) уже вовсю занимается разработкой. Именно по этой причине он 2 января зарелизил и сразу же обновил до версии 0.2.2 небольшой, но замечательный плагин для Grails платформы под названием «Magic Numbers».

Плагин замечателен тем, что, основываясь на методологии библиотеки Active Support в Ruby on Rails, он расширяет классы Long и Integer специальными методами, позволяющими на более простом и понятном уровне производить различные числовые операции над датами и битами в приложении. Посмотрите, например, на следующие варианты использования:

Замечательно, не находите?

Более подробная информация доступна на странице плагина. Установка плагина производится через стандартный Grails-репозитарий посредством выполнения следующей команды:

Комментариев нет

Вдруг кто-нибудь из вас подзабыл или до сих пор не знал различия между типами запросов GET/POST/PUT/DELETE и других в протоколе HTTP. Рекомендую в таком случае вернуться к истокам и прочитать статью «Типы HTTP-запросов и философия REST», в которой хабрапользователь indigo простым и понятным языком раскрывает основы этой темы.

Комментариев нет

Должно быть каждый Grails-программист, только начавший постигать премудрости метода «разработки приложения посредством тестирования», задается вопросом: «Для чего же в Grails существуют две разновидности тестов, и какая между ними разница?». Ведь на первый взгляд очевидной разницы между ними нет, кроме того, что Unit-тесты создаются в папке test/unit приложения, а интеграционные — в test/integration.

Однако все не так просто, как могло бы показаться. Начнем с Unit-тестов. Они потому так и называются, что производят тестирование очень маленьких частей приложения, единиц или юнитов функциональности: отдельных классов и их методов. Интеграционные тесты же специально разработаны для тестирования достаточно крупных частей приложения: таких, как контроллеры и все их зависимости. Но главное же отличие между этими разновидностями тестов заключается в том, что интеграционные тесты выполняются в контексте запущенного приложения — с одновременным запуском базы данных и доступом ко всем динамическим свойствам и методам, в которых может нуждаться тестируемый код. Т.е. буквально, интеграционные тесты интегрируются в запущенное приложение во время его тестирования. Поэтому отпадает необходимость в моккинге (англ. «mock» - имитирование, подражание).

Давайте рассмотрим более подробно, что будет, и что не будет работать при интеграционном тестировании:

• все плагины, у которых не исключена возможность интеграционного тестирования, будут загружены;
• код в классе BootStrap будет выполнен. Контекст Spring-приложения будет полностью развернут;
• доменные классы будут взаимодействовать с реальной базой данных (по умолчанию, на этапе тестирования используется временная база данных HSQLDB);
• все динамические свойства и методы, впрыскиваемые Spring, доступны на этапе тестирования;
• будут использованы «моккнутые» версии свойств request (GrailsMockHttpServletRequest), response (GrailsMockHttpServletResponse) и session (MockHttpSession);
• фильтры не будут работать;
• URL-mapping не производит никакого эффекта;
• нет поддержки тестирования видов (GSP-страниц).

Важной особенностью является то, что интеграционным тестам требуется гораздо больше времени для выполнения, чем Unit-тестам, поскольку в этом случае перед тем, как непосредственно выполнить интеграционные тесты, Grails необходимо осуществить запуск и развертывание приложения. Поэтому, из-за достаточно серьезной экономии времени, Unit-тесты являются более предпочтительными. Однако не стоит относиться с пренебрежением и к интеграционным тестам. Вот список тех ситуаций, когда они могут оказаться просто незаменимыми:

• когда у вас нет возможности протестировать что-то посредством Unit-тестов;
• когда вы хотите протестировать взаимодействия между различными объектами в приложении;
• когда проще протестировать какой-либо функционал, взяв реальные данные из базы, чем «моккать» все подряд в приложении.

На этом все. Удачного вам погружения в физику и магию тестирования!

2 комментария

Представим себе типичную ситуацию. Пусть в составе нашего приложении имеются два сервиса:

и

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

Ошибка связана с тем, что Spring не может проинициализировать свойство, в которое требуется поместить ссылку на экземпляр объекта, нуждающийся в обратной ссылке на текущий объект. Классическая ситуация «курицы и яйца», по-другому не назовешь.

Как же решить проблему? Снимем обязанность по инъекции в одном из классов со Spring и прибегнем к ленивой инициализации свойства. А еще точнее в одном из сервисов сам процесс инъекции поместим в соответствующий геттер. Посмотрите на следующий листинг:

Итак, что же мы сделали:

1. В сервисе PostService мы имплементировали интерфейс ApplicationContextAware.
2. Добавили в класс инъекцию ApplicationContext.
3. Вместо инъекции personService мы создали метод-геттер getPersonServiceBean, в котором посредством метода applicationContext.getBean() возвращаем ссылку на экземпляр нужного нам сервиса.
4. В методе bar к экземпляру сервиса обращаемся посредством свойства personServiceBean, которое, по сути дела, является аналогом вызова геттера getPersonServiceBean(). Обратите внимание, что названием геттера является getPersonServiceBean, а не getPersonService. Тем самым при помощи переименовывания мы пресекаем любые попытки инъекций этого свойства со стороны Spring.

Код сервиса PersonService мы оставляем без изменений — с односторонними зависимостями Spring справляется очень даже хорошо. Тестируем приложение и проверяем, что теперь оно запускается без ошибок.

Вот и все на сегодня. Удачного вам дня!

Комментариев нет