Про настройку шрифтов в IDE (Netbeans) под Linux.

Какой самый лучший шрифт для программиста?
Каждому своё.
Одним нравятся округлые очертания, другому наоборот тонкие и острые. Поэтому выбор шрифта — дело вкуса, хотя конечно есть базовые требования.
Самое главное и очевидное — шрифт должен быть моноширинным, т.е. все символы должны быть одной ширины. Это очень важно для того, чтобы сохранить структуру кода, т.к. иначе будут плыть все отступы и исходный код будет плохо читаться.
Если человек пришел в программирование с дизайнерским/типографским прошлым, такой шрифт его может раздражать. Моноширинные шрифты не самые приятные для чтения, хотя их используют не только программисты-техногики, но и люди искусства.
Например, если верить википедии, в западной театральной и кинематографической традиции сценаристы используют шрифт Courier-12. Одна страница такого сценария длится примерно одну минуту. Вроде это какой-то даже у них стандарт де-факто в отрасли.

Кроме моноширинности, при выборе следует обратить внимание на следующее:
- Цифра 0 (ноль) должна отличаться от буквы O.
- Цифра 1 (один) должна отличаться от буквы l (маленькая L).

Что касается меня, то сейчас я использую шрифт Consolas.

Специфика Linux.

На момент написания этой статьи у некоторых пользователей Linux (Ubuntu) есть определенное недовольство качеством отображения шрифтов в IDE.
Итак, что можно попробовать сделать.

Во-первых, я ставлю набор микрософтовских шрифтов:

$sudo apt-get install ttf-mscorefonts-installer

Во-вторых, особо чувствительные к шрифтам могут поставить Infinality.

В-третьих и самое главное. Это не сильно помогает, т.к. на момент написания этой статьи в Java (точнее в её графической подсистеме AWT/Swing) есть какие-то проблемы с красивым отображением шрифтом в Ubuntu. Другими словами проблема актуальна для Netbeans и Android Studio.

Единственное нормальное решение я нашел здесь askubuntu.com.
Итак чуть более подробный пересказ, что нужно делать.
Читать далее...

Про org.json парсер

С json парсерами в Java дела обстоят следующим образом. С одной стороны их существует несколько разновидностей, с другой стороны сложно сделать выбор.

Хорошо когда только один критерий принятия решения, например скорость работы или размер библиотеки. Сложности начинаются тогда, когда нужно выбрать с учетом нескольких характеристик.
В этой небольшой заметке я хотел бы кратко описать случаи, когда уместно использование библиотеки "org.json".

Итак, кратко плюсы и минусы.

Минусы:
- Далеко не самый быстрый парсер.
- Нет автоматической сериализации в JavaBean-ы.

Плюсы:
+ По-умолчанию есть в стандартной поставке Android
+ Простое API

Занятные факты:
~ Первые версии этой библиотеки были написаны Дугласом Крокфордом (англ. Douglas Crockford) — создателем формата JSON.

Теперь чуть подробнее.

Наличие в стандартной поставки Android API это действительно плюс, с учетом лимита в Android-е на кол-во методов в 64К (65 536 шт) любая дополнительная библиотека может обернуться лишней головной болью.

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

В случае если объем данных занимает мегабайты, а ручной разбор и мэппинг в бины - утомителен и однотипен, то естественно надо от него уходить в сторону других решений.
Лично я предпочитаю в таких случаях использовать gson, но это дело вкуса и технической необходимости. Никаких предубеждений против того же jackson-a я не имею.

В стандартной Java появление легковесного API пока не предвидится. В новостях были сообщения, что JEP 198: Light-Weight JSON API не будут включать в Java 9, аргументируя это тем, что и так много опенсорных json-парсеров.

Поэтому если все-таки нужен именно "org.json" в стандартной Java, то его можно подключить через мавен.

<dependency>	 	 
 <groupId>org.json</groupId>	 	 
 <artifactId>json</artifactId>	 	 
 <version>20160810</version>	 	 
</dependency>

При этом надо понимать, что во-первых в нормальной Java (не Android) нет ограничений в 64К методов, во-вторых нет стандартного json парсера, поэтому использование org.json не столь очевидно.

Что касается Java EE, в нем есть стандартный javax.json пакет с классами для работы с JSON-ом.

Компьютер/ноутбук для программиста

В этой статья я расскажу про свой опыт, про других, про мировые практики и попробую дать советы в выборе компьютера для программиста.

Мой опыт.

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

Кратко, как было у меня. Изначально, кажется в 2009-ом году, когда нужно было много ездить по разным встречам, я предпочитал небольшие ноутбуки. В частности, у меня был 13-дюймовый ноутбук (BenQ T31) с достаточными на тот момент характеристикам для компиляции и запуска IDE. Продержался я на нем не так долго, т.к. на маленьком экране и компактной клавиатуре не очень удобно работать. Выходил из положения подключением внешнего монитора (кажется 21-дюймовый Samsung) и клавиатуры.
probook
Через некоторое время я заменил BenQ на HP Probook 4720s и отправил старый ноутбук на дачу. Новый ноутбук был полноценной боевой машиной весом больше трех килограмм с 17-дюймовым экраном и нормальной полноразмерной клавиатурой. В целом машиной был доволен, но пришлось приобрести специальный большой компьютерный рюкзак.

Работать на выезде у заказчика и в поездках стало почти также комфортно как и за рабочим столом. Приблизительно в это же время я перестал работать дома и переехал в коворкинг (на ДЗ Флакон) с фиксированным рабочим местом. При этом от стационарного монитора и клавиатуры я не отказался. Правда я заменил Samsung на ViewSonic чуть большей диагонали.

Через некоторое время я взял новый ноутбук ASUS G550JK серии ROG (Republic of Gamers).asus Старый ноутбук я отдал племяннику, он на нём учится программировать. Новый ноутбук хоть и был из игровой серии (Asus ROG) именно эта модель получила много негативных отзывов от геймеров, поскольку в нем не самая мощная видеокарта. Для моих задач, как программиста это было не важно, главное было то, что в нем стоит неплохой процессор (i7) и 16 Gb памяти.

Через некоторое время я сменил внешний монитор ViewSonic на DELL с 24". Замена мне понравилась. Старый ViewSonic показал себя не с лучшей стороны, первые полтора года отработал без проблем, но потом пару раз сломался, даже пришлось обратиться в гарантийным отдел. Я редко обращаюсь в сервис, обычно не чиню, а просто покупаю новое оборудование и перестаю пользоваться изделиями этого бренда, просто у этого монитора оказалась очень длительная гарантия, но тем не менее, думаю в ближайшее время ViewSonic-ами пользоваться не буду.

Что касается периферии - мышек и клавиатур, то я меняю их достаточно часто (раз-два в год). Любимые бренды - A4Tech, Logitech и Microsoft. Кстати кто не знает, у микрософта в линейке клавиатур и мышек всегда имелись неплохие модели. Сейчас работаю на Microsoft Wireless Comfort Desktop 5000, уже больше года. Пока это для меня самая удобная клавиатура.

В такой конфигурации я проработал около года, потом опять всё немного поменялись и я перестал таскать с собой ноутбук на встречи, клиенты стали чаще приезжать сюда в коворкинг. Спустя несколько месяцев у меня оказалась без дела рабочая станция на DELL и я решил переехать с ноутбука на стационарный компьютер. Для того чтобы принять это решение пришлось себя немного "поломать". Сложно было принять рациональное решение, тем не менее из плюсов - еще лучше железо, больше свободного места на столе и самое главное, не нужно вечно таскать как черепашка-ниндзя на своей спине рюкзак с ноутбуком. После этого у меня началась настоящая "Dolce Vita!" для программиста.

Приезжаю утром в коворкинг, налегке, без рюкзака, выпиваю чашку кофе, в холле играет легкий джаз, поднимаюсь в комнату, сажусь в кресло и включаю компьютер. Всё уже настроено для комфортной работы - не нужно подключать клавиатуру, монитор, мышку. В комнате - как в научной библиотеке, никто громко не говорит, а для разговора по телефону или между собой все выходят. Сохраняется рабочая атмосфера, только мерное шуршание клавиатуры и запах утреннего кофе. Если хочется общения, то можно спуститься к барной стойки на первом этаже стартхаба, плюс каждую неделю проходят программистские встречи.

Вот так выглядит мое рабочее место.
desktop

Мои друзья.

Безусловно такое непостоянство в смене компьютеров возможно является следствием моего темперамента или типом личности. Например, мой друг купивший где-то в конце 2000-ных(!) Thinkpad T520 остается ему верен до сих пор. Безусловно это отличная модель, с хорошими характеристиками, четким линиям и выразительными чертами в дизайне. Второй его ноутбук, это Asus ROG, стилизованный под спорткар Ламборгини, обладает ещё большей маскулинностью. Это тяжелая брутальная заряженная машина сделанная в черно-матовом дизайне. Он тяжелый, массивный и очень резвый.

Если взять другой пример, например вы хрупкая девушка-программист, которая пишет мобильные приложения под iOS и выбираете ноутбук, то в таком случае нужно брать MacBook (или какой-нибудь другой компьютер от Apple). Это будет самый правильный способ и если не хочется каких-то острых извращений, то для эффективной разработки iOS-приложений компьютеры Apple будут самым нормальным решением. Плюс конечно, макбуки это просто красиво и у них действительно неплохая аппаратная платформа. Хотя ничто не идеально, сломаться может всё что угодно, а ремонт мака может обойтись существенно дороже обычного pc.
Читать далее...

Установка и настройка Apache Tomcat под Linux

Tomcat-logo

Причины.

Замысел написать эту статью про установку и настройку, наверное, одного и самых популярных веб-серверов на Java возник уже давно. Одной из причин было желание сделать небольшую заметку "для себя" с подробной инструкцией. Возможно эта статья также пригодится другим java программистам. Пользы для кого-нибудь ещё, например для системных администраторов в ней будет не так много. Скорее всего они просто сделают так: apt-get install tomcat8 и затем потребуют у программиста war-ик для развертывания. Программист же часто хочет чуть большего — например, возможности работать с различными версиями серверов (которых может даже ещё нет в официальном репозитории) или наоборот откатиться к какой-то специфичной версии. Системному администратору такие исследования, как правило, не нужны. По-хорошему, у него должна стоять просто стабильная работающая версия, на которую периодически он будет накатывать обновления и лишний раз на неё не дышать.

В общем, это статья про то, как программисту установить Apache Tomcat под Linux чтобы "поиграться" с ним, но при этом ничего сильно не сломать.
Также эта статья может быть полезна в тех случаях, когда начинающий java программист отладив свое веб-приложение Tomcat запущенным на Windows, сталкивается со жгучим желанием развернуть свой сайт на какой-нибудь недорогой VPS-ке с Ubunt-ой.

Статья может показаться излишне многословной, но мне хотелось рассказать про основные "грабли" и способы их обхода. Могу предположить, что системные администраторы могут быть недовольны тем, что это решение недостаточно системные. Поэтому тем, кто хочет подробно изучить данный вопрос или посвятить свою жизнь профессиональной (т.е. получать за это деньги) настройки линуксовых серверов, тому лучше следует обратиться к соответствующей литературе, обучится этому ремеслу у профессионала и черпать знания у сисадминского сообщества. Здесь же у меня просто блог для java программистов.

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

Подготовка

Исходные данные.
Linux. Debian 9. 64bit.

1. Устанавливаем JDK.
Почему JDK, а не JRE? По-факту достаточно JRE, но лично мне приятно иметь возможность в случае необходимости по-быстрому скомпилировать программку на java прямо на сервере.
Вы не поверите, но жизнь такая интересная штука, никогда не угадаешь когда тебе может понадобится скомпилировать и запустить что-то на Java. Лично мне запуск javac из консоли на сервере помогал несколько раз.

Далее, я предпочитаю ставить Oracle JDK. Собственно OpenJDK тоже неплох и устанавливается гораздо проще (sudo apt-get install default-jdk). Просто я отдаю предпочтение оригинальной Sun/Oracle. Тем не менее, ставить Oracle JDK, OpenJDK или какую-либо другую версию - личное дело каждого. Лично я отношусь к пользователям Open JDK без предубеждения. Более того, сам часто использую версии Open JDK (например Java 9) для того, чтобы ознакомиться с их новыми возможностями.

Установка Oracle JDK под Windows и Linux сильно отличаются. Под Windows проще установить Oracle JDK проще простого (скачать и запустить), а сборку Open JDK под Windows нужно ещё поискать.
С Linux-ом всё наоборот. Open JDK как я писал ставится очень просто через apt, с Oracle JDK чуть сложнее.

В интернете существует совет, что для установки нужно добавить ещё один apt-репозиторий. Я так не делаю. Возможно это лично моя паранойя, но я стараюсь так не делать и делаю установку руками. Особенно если учесть, что установка заключается в том, чтобы скачать и распаковать архив.

Для этого заходим на сайт загрузки Oracle.

Выбираем jdk-XYZ-linux-x64.tar.gz файл. Правой кнопкой - сохранить ссылку.

Далее скачиваем архив:

$wget --header "Cookie: oraclelicense=accept-securebackup-cookie" [ссылка]

Например так:

$wget --header "Cookie: oraclelicense=accept-securebackup-cookie" 
    http://download.oracle.com/otn-pub/java/jdk/8u73-b02/jdk-8u73-linux-x64.tar.gz

Специально для параноиков, нужно проверить SHA-1 сумму (поскольку выкачиваем-то по голому http).

Проверяем:

$sha256sum jdk-8u73-linux-x64.tar.gz

Смотрим что показалось на экране и сверяем значение, с тем что опубликовано на официальном сайте. Читать далее...

Про Android TV.

androidTV_player-entertainment-default

Небольшая предыстория.

Так получилось, что мы пишем приложение для Android TV.
Вообще, обычно я занимаюсь тем, что в программисткой среде принято называть "суровым энтерпрайзом" — веб-службы, высокая нагрузка и прочие Java EE штуки.

Тем не менее, иногда мы делаем проекты и под мобильные платформы. Как правило это заказная разработка, например мобильные приложения для внутренних нужд компании (приложения для сотрудников организации/диспетчеров/водителей, интерактивные учебные пособия, системы учета/бронирования, системы мониторинга и так далее), которые потом обычно и интегрируют с бэкендом на "суровом энтерпрайзе". Этими приложениями пользуется персонал компании, а не простые пользователи. В большинстве случаев они даже не публикуются на маркете.

Естественно из этого есть исключения.
Итак. Да, мы пишем под Android TV. Не знаю, много ли существует мобильных разработчиков в России, которые что-то делают под эту платформу. Понятное дело, есть крупные компании, которые занимаются производством и распространением телевизионного и медиа контента и им сам Бог велел заниматься созданием приложений под эту платформу. Когда-то давно, я тоже делал мобильное приложение для одного популярного в определенных кругах телеканала, но сейчас не об этом.

У нас немного другая история. Мы изначально делали обычное приложение (с кнопочкам и картинками), и по началу думали, что оно будет работать на телефонах, планшетах и китайских свистелках-поделках - "тв приставках". Потом внезапно выяснилось, что платформа Android TV подошла на удивление хорошо для целей проекта.

Про Android TV.

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

1. Нормального эмулятора нет (как обычно). Мы используем оригинальный, привезенный нам из забугорья Android Nexus Player. Настоящий суровый американский Nexus Player с плоской вилкой на 110 В. Без намёка на РОСТЕСТ. Без такого устройства нормальная разработка под Android TV была бы затруднительна. Как и все Nexus-ы он неплохо подходит для целей отладки и разработки. Нет проблем с драйверами, подключением по adb и т.д. Это наше основное девелоперское устройство в этом проекте.

2. Конечно мы проводим бета-тесты еще и на телевизоре Sony. Как выяснилось, это вполне такой обычный телевизор, просто на нем установлен Андроид.
Естественно кроме телевизора и Nexus-а, перед тем как выложить приложение, нам приходится тестировать приложение на десятках разных телефонах и планшетах (те кто пишет под Андроид знают, что это не гипербола, а суровые будни андроид программиста).
Так вот, на телевизоре что-либо дебажить очень не удобно, поэтому опять таки основным устройство у нас является Nexus Player.

3. В какой-то момент Nexus Player внезапно обновился на Marshmallow (Android M) (что в прочем для нексусов вполне типично).
В итоге у нас в руках появился очень редкий, можно сказать "краснокнижный" зверь. Устройство под Android TV (которых мало) и с 6-ой версией Android-а (которых еще меньше). Это прямо-таки удивительное и непредсказуемое создание. Часто было не понятно, особенности в его поведении были связанны с тем, что это был шестой андроид или потому, что это Android TV.

Выводы.

Стоит ли писать под Android TV? Думаю решать нужно исходя из целей проекта. Приведу свои, субъективные размышления на эту тему (актуально на момент публикации этой статьи).

1. ТВ стали смотреть меньше. Возможно я ошибаюсь, но это общий тренд. Я не уверен, что в будущем вообще будут много смотреть телевизоры.
2. Играть на Android TV в игры - сомнительное удовольствие. Я конечно не геймер, но мне кажется, что уж лучше подключить XBox.
3. Платформа требует отдельного внимания и тщательного изучения API.
Текстовый ввод не удобен (т.к. пульт). Если у вас много элементов управления (текстовых полей, кнопок) или используется тач, то придётся все эти моменты перерабатывать.
4. Аудитория. Может я не прав, но если сравнивать со всей массой пользователей андроид устройств её почти нет.
Вживую телефон с андроидом я видел у многих. Телевизор с Android TV только один.
5. Как операционная система Android для телевизоров удобней чем Smart TV. Это лично мое мнение, я могу сравнить, т.к. дома у меня телевизор LG с webOS, а на работе тестируем на Sony с Android-ом.

Мое личное мнение, использовать Android TV приложения, только в том случае, если это действительно вам подходит.
Сил и времени потратите уйму. Если делать по-уму, нужно оптимизировать пользовательский интерфейс (иначе приложением нельзя будет пользоваться), обрабатывать нажатие с пульта, менять систему навигации и многое другое.

Стоит ли следить за развитием платформы? Да, однозначно стоит. Бросить всё, уволиться с работы, продать машину и квартиру и начать делать ещё один клон "ангри бёрдс" под Android TV, в надежде что он вас озолотит — на мой взгляд не самая здравомыслящая идея.

Делать прогнозы сложно, но вряд ли эта платформа даст такой же взрывной рост как и обычные мобильные приложения. Android TV — очень специфичный продукт.
В целом, ситуация с ним чем-то напоминает бум умных часов. Было очень много маркетинговой шумихи, а в итоге никакого стремительно роста никто пока не наблюдает. Эти умные часы я тоже купил, вроде как на всякий случай, думал буду что-то писать под них, но пока они просто лежат у меня в ящике рабочего стола.

PS: Хотел уточнить, чтобы не возникло искаженное понимание ситуации, т.к. я с одной стороны критикую платформу, а с другой стороны пишу что мы под нее активно разрабатываем. Да я считаю, что нет особого смысла в обычных приложениях под Android TV. У нас совсем другой случай, мы делаем специализированный продукт для B2B-сектора по заказу. Другими словами, пишем приложение специально предназначенное для работе на телевизоре.

FWD: Just Say mNo to Hungarian Notation!

mNo

Не могу пройти мимо призыва Джейка Вартона - "Скажи mNo венгерской нотации!".

Во-первых (и это мое личное мнение), использовать такую нотацию в исходниках на Java действительно нелепо.
Во-вторых, когда-то давно я grep-ом проходил исходники андроида (кажется 16-ый API Level) и там нотация не соблюдалась. Более того она была некорректной (статические поля с m-префиксом).

Вартон молодец, что наконец-то поднял эту тему.

В Digital October

Публикую вот такой небольшой анонс (попросили об информационной поддержке из Digital October-а).

digital october conf

Сбербанк-Технологии приглашает на День открытых дверей программы «Единая фронтальная система».

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

Посмотреть вакансии и отправить заявку возможно сейчас на сайте www.efs-conference.ru
Отправляйте заявку прямо сейчас – присоединяйтесь к команде будущего!

Заметка об экспериментах со SnappyDB (NoSQL KeyValue DB под Android)

Небольшая заметка про SnappyDB. Это NoSQL база данных под Android, которая базируется на LevelDB и алгоритме сжатия Snappy.

LevelDB - это key-value база данных. Написана Google-ом для каких-то своих мега проектов.
Snappy - метод сжатия данных, сбалансированный на скорость (т.е. приоритет быстрота, а не степень сжатия). Также написана Google-ом.

Авторы SnappyDB на своем блоге приводят очень привлекательный график сравнивая скорость работы SnappyDB с SQLite.

Все это конечно очень и очень заманчиво, но лично меня она заинтересовала не поэтому. Дело не в скорости и даже не в том, что какие-то части этой БД делал Сам Google, а в более-менее нормальном API.

На практике у меня пока не возникали задачи, в которых нужно было обрабатывать на мобильных устройствах (а я напомню это именно БД для Android) терабайты данных. При этом хранить различные небольшие справочники, настройки, профили и прочую ерунду приходится регулярно.

Конечно по-хорошему можно использовать API Preferenes или SQLite, но в некоторых случаях это не очень удобно.
В частности у SQLite несколько громоздкий API, а в preferences нет удобных методов для сложных выборок по ключам.

Упоминая более-менее нормальное API я имел в виду следующее. Вот что нужно сделать чтобы получить значение по ключу в Preferences (Android API).

  SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(context);
  String username = sharedPref.getString("name", "");

Вот что нужно сделать чтобы получить значение по ключу в Snappy DB.

  DB db = DBFactory.open(context); 
  String username =  db.get("name");

Другими словами, API не такое "многословное" как стандартное Android API.

При этом если есть несколько записей ("name:0","name:1","name:2" и т.д.), то их можно получить как-то так:

  db.findKeys("name:");

Такое "из коробки" в Preferences сделать пока невозможно.

Поэтому мне показалось, что Snappy DB это удобно. Можно использовать например в таких задачах как:
- Сохранить справочников кодов и их описание
- Запоминать время работы каких-то специальных команд или хранить данные по мониторингу
- Идентификатор пользователя и его профиль (например в XML или JSON формате)

В общем все было хорошо, пока не наткнулся на одну приставку под Android TV, на которой был установлен Android M. Так вот, на этом устройстве Snappy DB внезапно стала работать с ошибками. Поскольку БД нативная, а желания дебажить сишный код у меня в последнее время нет, пришлось отказаться от ее использования в текущих проектах.

Мини-пост про scala туториал

Какая-то компания (udemy.com) прислала ссылку на их тьюториал по Scala и попросили разместить её, т.к. нашли мой старый вольный перевод на русский язык мини-учебника по Scala. Думаю поэтому они предположили, что возможно я релевантен или читали этого блога релеванты...

Если честно, лично я делал ту старую публикацию когда вел курс по выбору на физтехе (практикум по программировнию на Scala/Java) и хотел, чтобы у моих студентов был хоть какой-нибудь учебный материал по Scala на русском. Было это лет пять назад.

Сейчас со Scala сталкиваюсь меньше. Изначально в Scala были вещи которых мне очень не хватало в Java. С выходом Java 8 острая необходимость в Scala у меня отпала.
Тем не менее Scala довольно интересный язык, на рынке труда востребован, так что может этот учебник кому-то поможет в его изучении.

Вот ссылка на тот туториал, который мне прислали.

PS: Спросил собираются ли они делать перевод на русский язык, пока жду ответа.

Шаблонизатор mustache и Java.

mustache

В этом году решил изменить вековые традиции и в Java проектах начать использовать вместо велосити (анг. Apache Velocity) популярный хипстерский мусташ (анг. Mustache). Дело в том, что в обычной жизни я, как правило, обхожусь вообще без шаблонизаторов и в простых случаях использую регулярки (regexp-ы). Когда нужно использовать сложные шаблоны для генерации текстовых файлов, то подключаю велосити (просто потому, что "рука набита").

В этот раз нужно было что-то среднее. С одной стороны, не такое тяжеловесное, как велосити, а с другой стороны... не хотелось все делать руками. В итоге выбор пал на Mustache. В историческом обзоре на википедии написано, что изначально Mustache был сделан для рубистов. Тем не менее, позже он стал крайне популярен на фронтендэ у JavaScript-eров (и не только), и сейчас пользу от его использования сложно переоценить. Более того, если зайти на сайт Mustache, то можно узнать, что он реализован на 30+ языках программирования. Естественно Java также присутствует среди них. Если быть точным, то на сайте у них Java на десятом месте (между Objective-C и C#). Стоит отдать должное создателям java версии библиотеки. Хотя она занимает не первое место в списке, но находится, как и документация к ней, в весьма удовлетворительном состоянии. Установить библиотеку и начать с ней работу особого труда не составляет: jar-ик подключается через мавеновский репозиторий.

В качестве отличительных особенностей самого шаблонизатора можно указать следующие:

Во-первых, символами, обрамляющими метки-заполнители (placeholder-ы), являются фигурные скобки "{". Визуально они чем-то напоминают усы (анг. mustache), повернутые на 90 градусов.
Выглядит это так:

Hello {{name}}
You have just won {{value}} dollars!
{{#in_ca}}
Well, {{taxed_value}} dollars, after taxes.
{{/in_ca}}

Во-вторых, основная идея mustache состоит в logic-less подходе. Под этим авторы подразумевают отсутствие различных if-else конструкций, а также циклов. Другими словами, вот такие велоситивские штуки не пройдут:

## Пример для Veloctity
#if( $foo < 10 )
    Go North
#elseif( $foo == 10 )
    Go East
#elseif( $bar == 6 )
    Go South
#else
    Go West
#end

Процессинг шаблонов в таком случае становится очень простым.

1. Берем шаблон.
2. Передаем данные. В случае Java это обычный Map.
3. Смотрим на ключ. Проверяем значение.
3.1. Значение является строчкой? Показываем.
3.2. Значение является пустым списком, false или отсутствует? Не показываем.
3.3. Значение является список (точнее Iterable)? Проходим по каждому элементу списка и применяем для него правило.
3.4. Значение является Callable? Получаем функциональщину.

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

В ней детально изложены различные практические аспекты.
Например:
- Что делать, если вы хотите эскейптить HTML символы? Или не эскейпить?
- Что делать, если вы хотите выводить что-то в случае отсутствия данных (Inverted section)?
- Что делать, если вы хотите делать какую-то "предварительную" обработку данных, перед показом?
и т.д.

В-третьих. Сама структура библиотеки и ее архитектура оказались достаточно гибкими. Например, если есть желание хранить/загружать шаблоны из своего спецхранилища (а не только из файлов или загрузчиков классов), то можно сделать свою реализацию MustacheResolver. Другими словами, архитектура библиотеки более-менее сбалансированная. Не слишком много "абстракций", но при этом сохранилась необходимая гибкость.