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

В моем коде я высчитывал startDate и endDate, и возвращал Duration вот таким образом:

  return new Period(startDate, endDate).toDuration();

Выяснилось, что если startDate и endDate отстояли друг от друга больше, чем на месяц, JodaTime кидал исключение. Решение было найдено быстро:

  return new Interval(startDate, endDate).toDuration();

Починил, и задумался, почему я допустил такой ляп. JodaTime имеет очень богатый набор классов для описания всего, что связано со временем, и мне некогда было разбираться в разнице между Period, Interval, Duration и т.д. И очень зря.
Когда я писал код, в голове вертелось «за отчетный период хлеборобы Кубани убрали и намолотили....». Я, хотя и свободно говорю по-английски, выбрал первый попавшийся класс, похожий на «отчетный период», т.е. Period.

К чему я это все? К тому, как важно правильно называть свои классы/методы/переменные. Почитал я (вовремя, ага, после того, как закончил проект) документацию к JodaTime и позавидовал белой завистью. Ребята приложили кучу усилий к тому, чтобы назвать каждый класс нужным существительным. Interval — это не Period, и понятно почему (ага, теперь понятно). У меня так, к сожалению, получается не всегда. А жаль.

Глядя сегодня в адресную книгу своего телефона на Андроиде, я понял, что мне неудобно смотреть на список моих контактов, отсортированный по порядку символов в UTF.

Думаю, почти каждый сталкивался с таким мнением: писать тесты сложно, все примеры написания тестов даны для простейших случаев, а в реальной жизни они не работают. У меня же за последние годы сложилось впечатление, что писать тесты — это очень просто, даже тривиально. Продолжаю начатое в первой части.

Думаю, почти каждый сталкивался с таким мнением: писать тесты сложно, все примеры написания тестов даны для простейших случаев, а в реальной жизни они не работают. У меня же за последние годы сложилось впечатление, что писать тесты — это очень просто, даже тривиально^*. Автор упомянутого выше комментария далее говорит, что неплохо было бы сделать пример сложного приложения и показать, как его тестировать. Попробую именно этим и заняться.

^*)Писать сами тесты — действительно элементарно. Создать инфраструктуру, позволяющую легко писать тесты — чуть сложнее.

Только что вернулся со сборища в Oracle для участников местных групп пользователей Java. Было объявлено, что конференция JavaOne будет жить и в 2010-2011 годах пройдет в Сан-Франциско, Пекине, Сан-Паоло, Хайдарабаде и Санкт-Петербурге. В Сан-Франциско конференция пройдет в рамках конференции Oracle Open World с 19 по 23 сентября 2010 года, даты в других городах пока не объявлены.

Буквально только что в топе проскочила замечательная статья "Элементы семантической паутины". Начал писать на нее ответ, но он получился слишком большим, поэтому выделяю его в отдельный топик.

Итак, большинство комментариев делится на две категории: «Да ну, рядовому юзеру семантическая разметка информации непонятна, недоступна, и соответственно, он не будет ей заниматься» и «Да ладно, все будет хорошо, как-нибудь добредем то этого светлого будущего».

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

Проходящая сейчас (и почти уже закончившаяся) в Новом Орлеане конференция SpringOne 2GX — отличный повод поговорить о том, чем нас радовал SpringSource в последнее время и порадует в ближайшем будущем.

SpringOne 2GX — это ежегодная конференция, проводимой компанией SpringSource. Так как относительно недавно SpringSource стал счастливым обладателем технологий Groovy и Grails, в этом году конференции SpringOne и 2Gx решили объединить в одну.

Недавно уважаемый akakunin опубликовал топик "Firefox становится дефолтовым браузером", в котором цитировал сообщение, появляющееся при заходе в консоль недавно выпущенного сервиса Spring Source Cloud Foundry: «The browser that you are using is not supported by Cloud Foundry. You may continue to explore using this browser, but many features and layout elements will not work or display properly. We recommend that you use FireFox 3.0+ for Cloud Foundry.» Из этого факта он, да и народ в комментариях стал задумываться о тенденции.

На самом деле, объяснение такой тенденции довольно простое, и состоит оно из двух названий продуктов: FireBug и Selenium.

FireBug — это то, что хоть как-то мирит меня с миром Ajax. Без него я себе разработку Ajax-приложений просто не представляю. Да, в новой Опере есть DragonFly, но ПМСМ с ним тяжелее работать.

Selenium — если кому-то из разработчиков веб-приложений надо объяснять, что это такое, мне искренне жаль этих людей :) В принципе, правильно организованный процесс разработки в сочетании с использованием Selenium позволяет обходиться без живых тестеров. А если ваше приложение написано на Spring framework, то можно использовать umangite — библиотеку, делающую конфигурацию Selenium-а для вашего приложения делом достаточно тривиальным. На линуксе Selenium работает тоже только с Firefox (по крайней мере, до недавнего времени). Да и на Винде, насколько я знаю, Firefox дружить с Selenium-ом лучше всех.

В-общем, получается, что Firefox — единственный браузер, в котором можно быть уверенным, что он будет отображать ваше приложение так, как задумано.