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

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

Мой опыт.

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

Кратко, как было у меня. Изначально, кажется в 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.

Другими словами, всегда нужно выбирать компьютер "под себя".

Про успешные компании.

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

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

Если кратко, в Google - стационарные компьютеры с 24 или 30 дюймовыми мониторами. Операционка - Linux (Ubuntu). Если ноутбуки - то МакБуки (Apple) или ThinkPad-ы (Lenovo).
В фейсбуке - макбуки + внешний монитор (DELL).
В Микрософте хорошо заряженные рабочие станции (HP или DELL) с большими мониторами.

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

Тем не менее, нужно всегда соотносить свои желания с реальными возможностями. Как мне сказала одна знакомая, после очередного собеседования в московской конторе: "Я понимаю, когда Гугл или Микрософт спрашивает дебильные вопросы про круглые канализационные люки и у них многоэтапные собеседования.. Но эти ...!? Они же ни разу не гугл, не яндекс и не касперский. Это какая-то шарашка, которая живет на подачки от какого-то инвестора или пилит какой-то безумно мутный проект а-ля 'фейсбук только для белых пушистых животных'. Тем не менее на собеседовании — пафос, понты и идиотские вопросы. Почему так?".

Суть в том, что всегда нужно смотреть сколько есть денег, для чего нужен компьютер и действительно стоит ли он этого? Другими словами стараться не забывать, кто Google, а кто совсем "не Google". Почти всегда, даже на бюджетный компьютер со скромными характеристиками, можно поставить Xubuntu (Ubuntu + XFCE) и работать.

Советы.

Итак, при выборе ноутбука следует обратить внимание на следующие характеристики:
Память. Например 8 Gb, желательно 16 Gb.
Хороший процессор. Например i7.
SSD-диск. Если нет - ничего страшного, но если есть - лучше брать с ним.

(!) Естественно это актуально на момент публикации. Через некоторое время это будут уже устаревшие данные. Для веб-разработки видеокарта не так нужна. Для GameDev - только если разрабатывать определенного вида игры. Если писать под iOS - нужно брать мак.

Если берете ноутбук нужно обратить внимание на клавиатуру. Иногда некоторые кнопки (например Ins) могут требовать дополнительного нажатия Fn-кнопки, в итоге пользоваться некоторыми горячими клавиши (Alt-Ins, Ctrl-Ins и тд) будет неудобно, они из двух буквенных становятся трех буквенными (а это неприятно).

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

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

Вместо послесловия.

Интересно, но маркетологи игнорируют это нишу - ноутбук для программистов. Как правило программисты, у которых есть деньги просто покупают топовый дорогой и модный ноутбук, который априори обладает нормальными техническими характеристиками, например MacBook и ThinkPad. Это что касается уже выше-среднего и продвинутого уровня.

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

Установка и настройка 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 - это неудобный и даже архаичный инструмент.

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