Месяц: Ноябрь 2016

Рубрики
3. Инструментарий Java

Про настройку шрифтов в 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.
Итак чуть более подробный пересказ, что нужно делать.

Продолжить чтение "Про настройку шрифтов в IDE (Netbeans) под Linux."
Рубрики
Java

Про 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-ом.