воскресенье, 20 марта 2016 г.

JVM параметры для тонкой настройки сборщика мусора

Совсем недавно столкнулся с необходимостью уменьшения паузы "stop world" во время сборки мусора. Во время копания в данном вопросе, открыл для себя множество интересных параметров jvm. Чтобы знания не потерялись, решил зафиксировать их в табличку.

пятница, 26 февраля 2016 г.

Rest сервис на Netty

netty framework logo
Недавно познакомился с фреймворком Netty. В традиционной модели на каждое соединение создается один поток, который его обрабатывает. Это приводит к росту нагрузки на CPU и объема потребляемой памяти. Netty использует другой подход, позволяющий обрабатывать одновременно количество соединений большее, чем количество запущенных потоков. Реализован он с использованием библиотеки java.nio. В данной статье, я опишу как Netty работает и расскажу как реализовать с его помощью простой REST сервис.

вторник, 23 февраля 2016 г.

Коротко: Экстремальное программирование

экстремальное программирование

Вступление.

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

Основные моменты.

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

четверг, 11 февраля 2016 г.

10 заповедей Zen программиста

  1. Внимательность.

    Если вы работаете над решением задачи, делаете её хорошо,  на столько насколько вы можете. Не переключайтесь на другие вещи. Работайте только над чем то одним, в один момент времени. Вы не станете быстрее, если будете работать в многозадачном режиме. Если вы работаете над несколькими задачами, вы раньше устанете и сделаете больше ошибок и потратите больше времени на переключение между задачами. Это применимо к различным областям, не только к программированию.
    zen программист
    Кодо Саваки говорил: "Если вам нужен сон, спите". Не планируйте процесс разработки, когда вы пытаетесь уснуть. Если вы пишете код, пишите. Не отвлекайтесь - пишите код. Если вы устали на столько, что не можете программировать - спите.
  2. Держите разум чистым.

    Перед тем как вы приступите к работе, очистите голову от лишних мыслей. Оставьте в стороне посторонние мысли, что занимали вас. Если у вас проблемы, не позволяйте им влиять на вас. Часто, эти проблемы решаемы. Редко встречаются те, от которых тяжело на столько, что нельзя работать. Когда вы погружаетесь в работу, внешний мир отойдет на второй план. Перестаньте читать email рассылку.Там нет ничего важного - вы сможете это сделать позже. Выключите программы, которые наполняют мозг дерьмом: закройте twitter, facebook, почтовый клиент. Переведите телефон в беззвучный режим и перестаньте держать его в руках, пусть он лежит в кармане. Вы скажите, что это похоже с первым советом, отчасти, но они отличаются одним ограничением: “Не используйте устройства перед работой и во время обеда.” Они связывают вас с внешним миром и доставляют вам новые проблемы или информацию, которая требуют внимания.
    Держите разум в состоянии, похожем на то, когда вы только что проснулись. Если не получается, то спорт может в этом помочь (я бегаю на длительные дистанции). Если вы чувствуете себя бодрым и свежим, вы работаете лучше, вы можете работать на пределе. Закончить рабочий день с головой в которой полный беспорядок, сомнительное удовольствие. Twitter и Компания потребляют много энергии. Не тратьте на них время, может только минуту, не более.

среда, 10 февраля 2016 г.

Хроника будней java EE разработчика

Однажды при деплои на тестовый стенд обнаружилась такая ошибка NoSuchMethodException. Просмотр логов дал следующую информацию:


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

понедельник, 25 января 2016 г.

Collect своими руками

После выхода java 8 появилась возможность писать в pipeline стиле. Т.е. создавать последовательность операций которые будут обрабатывать элементы из некоторого источника, будь то коллекция, бесконечная и конечная генерирующая функция, строки из файла и пр. Это тема достаточно обширная и она не будет освещена в данном топике. Расскажу про collector'ы. Это такие объекты с помощью которых, можно привести результат обработки элементов к определенному виду. Существует несколько встроенных, в классе java.util.stream.Collectors. Например, там есть toList, он создает список из элементов потока. Есть и более сложные, например, groupingBy, группирующий элементы по определенному критерию. Мы же напишем свой, который будет группировать строки по начальным буквам.

четверг, 17 декабря 2015 г.

Коротко: Методология SCRUM

Вдохновленный прочтением "Scrum. Революционный метод управления проектами", хочется немного подвести итоги и написать об основных моментах методологии scrum.

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

Проектирование -> Дизайн пользовательского интерфейса -> Написание кода -> Тестирование.


Чем же плох такой подход?