Мне кажется, что этот путь заведет в тупик, хотя и принесет некоторую пользу. Оставаясь в рамках парадигмы* разметки документа, мы заранее ограничим разнообразие семантической информации, которую сможем публиковать.
Мне кажется более многообещающим вариант, когда пользователь указывает системе (шаблону? движку?), что некий элемент — это сущность определенного класса. И дальше система, а точнее, плагин к системе CMS, который занимается обработкой таких элементов, решает как его отображать. Ибо не микроформатом единым…
Но, как и везде, выгоды эластичного Hadoop-а идут не без цены. И дело не только в деньгах, которые платятся за время работы вашего кластера. Я слушал презентацию одного мужика, который работает на громадном Hadoop-кластере в Yahoo, и он говорил, что физическое расположение машин в кластере имеет громадное значение для его производительности. То есть, на амазоновском Hadoop-е можно делать все, что угодно, но производительность будет хромать, что естественно. Но тут уж, кому что. В целом, возможность запускать задачи Map/Reduce по требованию и платить только за использованное время — это очень круто.
Подозреваю, что если такую идею реализовать на практике, то на основе наблюдений за ней можно будет написать не один диссер по самым разным дисциплинам: психологии, экологии, кибернетике, и т.д.
Просматривая Twitter по тагу #springone2gx, набрел на прекрасный комментарий: «Производительность GSP в Grails 1.2 повысилась в 2-3 раза благодаря тому, что убрали случайно забытый вызов Thread.sleep()»
То есть как это? Что может быть непонятного в связке Spring + Hibernate?! :)
Я, например, к Grails отношусь с подозрением, ибо не до конца понимаю, что оно там внутри делает («а внутре у нее неонка»). То есть, теоретически я знаю, что под капотом у Grails все те же Spring + Hibernate (да?), но все же…
Это в смысле — каждому свое. Лично мне нравится, что я получаю знакомый набор технологий maven + java + spring + hibernate. (Олд скул форева). Выпадет шанс реально поработать с Grails — может, изменю мнение. Groovy я уже полюбил :)
По крайней мере, мотивация для создания Roo была именно такой.
Мне Roo понравился (плюс, его автор — совершенно замечательный тип :) ).
Вот пример скрипта на Roo (тот самый wedding.roo из комплекта):
project --topLevelPackage com.wedding
persistence setup --provider HIBERNATE --database HYPERSONIC_PERSISTENT
database properties list
database properties set --key database.url --value jdbc:hsqldb:${user.home}/my-wedding
entity --name ~.domain.Rsvp
field string code --notNull --sizeMin 1 --sizeMax 30
field string email --sizeMax 30
field number attending --type java.lang.Integer
field string specialRequests --sizeMax 100
field date confirmed --type java.util.Date
test integration
controller scaffold ~.web.RsvpController
selenium test --controller ~.web.RsvpController
Аннотации в стопицот (ну люблю я это слово) раз удобнее XML-конфигурации. Причем это относится и к MVC, и к бизнес-логике.
В MVC мой файл *-servlet.xml содержит минимальное количество конфигурации: объявляется context:component-scan, DefaultAnnotationHandlerMapping, AnnotationMethodHandlerAdapter, и, практически, это все. Все остальное делается через аннотации @Controller и @RequestMapping.
Гораздо удобнее тестировать контроллеры, когда они представляют собой простые классы (POJOs), а не подклассы Спринговских базовых классов.
Да и в остальном коде тоже удобно. @Autowired и @Component — и все прекрасно, все зависимости разрешены. С тех пор, как мы перешли на использование аннотаций в Спринге, я ни разу не воспользовался специальными спринговскими расширениями для Эклипса — просто нет нужды.
В Spring 3, который вот-вот выходит, будет возможность определять свои аннотации. К примеру @Service можно будет определить как @Component, все методы которого будут обернуты в транзакцию, причем, методы, начинающиеся со слова get — в транзакцию только для чтения.
Единственная моя претензия к аннотациям — это то, что исходники засоряются информацией для контейнера. Мой внутренний пурист морщится каждый раз, когда в импортах класса я пишу import org.springframework.stereotype.Component. Но есть надежда, что в какой-то момент эти аннотации будут стандартизированны, и тогда код теоретически можно будет переносить без перекомпиляции с Spring на Guice и обратно. Но, если честно, вероятность того, что это когда-либо понадобится, исчезающе мала.
Нет, не попадалась. И, если честно, я не прочел ни одной книги по тестированию. Все, что знаю по этому вопросу — это сумма прочитанного в блогах, собственного опыта, и дискуссий со знакомыми.
Я, вообще-то, разработчик, и подход к тестированию у меня специфический, расчитанный на автоматическое тестирование моего собственного кода. Профессиональные тестеры это все делают слегка по-другому.
Когда я начинал заниматься Джавой стопицот лет назад, я пролистал самый первый самоучитель на сановском сайте и начал писать. Все остальное пришло с опытом, как ни шаблонно бы это звучало. Помогло еще то, что я тогда работал в Sun :)
Если вы относитесь к числу счастливчиков, которые могут сами себе придумывать задачи и не лениться их выполнять, то проблем нет, самоучителей полно. Другой вариант — примазаться к какому-нибудь существующему проекту с открытым кодом, компилировать чужие исходники, пробовать что-то менять, писать самому что-то похожее, ну, и спрашивать людей, почему они это пишут так.
Третий вариант, наименее реальный, особенно в наше время — найти клиента, которому нужен софт, честно предупредить, что это займет МНОГО времени, и начать писать. Опять же, сильно поможет наличие друзей, которые разбираются, они ткнут в best practices, помогут разобраться с проблемами.
Ну, не знаю. За последнее время единственный раз, когда я пользовался NetBeans — это когда Scala изучал. Поддержка Scala для NetBeans намного лучше (была несколько месяцев назад), чем в IDEA или Eclipse.
Поддержка Groovy в Eclipse, кстати, получше стала, особенно в варианте STS, как-никак SpringSource уже некоторое время назад купил Groоvy и Grails.
NetBeans отвратительно смотрится на линуксе (IDEA, кстати, тоже не фонтан, ИМХО).
Точнее, смотрелся раньше, до Java 6. Сейчас, вроде, есть возможность запустить любое Swing-приложение с родным стилем GTK, но я не пробовал. Но по-любому SWT > Swing (опять же, имхо).
В принципе, на eclipse, кроме привычки, меня держит совершенно изумительная вещь — Mylyn, которой нет под другие IDE.
Нынешний мой проект — сложное AJAX приложение, основанное на Dojo, а в качестве backend — Tomcat/Spring/Hibernate. Пришлось очень сильно помучиться с Selenium-ом, но результат оправдал все мучения. С кросс-доменной аутентикацией не сталкивался, пардон.
Главная проблема — реагирование на события в интерфейсе, ожидание каких-то условий, появления элементов в DOM-e, и т.д. Я общался с автором Selenium-a, и, по его словам, идеального решения этой проблемы еще вообще не найдено.
Сильно помогает page object pattern. Мы с шефом его придумали некоторое время назад, а потом выяснили, что он так называется, и другие люди его тоже используют :) Идея достаточно проста — пишутся stateless классы-помощники, которые инкапсулируют нудные подробности доступа к каким-то элементам интерфейса. Например, класс LoginPage имеет поле selenium (класс Selenium), и методы: fillIn(String username, String password), clickForgotPassword(), assertLoginError(String expectedMessage), и т.д.
Также я стал писать классы-помощники для сложный Javascript-овский виджетов, запихивая в них как можно больше деталей.
После этого написание собственно тестов стало доставлять удовольствие. Например:
IDE — Eclipse, конечно. Сейчас я использую Spring Tool Set (STS) — вариант Eclipse от SpringSource, с некоторыми дополнительными возможностями. IntelliJ IDEA — тоже очень хорошо, но дорого. Я недавно выиграл халявную лицензию, но все равно остался с Eclipse-ом. Привык.
Фреймворк — Spring framework!!! Без него очень тяжело. Потребовались некоторые мозговые усилия, чтобы начать думать в их стиле, но теперь я вообще себе не представляю разработку на Java :)
Некоторое время назад пришлось начать писать на Groovy. Сначала не понравилось, в-основном из-за не очень хорошей поддержки в IDE, но сейчас стал оттаивать. Особенно приятно парсить XML — вообще без усилий.
Пардон, но это же совсем другое дело! WinMobile (при всей моей нелюбви к Майкрософту) — это открытая платформа. В смысле, что закрытая имплементация, конечно, но API — опубликованы. У меня прекрасно гоняется на таком телефоне Funambol (sync4j), который замечательно синхронизирует все с сервером, с Гуглом и с моим Thunderbird. Это не хак, это совершенно нормальное приложение, использующее публичные возможности платформы.
кстати, насколько я понимаю, под айФон тоже есть нормальный клиент для Funambol. Хоть тут не закрыли :)
Ну, дело не только в этом. Позвольте переформулировать.
Я не хочу трахаться (пардн май френч) с побочными эффектами ради достаточно дорогой игрушки. Если я плачу (и приплачиваю за марку, кстати) достаточно большие деньги, и меня еще и загоняют в единственно возможный контракт, мне совершенно не хочется нарушать закон, чтобы за свои же деньги этой игрушкой пользоваться. Нарушение, естественно, еще то, по этапу не загремишь :), но дело в принципе.
Я бы с радостью купил iPhone еще тогда, если б было сказано: «мы рекомендуем пользоваться iTunes. Не хотите — вот вам api, трахайтесь сами». А поскольку сказано: «можно пользоваться только iTunes, иначе мы оставляем за собой право превратить ваш новенький телефончик в красивое, но малофункциональное пресс-папье», то я думаю, что эпплу придется обойтись без моих четырехсот баксов. Да, небольшая потеря, но даже и четыреста баксов лучше получать, чем нет :)
Мне кажется более многообещающим вариант, когда пользователь указывает системе (шаблону? движку?), что некий элемент — это сущность определенного класса. И дальше система, а точнее, плагин к системе CMS, который занимается обработкой таких элементов, решает как его отображать. Ибо не микроформатом единым…
*)Гы, а еще я знаю богатое слово «гомосексуализм»
Но, как и везде, выгоды эластичного Hadoop-а идут не без цены. И дело не только в деньгах, которые платятся за время работы вашего кластера. Я слушал презентацию одного мужика, который работает на громадном Hadoop-кластере в Yahoo, и он говорил, что физическое расположение машин в кластере имеет громадное значение для его производительности. То есть, на амазоновском Hadoop-е можно делать все, что угодно, но производительность будет хромать, что естественно. Но тут уж, кому что. В целом, возможность запускать задачи Map/Reduce по требованию и платить только за использованное время — это очень круто.
package com.wedding.domain;
import java.lang.String;
import javax.persistence.EntityManager;
import javax.persistence.Query;
privileged aspect Rsvp_Roo_Finder {
public static Query Rsvp.findRsvpsByCodeEquals(String code) {
if (code == null || code.length() == 0) throw new IllegalArgumentException("The code argument is required");
EntityManager em = Rsvp.entityManager();
Query q = em.createQuery("SELECT Rsvp FROM Rsvp AS rsvp WHERE rsvp.code = :code");
q.setParameter("code", code);
return q;
}
}
Хммм… даже не на Hibernate, оказывается. Интересно, надо покрутить.
Я, например, к Grails отношусь с подозрением, ибо не до конца понимаю, что оно там внутри делает («а внутре у нее неонка»). То есть, теоретически я знаю, что под капотом у Grails все те же Spring + Hibernate (да?), но все же…
Это в смысле — каждому свое. Лично мне нравится, что я получаю знакомый набор технологий maven + java + spring + hibernate. (Олд скул форева). Выпадет шанс реально поработать с Grails — может, изменю мнение. Groovy я уже полюбил :)
Мне Roo понравился (плюс, его автор — совершенно замечательный тип :) ).
Вот пример скрипта на Roo (тот самый wedding.roo из комплекта):
project --topLevelPackage com.wedding
persistence setup --provider HIBERNATE --database HYPERSONIC_PERSISTENT
database properties list
database properties set --key database.url --value jdbc:hsqldb:${user.home}/my-wedding
entity --name ~.domain.Rsvp
field string code --notNull --sizeMin 1 --sizeMax 30
field string email --sizeMax 30
field number attending --type java.lang.Integer
field string specialRequests --sizeMax 100
field date confirmed --type java.util.Date
test integration
controller scaffold ~.web.RsvpController
selenium test --controller ~.web.RsvpController
// (quit, mvn test, mvn tomcat:run, localhost:8080/wedding, mvn selenium:selenese)
logging setup --level DEBUG --package WEB
security setup
controller class --name ~.web.PublicRsvpController
finder list --class ~.domain.Rsvp --filter code,equ
finder add --finderName findRsvpsByCodeEquals
email sender setup --hostServer 127.0.0.1
field email template --class ~.web.PublicRsvpController
// quit, mvn eclipse:eclipse; import project into Eclipse
// complete manual configuration as described at blog.springsource.com/roo-part-2/
logging setup --level DEBUG
На выходе получаем приложение на Java + Spring + Hibernate, плюс тесты (в т.ч для Selenium) — в виде maven проекта.
По-моему, круто.
В MVC мой файл *-servlet.xml содержит минимальное количество конфигурации: объявляется context:component-scan, DefaultAnnotationHandlerMapping, AnnotationMethodHandlerAdapter, и, практически, это все. Все остальное делается через аннотации @Controller и @RequestMapping.
Гораздо удобнее тестировать контроллеры, когда они представляют собой простые классы (POJOs), а не подклассы Спринговских базовых классов.
Да и в остальном коде тоже удобно. @Autowired и @Component — и все прекрасно, все зависимости разрешены. С тех пор, как мы перешли на использование аннотаций в Спринге, я ни разу не воспользовался специальными спринговскими расширениями для Эклипса — просто нет нужды.
В Spring 3, который вот-вот выходит, будет возможность определять свои аннотации. К примеру @Service можно будет определить как @Component, все методы которого будут обернуты в транзакцию, причем, методы, начинающиеся со слова get — в транзакцию только для чтения.
Единственная моя претензия к аннотациям — это то, что исходники засоряются информацией для контейнера. Мой внутренний пурист морщится каждый раз, когда в импортах класса я пишу import org.springframework.stereotype.Component. Но есть надежда, что в какой-то момент эти аннотации будут стандартизированны, и тогда код теоретически можно будет переносить без перекомпиляции с Spring на Guice и обратно. Но, если честно, вероятность того, что это когда-либо понадобится, исчезающе мала.
Я, вообще-то, разработчик, и подход к тестированию у меня специфический, расчитанный на автоматическое тестирование моего собственного кода. Профессиональные тестеры это все делают слегка по-другому.
Когда я начинал заниматься Джавой стопицот лет назад, я пролистал самый первый самоучитель на сановском сайте и начал писать. Все остальное пришло с опытом, как ни шаблонно бы это звучало. Помогло еще то, что я тогда работал в Sun :)
Если вы относитесь к числу счастливчиков, которые могут сами себе придумывать задачи и не лениться их выполнять, то проблем нет, самоучителей полно. Другой вариант — примазаться к какому-нибудь существующему проекту с открытым кодом, компилировать чужие исходники, пробовать что-то менять, писать самому что-то похожее, ну, и спрашивать людей, почему они это пишут так.
Третий вариант, наименее реальный, особенно в наше время — найти клиента, которому нужен софт, честно предупредить, что это займет МНОГО времени, и начать писать. Опять же, сильно поможет наличие друзей, которые разбираются, они ткнут в best practices, помогут разобраться с проблемами.
Поддержка Groovy в Eclipse, кстати, получше стала, особенно в варианте STS, как-никак SpringSource уже некоторое время назад купил Groоvy и Grails.
Точнее, смотрелся раньше, до Java 6. Сейчас, вроде, есть возможность запустить любое Swing-приложение с родным стилем GTK, но я не пробовал. Но по-любому SWT > Swing (опять же, имхо).
В принципе, на eclipse, кроме привычки, меня держит совершенно изумительная вещь — Mylyn, которой нет под другие IDE.
Главная проблема — реагирование на события в интерфейсе, ожидание каких-то условий, появления элементов в DOM-e, и т.д. Я общался с автором Selenium-a, и, по его словам, идеального решения этой проблемы еще вообще не найдено.
Сильно помогает page object pattern. Мы с шефом его придумали некоторое время назад, а потом выяснили, что он так называется, и другие люди его тоже используют :) Идея достаточно проста — пишутся stateless классы-помощники, которые инкапсулируют нудные подробности доступа к каким-то элементам интерфейса. Например, класс LoginPage имеет поле selenium (класс Selenium), и методы: fillIn(String username, String password), clickForgotPassword(), assertLoginError(String expectedMessage), и т.д.
Также я стал писать классы-помощники для сложный Javascript-овский виджетов, запихивая в них как можно больше деталей.
После этого написание собственно тестов стало доставлять удовольствие. Например:
@Test public void testLoginAndChangePassword() { login("u", "p"); gotoSettingsPage(); settingsPage.updateBothPasswordFields("newPassword").save(); logout(); login("u", "newPassword"); homePage.assertHere() }Пишите, если есть еще вопросы!
Фреймворк — Spring framework!!! Без него очень тяжело. Потребовались некоторые мозговые усилия, чтобы начать думать в их стиле, но теперь я вообще себе не представляю разработку на Java :)
Некоторое время назад пришлось начать писать на Groovy. Сначала не понравилось, в-основном из-за не очень хорошей поддержки в IDE, но сейчас стал оттаивать. Особенно приятно парсить XML — вообще без усилий.
Java, Amazon Web Services / EC2, Spring framework, Dojo toolkit, Selenium
кстати, насколько я понимаю, под айФон тоже есть нормальный клиент для Funambol. Хоть тут не закрыли :)
Я не хочу трахаться (пардн май френч) с побочными эффектами ради достаточно дорогой игрушки. Если я плачу (и приплачиваю за марку, кстати) достаточно большие деньги, и меня еще и загоняют в единственно возможный контракт, мне совершенно не хочется нарушать закон, чтобы за свои же деньги этой игрушкой пользоваться. Нарушение, естественно, еще то, по этапу не загремишь :), но дело в принципе.
Я бы с радостью купил iPhone еще тогда, если б было сказано: «мы рекомендуем пользоваться iTunes. Не хотите — вот вам api, трахайтесь сами». А поскольку сказано: «можно пользоваться только iTunes, иначе мы оставляем за собой право превратить ваш новенький телефончик в красивое, но малофункциональное пресс-папье», то я думаю, что эпплу придется обойтись без моих четырехсот баксов. Да, небольшая потеря, но даже и четыреста баксов лучше получать, чем нет :)