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

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

    	 	 
    
        org.json
        json
        20160810
     
    

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

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