Инструкции по сборке проекта под iOS уже были доступны уже в течение некоторого времени, однако у простых разработчиков как-то не получалось запускать что-то сложнее чем «здравствуй мир» на реальных девайсах.

40 Минут назад, некто Johan написал в рассылку mobile-dev@openjdk о том, что ему удалось запустить приложение использующее Gluon Charm (Material Design UI) в JavaFX (OpenJFX 9) в Java на iPad mini. На мой взгляд это существенно достижение!

Некоторое время назад я писал, как при помощи языческих танцев и прочих паранормальных активностей я добился работы Apache POI XSSF на Android 4. Всё становится гораздо проще с Android Build Tools (21+) и Android 5 (ART).

Теперь достаточно собрать проект с поддержкой multi-dex и всё будет работать* на устройствах c ART. Я полагаю, что это происходит благодаря Ahead-of-time (AOT) compilation на устройстве и multi-dex, теперь, как таковой, нужен только как промежуточный этап.

* К сожалению не всё так гладко. В зависимостях проекта есть xmlbeans-2.6.0.jar, который запакован с ошибкой и содержит дубликаты классов. Это приводит к провалу сборки на задаче packageAllDebugClassesForMultiDex, со следующей ошибкой:

Error:Execution failed for task ':app:packageAllDebugClassesForMultiDex'.
> java.util.zip.ZipException: duplicate entry: org/apache/xmlbeans/xml/stream/Location.class

XMLBeans придётся перепаковать.
Этот дефект уже сто лет в обед как зарегистрирован issues.apache.org/jira/browse/XMLBEANS-499, однако воз и ныне там.

Несколько месяцев назад я опубликовал плагин к Moment.js позволяющий рассчитать: сколько это N рабочих дней от сегодня в календарных днях? какая дата будет спустя N рабочих дней от заданной даты? сколько рабочих дней в заданном диапазоне? Возможность сконфигурировать рабочие дни и исключения в виде праздников — имеется.

Плагин можно найти на github: https://github.com/andruhon/moment-weekday-calc

Плагин можно установить через bower и npm:

bower install moment-weekday-calc

npm install moment-weekday-calc

Плагин добавляет несколько функций в Moment.js:

• int weekdayCalc — считает сколько «рабочих» дней в заданном диапазоне
• date addWorkdays — находит дату спустя N «рабочих» (пн-пт) дней
• int workdaysToCalendarDays — конвертирует рабочие дни в календарные
• date addWeekdaysFromSet — добавляет дни из заданного множества к заданной дате
• int weekdaysFromSetToCalendarDays — конвертирует дни из заданного множетсва в календартные дни

Каждая из функций доступна с префиксом iso, такие функции используют множество рабочих дней начинающееся с понедельника (1-7), функции без префикса используют американский формат начинающийся с воскресенья (0-6).

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

UPD (06.09.2014): Больше нет необходимости компилировать с опцией --core-library
Сама по себе задача прочитать формат XLSX при помощи Apache POI XSSF совершенно не хитрая. Не хитрая ровно до тех пор, пока вы не решите подключить эту библиотеку к вашему приложению для Android. К сожалению, гугление ни к чему не привело — мне не удалось найти реальных инструкций или рекомендаций по использованию XSSF на Android. Вообще ни одного упоминания о том, что эта библиотека действительно может работать на Android.

HSSF(XLS) — работает без проблем, XSSF(XLSX) — не удалось ничего найти, только рекомендации обрабатывать все при помощи POI где-нибудь на сервере.

Далее раскрываю, в чем заключается проблема и как я её решил

Сегодня пол часа потратил на необычную для меня проблему: Документ во всех браузерах отображается нормально, а в файрфоксе почему-то не работали стили.

Проблема возникла только, после помещения сайта на виртуальный хостинг — с домашнего тестового сервера все работало нормально.
Файл с css вроде был доступен, тем не менее firefox не определял его как стиль.

На деле все оказалось достаточно просто: когда в документе прописан DOCTYPE файрфокс становится требователен к типу содержимого файла с таблицей стилей, то есть сервер должен вернуть файл исключительно с Content-Type: text/css, в соответствии со спецификацией W3C. Однако апач у хостера был настроен каким-то интересным образом, так, что он возвращал файлы css с Content-Type: text/plain.

Из-за такой нелепости пришлось потерять достаточно много времени.

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

developer.mozilla.org перевели на новую wiki — будем привыкать.

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

Задача
В системе с использованием XSLT шаблонов предоставить контентерам возможность просто использовать привычные для них имена сущностей наподобие & nbsp; & mdash; и т.д. без необходимости использования цифровых определений типа & #160;, & #x00A0; или помещения спецсимволов в CDATA

Проблема
При загрузке в XML из базы данных множества блоков у меня возникла следующая проблема: Парсер ругался на неописанные сущности примерно следующим образом: «Entity: line 1: parser error: Entity 'yen' not defined».

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