Установка и настройка 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

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

Например для jdk-8u73-linux-x64.tar.gz

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

она должна быть f4f1f7ab1b5986aa2ee2a2f035a2d7a8ab57a673bdee4fc51d8127dd84f423ae

Если в картинках, то так:

download_jdk

Загрузка Oracle JDK

2. Распаковываем:

$tar -xzf jdk-8u73-linux-x64.tar.gz -C /opt

По старой привычке я складываю всё в "/opt". После этого делаю симлинк.

$link -s /opt/jdk1.8.0_74 /opt/jdk

Установка

1. Загружаем Apache Tomcat с официального сайта.
Выбираем нужную версию, копируем ссылку на tar.gz архив и скачиваем.
Например так:

$wget http://apache-mirror.rbc.ru/pub/apache/tomcat/tomcat-8/v8.0.33/bin/apache-tomcat-8.0.33.tar.gz

Проверяем хэши.

$sha1sum apache-tomcat-8.0.33.tar.gz

Я понимаю, что многим это может показаться занудством, но все-таки решил написать, может просто кто-то не знает что он должен это делать.
Вообще можно проверить и так:

$wget https://www.apache.org/dist/tomcat/tomcat-8/v8.0.33/bin/apache-tomcat-8.0.33.tar.gz.sha1
$sha1sum -c apache-tomcat-8.0.33.tar.gz.sha1

Тоже самое в картинках:

download_tomcat


Загрузка Apache Tomcat

2. Сервер можно распаковать туда же в /opt.

$tar -xzf apache-tomcat-8.0.33.tar.gz -C /opt
$link -s /opt/apache-tomcat-8.0.33 /opt/tomcat

Также для удобства делаю симлинк, например tomcat, tomcat-dev, tomcat-8, tomcat-not-working и т.д... В зависимости от целей сервера.

Настройка

Переходим в папку /opt/tomcat/bin

Создаем файлик setenv.sh

Записываем в него:

JAVA_HOME=/opt/jdk

Про этот файл можно почитать в документации: RUNNING.txt.
На самом деле, часто некоторые разработчики просто тупо вбивают "JAVA_HOME=...." прямо в catalana.sh.
Дело в том, что проще открыть nano catalana.sh и поправить его, чем создавать setenv.sh (а точнее как-то узнать про его существование), хотя изначально этот файл специально был сделан для того, чтобы менять ключи JVM и различные переменные окружения, и при этом не портить основной запускаемый файл.

Вот выдержка из документации:

Using the "setenv" script (optional, recommended)

Apart from CATALINA_HOME and CATALINA_BASE, all environment variables can
be specified in the "setenv" script. The script is placed either into
CATALINA_BASE/bin or into CATALINA_HOME/bin directory and is named
setenv.bat (on Windows) or setenv.sh (on *nix). The file has to be
readable.

By default the setenv script file is absent. ...

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

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

Кстати заметил интересный момент. При запуске на виртуальном хостинге может быть довольно ощутимая задержка в старте (около минуты).
Не хочется углубляться в детали, но мне помогла установка haveged.

$apt-get install haveged

В принципе это опционально, можно просто подождать и проверить, как всё запустилось на 8080 порту.
Если все хорошо, двигаемся дальше.

Далее создаем специального пользователя для запуска сервера.

$groupadd tomcat
$useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat
$chown -R tomcat:tomcat /opt/tomcat

После этого проверяем, что всё запускается. Например так:

$sudo -u tomcat /opt/tomcat/bin/startup.sh
$tail -f /opt/tomcat/catalina.log

Ждем пока не появится надпись, что сервер успешно запустился.

Дальше попробуем запустить на 80-ом порту. Поскольку для запуска на 80-ом порту нужен рут, а запускать из под рута это нарушение "техники безопасности", то это можно сделать быстрым хаком, перенаправив порты.

$iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080

Естественно нужно убедиться, что у вас не установлен уже какой-нить веб-сервер (например apache или nginx), который работает на 80-ом порту.

Проверяем, что все нормально и если всё хорошо - сохраняем правило переброса портов.

$invoke-rc.d iptables-persistent save

Если сохранялка iptables не установлена - устанавливаем:

$apt-get install iptables-persistent

Собственно говоря всё.

Теперь о том, на что скорее всего обратят внимание профессиональные системные администраторы.

1. Tomcat заводят через mod_jk за Apache HTTPD или за Nginx (через reverse proxy).
Это дает возможность разделить статику, балансировать нагрузку и делать многие другие полезные штуки. Это круто в продакшене, но в девелоперской конфигурации это ещё один слой который не всегда упрощает отладку и разработку.
В принципе в настройке ничего сложного нет, но всё равно нужно будет покурить документацию. Раньше я предпочитал связку через mod_jk, теперь чаще сталкиваюсь с Nginx.

2. Нужно сделать запуск Tomcat-а как службу. Это не паранойя, а здравый смысл. По-крайней мере если не дай Бог сервер перезапустится, не нужно будет в ручную его запускать.

3. Правильные сисадмины разводят файлы томката по правильным папкам (/etc, /var/log и т.д.) и более деликатно относятся к правам доступа к конфигурационным файлам (и не только).
Можно посмотреть, как это делается через apt-get install tomcat8.

4. Не буду отрицать, что у многих /opt - помойка в которой лежит всякое барахло.
Тем не менее, если это мой персональный сервер, то это не помойка, а мой личный склад программ.

5. Хорошие сисадмины настраивают iptables и прикрывают 8080 порт извне. Точнее они прикрывают все порты, к которым не нужен доступ из вне.

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

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

- Не запускать от рута (даже если нужен 80-ый порт).
- Закрывать доступ к служебным портам.
- Не оставлять дефолтных паролей.
- Не запускать непонятных и непроверенных программ.

В идеале этим нужно заниматься у себя в песочнице, но часто такие вещи нужно уметь делать и в реальном мире.
Да и вот мой реферал на DigitalOcean, для всяких пробных веб-проектов на Java я пользуюсь их хостингом. Раньше пользовался brim.ru, они наверное самый известный java-хостинг в России.

PS: Если совсем не терпится и хочется сделать совсем всё по-быстрому, то можно запустить в два-три шага:
1. Через apt-get поставить tomcat8
2. Загрузить свой ROOT.war
3. Если нужно пробросить порт.

Про 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. Другими словами, архитектура библиотеки более-менее сбалансированная. Не слишком много "абстракций", но при этом сохранилась необходимая гибкость.

Android Design Support Library

Наконец Google сделал эту библиотеку с материальными виджетами!

Важно!
Возможно в официальной документации developer.android.com ошибка.
Вместо:
'com.android.support:support-design:22.0.0'

нужно указывать:
'com.android.support:design:22.2.0'

Про Gradle для любопытных.

Предыстория.

Вот раньше был Ant. Простой и понятный инструмент для сборки проектов. Открываешь xml-ку и видишь: здесь мы хотим скомпилировать файлы, здесь скопировать всё в папку dist, а здесь сделать jar-ик.

Потом придумали Maven. Это была небольшая революция. Искать и подключать популярные библиотеки стало намного проще. Все стали использовать приблизительно одинаковую структуру проектов (исходники хранились в одной папке, конфигурационные файлы - в другой, тесты - в третьей).

В результате, в некоторых программерских компаниях разработчиков стали насильно пересаживать на Maven. Так наступило время, в течение которого процесс сборки проектов для некоторых программистов был окутан туманом.

Разобраться, как работает Maven; понять, что означают все эти тэги – было весьма затруднительно. Всё взаимодействие ограничивалось, как правило, запуском команды mvn clean install. Для многих это действие означало что-то похожее на взмах волшебной палочки с параллельным произнесением заклинаний: "Expelliarmus" или "Avada Kedavra".

Любая проблема, требующая каких-либо нестандартных исправлений в pom.xml, первым делом решалась поиском "нужного заклинания" в stackoverflow или Google. Главная причина недовольства, которое высказывали многие программисты, что не понятно как и в какой последовательности всё работает. Например, что нужно сделать, чтобы просто скопировать файлик и затем выложить его на ftp (или запустить обфускатор)?

Тем не менее, Maven постепенно занял свое место в умах людей. Кто-то из любопытствующих и упорных в итоге разобрался в его внутреннем устройстве. Кто-то просто свыкся. Но время идет, мода меняется. Находятся люди, для которых уже и Мaven - это неудобный и даже архаичный инструмент.

Время не щадит никого...
Читать далее...

Практикум по программированию. Beta.

Мы начинаем курс Java/Android в рамках программы Weekend Coding Lab.
Друзья из коворкинга убедили меня, что возможно это будет интересно и востребовано.

Во-первых Java сама по себе востребована, во-вторых разработка мобильных приложений/игрушек Android тоже много кому интересна.
Начинаем уже в ближайшую субботу. Группа небольшая, предварительно уже часть людей записалось, просто разместить объявление у себя в блоге забыл.
Исправляюсь...

ВНИМАНИЕ, АНОНС!
logo

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

Сегодня Java - это более 9 миллионов разработчиков по всему миру, повсеместный спрос на рынке корпоративного ПО, при этом - безудержный спрос на специалистов на рынке труда и топовые зарплаты в рейтингах профессий.

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

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

Студент знай! 
      Java - это не только скучное корпоративное программное обеспечение для банков и заводов.
      Java - это язык программирования под Android!

Этим мы и займемся, освоив основные принципы и написав свое приложение под эту замечательную платформу.

Запись на курс по телефону: 8 925 508 59 48 (Ирина)
Занятия по субботам с 11:00 (4 ак. часа) в коворкинге.
Описание программы: http://goo.gl/iJbnAT