Some days ago there was a seminar held by the Bulgarian Java User Group with topic “REST, HATEOAS, Novelties in JAX-RS 2.0 & Spring HATEOAS”. I talked about the Spring HATEOAS related piece presenting a small demo project I developed beforehand with Spring HATEOAS.
The code along with a few wiki pages with rough explanations of what is done and how to be used are available on my GitHub account.
Книга “Класически шаблони за дизайн”
Стартираме нова итерация за писане на книгата с отворен код за “Класически шаблони за дизайн” http://code.google.com/p/design-patterns-book/.
Търсим автори и редактори, които да се включат в проекта.
Свободните теми за писане са следните:
Наличните теми за редакция са:
Ако имате желание да се включите в екипа, ни пишете на design.patterns.book.team [at] gmail.com
Ще Ви бъдем благодарни, ако разпространите това съобщение сред приятели, познати и колеги, които биха били заинтересовани.
Днес, 21.03.2013 г, ще се проведе семинар на тема “Eclipse plug-in development” пред българската Java потребителска група (BG-JUG). Семинарът ще бъде в зала 299 на ФМИ с начало19:00 ч.
На семинара ще бъдат разгледани следните въпроси:
По време на семинара ще се наблегне и на новостите в e4.
Лектори на семинара ще бъдат Мартин Тошев и Дмитрий Александров.
Това е обявата на събитието и на сайта на BG-JUG.
Книга “Класически шаблони за дизайн”
След първата организационна сбирка (която се състоя на 19.12.20011) и края на първата итерация от проекта за написването на книга за класически шаблони за (софтуерен) дизайн, екипът на книгата реши да се събере отново и втората сбирка ще се състои на 17.03.2012 (събота) от 10 ч, в учебен център “SoftAcad”, намиращ се на следния адрес:
ул. Проф. Кирил Попов 27, кв. Студентски град, гр. София [карта]
Някои от по-важните теми на сбирката ще са следните:
Целта на проекта е да се създаде оригинална българска книга с отворен код, по подобие на книгите “Въведение в програмирането с Java” и “Въведение в програмирането със С#”, която предоставя изчерпателна и актуална информация за шаблоните за софтуерен дизайн (design patterns), служейки еднакво добре, както за въведение в материята, така и като справочник. Като евентуално начало на поредица от книги за шаблони за софтуерен дизайн, тази книга ще обхваща най-често използваните (“класически”) шаблони за софтуерен дизайн (GoF patterns). Ако всичко приключи добре, инициативата може да продължи с други поредица от проекти за написване на книги за архитектурни шаблони, интеграционни шаблони, шаблони за конкурентно програмиране и т.н. Друга цел на проекта е да предостави безплатен достъп до електронната версия на книгата. Цената на хартиеното копие ще бъде в размера на разходите за отпечатване и дистрибуция, като сумата събрана от продажбата ще се преизползва за следващи тиражи
Тъй като се опитваме да ръководим проекта, следвайки модифициран вариант на Scrum методологията, това ни дава възможност да сме гъвкави, относно присъединяването на нови автори и редактори към екипа. В този ред на мисли, ако някой има желание да се включи в проекта, ще бъде добре дошъл(а), стига да е сериозен/сериозна и да има желание да отдели част от свободното си време за създаването на тази книга 🙂 За целта, моля присъединете се към дискусионната група на книгата и чрез нея се свържете с нас. Връзката с организационния екип на проекта можете да осъществите също, като ни пишете на design.patterns.book.team [кльомба] gmail.com. Естествено, ако имате желание да се включите, можете да дойдете директно на сбирката и да обсъдим включването Ви 🙂
Книга за софтуерни шаблони за дизайн се състои от няколко части. Първата част представлява кратко въведение в основните принципи на софтуерен дизайн. Втората излага трите групи “класически” шаблони, а именно за създаване на обекти, структурни и поведенчески. Третата част е своеобразен преход към евентуална книга за архитектурни шаблони и представя многослойната архитектура и шаблона MVC. Четвъртата част евентуално ще съдържа материал, който е важен за изложението но не се вписва в контекста на нито една от предходните три части. Книгата ще следва до някъде класическите концепции от GoF, но няма да е превод на тяхната книга, а ще дава съвременно виждане за шаблоните с имплементация на Java и примери от практическия опит на авторите. Следва планираното съдържание на книгата по глави:
Глава 1. Основни етапи при разработката на софтуер Глава 2. Принципи и техники на ООП Глава 3.1. Принципи на обектно-ориентиран дизайн Глава 3.2. Принципи SOLID Глава 4. Кратко въведение в UML
Глава 5. Шаблони за дизайн – въведение
Глава 6. Абстрактна фабрика (Abstract Factory) Глава 7. Строител (Builder) Глава 8. Метод фабрика (Factory Method) Глава 9. Прототип (Prototype) Глава 10. Сингълтон (Singleton)
Глава 11. Адаптер (Adapter) Глава 12. Мост (Bridge) Глава 13. Композиция (Composite) Глава 14. Декоратор / обвивка (Decorator / Wrapper) Глава 15. Фасада (Façade) Глава 16. Миниобект (Flyweight) Глава 17. Прокси (Proxy)
Глава 18. Верига от отговорности (Chain of Responsibility) Глава 19. Команда (Command) Глава 20. Интерпретатор (Interpreter) Глава 21. Итератор (Iterator) Глава 22. Посредник (Mediator) Глава 23. Спомен/Мементо (Memento) Глава 24. Наблюдател (Observer) Глава 25. Състояние (State) Глава 26. Стратегия (Strategy) Глава 27. Шаблонен метод (Template Method) Глава 28. Посетител (Visitor)
Глава 29. Многослойна архитектура (Multilayer Architecture) Глава 30. Модел-презентация-контролер (MVC)
* в процес на изясняване
Официалният сайт на книгата за шаблони за софтуерен дизайн за момента е в Google Code: http://code.google.com/p/design-patterns-book. Дискусионна група на проекта е: http://groups.google.com/group/design-patterns-book. Всички активи по проекта са публично достъпни от неговото SVN хранилище: http://design-patterns-book.googlecode.com/svn/trunk/. Следващата итерация (за редакция на написаното до момента) ще започне най-вероятно идната седмица, а тази, за писане на глави, най-вероятно – след две седмици, така че не е късно да се включите. 🙂 Забележка: Фонът на картинката е от творба на Ешер, взета от този сайт: http://www.wikipaintings.org/en/m-c-escher/symmetry-watercolor-55-fish
Българската Java потребителска група организира семинар на тема “Java Portlets with Liferay and JSF”.
Събитието ще се проведе на 29.09.2011 г от 19:00 до 21:00 в зала 325, на Факултет по математика и информатика към СУ “Св. Климент Охридски”.
JS Mashup с портлети
Портлетите представляват видимия и полезен за крайния потребител резултат от внедряването на Service Oriented Architecture (SOA). Те са технология, която дава възможност на бизнес организациите да осигурят повече функционалност, гъвкавост и възможност за персонализация за своите клиенти. С помощта на Web Services for Remote Portlets (WSRP) стандарта на OASIS за отдалечено публикуване на портлети става възможно бизнес услугите лесно да бъдат интегрирани в партньорски портали. Стандартът се ползва с подкрепата на големите доставчици на портални решения като Oracle®, IBM® и Microsoft®.
Внедряването на централизирани уеб портали предлага редица предимства за бизнеса:
В последните години Java портлетите станаха популярна технология, която позволява лесно споделяне и комбиниране на приложения от различни организации и индивиди в персонализиран уеб портал. Новият портлетно-базиран стил на разработка на уеб приложения дава възможност за създаване на по-разпределени, гъвкави и лесни за повторно използване компоненти, в сравнение с традиционните монолитни решения. Портлетните приложения типично се състоят от множество различни портлети, които могат да бъдат гъвкаво позиционирани върху уеб страницата и комуникират помежду си с използване на споделени параметри (shared parameters), събития (publish/subscribe events), съгласно Portlet Specification 2.0, или чрез JavaScript и AJAX (без презареждане на страницата).
Презентацията демонстрира разработката на портлети с Portlet 2.0 Specification (JSR-286) и портален сървър Liferay (http://www.liferay.com). Liferay е едно от водещите портални решения с отворен код, лидер в Gartner®’s Magic Quadrant for Horizontal Portals.
Включени са демонстрации на JSP, JSF и Spring портлети, Mashups с използване на Google Maps, както и новости при разработката на портлети с JSF 2.0 и JSF 2 –> Portlet 2 Bridge (http://www.portletfaces.org) и IceFaces (http://www.icefaces.org). Ще бъдат разгледани също допълнителни примери за JavaScript портлети и използване на новата JS библиотека Alloy UI базирана върху YUI3 (http://yuilibrary.com/projects/yui3), която замени jQuery при Liferay 6.
Траян Илиев е магистър по Информатика от Софийски университет „Св. Климент Охридски“. От 2003 той е управител на IPT – Intellectual Products & Technologies (http://www.iproduct.org). Компанията е специализирана в провеждането на обучения по JAVA™ SE/EE технологии.
От 2000 година той преподава в Софийски университет, Факултет по математика и информатика, където води курсове: Обектно ориентиран анализ и проектиране с езика UML, Информационни и комуникационни технологии, Системи за подпомагане вземането на решения, Мултимедийни технологии, Изкуствен интелект. Участвал е в редица национални и европейски изследователски проекти.
Сред неговите технически и изследователски интереси са Service Oriented Architecture, business systems and process modeling using UML and BPMN, Java portlets and portal frameworks (Liferay, GateIn, etc.), AJAX and JavaScript libraries, Java EE technologies (EJB 3.1, JSF 2.0, JPA 2.0, EJB™ 3.1, JSF 2.0, REST-ful web services, WSRP), Java multithreading, multi-agent technologies (http://www.h2j.org).
Без съмнение при разработването на Java-базирани уеб приложения, Eclipse и Tomcat са избор по подразбиране. Обикновено предпочитам да използвам предварително инсталиран Tomcat, използвайки го през Eclipse. В този случай обаче, по подразбиране, логгинга на Tomcat не работи, което обикновено е доста дразнещо, тъй като не ни се иска да се връщаме в тъмните времена на System.out.println() (което добавя още един аргумент към молбата на Мишо за подобряване на интеграцията между Eclipse и Tomcat).
За включване на логването под Tomcat, който се управлява управлява от Eclipse, са нужни следните стъпки:
-Djava.util.logging.config.file="[LOG4J_PROPS_LOCATION]/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
Когато конфигурирам Tomcat, предпочитам конфигурационните файлове да бъдат в директорията на сървъра. Когато сървърът се стартира през Eclipse обаче, това не е толкова лесно.
Когато се създаде сървър под Eclipse, използвайки независима Tomcat инсталация, физически конфигурационните файлове на сървъра се съхраняват в следната директория “[ECLIPSE_WORKSPACE]/.metadata/.plugins/org.eclipse.wst.server.core".
В тази папка, в отделни поддиректории се пазят конфигурационните файлове на всеки един от сървърите “създадени” през Eclipse. Поддиректориите са именувани с tmp[i], където с [i] е означен поредния номер на сървъра в зависимост от последователността на създаването му. Например за следните сървъри
имаме съответните конфигурационни директории:
drwxrwxrwx 1 user group 0 Aug 22 08:54 tmp0 drwxrwxrwx 1 user group 0 Aug 22 08:55 tmp1 drwxrwxrwx 1 user group 0 Aug 29 17:23 tmp2
Всяка една от папките има структура подобна на подразбиращата се за Tomcat:
d:eclipse-workspace.metadata.pluginsorg.eclipse.wst.server.coretmp2>ls -al total 0 drwxrwxrwx 1 user group 0 Aug 29 17:23 . drwxrwxrwx 1 user group 0 Aug 29 17:23 .. drwxrwxrwx 1 user group 0 Aug 29 17:23 conf drwxrwxrwx 1 user group 0 Aug 29 17:23 logs drwxrwxrwx 1 user group 0 Sep 9 19:37 temp drwxrwxrwx 1 user group 0 Aug 29 17:23 webapps drwxrwxrwx 1 user group 0 Aug 29 17:23 work drwxrwxrwx 1 user group 0 Sep 9 13:18 wtpwebapps
Отново, по подобие на конфигурацията на стандартната инсталация на Tomcat, поставяме конфигурационния файл на Log4J log4j.properties в папката conf, изпълняваме стъпките описани в предходната секция и voilà, логването е включено.
Рано или късно, след една, две или няколко преинсталации на операционната система, всеки от нас достига до извода, че трябва да инсталира потребителските програми на дял/твърд диск, различен от системния. Да, но повечето програми, при инсталиране имат предефинирани настройки, които обикновено (поне в случая с Windows) очакват, че инсталацията на сътоветната програма е на системния дял. Подобен е случая и с Eclipse и Maven.
Дори Maven да е инсталиран на дял различен от системния, по подразбиране Maven хранилището на локалния компютър се очаква, че ще бъде по подразбиране точно на системния дял:
Ако искаме да променим местоположението на локалното хранилище, да бъде на дял различен от системния например, единственото, което е нужно да направим е да променим конфигурационния файл на Maven – settings.xml, намиращ се в инсталационната директория на Maven. За целта, разкоментираме тагът localRepository и добавяме пътя до новата директория, която ще бъде използвана за хранилище:
<settings> ... <localrepository>/path/to/local/repo/</localrepository> ... </settings>
В моя случай, промяната изглежда по следния начин:
<settings> ... <localrepository>D:/config/maven/.m2/repository</localrepository> ... </settings>
По подразбиране Eclipse използва собствена инстанция на Maven. За локално хранилище, по подразбиране, използва следните папки:
Ако инсталираме Maven на място различно от това по подразбиране и конфигурираме локалното хранилище да бъде на място различно от това, което се очаква по принцип, инсталирането на генерираните от Maven архиви (jar,war, и т.н.) в локалното хранилище, ще се записват на новоуказаното място.
Ако не отразим тези промени и в Eclipse, той ще използва собствената инстанция на Maven и собствени настройки за локално Maven хранилище. Съответно, ако Eclipse не намери папката .m2/repository в директорията на текущия потребител (user.home) на системния дял/диск, той я създава и инсталира генерираните архиви от Maven проектите там. Така, компилирането и инсталирането (в термините на Maven) на едни и същи проекти от командния ред и от Eclipse, ще доведе до съхраняването на архивите съответно на две различни места.
Нещо повече, не винаги версията на Maven, която Eclipse използва (M3 за Eclipse 3.6.1 например), съвпада с тази, която използваме в текущия проект (M2 за проекта, по който работя в момента). Както знаем, поради нововъведенията направени във връзка оптимизирането на работата на Maven във версия M3, Maven проектите, компилирани с тази версия са несъвместими с М2 и обратно.
Така можем да обобщим следните проблеми при промяна на локалното хранилище (и инсталация) на Maven, но неотразяването им в Eclipse:
За да ги избегнем, трябва да направим две промени в настройките на Eclipse. Отваряме менюто Window > Preferences и променяме:
Преди месец, на семинар на Българската Java потребителска група, направих презентация, “BDD с JBehave и Selenium”, с която се опитах да представя концепцията за разработка на софтуер ръководена от поведението на софтуера (Behaviour Driven Development) и основите на JBehave (конкретна BDD технология). Презентацията съдържа още и пример, който онагледява как JBehave може да бъде интегриран със Selenium, във връзка с тестването на уеб интерфейси използвайки BDD.
Презентацията може да бъде намерена на профила ми в Slideshare:
Кодът от примерите и самата презентация могат да бъдат свалени също и от Google Code хранилището на групата: http://tinyurl.com/6xoz4sp
Кодът и презентацията са публикувани под CC-BY лиценз.
Във връзка с въпроса:
Къде (и в какъв ред) се търсят *.properties файловете, когато се зареждат с:
ResourceBundle.getBundle(filename)
се поразрових и преведох следната интересна информация:
1) .properties файловете се зареждат от classloader-а, подобно на .java класовете, т.е. трябва местоположението им да е включено в CLASSPATH променливата на средата.
2) .properties файловете имат пълно име (fully-qualified-resource-name), както при .java класовете, с изключение на това, че не може да се извършва import на ресурcи (.properties файлове) в някой .java клас.
3)
ResourceBundle.getBundle("myBundleProps")указва на classloader-a да зареди ресурс с име myBundleProps в пакета по подразбиране. Това не значи, че ресурса трябва да е в текущия пакет, в който е класа, от който се зарежда.
4)
ResourceBundle.getBundle("package1.package2.package3.myBundleProps")указва на classloader-a да зареди ресурс myBundleProps с пакет package1.package2.package3. Неговото пълно име (fully-qualified-resource-name) съответно е
package1.package2.package3.myBundleProps.
Т.е. ако директорийната структура на проекта е следната:
project_path
+-- src
| +-- package1
| +-- package2
| +-- package3
| +-- TestResourceBundle.java
+-- classes
+-- package1
+-- package2
+-- package3
+-- TestResourceBundle.class
+-- myBundleProps.properties
и ако в TestResourceBundle.java, ResourceBundel класa се зарежда със следният код:
ResourceBundle myBundleProps = ResourceBundle.getBundle(
"myBundleProps");
е нужно myBundleProps.properties да се копира в project_path/classes, на същото директорийно ниво на project1 папката. Като алтернатива може да се пакетира myBundleProps.properties в един .jar файл, така че myBundleProps.properties да е в главната директория в .jar архива, който няма никакви поддиректории архивирани в него. След това трябва да се добави този .jar файл в CLASSPATH променливата на средата.
Ако в TestResourceBundle.java се зарежда обект от тип ResourceBundel със следният код:
ResourceBundle myBundleProps = ResourceBundle.getBundle(
"package1.package2.package3.myBundleProps");
Тогава е нужно да се копира myBundleProps.properties в
project_path/classes/package1/package2/package3. Като алтернатива, може да се сложи
package1/package2/package3/myBundleProps.properties съответно в един .jar файл (запазвайки директорийната структура на пакетите и в него) и да се добави този .jar файл в CLASSPATH променливата на средата.
Причините за гореописаните начини за употреба на .properties ресурсни файлове са следните:
1) Прозрачност в локализирането на файла – по време на изпълнение на програмата, myBundleProps.properties НЕ е файл, той е просто ресурс, който се зарежда. myBundleProps.properties може да не се съдържа в проекта като цяло, и човека който пише TestResourceBundle.java може изобщо да не види този ресурс. Един URLClassLoader може да го намери в мрежовия път или в URL по време на изпълнение. Това специално е важно за server-side компоненти като EJB, Servlet, JSP и т.н., който по принцип нямат достъп до файловата система. При опит да се получи даден ресурс от classloader, няма значение къде се съхранява съответният ресурс.
2) Mеханизма при работа когато имаш namespaces – конструирайки програмата с пакети, това позволява множество други пакети да съдържат ресурсни файлове (.properties файлове) със същото кратко име (в случая myBundleProps.properties) без това да причинява конфликти в цялата работа на системата. Това е като java пакетите и xml namcesaces.
[Източник: http://blogs.sun.com/chengfang/entry/p_java_util_missingresourceexception_can]